Searching \ for '[PIC] 9 bit binary to digits?' in subject line. ()
Help us get a faster server
FAQ page: massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: '9 bit binary to digits?'.

Exact match. Not showing close matches.
'[PIC] 9 bit binary to digits?'
2010\02\09@003610 by

Hi all. I'm thinking of a project where I'll have a 9 bit binary
number, and I'll want to display it on a 3 digit 7 segment display. To
do this I'll need to extract the hundreds, tens, and ones digits from
the number. The PICList.org website has an 8 bit version to do this
Has anyone seen a 9 bit version (or a higher bit version that's easily
foolable, I guess up to 16 bit would be easy)?

Binary maths and translations aren't my strong point so I'd love to
see an example rather than trying to write one myself.

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
> The PICList.org website has an 8 bit version to do this

How about subtract 100 from the number until the 9th bit is clear,
then use the 8-bit routine to get the rest. Add the number of subtracts
to the 100's digit. That would be a maximum of 4 subtracts, to find
256 - 300, 301 - 400, 401 - 500 and > 501

wbr

On Tue, 9 Feb 2010, Josh Koffman wrote:

{Quote hidden}

Multiprecision arithmetic is a pretty fundamental aspect of 8 bit
processors. I would strongly recommend that you learn to be comfortable
with it. Having a good reason to learn something helps. You've got one now
so take advantage of the situation and learn to do 16 bit addition and
subtraction.

Friendly Regards
Sergio Masci
Just thinking .....

> That would be a maximum of 4 subtracts, to find
> 256 - 300, 301 - 400, 401 - 500 and > 501

The boundaries are at x55, not x00, so that's 3 max

wbr
On Tue, Feb 9, 2010 at 12:36 AM, Josh Koffman <joshybeargmail.com> wrote:
> Hi all. I'm thinking of a project where I'll have a 9 bit binary
> number, and I'll want to display it on a 3 digit 7 segment display. To
> do this I'll need to extract the hundreds, tens, and ones digits from
> the number. The PICList.org website has an 8 bit version to do this
> Has anyone seen a 9 bit version (or a higher bit version that's easily
> foolable, I guess up to 16 bit would be easy)?

I've decided to limit myself to an input of 255 for now. Once I get
that working I'll move on to getting the extra bit to work and adding
on to my existing 8 bit to H,T,O.

I'm starting to work with the routine linked to in my original email.
I'm rewriting it in my own style to make sure I understand how it
works. I got the hundreds conversion (at least I think I understand
it). I must admit I've lost the scent on the tens and ones. The author
notes that they should be run together, but I can't see why. In fact
it seems to me that if they are run together then the routine won't
output the number of tens anywhere. Also shouldn't the hundreds
routine feed into the tens routine?

Man I'm confused. Continuing web searching, but any help would be appreciated.

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
Um...in addition to my previous message, I just realized I might have
been making a nomenclature mistake.

Would it be fair to say I'm looking for a routine that does binary to
unpacked BCD? I've been avoiding those examples as I thought they were
something else.

I also realized that my PIC'n up the Pace book has the routine I need.

--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
At 06:01 PM 2/14/2010, you wrote:
>Um...in addition to my previous message, I just realized I might have
>been making a nomenclature mistake.
>
>Would it be fair to say I'm looking for a routine that does binary to
>unpacked BCD? I've been avoiding those examples as I thought they were
>something else.
>
>I also realized that my PIC'n up the Pace book has the routine I need.

You don't look a day over 300.. ;-)

Why don't you look at Peter Hemsley's 12-bit code at piclist.com?

D3 will always be 0 for your application, of course, so you could
shorten it a bit once you go through the exercise of understanding it,

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

> Would it be fair to say I'm looking for a routine that does binary to
> unpacked BCD?

AIUI (but not sure if it applies to PICs or micros in general) packed
also contains the sign. The BCD I think you're probably wanting has
the three 0-9 digits in their own nybbles. They can be displayed with
a BCD-to-segment decoder (eg CMOS 4543) or can be separated
off and converted to ASCII by adding 0x30 for an LCD

