-
Notifications
You must be signed in to change notification settings - Fork 88
Home
MIN is a simple point-to-point frame based protocol designed to connect a microcontroller to a PC (or other microcontroller).
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.
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
There are three layers to the protocol:
-
[Layer 0] (Bit). This is the UART setup. The specific baud rate is determined by the application hardware and software. But MIN has been 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 (Application). The application as specified by the system designer. This defines the meaning of payload data and imposes any desired 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).
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.
A C API for Layer 1 is defined.
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. Both are used in a test program that illustrates MIN being used with an Arduino Mega 2560 board and some breadboard I/O.
There are additional features of MIN, including:
- A transport layer for carrying block or stream data.
- 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 tools to autogenerate layer 2 code for signal handling using the JSON description.
- 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).