bcd 16 bits to bin

--- In p..., "pseakins" wrote:
>
> --- In p..., Fagundes Elrica
> wrote:
> > But if my number is a 16 bits value?
> > Example= 1320 (bcd) = 528 (hex) --- How i do the conversion??
>
> Thing is. A BCD number is already represented in Hex. So 1320 (bcd) -
> is 0x1320. In decimal that would be 4896.
>
> http://en.wikipedia.org/wiki/Binary-coded_decimal
>

I don't think so...

A BCD number and a hex number would be quite different. The BCD
number 1320 ordinarily represents the value 1320 decimal by convention
- it is just represented in nibble form. IIRC, the 8080 would
actually do arithmetic on BCD numbers with the DAA (Decimal Adjust
Accumulator) instruction (there seems to be some debate as to whether
it was implemented correctly). In fact, the IBM 1620 did all of its'
calculations using BCD numbers.

The hex value 0x1320 would represent 4896 decimal as indicated.

Richard Start a New Thread

Richard,

You are way off the mark. Please do a bit of googling. Did you look
at the wiki reference I included?

The number 1320 when represented in BCD is 0x1320. That's what BCD
is. Binary coded decimal. A decimal value 0 to 9 in each of the four
nybbles.
--- In p..., "rtstofer" wrote:
>
> --- In p..., "pseakins" wrote:
> >
> > --- In p..., Fagundes Elrica
> > wrote:
> > > But if my number is a 16 bits value?
> > > Example= 1320 (bcd) = 528 (hex) --- How i do the conversion??
> >
> > Thing is. A BCD number is already represented in Hex. So 1320
(bcd) -
> > is 0x1320. In decimal that would be 4896.
> >
> > http://en.wikipedia.org/wiki/Binary-coded_decimal
> > I don't think so...
>
> A BCD number and a hex number would be quite different. The BCD
> number 1320 ordinarily represents the value 1320 decimal by
convention
> - it is just represented in nibble form. IIRC, the 8080 would
> actually do arithmetic on BCD numbers with the DAA (Decimal Adjust
> Accumulator) instruction (there seems to be some debate as to
whether
> it was implemented correctly). In fact, the IBM 1620 did all of
its'
> calculations using BCD numbers.
>
> The hex value 0x1320 would represent 4896 decimal as indicated.
>
> Richard
> Start a New Thread

--- In p..., "pseakins" wrote:
>
> Richard,
>
> You are way off the mark. Please do a bit of googling. Did you look
> at the wiki reference I included?
>
> The number 1320 when represented in BCD is 0x1320. That's what BCD
> is. Binary coded decimal. A decimal value 0 to 9 in each of the four
> nybbles.

I agree that each decimal digit is encoded in a 4 bit nibble - no
question about that. However, there is no way in the world that 1320
(BCD) is equivalent (or equal) to 0x1320 because that is a radix 16 value.

The point is that the '0x' part specifies a hexadecimal constant (by
convention) and while the nibbles are the same, the value implied is not.

It isn't the electrical state of the bits that is the issue, it is
what they 'mean'. Each BCD nibble is a power of ten, not a power of 16.

There would be no conversion necessary to change 0x1320 to binary.
But there certainly is a little work involved in converting 1320 (BCD).

Richard Start a New Thread

> --- In p..., "pseakins" wrote:
>>
>> Richard,
>>
>> You are way off the mark. Please do a bit of googling. Did you look
>> at the wiki reference I included?
>>
>> The number 1320 when represented in BCD is 0x1320. That's what BCD
>> is. Binary coded decimal. A decimal value 0 to 9 in each of the four
>> nybbles.
>
> I agree that each decimal digit is encoded in a 4 bit nibble - no
> question about that. However, there is no way in the world that 1320
> (BCD) is equivalent (or equal) to 0x1320 because that is a radix 16 value.
>
> The point is that the '0x' part specifies a hexadecimal constant (by
> convention) and while the nibbles are the same, the value implied is not.
>
> It isn't the electrical state of the bits that is the issue, it is
> what they 'mean'. Each BCD nibble is a power of ten, not a power of 16.
>
> There would be no conversion necessary to change 0x1320 to binary.
> But there certainly is a little work involved in converting 1320 (BCD).
>
> Richard

