Hello everyone.
a similar task is described here
https://github.com/letscontrolit/ESPEasy/issues/539
when can be made of rules
SerialSendHex 0x08 0x22 0x00 0x00 0x00 0x16 ?
SerialSend does not allow sending arbitrary data, and adds at the end 0x0d,0x0a
and does not allow you to change the speed uart on advanset page, speed uart all 15200
Release mega-20200515
Djon
SerialSendHex
Moderators: grovkillen, Stuntteam, TD-er
Re: SerialSendHex
The Serial.write(buf, length) function sends your data as bytes.
It sounds like you want to send your data as ASCII so that a serial terminal will display strings like '55'. For that you need to use Serial.print(n, HEX) in a loop to process your buffer.
Note when you send a byte with Serial.write it uses one byte of bandwidth. When you send it as hex using Serial.print it will take two bytes of bandwith to send each byte of data. So unless you want to look at the terminal output directly it will be more efficient to send it with Serial.write. It's also easier for a receiving device to read it, since it doesn't have to be decoded from two-byte hex encoding back to a single byte value.
Also, your terminal program may be able to render the incoming datastream in hex. That can be useful if you just want to see the values coming across the wire and don't actually need them to be in human-readable format.
Edit: oh, and the reason you are getting "Uÿ" is because whatever viewer you are using is rendering those bytes as UTF8 code points, and in that encoding 0x55 codes for "U" and 0xFF is "ÿ".
It sounds like you want to send your data as ASCII so that a serial terminal will display strings like '55'. For that you need to use Serial.print(n, HEX) in a loop to process your buffer.
Note when you send a byte with Serial.write it uses one byte of bandwidth. When you send it as hex using Serial.print it will take two bytes of bandwith to send each byte of data. So unless you want to look at the terminal output directly it will be more efficient to send it with Serial.write. It's also easier for a receiving device to read it, since it doesn't have to be decoded from two-byte hex encoding back to a single byte value.
Also, your terminal program may be able to render the incoming datastream in hex. That can be useful if you just want to see the values coming across the wire and don't actually need them to be in human-readable format.
Edit: oh, and the reason you are getting "Uÿ" is because whatever viewer you are using is rendering those bytes as UTF8 code points, and in that encoding 0x55 codes for "U" and 0xFF is "ÿ".
Who is online
Users browsing this forum: No registered users and 37 guests