I coded my own hardware so that any numeric parameters needs to be in little-endian format. But I'm finding the PC likes to deal with numbers in big endian format.
Nice thing with Qbasic (which seems to be the only programming language I know that supports this directly) is that I can use mki$ and cvi and friends to help me in my quest.
So as an example, say the required packet format my hardware expects is as follows:
Byte 1: Function number
Bytes 2-4: 24-bit data
Byte 5: checksum
So my qbasic program will convert the string-hex format of the data to ascii to send down the serial line. By string-hex I mean where it prints hex characters as string.
For example, If I wanted to use function number 10 and the 24-bit data is the 24 bit number 254, and the checksum is 20, then in my program, I would have it process the string:
"0AEF000014"
Because 0A is hex for 10, EF0000 is little-endian 24-bit value for 254 and 14 is hex for 20.
Eventually I want to make these values not fixed. Say I want the user to input the 24-bit value in and he types 254 as the number
Somehow I want it to go down the serial line as data equivalent to qbasic's chr$(&HFE)+chr$(0)+chr$(0)
I'll write code to illustrate my point:
Code: Select all
funcn%=10
checksum%=14
myvalue&=254
'convert to output for serial
toser$=chr$(funcn%)+chr$(myvalue& AND 255)+chr$((myvalue&/256) AND &H100)+chr$((myvalue&/&H10000) AND 255)+chr$(checksum%)
;convert to user readable output
bytes$=""
for n%=1 to len(toser$)
bytes$=bytes$+right$("00"+hex$(asc(mid$(toser$,n%,1))),2)
next n%
print bytes$
If my number was a 32-bit number, I could maybe replace my thought of:
Code: Select all
... chr$(myvalue& AND 255)+chr$((myvalue&/256) AND &H100)+chr$((myvalue&/&H10000) AND 255)+chr$(chr$((myvalue&/&H1000000))
Code: Select all
mkl$(myvalue&)