Searching \ for '[PIC]: 18Fxxx 16-bit Binary to ASCII conversion' 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=18F
Search entire site for: '18Fxxx 16-bit Binary to ASCII conversion'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 18Fxxx 16-bit Binary to ASCII conversion'
2004\01\04@112033 by Roy J. Gromlich

picon face
Greetings:

I need to Read the 18Fxxx A/D and send the resulting 16-bit number to the UART for output, thus I need to convert 16-bit Binary to ASCII.  I have tried several procedures fromn PIClist but none of them appear to be complete and so far none of them will make it through the PIC assembler (MASM).  I am getting various cryptic messages regarding illegal and/or missing op codes.  I can probably figure this out eventually, but I have a deadline issue and would like to know if ANYONE has a working & tested procedure for the 18Fxxx series chips with sufficient documentation that it can be used without a lot of hacking.

Thanks in advance,
Roy J. Gromlich



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

2004\01\04@113526 by Ken Pergola

flavicon
face
Roy J. Gromlich wrote

> ...I need to convert 16-bit Binary to ASCII...

Hi Roy,

It was not clear what *ASCII representation* you want to display the data
as: binary, hex, decimal (5-digit BCD)?

For example, if your 16-bit binary data in your PIC is 1010110011011100,
which ASCII format to you want to pump out the USART?:

1010110011011100
ACDC
44252


Regards,

Ken Pergola

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

2004\01\04@125936 by Dave Dilatush

picon face
Roy J. Gromlich wrote...

>I need to Read the 18Fxxx A/D and send the resulting
>16-bit number to the UART for output, thus I need to
>convert 16-bit Binary to ASCII.  I have tried several
>procedures fromn PIClist but none of them appear to
>be complete and so far none of them will make it
>through the PIC assembler (MASM).  I am getting various
>cryptic messages regarding illegal and/or missing op
>codes.  I can probably figure this out eventually, but
>I have a deadline issue and would like to know if ANYONE
>has a working & tested procedure for the 18Fxxx series
>chips with sufficient documentation that it can be used
>without a lot of hacking.

The following PIC18F code will convert an unsigned 16-bit integer
in a two-byte variable called Binreg, to unpacked 5-digit BCD in
a 5-byte variable BCDreg (both these variables are stored with
most-significant-byte/digit at the lowest address).

The unpacked BCD then can be converted to ASCII simply by adding
hexadecimal 0x30 to each digit.

Sorry for the lack of comments.  This code has been copied many
times for use on many projects over the years, and the comments
are long gone.  It's based on what I believe is commonly called
the "add-3 algorithm", I remember that much.  And it works.

       UDATA

Count   RES     1   ; loop counter
BCDreg  RES     5   ; 5-digit unpacked BCD output register
Binreg  RES     2   ; 16-bit unsigned binary input register

       CODE

       GLOBAL  UInt16toBCD5, BCDreg, Binreg

UInt16toBCD5

       movlw   16
       movwf   Count
       clrf    BCDreg+0
       clrf    BCDreg+1
       clrf    BCDreg+2
       clrf    BCDreg+3
       clrf    BCDreg+4

loop

       movlw   5
       subwf   BCDreg+0, W
       movlw   3
       btfsc   STATUS, C
       addwf   BCDreg+0, F
       movlw   5
       subwf   BCDreg+1, W
       movlw   3
       btfsc   STATUS, C
       addwf   BCDreg+1, F
       movlw   5
       subwf   BCDreg+2, W
       movlw   3
       btfsc   STATUS, C
       addwf   BCDreg+2, F
       movlw   5
       subwf   BCDreg+3, W
       movlw   3
       btfsc   STATUS, C
       addwf   BCDreg+3, F
       movlw   5
       subwf   BCDreg+4, W
       movlw   3
       btfsc   STATUS, C
       addwf   BCDreg+4, F

       bcf     STATUS, C
       rlcf    Binreg+1, F
       rlcf    Binreg+0, F

       rlcf    BCDreg+4, F
       bcf     STATUS, C
       btfsc   BCDreg+4, 4
       bsf     STATUS, C
       rlcf    BCDreg+3, F
       bcf     STATUS, C
       btfsc   BCDreg+3, 4
       bsf     STATUS, C
       rlcf    BCDreg+2, F
       bcf     STATUS, C
       btfsc   BCDreg+2, 4
       bsf     STATUS, C
       rlcf    BCDreg+1, F
       bcf     STATUS, C
       btfsc   BCDreg+1, 4
       bsf     STATUS, C
       rlcf    BCDreg+0, F

       movlw   0x0F
       andwf   BCDreg+0, F
       andwf   BCDreg+1, F
       andwf   BCDreg+2, F
       andwf   BCDreg+3, F
       andwf   BCDreg+4, F

       decfsz  Count, F
       goto    loop

       return

       END


