Searching \ for '[PIC]: Binary to Packed BCD Conversion Problem' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Binary to Packed BCD Conversion Problem'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Binary to Packed BCD Conversion Problem'
2003\02\03@013732 by Jon M (Mike) Jones

picon face
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


ExtA1    ; Test Binary to Packed BCD macro
    movf         BinB,w
    movwf      binvar  ; LSB
    movf         BinB+1,w
    movwf      binvar+1
    movf         BinB+2,w
    movwf      binvar+2
    movf         BinB+3,w ; MSB
    movwf      binvar+3

    BIN2BCD binvar,binbytes,bcdval,bcdbytes,mytemp     ; Test

return

A sample of the test results;
; --------------------------------------------------------------------------
                      bcdval                bcdval
binvar             Expected           from macro    Diff
-----------      ------------       -------------  -----
00 00 00 FF    00 00 02 55    00 00 02 55    0
00 00 01 FF    00 00 05 11    00 00 05 11    0

00 00 02 00    00 00 05 12    00 00 05 12    0
00 00 02 0F    00 00 05 27    00 00 05 27    0
00 00 02 F0    00 00 07 52    00 00 01 52    600

00 00 02 FF    00 00 07 67    00 00 00 67    700
00 00 03 FF    00 00 10 23    00 00 10 23    0
00 00 04 FF    00 00 12 79    00 00 12 79    0
00 00 05 FF    00 00 15 35    00 00 01 35    1400

00 00 FF FF    00 06 55 35    00 02 41 35    41,400



--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\03@073801 by Bob Ammerman

picon face
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

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\03@224330 by Jon M (Mike) Jones

picon face
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
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 removed}

2003\02\03@230159 by Ray Gallant

flavicon
face
----- Original Message -----
From: "Jon M (Mike) Jones" <spam_OUTpmjones3TakeThisOuTspamATTBI.COM>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Monday, February 03, 2003 11:41 PM
Subject: Re: [PIC]: Binary to Packed BCD Conversion Problem


> 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}

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}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\02\03@232222 by Jon M (Mike) Jones
picon face
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.

Mike Jones.
{Original Message removed}

2003\02\04@031649 by

flavicon
face
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...

Jan-Erik Söderholm.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2003\02\04@051553 by Jon M (Mike) Jones

picon face
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;

(Note: 18F452 processor, checking apparent addwfc and/or daw problem)

        cblock 0x00
        binvar:1
        bcdval:1
        end

    clrc
    movf         binvar,w
    addwfc     binvar,w
    daw
    movwf      bcdval

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.

Mike Jones

{Original Message removed}

2003\02\04@064634 by

flavicon
face
Interesting...

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.

Gotta think about this a while...

Jan-Erik Söderholm


{Original Message removed}

2003\02\04@065510 by John Sanderson

flavicon
face
Hello Jon & PIC.ers,

>Date:    Sun, 2 Feb 2003 22:35:44 -0800
>From:    "Jon M (Mike) Jones" <pmjones3spamspam_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@bfehrenbKILLspamspamEXECPC.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.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\02\04@065916 by

flavicon
face
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.
...
...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...