-
Notifications
You must be signed in to change notification settings - Fork 88
Frame
A MIN frame consists of the following fields:
- Start of frame (3 bytes)
- Identifier/Control (1 byte)
- Length (1 byte)
- Payload (up to 255 bytes)
- Checksum (4 bytes)
- End of frame (1 byte)
It is shown in the diagram below:
+------------+------------+------------+------------+------------+------------+------------+-----------+----------+------------+------------+------------+------------+------------+------------+
| SOF 0 | SOF 1 | SOF 2 | ID/control | (Sequence) | Length | Data 0 | Data 1 | | Data 255 | Checksum | Checksum | Checksum | Checksum | EOF |
| 0xAA | 0xAA | 0xAA | | | | | | | | (MSB) | | | (LSB) | 0x55 |
+------------+------------+------------+------------+------------+------------+------------+-----------+----------+------------+------------+------------+------------+------------+------------+
The three SOF (Start-of-frame) bytes are the header that mark the beginning of a frame. If three 0xAA bytes in a row are received then this always indicates a new frame has started and the receiver must prepare to receive the rest of the frame; any incomplete frame reception prior to the reception of this header must be discarded.
An implementation of MIN is free to use the header to perform automatic baud rate detection (the value 0xAA in binary is 10101010 and this ensures there will be a sequence of the shortest pulses possible and hence the baud rate can be determined dynamically).
The Identifier/Control byte is an indication to the application layer on how to treat the payload. The top two bits are reserved for the protocol: bit 7 indicates if the frame is handled under the transport protocol. Bit 6 is reserved and must be 0. Bits 0-5 are for the application programmer to use.
The Sequence byte is used by the transport protocol and only present if the top bit of the Identifier/Control byte is 1.
The Length byte manages the control of the reception of the frame.
The payload of a frame can be up to 255 bytes (a zero-byte payload frame is permitted and will typically be used by the application to indicate an event has occurred). The payload bytes used to encode sensor and command data as words greater than a byte must be stored in network order. Network order is big endian (i.e. most significant byte transmitted first). The specific placement of words within a frame is determined by the application layer.
The Checksum is a 32-bit CRC transmitted in network order and is computed over the Identifier, Sequence, Length and Payload bytes.
The EOF (end-of-frame) byte indicates the frame reception has completed and that the receiving software can pass the frame up to a higher layer if the frame is well-formed.
In order to prevent any part of the frame body transmitting three 0xAA bytes in a row (and thus producing a false SOF header) the frame body (identifier, control, payload and checksum) is subject to byte stuffing as follows:
- For the transmission of a frame body if two 0xAA bytes in a row are transmitted a stuff byte with value 0x55 is inserted into the transmitted byte stream.
- For the reception of a frame body if two 0xAA bytes in a row are received then the next received byte is discarded.
The checksum algorithm used for MIN is the 32-bit CRC with an initial value of 0.
A received frame is valid if and only if all of the following are true:
- The calculated checksum matched the received checksum
- The SOF bytes at the beginning of the frame have the value 0xAA
- The EOF byte at the end of the frame (as delimited by the number of payload bytes) has the value 0x55
- All discarded stuff bytes have the value 0x55
An invalid frame is always discarded and never passed up to a higher layer. The transport protocol ensures dropped frames are retransmitted.