UART binary issue - might help others

[SpiderKenny]

I recently moved some code over from a project I had running on HLK-7688A devices.
It uses RS485 to communicate with other devices.

I simply re-compiled the code using the Onion cross-compiler and it all seemed to work nicely.

Except one thing...
Every now and then I would get a corrupt message from a remote device. A chksum embedded in the protocol would not match, and ocasionally a length byte in the received bytes would be wrong too.
I thought it might be just a noisy RS485 line but when probing the actual RX line going into the Omega showed a perfectly valid signal.

On the wire the bytes would look something like this (in hex):

21 24 56 58 0D 00 01 00

But in the app the bytes being read() from the port would be something like:

21 24 56 58 0A 00 01 00

Thing is that the error was consistently the same error. Not like noise or random bits being flipped. Always the exact same corruption. I had never seen this before, this code had run fine on the HLK-7688A

It turns out that it was the terminal options I was setting on the file descriptor of the port I opened using open().
After opening the port with

fd = open(path, O_RDWR | O_NOCTTY | O_NDELAY);

I then use tcgetattr and tcsetattr to get the port options and modify things like the baudrate, parity, flow-control etc. I was using this:

options.c_iflag &= ~(IXON | IXOFF | IXANY);

But I had to change it to :

options.c_iflag &= ~(IXON | IXOFF | IXANY | ISTRIP | ICRNL);

To stop the pre-parser stripping the 8th bit from bytes and to stop it converting 0D to 0A (ie. CR to NL).

This is a bit of a simplified explanation, but it shows it pays to be careful with the options flags!
Funny how this never came up on the HLK-7688A - but they do use a very different build from OpenWRT.