Never too late to learn Josh

wbr

wikipedia has a page

en.wikipedia.org/wiki/Binary-coded_decimal
On Sun, Feb 14, 2010 at 7:34 PM, Spehro Pefhany <speffinterlog.com> wrote:
> At 06:01 PM 2/14/2010, you wrote:
>
> You don't look a day over 300.. ;-)

Oh, I've really let myself go since I last saw you Spehro! Actually,
that's a bit weird that the message got truncated. Was supposed to say
"too bad I'm 3500 miles away from it".

> Why don't you look at Peter Hemsley's 12-bit code at piclist.com?
>
> D3 will always be 0 for your application, of course, so you could
> shorten it a bit once you go through the exercise of understanding it,
> and it's really not too bad for your application even as-is.

I'm working through it now. I tried putting it in macro form but
something funny is happening. It's bedtime here, but tomorrow I'll put
the code inline and massage it until I get it to work. Then I'll worry
about macro-ing it. I hope it works on the 18F line. I had to change
his rlf to rlcf and his:
skpnc
goto mod0

to

bnc mod0

Hope I got that right!

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
On Sun, Feb 14, 2010 at 7:44 PM, ivp <joecolquittclear.net.nz> wrote:
> AIUI (but not sure if it applies to PICs or micros in general) packed
> also contains the sign. The BCD I think you're probably wanting has
> the three 0-9 digits in their own nybbles. They can be displayed with
> a BCD-to-segment decoder (eg CMOS 4543) or can be separated
> off and converted to ASCII by adding 0x30 for an LCD

had my terminology wrong. I believe I'm now looking for the right
thing. I'm not too worried about having digits combined into their own
nybbles as I can extract that fairly easily.

>
> Never too late to learn Josh

Old dogs, new tricks, kids these days, uphill both ways in the snow, etc.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
On Sun, Feb 14, 2010 at 7:47 PM, Josh Koffman <joshybeargmail.com> wrote:
>> Why don't you look at Peter Hemsley's 12-bit code at piclist.com?
>>
>> D3 will always be 0 for your application, of course, so you could
>> shorten it a bit once you go through the exercise of understanding it,
>> and it's really not too bad for your application even as-is.
>
> I'm working through it now. I tried putting it in macro form but
> something funny is happening. It's bedtime here, but tomorrow I'll put
> the code inline and massage it until I get it to work. Then I'll worry
> about macro-ing it. I hope it works on the 18F line. I had to change
> his rlf to rlcf and his:
> skpnc
> goto mod0
>
> to
>
> bnc mod0

Well, I believe my code substitution is alright, but I think I've
found another problem. In the 16F processors it appears that the decf
command doesn't effect the carry bit, but in the 18F chips it does.
That's screwing up the logic as the routine is assuming C is unchanged
and was last effected by an addwf. Here's a snippet:
mod0
decf    _D1,f
;        skpc
;        goto    mod0
bnc                mod0

The commented lines are the ones I substituted with the bnc.

Maybe I should try reversing the order of the commands? Then the C bit
would be last effected by the addwf?

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.

On Sun, 14 Feb 2010, Josh Koffman wrote:

{Quote hidden}

lets say you want to convery the binary number 359 to ascii digits. Dont
worry that it's shown as decimal or greater than 255 for now.

So what you would normally do is look at the 100s column and take the 3
then the 10s column and take the 5 then the 1s column and take the 9. Ok
so how do we take a digit from a column on a computer. Well what we
actually do is take '1' away from that column until we get to '0' and we
count how many times we are able to do this. If we write this in pseudo
code we get:

For the 100s column

value = 359
count = 0

while value >= 100 do
value = value - 100
count = count + 1
done

at this point we end up with

value = 59
count = 3

For the 10s column

count = 0

while value >= 10 do
value = value - 10
count = count + 1
done

now we end up with

value = 9
count = 5

Now at this point you can easily see that the '1' column is whats left in
'value'

Now to clear up the confusing bits.

decimal 359 is binary 01 0110 0111
decimal 100 is binary 00 0110 0100
decimal  10 is binary 00 0000 1010
decimal   1 is binary 00 0000 0001