I agree with Richard here. You can encode hex into the BCD format and
that would be fine, however, BCD is specifically intended for decimal
(base 10) numbers for those processors that do decimal math (do any do
that any more anyway?) BCD is not hex, that would be BCH, if such a
thing exists.

DLC
--
Dennis Clark Start a New Thread

--- In p..., dlc@... wrote:
>
> > --- In p..., "pseakins" wrote:
> >>
> >> Richard,
> >>
> >> You are way off the mark. Please do a bit of googling. Did you look
> >> at the wiki reference I included?
> >>
> >> The number 1320 when represented in BCD is 0x1320. That's what BCD
> >> is. Binary coded decimal. A decimal value 0 to 9 in each of the four
> >> nybbles.
> >
> > I agree that each decimal digit is encoded in a 4 bit nibble - no
> > question about that. However, there is no way in the world that 1320
> > (BCD) is equivalent (or equal) to 0x1320 because that is a radix
16 value.
> >
> > The point is that the '0x' part specifies a hexadecimal constant (by
> > convention) and while the nibbles are the same, the value implied
is not.
> >
> > It isn't the electrical state of the bits that is the issue, it is
> > what they 'mean'. Each BCD nibble is a power of ten, not a power
of 16.
> >
> > There would be no conversion necessary to change 0x1320 to binary.
> > But there certainly is a little work involved in converting 1320
(BCD).
> >
> > Richard
>
> I agree with Richard here. You can encode hex into the BCD format and
> that would be fine, however, BCD is specifically intended for decimal
> (base 10) numbers for those processors that do decimal math (do any do
> that any more anyway?) BCD is not hex, that would be BCH, if such a
> thing exists.
>
> DLC
> --
> Dennis Clark
>

Oddly enough, the ATmega128 (and I suppose the entire family) has a
'Half Carry Flag' to support BCD arithmetic and includes the
appropriate branch on condition for the flag.

I don't know of any current computers that natively use BCD. Even the
1620 didn't have a base 10 ALU. It used lookup tables.

In fact, if I had to do a 4 digit BCD to binary conversion, I
certainly wouldn't do 3 16-bit multiplies by constants. I would do a
table lookup in 3 tables for the high order 3 digits.

The problem for the PIC is that 16 bit multiplication is a lengthy
operation. Even shifting 16 bit values is time consuming.

It still requires isolating the nibbles but this is easy with SWAPF.
Then too, the tables will have 2 byte entries but that isn't too
inconvenient.

Heck, it's easy in C. The assembly language details are a little bit
more sticky. I think I would first code it in C and look at the
resulting assembly code. If it wasn't too bloated, I would leave it
alone. Otherwise, I would write this in assembly language because I
can't imagine it taking more than 50 lines, if that. Just a bunch of
FSR, INDF, SWAPF and ADDWF stuff.

Richard Start a New Thread

Yes, but the 18 series has hardware 8x8 multiply in the ALU.
A 8x8 takes only one cycle.
This can be used for 8x8 or higher and it speeds up the process
10-60 times. Another good reason to use the PIC18 over the
smaller less capable (PIC16) chips.

I have made a couple of ASCII/BCD/BIN routines for handeling very large
numbers,
see headers below. There are a lot of math in these but still pretty
fast I think.
Still this type of routines are usually the slowest part of the program
where I've used them.

;******************************************************************************

ASCIIBCD2BIN24
;8 digit signed ASCII to BIN conversion routine
;ASCII input range is "-8388608" to "16777215"
;Any other data will result in garbage!
;Enter with ASCII BCD in ASCIIB7:ASCIIB0.
;Exits with binary in ASCIIB3:ASCIIB0. ASCIIB7:ASCIIB4 is garbage.
;Uses 6 temporary locations. Program memory: 412bytes. Cylcles approx.
495.
;VAR: ASCIIB7:ASCIIB0. TEMP3:TEMP0. MULCNT. BCDSIGN.
;Destroys: WREG. TEMP3:TEMP0. MULCNT. BCDSIGN.
;******************************************************************************

;*********************************************************************************

