Skip to content
Ken Tindell edited this page Mar 24, 2017 · 22 revisions

Microcontroller Interconnect Network (MIN) version 2.0

MIN is a simple point-to-point frame based protocol designed to connect a microcontroller to a PC (or other microcontroller).

Rationale

There is often a need for a microcontroller to communicate periodic signal data (e.g. temperature and speed sensor readings) reliably with another microcontroller or a PC using a UART but where RAM and CPU time are so constrained (e.g. in an 8-bit microcontroller) that existing protocols such as PPP and HDLC aren't feasible.

Design Objectives

MIN was designed to meet the following objectives:

  • Be implemented efficiently in C on an 8-bit microcontroller with minimal RAM (overheads measured tens of bytes, not hundreds)
  • Communicate with standard UART hardware using 8-bit characters without any special wiring requirements
  • Be able to send and receive sensor data and commands to and from a PC
  • Provide 'fail silent' reliability: if a frame is passed to the application it must have been received correctly, else it is discarded
  • Be run in 'open loop' with minimal state: not to need negative or positive acknowledgements or require inter-frame and inter-character timing constraints

Protocol

There are two parts to the protocol:

  • Frame. Frames contain a payload of 0-255 bytes, with a three byte header, a single ID/control byte which contains an application ID (bits 0-5), with bit 6 reserved and bit 7 used to indicate if the frame is a transport frame (see below). A 32-bit CRC is used (version 1.0 used a 16-bit CRC but this proved to be insuffient to protect large volumes of logging data).

  • Transport. The transport protocol provides a sliding window with delivery guarantees.

Flow control

There is no flow control specified in MIN (neither CTS/DTS nor XON/OFF). Since MIN is designed for embedded systems, the design must be scaled such that the sender has the processing capability to buffer and transmit all the application data and the sender is fast enough to receive and consume the data as it is received. If a transmit or receive buffer overflows then this will result in frames being corrupted. Corrupted frames are discarded by the protocol.

The system designer should pay attention to the peak application data being sent to either ensure that the buffer space allocated is always sufficient to hold the data in the worst-case scenario or to ensure the application can tolerate frame loss in peak situations.

Reference implementations and test programs

Two reference implementations are given. One is in C and designed to fit the resource requirements of 8-bit microcontrollers. The other is in Python and designed to run on a PC and be used for testing or further development.

An example program running on an Arduino board and a host PC is also provided.

Soak test

There is a soak test included for Arduino and a Python host. The term 'soak' isn't quite appropriate: light moistening would be a better word since the Arduino USB CDC support is flaky and the connection will die after a few minutes of being hammered (it can be re-enabled by disconnecting the native USB cable and reconnecting).

The soak test includes faking line noise to ensure that frames are sometimes dropped and so tests the protocol recovers properly from that.

Future improvements

There are additional features of MIN, including:

  • A signals layer where the carrying of up to 32-bit data is formalised (with a JSON definition for describing signals and their packing into MIN frames).
  • A a run-time protocol for interrogating a MIN system to extract the JSON for its configuration.
  • A LUA-based dissector for Wireshark (with support for signals by reading the JSON signals and frame description).
  • Autobaud algorithm so a PC can automatically select the baud rate to talk to a MIN embedded system (where the PC cannot sample the RX pin).