Author Topic: Thoughts on Message Protocols on Multidrop UART  (Read 4576 times)

0 Members and 1 Guest are viewing this topic.

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26917
  • Country: nl
    • NCT Developments
Re: Thoughts on Message Protocols on Multidrop UART
« Reply #25 on: July 23, 2021, 08:29:22 pm »

Yeah casting the whole byte array as a struct is a really good way of "parsing" the data.
Until you get burned a couple of times. I have stopped casting structs onto received data a long time ago. You will run into endianness problems and unaligned accesses which may silently fail causing corruption which is hard to spot. The portability between systems & compilers just sucks. I'm using readable text based protocols almost exclusively because they are easy to debug, easy to extend and easy to port.

Well when things break due to endianess or unaligned access the whole thing pretty clearly blows up to let you know. As for padding issues making it overrun the memory, that can be caught as an assertion by running the struct trough sizeof()
No, it can break silently causing subtle errors you won't spot until you've got a huge load of units in the field.

Uh. In theory, you're right. In practice, for this to happen, meaning having never spotted any issue with enddianness or alignment for the whole development cycle of the product, including testing, it would take a clueless team with near to zero testing. Seriously.
And yet it happens with hundreds of devices installed in the field used by dozens of customers. No, this is not my code. Just a bug that took me a couple of days to track down due to the many layers the software & hardware consists of.

Quote
Also, you probably need to do more testing. Frankly, if you ever implement data structures with a mismatched enddianness or mismatched alignement and your tests can't spot that, then you (or your test team) should probably change jobs. Yes yes, sure, tests are not everything,  but again if your tests haven't spotted a problem with this, then test coverage is clearly poor. When testing a communication protocol, it looks like a good idea to at least tests all parameters in a given protocol block, and a reasonable range of values for each. Just saying.
That is a lot of extra testing effort you can avoid by writing code which can't go wrong by design (no matter the compiler, platform or endianess). The particular piece of code that I had the unaligned access bug in has been thouroughly tested by the creators using a PC. However, the final target is an ARM CPU.
« Last Edit: July 23, 2021, 08:34:56 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf