Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

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

by afoken (Canon)
on Aug 06, 2019 at 21:08 UTC ( #11104061=note: print w/replies, xml ) Need Help??


in reply to Re^2: Code review: Start and End markers to ensure Serial data is valid
in thread Code review: Start and End markers to ensure Serial data is valid

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 IC 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 IC, and IC 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

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
  • Comment on Re^3: Code review: Start and End markers to ensure Serial data is valid

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11104061]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (9)
As of 2020-04-01 17:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    The most amusing oxymoron is:
















    Results (18 votes). Check out past polls.

    Notices?