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.
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)