I was searching for a binary to BCD conversion routine and found this:
www.piclist.org/techref/postbot.asp?by=time&id=piclist/2002/12/24/164925a
from Bob Ammerman. It appeared to be just what I was looking for but it
'seems' to have a problem. Can anyone tell me what is missing/wrong with this macro
or suggest where I may be going wrong with its use?
The macro was listed as "untested" but it looks like it should work and in
fact does for many, but not all, numbers. 0x2FF, for example, converts
to 00 00 00 00 67. When stepping through the macro on paper, I get the
correct result, 00 00 00 07 67. It's almost as if DAW and/or ADDWFC and/or RLCF isn't working correctly (not likely) or at least not as I expected.
The only change I made to the macro was to substitute RLCF for RLF.
I can probably find or write another binary to BCD conversion
routine but I'd really like to understand what the problem is with this
macro or my use of it.
Thank you
Mike Jones
My code:
-----------------------------------------------------------------
#define bcdbytes 5
#define binbytes 4
; Access Ram 128 Bytes (00h - 7Fh) Bank 0
cblock 0x000
bcdval:bcdbytes
binvar:binbytes
mytemp:1
BinB:4 ; Since binvar is destroyed, BinB is used
; to keep the original around as a sanity check
endc
The following are examples of two binary to BCD conversions with the left
column
showing what the intermediate results should be and the right column showing
what the observed intermediate results were. (Leading additions of zeros
ignored.)
I haven't thought of a way to dig any deeper with my very limited debug
tools but my
first impression is that DAW isn't always generating a carry when I think it
should.
> A little more information;
>
> The following are examples of two binary to BCD conversions with the left
> column
> showing what the intermediate results should be and the right column
showing
> what the observed intermediate results were. (Leading additions of zeros
> ignored.)
> I haven't thought of a way to dig any deeper with my very limited debug
> tools but my
> first impression is that DAW isn't always generating a carry when I think
it {Quote hidden}
> should.
>
> for 0x2FF
> 1 1
> 2 2
> 5 5
> 11 11
> 23 23
> 47 47
> 95 95
> 191 91
> 383 83
> 767 67
> Fails to add and/or convert (daw) 95+95+1 correctly
>
> for 0x8FF
> 1 1
> 2 2
> 4 4
> 8 8
> 17 17
> 35 35
> 71 71
> 143 143
> 287 287
> 575 475
> 1151 951
> 2303 1903
> Fails to add and/or convert (daw) 287+287+1 correctly
>
> Mike Jones
>
> ----- Original Message -----
> From: "Bob Ammerman" <rammermanKILLspamADELPHIA.NET>
> To: <.....PICLISTKILLspam.....MITVMA.MIT.EDU>
> Sent: Monday, February 03, 2003 4:35 AM
> Subject: Re: [PIC]: Binary to Packed BCD Conversion Problem
>
>
> > Jon,
> >
> > Very interesting. I'll take a look at this when I get a chance.
Hopefully
> in
> > the next day or so.
> >
> > Bob Ammmerman
> > RAm Systems
> >
I have some code in assembler released for a 16C74 as part of a glass LCD
project which is a conversion to 5 digit BCD. I believe the leading zeros
where taken care of in different routing (printing to LCD) Good Luck.
{slewrate}
Sorry, I didn't mean to mislead about the 'leading zeros. I was just
referring to the
fact that for the sake of brevity I didn't list the first 20 or so previous
additions of 0+0+carry of zero.
I wrote a routine to convert a bin value to BCD
some time ago. One thing that I missed about the
DAW instruction, is that DAW "Decimal adjust W" when
W containes the result of an addition of two other
values *which both was in BCD format before the addition*.
So you can not add two *binary* values and then use
DAW on the result. You'll get all kinds of funny
results.
(And if one read the data sheet carefully, this is
clearly written there...)
I have not checked is this is the case for your code,
but anyway...
Thanks for the reminder, I made that mistake once or twice myself.
On the assumption that 0x70 and 0x80 are valid packed bcd numbers
I just finished a simple test to isolate the problem. The shortened version
of
the code goes like this;
Test 1:
set binvar = 0x70
after the addwfc, WREG = 0xE0 Carry = 0
after the daw, WREG = 0x40 Carry = 1
So far so good!
Test 2
set binvar = 0x80
after the addwfc, WREG = 0x00 Carry = 1
after the daw, WREG = 0x60 Carry = 0
What happened to the carry bit ?? I rather expected it to still be
there.
In fairness, the data sheet doesn't say much about how or why the
carry bit is affected, it just say that it is affected. There may be other
documents that give more detailed information about the status bits
during and after a 'daw' but I haven't found any yet.
Going back to the original problem: I don't know how completely valid
this is yet but, after a very brief test, it appears that if I save the
carry
bit after the addwfc and restore it after the daw, all may be well.
Looks like one should have to "OR" the C from the ADD
with the C from the DAW and feed the result into the next
ADD...
Would it work if the DAW never clears the C but leave
it set if set before (and set C if needed) ?
Have to check my own routines once again :-(
I did the following :
add_bcd
; add INCH:INCL to BCDH:BCDL
; Adds a BCD coded "increment" to a BCD value.
movf INCL, w ; Load low byte of increment
addwf BCDL, w ; Add to low BCD byte
daw ; Adjust
movwf BCDL ; Store back adjusted low BCD byte
movf INCH, w ; Load high byte of increment
addwfc BCDH, w ; Add to high BCD byte
daw ; Adjust
movwf BCDH ; Store back adjusted high BCD byte
return
This have been working for the values I have tested with.
I my case the "increment" have been powers of 2 between 0x0000
and 0x0512 (coded as BCD). But, using the "right" values, I expect
this code to have the same problem as you are seeing.
>Date: Sun, 2 Feb 2003 22:35:44 -0800
>From: "Jon M (Mike) Jones" <pmjones3spam_OUTATTBI.COM>
>Subject: [PIC]: Binary to Packed BCD Conversion Problem
>
>I was searching for a binary to BCD conversion routine and found this:
>www.piclist.org/techref/postbot.asp?by=3Dtime&id=3Dpiclist/2002/12=
>/24/164925a
>from Bob Ammerman. It appeared to be just what I was looking for but it
>'seems' to have a problem. Can anyone tell me what is missing/wrong with =
>this macro
> or suggest where I may be going wrong with its use?=20
>
I have been using the following routine successfully for some years.
It was adapted from an original algorithm by Bob Fehrenbach, to meet
my internal editing norms.
The macro `movlf' moves literal to freg.
************************************************
BIN2BCD
;Date: Mon, 16 Mar 1998 14:18:12 -0600
;From: Bob Fehrenbach <@spam@bfehrenbKILLspamEXECPC.COM>
;Subject: Re: 32 bits binary to BCD convert?
;>Does anyone know how to convert 32 bits binary to BCD format?
;There probably faster routines but this should do the job.
; Binary - BCD 32 bits
; Input in buff_4 buff_3 buff_2 buff_1 with MSByte buff_4
;
; Converts to *packed* bcd in temp_a(ms), temp_b, temp_c,
;temp_d, temp_e with the most sig in temp_a.
; Handles full range: ff ff ff ff -> 4,294,967,296
; Also uses temp_f and count.
; 2940 cycles including call and return.
;
bcf status, c
movlf 32, scratch_lo
clrf temp_a
clrf temp_b
clrf temp_c
clrf temp_d
clrf temp_e
bin2bcd_loop:
rlf buff_1, same
rlf buff_2, same
rlf buff_3, same
rlf buff_4, same
rlf temp_e, same
rlf temp_d, same
rlf temp_c, same
rlf temp_b, same
rlf temp_a, same
decfsz scratch_lo, same
goto adj_dec
goto done
adj_dec:
movlf temp_e, fsr
call adj_bcd
movlf temp_d, fsr
call adj_bcd
movlf temp_c, fsr
call adj_bcd
movlf temp_b, fsr
call adj_bcd
movlf temp_a, fsr
call adj_bcd
goto bin2bcd_loop
adj_bcd:
movlw h'3'
addwf indf, w
movwf temp_f
btfsC temp_f, 3
movwf indf
movlw h'30'
addwf indf, w
movwf temp_f
btfsC temp_f, 7
movwf indf
return
done: return
************************************************
best regards, John
eMail from the desk of John Sanderson.
JS Controls, PO Box 1887, Boksburg 1460, Rep. of S. Africa.
Tel / Voice / Fax : 011 893 4154
email : jsand @pixie.co.za
Cell : 082 741 6275
Manufacturer & Purveyor of laboratory force testing apparatus and related
products & services.
There are many ways to "emulate" DAW, but it don't
answer the question why DAW works like it does, or
how it should be used properly...
Thanks anyway !
Jan-Erik Söderholm.
John Sanderson wrote :
>I have been using the following routine successfully for some years.
>It was adapted from an original algorithm by Bob Fehrenbach, to meet
>my internal editing norms.
...
...
ATTBI.COM>
