Skip to content
kentindell edited this page Feb 15, 2015 · 22 revisions

MIN (Microcontroller Interconnect Network)

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 resource-constrained 8-bit microcontroller to communicate periodic signal data (e.g. temperature and speed sensor readings) reliably with another microcontroller or a PC using a UART in such a way as to require little resource (CPU time and RAM). Existing protocols using special hardware (e.g. CAN, Ethernet) are not suitable. Nor are RAM-hungry protocols such as PPP or SLIP.

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
  • Send and receive sensor data, commands and block data to and from a PC
  • Provide 'fail silent' reliability: if a frame is passed to the application is must be 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 layers

There are four layers to the protocol:

  • [Layer 0] (Bit). This is the UART setup. Layer 0 does not specify the baud rate - the specific baud rate is determined by the application hardware and software. Note that the protocol is specifically designed to allow a device to auto-detect the baud rate used by the other end.

  • [Layer 1] (Frame). Frames contain a payload of 0-15 bytes, with a three byte header, a single byte ID for the application to use to determine the meaning of the payload, a single control byte to indicate length, a 16-bit checksum and single byte end-of-frame marker.

  • [Layer 2] (Block). To support the exchange of an arbitrary length block of data this layer specifies how a sequence of frames with the same ID are used to implement block messages.

  • Layer 3 (Application). The application as specified by the system designer. This defines the meaning of payload data (for both frames and block messages) and imposes timeouts, acknowledgements, etc. The implementation of an application layer is not part of the MIN specification (MIN is designed to be well-suited to periodic transmission of state-based sensor data so that if a frame is lost due to transient errors then another transmission of the state will occur in due course).

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.

C API

A [C API] for the Frame and Block layers is defined.

Reference implementations

Two reference implementations are given for the Frame and Block layers. 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.

Clone this wiki locally