BIN2ASCIIBCD
;24bit BIN to signed ASCII BCD conversion routine
;BIN input range is "800000" to "7FFFFF"
;Output will be "-8388608" to " 8388607"
;Enter with BIN in ASCIIB2:ASCIIB0
;Exit with signed ASCII BCD in ASCIIB7:ASCIIB0
;VAR: ASCIIB7:ASCIIB0. BCDA3:BCDA0
;Destroys: WREG. BSR. INDF2. FSR2H:FSR2L. BCDA3:BCDA0
;Program memory: 202bytes. Cylcles approx. 1485.
;NOTE: due to indexed addressing BCDA3 MUST start at address 0X100 !!
;Example numbers:
;-8388608d0000h, -0000001dFFFFh, 0000000d0000h,
+0000001d0001h, +8388607dFFFFh
;*********************************************************************************

rtstofer wrote:

> ..............The problem for the PIC is that 16 bit multiplication is
> a lengthy
> operation. Even shifting 16 bit values is time consuming.
>
> ...........
>
> Richard
--
*******************************************
VISIT MY HOME PAGE:

LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen Start a New Thread

Hi-
Don't have the code with me here, but in general what I've found to
do the BCD to bin conversion is to clear an accumlating
register pair of registers.

For the 4 BCD digits, For each of the thousand's digits, add a
binary 1000(base ten) i.e. 0x03E8 and decrement the thousand digit.
Repeat until the thousand is exhausted. For example if the thousand
BCD digit is 5, add the 0x03e8 5 times. Once in each loop until
there are no more thousands left. Continue the process with the
hundreds digit adding 100(base 10) 0x64 each time. Then with the
10's 0x0A. For the digits, just add.

Worst case it will be 9 + 9 + 9 + 1 double precison adds for the PIC
code. Seems to work pretty quickly for me.

It's probably easier to code it up for your particular case that you
have in hand rather than try to shuffle around digits and stuff trying
to get all the data in the right place using a "canned" routine.

Best of luck!

Cheers,

Rich S.

--- In p..., "falcosms" wrote:
>
> Hi
>
> I need a code example for conversion of a 16 bits BCD data in BIN , in
> C (ccs PIC)
>
>
>
> []s
>
>
>
> Marcelo
> Start a New Thread

1320 BCD and 1320 hex is the same thing. It is very common for
beginners to get confused with the representation of register values.
The original poster was confused, I am simply trying to set him
straight. He thought that 1320 bcd equals 528 hex - it doesn't.

A BCD value of 1320 is stored in a 16 bit register (or high level
variable) in binary as 0001001100100000. No one can argue with this
fact. If you display the contents of that register in hex the value is
1320. If you display it in decimal it is 4896. The method of displaying
it is entirely up to the programmer and/or his debugging tools.
Depending on the radix of those tools it might be displayed in
different ways. Whether your processor has a few BCD related
instructions is irrelevant.

Now all the little boys who want to argue - please don't. I was doing
this stuff while your PARENTS were still in high school. I am right and
you are wrong.

> I agree that each decimal digit is encoded in a 4 bit nibble - no
> question about that. However, there is no way in the world that 1320
> (BCD) is equivalent (or equal) to 0x1320 because that is a radix 16
value.
>
> The point is that the '0x' part specifies a hexadecimal constant (by
> convention) and while the nibbles are the same, the value implied is
not.
>
> It isn't the electrical state of the bits that is the issue, it is
> what they 'mean'. Each BCD nibble is a power of ten, not a power of
16.
>
> There would be no conversion necessary to change 0x1320 to binary.
> But there certainly is a little work involved in converting 1320
(BCD). Start a New Thread

--- In p..., "pseakins" wrote:
>
> 1320 BCD and 1320 hex is the same thing. It is very common for
> beginners to get confused with the representation of register values.
> The original poster was confused, I am simply trying to set him
> straight. He thought that 1320 bcd equals 528 hex - it doesn't.

It does too... As long as I define 1320 (BCD) as 1*10^3 + 3*10^2 + 2
* 10^1 + 0 * 10^0 it is equal to 1320 decimal and any subsequent
conversion to binary is whatever it is: 0x528 or 10100101000b, whatever

Each nibble is a decimal value and its' position is a power of ten.
Bit positions are NOT a power of 2 in this case.
>
> A BCD value of 1320 is stored in a 16 bit register (or high level
> variable) in binary as 0001001100100000. No one can argue with this
> fact.