Hope this helps a bit...

Dave D.

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

2004\01\04@141745 by Roy J. Gromlich

picon face
Thank you Dave:

Yes, this is similar to the most recent attempt I have made at tweaking some
PIClist code to work.  So far I have gotten it to assemble without errors,
but it never comes out of the loop, so obviously there are still some bugs.
The code I have uses the <rlf> command, which has two forms in the 18F
MPASM - your code does it differently.  I will compare your code with this
old one - that will probably tell me what the problems are.  I'll let you
know how it works out.

Roy

{Original Message removed}

2004\01\04@151644 by Dave Dilatush

picon face
Roy J. Gromlich wrote...

>...The code I have uses the <rlf> command, which has two forms in the 18F
>MPASM - your code does it differently.  I will compare your code with this
>old one - that will probably tell me what the problems are.  I'll let you
>know how it works out.

The PIC16's RLF instruction is equivalent to the PIC18's RLCF
instruction; in both, the operand is rotated left through the
carry bit.  RLCF is the one you want for the code I posted, not
RLNCF.

Dave D.

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

2004\01\04@154759 by Ken Pergola

flavicon
face
Hi Roy,

Always keep in mind the possible problems that can occur when using the code
of others or exchanging your code with others with regard to default radix
(especially when code snippets are taken out of context from the entire
source file(s)) -- their default radix may be different than yours.
Definitely worth the time to review your code for this -- I'm not saying
this is your problem, however.

For example in the code that was just posted a few messages back in this
thread, you might want to replace:

movlw   16      <== will be interpreted as 0x16 if your default radix is hex

with:

movlw   .16   <== explicit decimal radix

   or

movlw   D'100' <== explicit decimal radix


Best regards,

Ken Pergola

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

2004\01\04@155222 by Ken Pergola

flavicon
face
I wrote:

>  movlw   16      <== will be interpreted as 0x16 if your default
> radix is hex
>
> with:
>
>  movlw   .16   <== explicit decimal radix
>
>     or
>
>  movlw   D'100' <== explicit decimal radix
>


Sorry about the  D'100' typo -- I meant D'16':


Correction:


movlw   16      <== will be interpreted as 0x16 if your default radix is
hex

with:

movlw   .16   <== explicit decimal radix

    or

movlw   D'16' <== explicit decimal radix



Regards,

Ken Pergola

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

2004\01\04@161341 by Jinx

face picon face
> a working & tested procedure for the 18Fxxx series chips

Variables needed - kzero, cnt1, temp (which I already have defined
for other routines and use them here as scratch), and 5 consecutive
bytes in RAM starting with dg1, which is the MSD

Enter with 16 bit number in hi:lo, ASCII returned in dg1 to dg5

;================================================
;        Convert 16-bit data to ASCII for LCD
;================================================

ascii16 nop

radix dec

        movf    fsr0l,w      ;save fsr
        movwf   cnt1
        clrf    kzero
        clrf    temp
        movlw   dg1    ;set store address
        movwf   fsr0l

        goto    skpinc1
sub10k   incf    temp,f
skpinc1  movlw   10000 & 255
        subwf   lo,f

IFNDEF  kzero

        movlw   10000 >> 8
        btfss   carry
        movlw   (10000>>8)+1
        subwf   hi,f
ELSE
        rlcf    kzero,W
        sublw   (10000>>8)+1
        subwf   hi,F
ENDIF
        bc      sub10k
        call    out_temp

        movlw   10
        movwf   temp
add1K    decf    temp,f
        movlw   1000 & 255
        addwf   lo,f

IFNDEF  kzero
        movlw   1000 >> 8
        btfsc   carry
        movlw   (1000>>8)+1
        addwf    hi,f
ELSE
        rlcf    kzero,w
        addlw   1000 >> 8
        addwf   hi,f
ENDIF
        bnc     add1k
        call    out_temp

        clrf    temp
        movlw   100
        goto    skpinc2
sub100
        incf    temp,f
skpinc2  subwf   lo,f
        btfsc   carry
        goto    sub100

        decf    hi,f
        btfss   hi,7
        goto    sub100

        call    out_temp

        movlw   10
        movwf   temp
