Decimal to binary conversion

[Demon]

Hi Luciano,

"From your code I see that the 5 decimal digits (input data)
are stored in a 5 bytes array. One byte per digit, so there is
no binary-coded decimal. (No BCD)."

That's why I do this:

DIGIT4 = DATAIN[0] - BCD48
DIGIT3 = DATAIN[1] - BCD48
DIGIT2 = DATAIN[2] - BCD48
DIGIT1 = DATAIN[3] - BCD48
DIGIT0 = DATAIN[4] - BCD48

Using 0 as an example, I convert each digit individually from an ASCII value (0011 0000), to a binary value (0000 0000), by subtracting 48 (0011 0000). I am left with digits which are compatible with BCD format; bits in the lower nibble representing 0 to 9.

The Assembler sub-routine takes care of doing all the math, all I had to do was prepare the digits. I tested the routine with numbers like 56,789 and it worked flawlessly, the 2nd time (11011101 11010101). LOL I had some stuff backwards and used the wrong variable as input. But that's a chair-keyboard problem, the sub-routine is good.

I'm curious though, can you tell me how many cycles your code converts into once it's all said and done? The author of the sub-routine boasts 33 cycles, I wonder if that is truly remarkable, or if he's only 2 or 3 cycles less than your solution.

Robert

[Demon]

Luciano,

One thing that appeals to me about your solution is the ease of expansion. I can easily add digits without convoluted maths exercises. I requested an expanded version of the sub-routine from the author to support 128MBytes, but I don't like doing that. If I need additionnal digits for gigabytes for example, then his sub-routine won't work and I am unable to expand it myself.

I really like the fact that your solution can be easily expanded with an extra variable and a simple math statement.

I'm just curious in the resulting performance difference. Is it really a big deal?

Robert

[Luciano]

Robert,

From where do you receive the 5 digits?
(Terminal program > Serial port)?

Luciano

[Demon]

Hi Luciano,

Yes, and no. Yes from the serial port, no from the terminal program, kinda. I'm using an RS232 chip into COM1. I'm using the serial window in IDE 'cause it's the only way I can transfer data down to the PIC. The reception variable is defined as VAR BYTE[5].

You probably know my opinion of HyperTerminal if you read my post in the other thread. LOL I'm trying RealTerm, but I don't know what I have to set. I get the COM1 8N1 thing done, but I must be missing other key parameters 'cause I can't get it to work.

My goal is to download a file in one instruction. Right now I'm sending parts of a record at a time manually. Good for testing, bad for final implementation. I have 2 sequential HSERINs for now:

HSERIN recordtype

IF recordtype = bla-bla-bla
HSERIN recordformat
ENDIF

When I send "recordtype-recordformat" in one SEND, it doesn't work. I'm still trying to figure what I'm missing. I can send both separately, but I can't chain them in a single string and have the program treat data section by section.

The plan is to add several other formats, and have them processed depending on the record type prefix. I'm still learning serial communication so I can quite easily have flaws in my approach. This works on main frames, but I'm not in Kansas any more.

Robert

[Luciano]

Hi Robert!


The following will also work.

========================================
Pseudo-Code:

ee_address VAR WORD
SERIN2 RxPin,84,[DEC5 ee_address]

========================================

Type the decimal number 62347 in
your PC terminal program.


After receiving the 5 ASCII bytes
the SERIN2 command will store the
decimal value 62347 in the
variable ee_address.

See PBP manual for SERIN2 modifiers, works
also with command HSERIN and HSERIN2.


Luciano

[Demon]

Uhhh, so you're saying I'm doing this conversion for nothing?

Robert
LMAO!

[mister_e]

Uhhh, so you're saying I'm doing this conversion for nothing?

Indeed dude.

I'm trying RealTerm, but I don't know what I have to set. I get the COM1 8N1 thing done, but I must be missing other key parameters 'cause I can't get it to work.

go to 'pin' tab then uncheck RTS and DTR... you'll be in business. Chances are because you're using an ICD adapter and those pins force your chip to reset.... that's it IMHO. OR you type in text box... you can send number

pretty sure HSEROUT is not working also ?!?

My goal is to download a file in one instruction. Right now I'm sending parts of a record at a time manually. Good for testing, bad for final implementation.

you may need 1 or 2 extra flow control pin for that to avoid dumb or messy download. 1 to tell the pic you're going to receive data, one from the pic to the PC to confirm you receive a byte and you're ready to receive another.