True

> If you display the contents of that register in hex the value is
> 1320.

Also true

> If you display it in decimal it is 4896.

Also true

> The method of displaying
> it is entirely up to the programmer and/or his debugging tools.
> Depending on the radix of those tools it might be displayed in
> different ways. Whether your processor has a few BCD related
> instructions is irrelevant.

Yes, it does matter. It gets to the issue of EQUAL. 1320 BCD doesn't
EQUAL 4896 or 0x1320 because it isn't a base 2 (or 16) number. It
EQUALS 1320 decimal or 0x528 after it is properly converted.

>
> Now all the little boys who want to argue - please don't. I was doing
> this stuff while your PARENTS were still in high school. I am right and
> you are wrong.

Doesn't mean all that much really. I've been messing around with this
stuff for nearly 40 years myself.

Take 0x1320 and add 0x700 and you get 0x1A20. Suddenly the hex
representation doesn't look so good.

Take 1320 (BCD) and add 700 (BCD) and you get 2020 (BCD) and it is the
fact that a Decimal Adjust Accumulator (DAA) instruction exists that
allows an otherwise binary arithmetic unit to come up with this result
by noting that the hex 'A' is not a valid decimal digit and correcting
accordingly.

Yes, 1320 (BCD) looks like 0x1320 when the register contents are
viewed but it doesn't EQUAL 0x1320 and you certainly can not do
arithmetic on the basis that it is equal.

Richard Start a New Thread

Heh..
The before mentioned confusion about BCD conversions is cleary out in
the open now :o)

I fully support Richard's view of these things.
rtstofer wrote:

> --- In p..., "pseakins" wrote:
> >
> > 1320 BCD and 1320 hex is the same thing. It is very common for
> > beginners to get confused with the representation of register
> values.
> > The original poster was confused, I am simply trying to set him
> > straight. He thought that 1320 bcd equals 528 hex - it doesn't.
>
> It does too... As long as I define 1320 (BCD) as 1*10^3 + 3*10^2 + 2
> * 10^1 + 0 * 10^0 it is equal to 1320 decimal and any subsequent
> conversion to binary is whatever it is: 0x528 or 10100101000b,
> whatever
>
> Each nibble is a decimal value and its' position is a power of ten.
> Bit positions are NOT a power of 2 in this case.
>
> >
> > A BCD value of 1320 is stored in a 16 bit register (or high level
> > variable) in binary as 0001001100100000. No one can argue with this
> > fact.
>
> True
>
> > If you display the contents of that register in hex the value is
> > 1320.
>
> Also true
>
> > If you display it in decimal it is 4896.
>
> Also true
>
> > The method of displaying
> > it is entirely up to the programmer and/or his debugging tools.
> > Depending on the radix of those tools it might be displayed in
> > different ways. Whether your processor has a few BCD related
> > instructions is irrelevant.
>
> Yes, it does matter. It gets to the issue of EQUAL. 1320 BCD doesn't
> EQUAL 4896 or 0x1320 because it isn't a base 2 (or 16) number. It
> EQUALS 1320 decimal or 0x528 after it is properly converted.
>
> >
> > Now all the little boys who want to argue - please don't. I was
> doing
> > this stuff while your PARENTS were still in high school. I am right
> and
> > you are wrong.
>
> Doesn't mean all that much really. I've been messing around with this
> stuff for nearly 40 years myself.
>
> Take 0x1320 and add 0x700 and you get 0x1A20. Suddenly the hex
> representation doesn't look so good.
>
> Take 1320 (BCD) and add 700 (BCD) and you get 2020 (BCD) and it is the
>
> fact that a Decimal Adjust Accumulator (DAA) instruction exists that
> allows an otherwise binary arithmetic unit to come up with this result
>
> by noting that the hex 'A' is not a valid decimal digit and correcting
>
> accordingly.
>
> Yes, 1320 (BCD) looks like 0x1320 when the register contents are
> viewed but it doesn't EQUAL 0x1320 and you certainly can not do
> arithmetic on the basis that it is equal.
>
> Richard
>
--
*******************************************
VISIT MY HOME PAGE:

LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen Start a New Thread