Hi David,
If you are in control of both sides of the conversion, then there's no need to use BCD and things would be more efficient and easier to code to simply convert the large integer into its upper/lower byte values.
If you 'think' of the number in hexadecimal, this is trivial. In your example, 144000000 = 0x08954400. Each 2 hex digits comprises of a single byte, so this naturally splits up into the following 4 bytes: 0x08, 0x95, 0x44 and 0x00. 4 bytes can represent any unsigned number between 0 and 4,294,967,295 (i.e. 0x00000000 to 0xFFFFFFFF) - in Flowcode we call this a "ULONG" integer type.
To split this up, simply use masking and bit shifting. The following example can be put into a calculation icon:
Code: Select all
byte_array[0] = ulong AND 0xFF
byte_array[1] = (ulong AND 0xFF00) >> 8
byte_array[2] = (ulong AND 0xFF0000) >> 16
byte_array[3] = (ulong AND 0xFF000000) >> 24
and reconstituting is also trivial, again in a single icon:
Code: Select all
ulong = byte_array[0]
ulong = ulong + (byte_array[1] << 8)
ulong = ulong + (byte_array[2] << 16)
ulong = ulong + (byte_array[3] << 24)
Note that none of this requires the ulong to be 'written' in hexadecimal or for you be converting or displaying it as such. Any integer in the program is not defined or restricted by its visual (i.e. human-readable) format. The computer or micro running your code 'sees' every integer as a series of 1's and 0's. So don't worry about me mentioning hexadecimal (but as a programmer, it is very useful to see integers as hexadecimals because this better represents the 1's and 0's that a computer 'sees').
I've not checked that these work. But I think they should.
OTOH, if you do require specific BCD conversion, that is not too difficult either. It's just more wasteful in terms of effort, processing speed and memory. You would only need to do this if you were not in control of the other side of the conversion and were forced to convert to BCD.
HTH,
Steve.