Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

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

by stevieb (Canon)
on Aug 06, 2019 at 20:02 UTC ( #11104058=note: print w/replies, xml ) Need Help??


in reply to Re: 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

"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 :)

  • Comment on Re^2: Code review: Start and End markers to ensure Serial data is valid

Replies are listed 'Best First'.
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
    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". ;-)

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (6)
As of 2020-06-01 06:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?