MOSP : Minimal Overhead Serial Protocol
This page is a work in progress… The purpose of this page is to describe and specify the general ideas behind MOSP, so that fellow engineers all over the world will be able to make their own implementation.
Changelog
- 07/09/2008 page created
- 09/09/2008 elaborating some more on frames
1. What is MOSP?
MOSP (Minimal Overhead Serial Protocol) is a protocol being developed by Tom Verschooten. MOSP’s main goal is to allow gradual implementation of algorithms onto embedded systems. MOSP will allow a more flexible debug solution for amounts of data which would be impossible to oversee with traditional debuggers (such as KEIL uVision in combination with an ULINK).
2. Features
- Benefits
- Simple Serial Protocol
- Error detection through checksum
- Easy to implement
- Flow Control
- Drawbacks
- Slow
- No timeout handling
3. MOSP Communication
3.1 Single Communication
The most basic form of communication featured by MOSP is a Single Communication. In general, a single communication consists of 2 frames :
- An instruction
- A reply (ACK, NACK or DATA)
The image above shows a Single Communications can be divided into two cases :
- A SET-instruction : An instruction to set a specified parameter in the slave device is sent. As a reply an ACK or NACK is expected
- A DATA-request : A piece of data is requested from the slave device. As a reply a DATA-frame is expected by the master.
3.2 Burst Communication
As a supplement to Single Communication MOSP also features a simple form of Burst Communication.
- Benefits
- An increase in overall transfer speed
- A decrease in overhead
- Drawbacks
- Implementation gets slightly more complex
- If a corrupt frame is detected, it has to be requested again by the master through single communication
The image below shows a simple example of how a Burst Communication works.
Note that the slave never receives 2 consecutive frames or more. As a result the slave’s reception buffer only has to supply space for 1 frame.
3.4 MOSP Frame Layout
The frame layout used by MOSP is fairly straightforward and always consists out of 7 bytes, each with it’s own purpose :
- Frame type : this flag field determines the type of frame
- Argument : A frame type usually comes with an argument, specifying extra information about the frame type
- Data bytes speak for themselves. Notice that 4 databytes combined allow you to transceive 1 word of data
- Checksum : this field is a simple addition of all previous fields
Now let’s take a closer look at the specific layout for Instruction frames and Data frames :
- Instruction Frame
- Instruction flag : this is a simple ‘I’ character
- Command : Specifies the command for the slave to execute (note: this way you can set up your own instruction set)
- Command Argument : Specifies an argument to go with the given command (for example, set the memory pointer to a certain value)
- A note about ACK and NACK :
To generate an ACK or NACK frame for an Instruction Frame, replace the Instruction Flag by an ‘A’ or ‘N’ character and recalculate the checksum.
- Data Frame
- Data Flag : this is a simple ‘D’ character
- Frame Counter : Specifies the number of a frame in a burst (note that this also means the maximum amount of frames in a Burst is 255). For a Single Communication the value of this field is set to zero.
- The data field can contain a word of data.
4. Where to go from here?
So you’re probably wondering “Is the MOSP specification really this simple? Can it be we’re already through reading it?”. The answer is “YES!”. Since one of the goals of this protocol is to be “simple”, there’s really no point of overcomplicating things with a spec containing a thousand pages.
This specification still leaves a few things open to your own interpretation such as :
- The instruction set to be used in your application
- The layout of the 4 bytes of data
As a result, you still have a lot of freedom in your own applications, while using the MOSP frame layout and a combination of Single Transmissions and Bursts. This combination offers a lot of possibilities with only a minimum of effort to be put into implementing this protocol.
All additional information about MOSP on this blog can be found in the MOSP archives.
