1

I've done many projects that include a PC & an arduino / PLC / some kind of other microcontroller / processor, and in every project we had a different protocol used for communication between the PC application and the embedded one. Usually the hardware / controller developer invents a simple protocol which always changes throughout the project, and goes into the form of 

Barker | Size | Data | Checksum

This time I'm implementing both sides, so I figured - This has been done a million times before. There must be a base protocol for these things with implementations in C, C#, Java, and such. What I'm looking for is a lightweight layer that transfers stream based serial communication into a message based one.

I've been looking around for one for a while, but I couldn't find anything on my own. Do you happen to know one?

Nitay
  • 4,193
  • 6
  • 33
  • 42
  • Serial port protocols get invented over and over again, there is no standard. There was an attempt made, RFC 916, but it was widely ignored. It works well but is not entirely solid when connection attempts fail because the other party isn't running yet, it can't deal with buffered bytes very well. Which is the underlying problem, protocols are never 100% fail-safe. Pick anything or go shopping. – Hans Passant Apr 01 '15 at 09:21
  • A lot depends on the features you need: Can the data be broken into logical packets (e.g. commands/readings)? How do you want to handle errors? How likely are bit errors? Do the two nodes have good clock synchronisation? What is the frame sync mechanism? Is it hot pluggable? What is the buffering capability of each node? While I agree most people seem to reinvent the same protocol, there can be good reasons why people might choose particular features for each situation. – Jon Apr 01 '15 at 13:43
  • While I very much agree with you, it still seems though that all of these requirements could go into one library. What I had in mind is a simple library that supports all the features you mentioned in #ifdef, but still be lightweight. I gotta say I haven't found what I'm looking for, but one of the ways mentioned in the solution would probably suffice for now. It just seems a waste to write the same state-machine again but with different bytes. – Nitay Apr 02 '15 at 19:09

3 Answers3

3

I had exactly the same requirements for a recent project and I found nothing simple enough for low-end 8-bit microcontrollers. So I designed MIN (Microcontroller Interconnect Network) to do the job (inspired by CAN and LIN).

The code is on github here: https://github.com/min-protocol/min (check out the wiki there).

I defined a layer 0 (the UART settings) and layer 1 (the frame layer, with checksums, etc.) plus a C API.

I'm also working on a higher layer that formally defines how sensor data (temperature, pressure, voltage, etc.) are packed, with a JSON representation and a tool to autogenerate the embedded code to pack/unpack them from frames. The end goal is to create a Wireshark dissector that can be clipped on to the serial line and when fed with the JSON will display the signals in human-readable form.

I wrote a blog post showing a Hello World app running on an Arduino board (with an FTDI UART-USB breakout board carrying the data up to my host PC):

https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/

This serial problem occurs so often that it would be nice if we as a community just nailed it rather than keep re-coding it for every project.

Ken Tindell
  • 343
  • 4
  • 7
1

Check Open Source HDLC

I recently came across MIN - never used this one though

Also check this Simple serial point-to-point communication protocol

Community
  • 1
  • 1
abRao
  • 2,787
  • 1
  • 25
  • 37
0

Using X/Y/Z MODEM protocol must be a good choice to solve your problem. It's easy to implement and ready-to-use. I use X-MODEM on an ISP tool communicates with our cortex-m0 powered MCU, and it works pretty well.

kevin wu
  • 72
  • 4