473,730 Members | 4,290 Online

# BCD List to HEX List

Hi,

I'm looking for an algo that would convert a list such as:

I'm using python to prototype the algo: this will move to C in an embedded
system where an int has 16 bits - I do not wish to use any python library.

l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678
l2 = func (l1)
# l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687
Regards,

Philippe

Jul 30 '06
67 6295
Philippe Martin wrote:
John Machin wrote:
Philippe Martin wrote:
Hi,

I'm looking for an algo that would convert a list such as:
Such as what?
>
I'm using python to prototype the algo: this will move to C in an
embedded system where an int has 16 bits - I do not wish to use any
python library.

l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678
Does it??? How do you represent the decimal number 12349678, then?
l2 = func (l1)
# l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687
I'm sorry, but very little of that makes any sense to me:

1. I thought BCD meant something very much like this:
http://en.wikipedia.org/wiki/Binary-coded_decimal

2. >>[0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687
[1, 2, 13, 6, 8, 7]

So [1], [2], [6] are unchanged, [3, 4] -[13] (or maybe [3, 4, 5] ->
13), and [7, 8] -[8,7].

I doubt very much that there's an algorithm to do that. What is the
relationship between 1234(maybe 5)678 and 0x12D687??? I would expect
something like this::

0x12345678 (stored in 4 bytes 0x12, ..., 0x78) -- or 0x21436587
or
0x012345678s (where s is a "sign" nibble; stored in 5 bytes 0x01,
..., 0x8s)

IOW something regular and explicable ...

3. Perhaps it might be a good idea if you told us what the *real*
problem is, including *exact* quotes from the manual for the embedded
system. You evidently need/want to convert from one representation of
signed? unsigned? integers to another. Once we all understand *what*
those representations are, *then* we can undoubtedly help you with
pseudocode in the form of Python code manipulating lists or whatever.

Cheers,
John

Hi,

From my answer to Marc:
My apologies, I clearly made a mistake with my calculator, yes the
resulting
array I would need is [0xb,0xc,0x6,0x1 ,0x4,0xe]
"Clearly"? I don't think that word means what you think it means :-)

All you need is something like the following. You will need to use
"long" if the C "int" is only 16 bits.

C:\junk>type bcd.py
def reconstitute_in t(alist):
reg = 0 # reg needs to be 32-bits (or more)
for digit in alist:
assert 0 <= digit <= 9
reg = reg * 10 + digit
return reg

def make_hex(anint) :
# anint needs to be 32-bits (or more)
result = []
while anint:
result.append(a nint & 0xF)
anint >>= 4
return result

def reverse_list(al ist):
n = len(alist)
for i in xrange(n >1):
reg1 = alist[n - 1 - i]
reg2 = alist[i]
alist[i] = reg1
alist[n - 1 - i] = reg2

C:\junk>
C:\junk>python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]
on win32
>>import bcd
num = bcd.reconstitut e_int([1,2,3,4,5,6,7,8])
num
12345678
>>result = bcd.make_hex(nu m)
result
[14, 4, 1, 6, 12, 11]
>>bcd.reverse_l ist(result)
result
[11, 12, 6, 1, 4, 14]
>>['0x%x' % digit for digit in result]
['0xb', '0xc', '0x6', '0x1', '0x4', '0xe']
>>^Z
HTH,
John

Jul 30 '06 #11
Dennis Lee Bieber wrote:
On Sun, 30 Jul 2006 16:39:47 -0500, Philippe Martin
<pm*****@snakec ard.comdeclaime d the following in comp.lang.pytho n:
>>
My apologies, I clearly made a mistake with my calculator, yes the
resulting array I would need is [0xb,0xc,0x6,0x1 ,0x4,0xe]
Take note that this is NOT a BCD form for "12345678". BCD (typically
packed) uses four bits per decimal digit. That would make "12345678" =>
0x12, 0x34, 0x56, 0x78 (ignoring matters of big/little end).

The binary representation of 12345678, in bytes, is 0xBC, 0x61, 0x4E

0xb, 0xc... is really 0x0B, 0x0C... 8-bits per byte, with MSB set to
0000.

Compare:
BCD 00010010 00110100 01010110 01111000
binary 10111100 01100001 01001110
your 00001011 00001100 00000110 00000001 00000100 00001110
--
Wulfraed Dennis Lee Bieber KD6MOG
wl*****@ix.netc om.com wu******@bestia ria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: we******@bestia ria.com)
HTTP://www.bestiaria.com/
Yes I realized that after writing it.

Regards,

Philippe

Jul 30 '06 #12
Philippe Martin <pm*****@snakec ard.comwrites:
I'm just using Python to prototype, so I cannot use any of these great
features of the language.
I think when writing a prototype, you should use whatever features you
want, except maybe at the upper levels of program organization. The
idea of prototyping is to get something done quickly, that you can use
for integration and user testing earlier in the development cycle. So
you should use whatever Python features are available to make
prototyping faster. You shouldn't expect the prototype code to
closely match the final C code, if that slows you down. If you want
code that closely resembles C code, you might as well write in C
directly.
Jul 30 '06 #13
Paul Rubin wrote:
Philippe Martin <pm*****@snakec ard.comwrites:
>I'm just using Python to prototype, so I cannot use any of these great
features of the language.