decimal 300 is binary 01 0010 1100
decimal  50 is binary 00 0011 0010

When we take the 3 from the 100s (hundreds) column we are trying to
convert
binary 0100101100 to binary 0000000011.

When we take the 5 from the 10s (tens) column we are trying to convert
binary 0000110010 to binary 0000000101.

so the easiest way to do this is to repeatedly take binary 0100101100 from
binary 0101100111 (359) and count in units (binary 0000000001).

0101100111 (359) - 0001100100 (100) = 0100000011 (259) ; count = 1
0100000011 (259) - 0001100100 (100) = 0010011111 (159) ; count = 2
0010011111 (159) - 0001100100 (100) = 0000111011  (59) ; count = 3

so at this point we have converted 'value' from 0101100111 (359) to
0000111011 (59) and 'count' to 0000000011 (3)

doing the same for the 10s (tens) we get:

0000111011 (59) - 0000001010 (10) = 0000110001 (49) ; count = 1
0000110001 (49) - 0000001010 (10) = 0000100111 (39) ; count = 2
0000100111 (39) - 0000001010 (10) = 0000011101 (29) ; count = 3
0000011101 (29) - 0000001010 (10) = 0000010011 (19) ; count = 4
0000010011 (19) - 0000001010 (10) = 0000001001  (9) ; count = 5

so at this point we have converted 'value' from 0000111011 (59) to
0000001001 (9) and  'count' to 0000000101 (5)

now if we look at the pseudo code again - just the 100s (hundreds) for
now:

value = 359
count = 0

while value >= 100 do
value = value - 100
count = count + 1
done

we see a horrible '>=' which kind of complicates things if we are trying
to convert this pseudo code into assembly language. We can rearrange
things to make them easier like this:

value = 359
count = 0

while (value - 100) > 0 do
value = value - 100
count = count + 1
done

Another way to think about "X > 0" is "is X not negative". If you have
enough bits in your variables and you are using 2's complement
arithmetic (which tends to be available on most processors these days)
then this is a very easy test to make.

e.g.

0000111011 (59) - 0001100100 (100) = 1111010111 (-41)

simply by looking at the most significant bit (the left most bit) and
testing if it is a '0' or a '1' we can see if the result is positive
or zero (for bit = 0) or negative (for bit = 1).

So we can actually convert the pseudo code to

value = 359
count = 0

while ((value - 100) & 512) == 0 do
value = value - 100
count = count + 1
done

If we tried to do this on a variable that had only 8 bits we would be
restricting ourselves to numbers on the range -128 to +127 (because we
want to use the most significant bit for the sign. If we use 16 bits then
we increase our range to -32768 to +32767.

The above pseudo code would then become

value = 359
count = 0

while ((value - 100) & 32768) == 0 do
value = value - 100
count = count + 1
done

Which is really really easy to convert to PIC assembly code!

It is well worth using multiprecision arithmetic on a PIC (going from 8
bit variables to 16 bit variable) to simplify maths.

Also a very important aspect of multiprecision arithmetic on an 8 bit CPU
like the PIC is the ability to calculate addresses greater than 255!!!

I hope this helps.

Regards
Sergio Masci

On Mon, 15 Feb 2010, sergio masci wrote:

{Quote hidden}

::        while (value - 100) >= 0 do
::                value = value - 100
::                count = count + 1
::        done
::
:: Another way to think about "X >= 0" is "is X not negative".

Regards
Sergio Masci
Wow Sergio, thanks for the explanation! It'll take me a while to work
through that, but I do want to understand how it's actually done, so
this is useful.

My changes to the 12 bit routine from the site did seem to work.
Swapping the position of the decf and addwf seems to have done the
trick...for now!

Thanks,

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
Em 15/2/2010 13:23, sergio masci escreveu:
{Quote hidden}

There is an interesting implementation which is used by MPLAB-C18
library (file itobcd.asm).
It is a very efficient serialized method, it uses only shifts and adds.
It is worthy a try.

Best regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

On Mon, 15 Feb 2010, sergio masci wrote:

{Quote hidden}

Sorry got a bit side tracked here.

One of the things I was trying to EMPHASIS here is the way DECIMAL digits
are spread over the BINARY equivalent of the same value.

In decimal it is easy to see how to take the digit out of the hundreds
column but when we look at the binary equivalent we cant just take a a
group of bits - we have to do a conversion so that the hundreds get
converted to units (units and digits are the same thing for this
discussion)

Regards
Sergio Masci

On Mon, 15 Feb 2010, Isaac Marino Bavaresco wrote:

> There is an interesting implementation which is used by MPLAB-C18
> library (file itobcd.asm).
> It is a very efficient serialized method, it uses only shifts and adds.
> It is worthy a try.

Hi Isaac,

Thanks for the pointer but in this case I was trying to explain the
fundamentals and in particular why getting to grips with 16 bit arithmatic
on an 8 bit PIC is a GOOD thing. The whole thing would have been really
trivial had the OP been comfortable with 16 bit arithmetic in the first
place.

Regards
Sergio Masci
Josh Koffman wrote:
> had my terminology wrong. I believe I'm now looking for the right
> thing. I'm not too worried about having digits combined into their own
> nybbles as I can extract that fairly easily.

There is a lot I could say about binary to decimal conversion, but not until
the admins stop running my post past censors before they are allowed to go
to the list.

I have said a lot about binary to decimal conversion in the past and have
even made code available.  It should not be hard to find with a little
digging.  This is a long solved problem that seems to come up anew every 6
months or so.  I generally use a 16 bit to 5 digit routine I wrote some
years ago, and posted about here.

********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
> There is an interesting implementation which is used by MPLAB-C18
> library (file itobcd.asm).
> It is a very efficient serialized method, it uses only shifts and adds.
> It is worthy a try.

I believe this is the normal method used for binary->decimal conversion.
Em 15/2/2010 14:44, sergio masci escreveu:
{Quote hidden}

I understand, but this method doesn't use 16-bit math at all. All the
math is done nibble-by-nibble, no carry is propagated during the additions.
The only part that uses carry propagation is during the shifts, that
shifts the whole 16-bit (or 9-bit in this case) value. It works for
values with any number of digits.

If you don't already know this method, I would suggest to study it, it
is very enlightening. Shows a very different approach that exploits
curious properties of binary and BCD numbers. It is being used for a
while by the CPLD/FPGA guys, because it is easily implemented using just

Best regards,

Isaac
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

I might suggest:
http://www.amqrp.org/elmer160/lessons/E160L18.pdf

--McD

On Mon, 15 Feb 2010, Isaac Marino Bavaresco wrote:

{Quote hidden}

Thank you Isaac I'll have a look at that later (got to get the C18
compiler and library first) :-)

I vaugely remember a method using half carrys but not well enough to do it
off the top of my head. I also know of a method using multiply by 10
(which itself can be broken down to shifts and add) but a method not
propagated carry in additions? I'm not sure I've seen that one or if I
have I've certainly forgotten all about it.

Thanks
Sergio
> There is an interesting implementation which is used by MPLAB-C18
> library (file itobcd.asm).
> It is a very efficient serialized method, it uses only shifts and adds.
> It is worthy a try.

I just looked it up and perhaps it is interesting but it is not
efficient at all, it uses ~750 cycles for 16 bits?!?

Even a pedestrian subtract 10k, 1k, 100, 10 method is faster.
With optimization, 16 bits can be converted in ~70 cycles, that is 10
times faster!

How can they afford to make the math routines so slow?

Djula

Josh Koffman wrote:
> Hi all. I'm thinking of a project where I'll have a 9 bit
> binary number, and I'll want to display it on a 3 digit
> 7 segment display. To do this I'll need to extract the
> hundreds, tens, and ones digits from the number...

Not necessarily, it depends on what you have in excess - computational
power or memory cells. 2K Byte memory will give you 512 * (4*Byte)
lookup table. In case of 8-bit number as you posted later, you are
okay with just 1K Byte lookup table if I understand your post
correctly.

Regards.

