Searching \ for 'ASCII conversion' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=ascii+conversion
Search entire site for: 'ASCII conversion'.

Truncated match.
PICList Thread
'ASCII conversion'
1999\03\19@132003 by

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

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

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
division routines.

Wagner

Thank You very much to everyone who helped me with my conversion problem!

Juha

Hi,

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
ing.

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:
> tenk:07
> thou:c0
> hund:d2
> tens:76
> ones:ec

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:
>
> tenk:05
> thou:d3
> hund:db
> tens:7f
> ones:f6
>
> 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 code.

The result is still binary, adding the following routine coverts the
results to ascii:

movlw   0x30
addwf   tenk,f
addwf   thou,f
addwf   hund,f
addwf   tens,f
addwf   ones,f

regards,
Reggie

--
e-mail: rberdinbigfoot.com
ICQ#:   31651436
URL:    http://www.bigfoot.com/~rberdin

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