Serial output transmit real HEX ? not Ascii-HEX

Ltech

Need some boost !

I use Full_duplex_serial to sent hex codes.
The code is a variable integer, example "88866344"
I need to sent this in Hex code
So has to be "05 4B FE 28" looking on Realterm program hex 8 bit mode

I use Fullduplexseria, command "text.hex(88866344,8)" sound easy....
=> bad output it is Hex translated in ascii " 30 35 34 42 46 45 32 38 " , not HEX code

It is frustrating, I can't find the way to get it


Thanks :crazy:

gis667en11

I actually haven't gotten around to playing with FDS yet, but does it have a shiftout method? It sounds like what you really want is just a bit by bit send and receiver

Electrodude

You don't want text.hex. "text.hex" sends it as hex characters in ascii. Just use "text.tx". You'll need to chop up your long into bytes, since text.tx sends bytes:

text.tx(data.byte[0])
text.tx(data.byte[1])
text.tx(data.byte[2])
text.tx(data.byte[3])

Most people would refer to this as sending it in binary, rather than hex, since one bit is sent at a time, not four.

JonnyMac

If you want to see the bytes MSBFIRST, reverse the order from Electrodude's suggestion:

  value := 88866344
  repeat idx from 3 to 0
    fds.tx(value.byte[idx])

Ltech

@Electrodude

Thanks for respons

I do not have acces to the lab now, so I can't test til tomorrow.

I try already text.tx (variable) .
But do you think text.tx (variable.byte[0])..... would make it a Hex value ?
Is this code not sending a 4 as HEX ..... then the next 4 as Hex ...

The text.hex result is correct, but in ascii translation (= 2 bytes / char)

JonnyMac

But do you think text.tx (variable.byte[0])..... would make it a Hex value ?
Is this code not sending a 4 as HEX .....

Please remember that computers store and transmit everything as BINARY. HEX is a shorthand notation of BINARY that is useful for humans; it has NO EFFECT on the storage or transmission of values.

Electrodude's example, and my looped version, are correct. If you have the ability to view bytes in HEX, it is your application that is doing the conversion for display -- it has nothing to do with the transmission or storage of the values.

JonnyMac

And here's proof. Notice on the RealTerm panel it actually says DISPLAY AS because everything is stored in binary; any other format for display is for human convenience.

Ltech

Update: Missed last print screen
@JonnyMac NICE ! 100% clear, Just what I need.
@Electrodude to point to .byte

Both of you are are really great peoples .

I have to wait tomorrow to test it. Lab is locked off
If this work we would be very happy
I missed the "x.byte[idx]" trick, never used myself.

thank again

JasonDorie

If you were doing this in C you could use:

unsigned char * bytes = (unsigned char *)&value;  // get a pointer to the bytes of "value"

for( int i=0; i<=3; i++ )
{
  text.tx(  bytes[i] );
}

This is basically identical to what Electrodude code is doing in Spin, and you'd reverse the order the same way as Jon showed.