Josh Koffman wrote:
> Hi all. I'm thinking of a project where I'll have a 9 bit
> binary number, and I'll want to display it on a 3 digit
> 7 segment display. To do this I'll need to extract the
> hundreds, tens, and ones digits from the number...

For this, I would use the "Shift and Add-3 Algorithm" to do the conversion you need:

http://www.engr.udayton.edu/faculty/jloomis/ece314/notes/devices/binary_to_BCD/bin_to_BCD.html

Take care,
-Chris

--
| Christopher Cole, Cole Design and Development, LLC          colecoledd.com |
| Embedded Software Development and Electronic Design       http://coledd.com |
| Stow, Ohio, USA                                                800-518-2154 |

> There is a lot I could say about binary to decimal conversion,
> but not until the admins stop running my post past censors
> before they are allowed to go to the list.

Yeah, I know this is not quite the place for democracy, but, may I
humbly wonder what the OP have commited to make him getting thrown
under the inquisition of the pre-moderation?

Thanks.
:-)

2010\02\15@174250 by

On Mon, 15 Feb 2010, Christopher Cole wrote:

{Quote hidden}

Seriously?!

I'm curious, how would you efficiently compare each BCD digit (of a 3
digit packed BCD number) to 5 after each shift on a PIC?

Regards
Sergio Masci
Christopher Cole wrote:
> Josh Koffman wrote:
>> Hi all. I'm thinking of a project where I'll have a 9 bit
>> binary number, and I'll want to display it on a 3 digit
>> 7 segment display. To do this I'll need to extract the
>> hundreds, tens, and ones digits from the number...
>
> For this, I would use the "Shift and Add-3 Algorithm" to do the conversion you need:
>
> http://www.engr.udayton.edu/faculty/jloomis/ece314/notes/devices/binary_to_BCD/bin_to_BCD.html

That algorithm is not well suited for PICs, it will take a very long
time. It's much better to make use of the hardware multiplier.

Djula

;**********************************************************************************************
;CONVERT 10-BIT BINARY TO THREE DECIMAL DIGITS (28 cycles, 25 program
memory)
;Input word:    Digits+1:Digits
;Output digits: Digits+2:Digits+1:Digits
;Trashes:       PRODH, PRODL
;**********************************************************************************************
Bin_To_Dec_999  movlw   d'41'                   ;Multiply by 0.01 (41/4096)
mulwf   Digits+1                ;
movff   PRODL, Digits+2         ;
mulwf   Digits                  ;
movf    PRODH, w                ;
mullw   0x10                    ;Lose the lower 8 bits
and shift
movf    PRODH, w                ;result 4 bits left
(divide by 4096)
movwf   Digits+2                ;Save result
mullw   d'100'                  ;and then multiply it
by 100
movf    PRODL, w                ;
subwf   Digits, f               ;Subtract from original
movf    PRODH, w                ;to get
subwfb  Digits+1, f             ;remainder
movf    Digits, w               ;Split remainder (0-99)
to two decimals
mullw   D'205'                  ;
movlw   D'32'                   ;Multiply by 0.1
mulwf   PRODH                   ;(205/256 * 32/256)
movf    PRODH, w                ;
movwf   Digits+1                ;Save result
mullw   D'10'                   ;and then multiply it by 10
movf    PRODL, w                ;Subtract from original
subwf   Digits, f               ;Save remainder
return                          ;Done

On Tue, 16 Feb 2010 00:17:46 +0200, "Marechiare" said:

> Yeah, I know this is not quite the place for democracy, but, may I
> humbly wonder what the OP have commited to make him getting thrown
> under the inquisition of the pre-moderation?

This is a [PIC] thread and as such it is for discussion of pics.

You're still a relative newcomer to the list, but if you search the
archives I'm sure you'll be able to find plenty to educate yourself on
this topic.

Best regards,

Bob

--
http://www.fastmail.fm - The professional email service

Thanks for all the interesting advice folks! Clearly I have a bunch of

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.

On Mon, 15 Feb 2010 15:27:59 -0800, "Bob Blick"
said:

