Wagner and others,
Sorry that my question was not accurate.
I have 16-bit value from timer3 (PIC17C43). It can be something between 1Eh...1700h. Lets say 0...270Fh for sure. I have to convert that value to ascii-numbers, because the value will be displayed with a LCD module (that needs ascii-characters, of course) and will be transmitted to a pc (RS232). I have 4 digits for display and transmit. So, the 16-bit value needs to be converted to four ascii-numbers. The timer value can't be greater than 270Fh, that's 9999 in ascii. This is the conversion I need!
Thanks in advance
Juha Tuomi wrote:
> Wagner and others,
> Sorry that my question was not accurate.
> I have 16-bit value from timer3 (PIC17C43). It can be something between 1Eh...
1700h. Lets say 0...270Fh for sure. I have to convert that value to ascii-number
s, because the value will be displayed with a LCD module (that needs ascii-chara
cters, of course) and will be transmitted to a pc (RS232). I have 4 digits for d
isplay and transmit. So, the 16-bit value needs to be converted to four ascii-nu
mbers. The timer value can't be greater than 270Fh, that's 9999 in ascii. This
is the conversion I need!
> Thanks in advance
Ok, then you need to do two steps:
1) Convert Hexadecimal to Decimal (BCD)
2) Convert (BCD) Binary Coded Decimal to ASCII
Lets call your 16 bits as TIM3
Lets call your 4 BCD's as BCD#1,BCD#2,BCD#3,BCD#4
BCD#1 is the most significant digit
The first step is done in several ways.
Lets see one way that get directly 4 digits with
values = 09 and below, not exactly bcd.
You can divide the 16 bits in three steps
a) Divide TIM3 / 03E8 = BCD#1, rest back to TIM3
b) Divide TIM3 / 0064 = BCD#2, rest back to TIM3
c) Divide TIM3 / 000A = BCD#3, rest is BCD#4
How you do the division of TIM3/03E8?
Just subtract TIM3 - 03E8 until it the result
goes below zero, so it generates "carry", then
add 03E8 to have the rest positive.
The quantity of subtractions with a positive
rest lower than 03E8 is the BCD#1.
The same for the others, 0064 and 000A.
Now you take BCD#1, and OR 30h, you have the
decimal ASCII value from 30h to 39h (0-9), do
it to BCD#2,3,4.
That simply division routine is not pretty and
not the faster one, but it works for your delight.
It can take as long as 36 subtraction loops, if
the TIM3 = 270Fh.
Remember to check for TIM3=0 before you do the
subtractions, if TIM3 = 0, BCD#n up to BCD#4 would
be also zero, so the division is finished.
Example: TIM3 = 0FA0h will give you 4 subtractions
of 03E8h and the rest will be zero, decimal result
will be 4000.
TIM3 = 0FA8h will give you 4 subtractions of 03E8h,
the rest will be 0008, none to BCD#2 (0064h), none
to BCD#3 (000A), resting to BCD#4, result: 4008d
You may find different solutions, but do this first,
easily you will learn differences between several
Thank You very much to everyone who helped me with my conversion problem!
Juha Tuomi wrote:
> You mailed some files to me. I'm using pic17c43 and converted those few instru
ctions to it. I have tried John Payson's binary to bcd routine and your addition
(labels lb1...lb4). I've run them with simulator but they don't seem to be work
The lb1 to lb4 are not my additions. It is still John's and is included
in the routine.
> I've set numl and numh to 0's and called "convert" The result is weird:
The result is ok. This looks weird because it still not normalized.
Lb1...Lb4 are the routines to normalize the result.
> This is just before the label lb1.
> After lb4 the result is:
> Have you tested those sources? The result is wrong already before label lb1,
but isn't there few errors within lb1...lb4? I mean lines with btfss 3,0. I rep
laced them with btfss tens,0 etc. Which way it should be? I'm a little confused
with the whole bin-ascii conversion now!!
The problem is that you change the btfss 3,0 to btfss tens,0. The
command tests for the carry flag (3=STATUS, bit 0 = carry flag). You
should not change the lines. Test again the result without modifying
The result is still binary, adding the following routine coverts the
results to ascii:
More... (looser matching)
- Last day of these posts
- In 1999
, 2000 only
- New search...