add10    decf    temp,f
        addwf   lo,f
        bnc     add10
        call    out_temp     ;convert and store
        call    out_lo       ;convert and store
        movf    cnt1,w       ;restore fsr
        movwf   fsr0l

radix hex

       return

;convert to ASCII and store

out_temp movf    temp,w
        addlw   0x30         ;add 0x30 to convert to ASCII
        movwf   indf0
        incf    fsr0l,f      ;store in RAM at dg1+fsr0l
        return

out_lo   movf    lo,w
        addlw   0x30
        movwf   indf0
        return

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

2004\01\04@163248 by

picon face
Roy J. Gromlich

> I need to Read the 18Fxxx A/D and send the resulting 16-bit
> number to the UART for output, thus I need to convert 16-bit
> Binary to ASCII.

The "18Fxxx A/D" will give you a 10-bit
binary number, right ?

Note that the code to convert a 10-bit number
into "0000" - "1023" in ASCII probably can be made
a bit shorter/faster then a full 16-bit conversion
routine...

Or where does your extra 6 bits come from ?

Jan-Erik.

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

2004\01\04@183642 by Roy J. Gromlich

picon face
Jan-Erik:

You are correct, it is a 10-bit converter, which would be range of 0,,1023..
However, it can be set up to return the result Right-justified or
Left-justified - the 0..1023 is Right-justified.  For a Left-justified
return the result would be 0..16368.  Assuming you want, as I do, to read a
12 volt battery voltage (among other things), a full scale reading output of
16368 is just fine, and eliminates any need for additional scaling of the
A/D output. The proper scaling resistors on the A/D input will put the
full-scale output at 16.384 volts into the divider. The alternative would be
to add a more-or-less complete set of math routines to the code, and at this
time I don't see the need for that. This is a two-resistor and 40-50 lines
of code solution.

I would be interested in a good math package which is properly documented as
to requirements, operation and limitations. I have found several packages,
including one on the Microchip web site, but the documentation is limited
and I don't have a lot of time to spend (at the moment) tuning & tweaking
the software.  Later, maybe, when this is in production.

Anyway - good question.

Roy


{Original Message removed}

2004\01\04@195516 by Djula Djarmati

flavicon
face
>missing op codes.  I can probably figure this out eventually, but I have a
>deadline issue and would like to know if ANYONE has a working & tested
>procedure for the 18Fxxx series chips with sufficient documentation that it
>can be used without a lot of hacking.

   Try this - a bit larger but a bit faster...

Djula


;CONVERT TWO BYTE WORD TO FIVE BCD DIGITS (65 cycles)
;Input bytes:   BinHi:BinLo
;Output digits: Dg10000:Dg1000:Dg100:BinHi:BinLo
;Trashes:       PRODH, PRODL

WordBCD rrcf    BinHi,w         ;Divide by 1000
       rrcf    WREG,f          ;Start with divide by 1024
       andlw   B'00111111'     ;
       movwf   Dg1000          ;Result to Dg1000
       mullw   .24             ;Correction factor = 24 (1024-1000)
       movlw   B'00000011'     ;Calculate /1024 remainder
       andwf   BinHi,f         ;
       movf    PRODL,w         ;Add correction factor
       addwf   BinLo,f         ;to remainder
       movf    PRODH,w         ;(maximum possible value is 2535)
       addwfc  BinHi,f         ;
       movlw   low .1000       ;
       subwf   BinLo,f         ;Subtract 1000
       movlw   high .1000      ;
       subwfb  BinHi,f         ;
       bnc     Fix1000         ;Abort if negative
       incf    Dg1000,f        ;Still positive, increment thousands
       movlw   low .1000       ;
       subwf   BinLo,f         ;Subtract 1000
       movlw   high .1000      ;
       subwfb  BinHi,f         ;
       bnc     Fix1000         ;Abort if negative
       incf    Dg1000,f        ;Still positive, increment thousands
       bra     End1000         ;Done
Fix1000 movlw   low .1000       ;Negative, add 1000
       addwf   BinLo,f         ;
       movlw   high .1000      ;
       addwfc  BinHi,f         ;