I think when writing a prototype, you should use whatever features you
want, except maybe at the upper levels of program organization. The
idea of prototyping is to get something done quickly, that you can use
for integration and user testing earlier in the development cycle. So
you should use whatever Python features are available to make
prototyping faster. You shouldn't expect the prototype code to
closely match the final C code, if that slows you down. If you want
code that closely resembles C code, you might as well write in C
directly.

Some truth in that.

Thanks,

Philippe

Jul 30 '06 #14
Philippe Martin wrote:
>
Thanks John, I do not have a long available on the device: stuck with 16
bits.
What does "available on the device" mean? Having a "long" is a property
of a C complier, not a device. What is the CPU in the device? What is
the C compiler you are using? N.B. Last time I looked, gcc would
generate code for just about any CPU since Babbage's. I would expect
*any* C compiler that is targetting a 16-bit CPU to provide a 32-bit
long and generate reasonably efficient code for most simple operations.
Is there no library of utility routines for *elementary* base
conversions such as you need? Is there no 32-bit-arithmetic-simulation
package?

Jul 30 '06 #15
John Machin wrote:
Philippe Martin wrote:
>>
Thanks John, I do not have a long available on the device: stuck with 16
bits.

What does "available on the device" mean? Having a "long" is a property
of a C complier, not a device. What is the CPU in the device? What is
the C compiler you are using? N.B. Last time I looked, gcc would
generate code for just about any CPU since Babbage's. I would expect
*any* C compiler that is targetting a 16-bit CPU to provide a 32-bit
long and generate reasonably efficient code for most simple operations.
Is there no library of utility routines for *elementary* base
conversions such as you need? Is there no 32-bit-arithmetic-simulation
package?
Hi John,

I'm working on an embedded 8 bit device and have no choice as to which
cross-compiler to use: in this case the guy knows up to short and that's
it.

Regards,

Philippe

Jul 30 '06 #16
Philippe Martin <pm*****@snakec ard.comwrites:
Thanks John, I do not have a long available on the device: stuck with 16
bits.
Oh, I think I understand now, why you were asking about algorithms.
You really did want something whose intermediate results all fit in 16
bits.

Even if your C compiler doesn't support a long int datatype, it may
have some library functions to do long arithmetic. Look for functions
with names like lmul, ldiv, etc.

Will the decimal digit strings always be 8 digits? If yes, there are
probably a few math tricks you can use to do the hex conversion
simply.
Jul 30 '06 #17
Philippe Martin wrote:
Hi,

I'm looking for an algo that would convert a list such as:

I'm using python to prototype the algo: this will move to C in an embedded
system where an int has 16 bits - I do not wish to use any python library.

l1 = [1,2,3,4,6,7,8] #represents the decimal number 12345678
l2 = func (l1)
# l2 = [0x1, 0x2, 0xD, 0x6, 0x8, 0x7] #represents 0x12D687
Regards,

Philippe
Thanks to all,

I decided to attack the problem another way and change the code in device #2
so it can now take the output from device #1.

As device #2 only needs to compare, add, and subtract the stuff .. it makes
my life much simpler.

Sample (potentially buggy):
l1 = [1,2,3,4]
l2 = [0,2,3,9]
def sup (l1, l2): #assume same length
for i in range(len(l1) ):
if l1[i] l2[i]:
return 1
if l1[i] < l2[i]:
return -1
return 0

def add (l1, l2): #assume same length
r = []
idx = range (len(l1))
idx.reverse()
carry = 0
for i in idx:

if l1[i] + l2[i] 10:
carry = 1
r.insert(0,(l1[i] + l2[i]) % 10)
else:
r.insert(0,l1[i] + l2[i] + carry)
carry = 0
return r

print sup(l1,l2)

Jul 30 '06 #18

Philippe Martin wrote:
John Machin wrote:
Philippe Martin wrote:
>
Thanks John, I do not have a long available on the device: stuck with 16
bits.
What does "available on the device" mean? Having a "long" is a property
of a C complier, not a device. What is the CPU in the device? What is
the C compiler you are using? N.B. Last time I looked, gcc would
generate code for just about any CPU since Babbage's. I would expect
*any* C compiler that is targetting a 16-bit CPU to provide a 32-bit
long and generate reasonably efficient code for most simple operations.
Is there no library of utility routines for *elementary* base
conversions such as you need? Is there no 32-bit-arithmetic-simulation
package?

Hi John,

I'm working on an embedded 8 bit device and have no choice as to which
cross-compiler to use: in this case the guy knows up to short and that's
it.
What do you mean, no choice? You generate code, you stuff it into the
device, it doesn't give a rat's where the code came from ...

Perhaps we could help you better if you actually answered the
questions, like:
What is the CPU in the device?
What is the C compiler you are using?

Is there an assembler for the CPU that's in the device?

Have you considered asking on a newsgroup where your problem might
actually be on-topic, like:
comp.lang.c
a NG devoted to microprocessors
?

Jul 30 '06 #19
John Machin wrote:
Have you considered asking on a newsgroup where your problem might
actually be on-topic, like:
comp.lang.c
Yes, I came here for the "algorithm" question, not the code result.

Regards,

Philippe

Jul 30 '06 #20

This thread has been closed and replies have been disabled. Please start a new discussion.