> You're still a relative newcomer to the list, but if you search the
> archives I'm sure you'll be able to find plenty to educate yourself on
> this topic.

Sometimes when I read what I've written it really isn't what I meant to
say. What I meant to say is that you joined the list "post-excitement"
and if you looked in tne archives it would mean that everyone else
wouldn't have to relive it.

Cheers,

Bob

--
http://www.fastmail.fm - Same, same, but different...

part 0 44 bytes
his is a multi-part message in MIME format.
part 1 550 bytes content-type:text/plain; charset=ISO-8859-1 (decoded 7bit)

Em 15/2/2010 10:35, Isaac Marino Bavaresco escreveu:
> There is an interesting implementation which is used by MPLAB-C18
> library (file itobcd.asm).
> It is a very efficient serialized method, it uses only shifts and adds.
> It is worthy a try.
>
> Best regards,
>
> Isaac
>

Attached is an implementation in assembly language for mid-range (14-bit
instructions) PICs.
The conversion routine takes 34 program words and runs (always) in 207
instruction cycles.

Best regards,

Isaac

part 2 1442 bytes content-type:application/octet-stream; (decode)

part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

Isaac Marino Bavaresco wrote:

> Attached is an implementation in assembly language for mid-range (14-bit
> instructions) PICs.
> The conversion routine takes 34 program words and runs (always) in 207
> instruction cycles.

It's been a while since I looked at this stuff, but 10 years ago we came
up with an efficient PIC-based algorithm. I think Nikolai's 16-bit version
can be truncated to 9-bits. This takes 38 cycles (and 38 instructions) for
a 9-bit binary to packed BCD.

Scott

On Mon, 15 Feb 2010, Isaac Marino Bavaresco wrote:

{Quote hidden}

Interesting, thank you for sharing that. I haven't worked my way through
it but it feels good. I'll have to work my may through it in detail :-)

With regards to optimisation, have you considered changing:

BIN2BCD9Bits:   movlw   0x01            ; Mask out the 7 higher bits of the value
andwf   BinValue+1,f

bcf     STATUS,C        ; Here we add a twist to allow 9bit conversion
rrf     BinValue+1,f    ; Instead of pre-shifting left 7times, we rotate
rrf     BinValue+0,f    ; right once an will use the bytes in reversed order.
rrf     BinValue+1,f

to

BIN2BCD9Bits:                           ; Mask out the 7 higher bits of the value
rrf     BinValue+1,f    ; Instead of pre-shifting left 7times, we rotate
rrf     BinValue+0,f    ; right once an will use the bytes in reversed order.
clrf    BinValue+1
rrf     BinValue+1,f

Regards
Sergio Masci

On Mon, 15 Feb 2010, Scott Dattalo wrote:

{Quote hidden}

Thank you Scott. We can always rely on you to come up with the real heavy
stuff :-)

Regards
Sergio Masci
Em 16/2/2010 02:39, Scott Dattalo escreveu:
> Isaac Marino Bavaresco wrote:
>
>
>> Attached is an implementation in assembly language for mid-range (14-bit
>> instructions) PICs.
>> The conversion routine takes 34 program words and runs (always) in 207
>> instruction cycles.
>>
> It's been a while since I looked at this stuff, but 10 years ago we came
> up with an efficient PIC-based algorithm. I think Nikolai's 16-bit version
> can be truncated to 9-bits. This takes 38 cycles (and 38 instructions) for
> a 9-bit binary to packed BCD.
>
>
> Scott
>

Hi Scott,

I already knew the code. I just didn't remember it was so efficient :)

Anyway, for someone learning how to program it is a bit too complicated.

The method I presented although less efficient, can be scaled-up to any
number of digits following the same simple mechanism.

For the people complaining about MPLAB-C18 library efficiency, take a
look at its 'printf' function (vfprintf indeed). It first converts every
value to be printed to 32 bits and extracts each digit by division/module.
I rewrote most of the MPLAB-C18 library to accept my generic pointers
and in the process I optimized the vfprintf function, but I didn't
replace the numeric conversion code yet. Someday I'm going to optimize
it using some routine in the Piclist source code library.

Best regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

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