End1000 rlcf    BinLo,w         ;Divide remainder by 100
       rlcf    BinHi,w         ;Start with divide by 128
       andlw   B'00000111'     ;
       movwf   Dg100           ;Result to Dg100
       mullw   .28             ;Correction factor = 28 (128-100)
       bcf     BinLo,7         ;Calculate /128 remainder
       movf    PRODL,w         ;Add correction factor to remainder
       addwf   BinLo,f         ;(maximum possible value is 299)
       bnc     Less256         ;No carry, ramainder < 256
       movlw   -.200           ;Remainder >=256
       addwf   BinLo,f         ;Subtract 200
       incf    Dg100,f         ;Increment hundreds twice
       incf    Dg100,f         ;
       bra     End100          ;Done
Less256 movlw   .100            ;
       subwf   BinLo,f         ;Subtract 100
       bnc     Fix100          ;Abort if negative
       incf    Dg100,f         ;Still positive, increment hundreds
       subwf   BinLo,f         ;Subtract 100
       bnc     Fix100          ;Abort if negative
       infsnz  Dg100,f         ;Positive, incr. hundreds, skip next
Fix100  addwf   BinLo,f         ;Negative, add 100
End100  movf    Dg1000,w        ;Now we have: TT:H:OO
       mullw   .205            ;Dg1000*1000 + Dg100*100 + BinLo*1
       movlw   .32             ;Split Dg1000 to two digits
       mulwf   PRODH           ;Multiply by 0.1
       movf    PRODH,w         ;(205/256 * 32/256)
       movwf   Dg10000         ;Result to Dg10000
       mullw   .10             ;Multiply by 10
       movf    PRODL,w         ;Subtract from original Dg1000
       subwf   Dg1000,f        ;Remainder is Dg1000
       movf    BinLo,w         ;Split BinLo to two digits
       mullw   .205            ;
       movlw   .32             ;Multiply by 0.1
       mulwf   PRODH           ;(205/256 * 32/256)
       movf    PRODH,w         ;
       movwf   BinHi           ;Result to BinHi
       mullw   .10             ;Multiply by 10
       movf    PRODL,w         ;Subtract from original BinLo
       subwf   BinLo,f         ;Remainder is BinLo
       return                  ;Done

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

2004\01\04@200139 by Dave Dilatush

picon face
You wrote...

>...For a Left-justified
>return the result would be 0..16368.

No, it'll be 0...65472.

>...The alternative would be
>to add a more-or-less complete set of math routines to the code, and at this
>time I don't see the need for that.

If you want to scale the input to the A/D with a voltage divider
so that the full-scale A/D result corresponds to 16.384 volts,
you hardly need a complete set of math routines: if you operate
the A/D so that its result is left-justified, just shift the
result right two bits (with zero fill) before converting it to
BCD; if you operate the A/D right-justified, shift the result
left four bits instead.

BTW, as Ken Pergola suggested, the default radix in the code I
posted was DEC.  Sorry for not specifying that.

Dave D.

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

2004\01\04@202424 by

picon face
Dave Dilatush wrote :
> You wrote...
>
> >...For a Left-justified
> >return the result would be 0..16368.
>
> No, it'll be 0...65472.

And it will jump in large "steps" so there isn't
realy more resolution, just more work for the
binary -> ASCII conversion routine.

> If you want to scale the input to the A/D with a voltage divider
> so that the full-scale A/D result corresponds to 16.384 volts,

The question is, is a 1 mV resolution realy needed to
monitor a (car ?) battery ?

And besided, couldn't the other side of the serial link
do the scaling of the ADC values ? Depending on what's
there, that could be easier.

Jan-Erik.

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

2004\01\04@203256 by

picon face
Roy J. Gromlich wrote :
>
> I would be interested in a good math package which is
> properly documented as to requirements, operation and
> limitations. I have found several packages, including
> one on the Microchip web site, but the documentation
> is limited and I don't have a lot of time to spend (at
> the moment) tuning & tweaking the software...

Fine. I can understand your situation.

Just a minor note...

Asking for others (free) help to save on ones own (highly
valued ?) time, usualy isn't the best tactics when
asking. It *can* make someones less willing to help...

That said,

I think that it will be hard to find a "math package"
that does *excatly* what you need. Anyway, there have been
a number of bin->ascii conv routines posted now. I'd take
one of the 18-series specific ones and build from that.

I have a 10-bit binary to packed BCD routine written for
the 18-series that I could post (when I'm back from my
current business trip in a few days). It was not build
for speed, but rather for readability and to be easy to
expand to more bits.

Jan-Erik.

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

2004\01\04@205202 by Jinx

face picon face
> > is limited and I don't have a lot of time to spend (at
> > the moment) tuning & tweaking the software...

