Re: Code review: Start and End markers to ensure Serial data is valid

[Anonymous Monk]

This node falls below the community's threshold of quality. You may see it by logging in.

[stevieb]

"Before you bother to re-invent a serial communication protocol, have you thoroughly examined every one that already exists?"

All? No. I've researched several different techniques because although UART does have standard protocol, there's no one defined packet protocol. Also no, I don't have the time to "thoroughly examine(d) every one that already exists".

Also, my question was an extremely high-level one looking for base ideas so that I can consolidate a packet protocol that I can use interchangeably with I2C, SPI, UART and the custom parallel hardware interface I'm designing into a PDIP IC without redesigning (or, as you say, re-inventing) TCP that'll work on my Linux/Unix systems, as well as on micro-controller devices with as small as 2KB of RAM, so I'm not looking for an already-created exact solution.

So, your "Didn't think so" is my "I've designed a multi-I2C-bus bit-bang technology for the Arduino/ESP that I'm currently porting to the Pi/Linux, so re-inventing helps me when need be".

Re-inventing a wheel isn't necessarily a bad thing; I've done it many times, as have all experienced developers/engineers. Reverse engineering and re-engineering something is a valuable learning exercise, and sometimes, the re-invention is better than the original :)

[afoken]

I can consolidate a packet protocol that I can use interchangeably with I2C, SPI, UART and the custom parallel hardware interface I'm designing into a PDIP IC without redesigning (or, as you say, re-inventing) TCP that'll work on my Linux/Unix systems, as well as on micro-controller devices with as small as 2KB of RAM, so I'm not looking for an already-created exact solution.

At work, we have a protocol that should fit your needs. Unfortunately, it is not available for the public. But I think I can give some hints:

• The protocol is actually a very tiny protocol stack.
• At the lowest level for transport over RS232, RS485, and similar, we have a message transport layer that uses some selected byte values to indicate start of message, end of message, and escape to allow transporting these three bytes without confusing the receiver.
• When using SPI, the CS line is used to indicate start and end of message, no start/end/escaping bytes needed.
• When using UDP/IP, we use a UDP packet per message, also no start/end/escaping bytes needed.
• We haven't used a parallel port so far, but assumung something like an old-fashioned PC parallel port, we could either use a spare status / control line to mark a message frame (like CS does for SPI), or we could simply use the parallel port as a byte transport layer like RS232, and use start, stop, and escape byte.
• There is also an I²C transport, specified but not yet implemented, very similar to SPI.
• TCP/IP and Bluetooth transports emulate a simple serial port.
• New message transport layers can be added as needed.
• On top of that message transport layers, we have a fixed-size header with some addressing, length, and optionally flags, an optional checksum and an optional payload. Part of the addressing is used to address devices on a bus, if we use a bus. Another part of the addressing is used to access various functions in software. In this respect, the message layer is VERY similar to I²C, and I²C was one of the main inspirations for the entire protocol.
• Our protocol allows to transport a payload containing an entire message, so you can transport messages through a chain of several connected devices in a hierarchy (a tree of nodes).
• Usually, we use a master-slave setup, but the protocol can also be used in a peer-to-peer setup if you have a full-duplex communication path.
• Using some standardized messages, we can detect and identify devices on a bus, even hot-plugged.

Alexander