I don't quite understand "tuning and tweaking"

16-bit in, ASCII out. What's there to "tune". If a maths package
is simply a collection of routines then most of my projects would
therefore have a "maths package". It just so happens that every
project has a different one. Maybe I'm missing something
regarding some HLL usage you have, as I work exclusively in
assembler and tailor s/w to suit the application. For example
I wouldn't waste memory space and upload time with a complete
suite of routines (that might include ARCTAN or SQRT) that
would be used in projects only infrequently

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

2004\01\04@205614 by Ken Pergola

flavicon
face
Dave Dilatush wrote:

> ...the default radix in the code I posted was DEC...

Hi Dave,

I hope you did not feel like I was singling you out -- that was not my
intention. I was just trying to point out that I wish MPASM *required*
mandatory explicit radix specification for constants by eliminating the
RADIX control directive. I feel that eliminating the RADIX control directive
from MPASM would eliminate the problems of code having constants whose radix
depends on the RADIX directive or lack thereof (default radix is hex). I get
around this by never using the RADIX control directive.

Best regards,

Ken Pergola

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

2004\01\04@210028 by Roy J. Gromlich

picon face
Jan-Erik and others:

I'm sorry if my question sounded like that - it was not meant that way.

It was my thought that this was a very common problem which had
probably been solved many times before, and which would be
readily available on something like the PIClist. It seemed a waste
of time to re-invent the wheel, so to speak. And in fact, it was there
in several different forms, all of which I do appreciate.

And again, you and others are correct regarding the Left-justified
value - just carelessness on my part, as I was referring to a number
I was thinking of using for the output scale and didn't go the rest of
the way to see what would happen. At the moment I have not added
the A/D code to the loop - I wanted to get the display output up first.

This is what happens when you are trying to go too fast, I guess.

I've been down that road before.

And finally, thank you again, your code segment works just fine, as
do several others I received in answer to my question.  Thanks to
everyone who answered  for their help.

Roy J. Gromlich

{Original Message removed}

2004\01\04@214708 by Dave Dilatush

picon face
Ken Pergola wrote...

>I hope you did not feel like I was singling you out -- that was not my
>intention.

Nah.  No offense taken.

>I was just trying to point out that I wish MPASM *required*
>mandatory explicit radix specification for constants by eliminating the
>RADIX control directive.

I concur; it would eliminate much potential for confusion and
error.

Dave D.

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

2004\01\04@214916 by Roy J. Gromlich

picon face
Jan-Erik:

The left-justified output is NOT what I want to use, as has been pointed
out to me, full scale would be 65472 and I would need to divide to
get a correct decimal value.  It is much easier to multiply on the 18F
with its nice hardware multiplier!

No, 1 mV resolution isn't needed. In fact, we will probably have
something more graphic, like a simple bar-graph on the display where
the pointer will change color to signal battery state.  And this isn't a car
battery, but similar - a GelCell pack being charged by a solar panel for
remote unattended operation.

Yes, the other end of the serial link can do the conversion, and certainly
will do so in a working application. This "project" is a demonstration of
concept kind of thing - I want to talk to this monitor board using a
simple terminal program like TeraTerm. That way the boss/owner can
test the operation without having to make changes to the present Win2K
application. I thought typing [B]attery on the terminal window and having
the remote monitor send back 13.24 volts would be more obvious than
a binary number would be.

Again, thanks to all for all the help.

Roy
{Original Message removed}

2004\01\05@072409 by Dave Dilatush

picon face
Roy wrote...

>The left-justified output is NOT what I want to use, as has been pointed
>out to me, full scale would be 65472 and I would need to divide to
>get a correct decimal value.  It is much easier to multiply on the 18F
>with its nice hardware multiplier!

Hmmm...  keep in mind that when you are multiplying or dividing
by an exact integer power of 2 (2, 4, 8, 16, 32, etc.), you can
accomplish that with a simple left or right shift.

For example, the instruction sequence

  rrcf  Binreg
  rrcf  Binreg+1
  movlw 0x3F
  andwf Binreg

will divide an unsigned 16-bit number in Binreg by 4.  That's all
there is to it.

Dave D.

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

2004\01\05@073618 by Olin Lathrop

face picon face
Roy J. Gromlich wrote:
> I need to Read the 18Fxxx A/D and send the resulting 16-bit number

It's actually a 10 bit number.  There may be a few 18F PICs that can do 12
bit, but certainly not 16 bit.

> to the UART for output, thus I need to convert 16-bit
> Binary to ASCII.

Huh?  UARTs are quite capable of sending binary.  Using a UART does not
imply that you need to send only ASCII.  In fact, it's a good idea to send
data from a PIC in binary when possible, then let whatever presents the data
to the user do the conversion.  This is especially true when the other end
of the RS-232 link is a general purpose computer.  Keep the numbers in
binary there too and convert only to/from the user interface.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2004\01\05@073827 by Hazelwood Lyle

flavicon
face
{Quote hidden}

Good Morning.
I think the above code will divide a 16 bit unsigned number by 2, then
mask the value with .63
Executing the rrcf pair TWICE before masking should give the result
described in the text.

Unless of course it's just too early on a Monday morinng, and I'm missing something obvious.

Lyle

Happy New years to all!
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\01\05@081018 by Olin Lathrop

face picon face
Jan-Erik Soderholm XA (TN/PAC) wrote:
> Asking for others (free) help to save on ones own (highly
> valued ?) time, usualy isn't the best tactics when
> asking. It *can* make someones less willing to help...

That's why I didn't even mention my math package.

> I think that it will be hard to find a "math package"
> that does *excatly* what you need.

I don't know what exactly he needs, but I've got various routines that
operate on 32 bit fixed point and 24 bit floating point.  These include the
usual add, subtract, multiply, and divide, plus some min/max and other
utilities.  The floating routines include capabilities for converting
to/from 32 bit fixed point numbers.

All these routines are part of our PIC development environment, although
they are not included in the free distribution available on the web site.
They are all "accumulator based", and operate on wide registers formed by
concatenating the REG0 - REGn general registers.  I didn't mention them
before because it seemed the OP was looking for something free, and I'm not
willing to give the math package away for free.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2004\01\05@081358 by Olin Lathrop

face picon face
Ken Pergola wrote:
> I hope you did not feel like I was singling you out -- that was not my
> intention. I was just trying to point out that I wish MPASM *required*
> mandatory explicit radix specification for constants by eliminating
> the RADIX control directive. I feel that eliminating the RADIX
> control directive from MPASM would eliminate the problems of code
> having constants whose radix depends on the RADIX directive or lack
> thereof (default radix is hex). I get around this by never using the
> RADIX control directive.

I think all numbers should be interpreted as decimal unless they are
explicitly coded to indicate otherwise.  The very first statement in the
very first include file of my PIC development environment
(http://www.embedinc.com/pic) sets the radix to decimal.  All the remaining
code requires is that way.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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

2004\01\05@111656 by Ken Pergola

flavicon
face
Olin Lathrop wrote:

> I think all numbers should be interpreted as decimal unless they are
> explicitly coded to indicate otherwise.

Hi Olin,

Can I twist your arm a little to change your ways? :)

In my opinion, this should not be decided at compile time as it is with the
RADIX control directive (or lack thereof) under MPASM -- it should be
explicitly coded in the source code by using an explicit radix before *each*
and *every* constant.

Everyone of course has free will, and your method is fine within a
controlled environment and if others follow your conventions, but this could
lead to problems when code is shared with others as I have previously
explained in a recent post.

You want to have "strong type naming" with constants so that anyone who uses
your code will get the same results. It's all about forcing consistency
right? MPASM's RADIX control directive (and its default hex radix if you
don't use the RADIX control directive) just encourages "weak type naming".

I'm just trying to raise awareness here. We talk a lot on the PICLIST of
doing things the right way and I think the *best* coding practice with
regard to constants is to always explicitly specify the radix with each
constant.

Doesn't this make better sense?

Best regards,

Ken Pergola

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

2004\01\05@165620 by Dave Dilatush

picon face
Lyle wrote...

>Dave Dilatush wrote:
>>
>>For example, the instruction sequence
>>
>>   rrcf  Binreg
>>   rrcf  Binreg+1
>>   movlw 0x3F
>>   andwf Binreg
>
>I think the above code will divide a 16 bit unsigned number by 2, then
>mask the value with .63
>Executing the rrcf pair TWICE before masking should give the result
>described in the text.
>
>Unless of course it's just too early on a Monday morinng, and I'm
>missing something obvious.

Ouch.  OK, let's try this again:

  rrcf  Binreg
  rrcf  Binreg+1
  rrcf  Binreg
  rrcf  Binreg+1
  movlw 0x3F
  andwf Binreg

Like you said, too early on a Monday morning.

Dave D.

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

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