SMP Bus And Protocol

SMP Bus and Protocol

The goal of SMP is to have a completely modular design. We designed a custom protocol that allows multiple modules to be connected to a single bus and have plug-and-play ability. It can use almost any serial interface such as the built in UART that many microcontrollers and embedded systems have.

Why not use I2C?
I2C was initially considered as a posiible solution for allowing multiple modules but its master-initiated nature was undesired for what we had in mind. We also wanted each “slave” module to have their own local I2C bus to communicate with sensors and other devices.

Unlike I2C, communication can be initiated by iether the “master” or the “slave”. This allows the “slave modules” to transmit data without waiting for the “master” module to tell it that it can send data. This allows data to be sent as soon as it is ready, significantly reducing latency because the “master” module does not need to poll each “slave” module in the bus and check if they have data or is present in the bus.

Collision Prevention and Bus Control
Slave Modules
– In order to prevent packet collisions by multiple “slave” modules transmitting at the same time, the bus needs to be locked whenever a “slave” starts to transmit data. To achieve this, two pins are used to control and check the bus status. Whenever a “slave” module has data ready to be trasmitted it checks the state of the bus by checking its busyPin, if it in a LOW or 0 state the bus is available. The “slave” module then toggles its sendingPin to a LOW or 0 state then sends a packet of data. After the packet is sent, the “slave” module immediately toggles the sendingPin to HIGH or 1 state. An inverter and an OR gate is connected to the “slave” modules sendingPin to allow immediate locking of the bus once a module starts to transmit data.
Master Module – When no “slave” module is transmitting data, the “master” module sets its busyPin to LOW or 0 state. It also continously checks its receivePin, to detect if a module is sending data. Once a “slave” module toggles its sendingPin and is detected at the master’s receivePin, the master module immediately toggles its busyPin to a HIGH or 1 state which locks the bus. After the master module finishes processing the packet, it toggles its busyPin to a HIGH or 1 which frees the bus. The OR gate connected to busyPin the allows the “master” module start or hold the lock on the bus even if there is no “slave” module transmitting.

Schematic

SMP_BUS_schematic

Tri-state buffers are added in each of the sendinPin and tx pins of the “slave” modules to prevent “slave” modules from interfering with each other. This is achieved because the buffers are configured to only allow signals to be transmitted through them when the corresponding sendingPin is in a LOW or 0 state.

Signal Diagram

signalCapture

Signal 1: sendingPin(S)/receivePin(M)
Signal 2: busyPin
Signal 3: tx(S)/rx(M)

busyPinRiseTime

As shown in the diagram the busyPin is immediately set to HIGH when a “slave” module pulls it sendingPin LOW, thus locking the bus and not allowing other “slave” modules to transmit.

SMP Packet

Header Byte Module ID Byte Data Length Byte Data Bytes Array Checksum Byte

Header – Every SMP packet starts with a header byte with value 0xAA
Module ID – The second byte is module ID byte
Data Length Byte -The third byte is the data length byte which is corresponds to the size of the number bytes in the data section of the SMP packet.
Data Bytes – Data section of SMP packet. Length is determined by the Data Length byte.
Checksum Byte – The last byte sent in every SMP packet. The checksum is calculated by summing the Module ID, Data Length, and Data bytes.

Slave to Master data transmission
Bus Scheduling
Whenever the bus is free, the first “slave” module to see a free or open bus gets to transmit. However, when the bus is locked, the “slave” module waits in the bus stop(loop). The time a “slave” module spends in the bus stop is determined by its priority. Prioritization is not determined by the “master” module but by the individual “slave” module themselves. Each “slave” module determines the priority of the data it needs to transmit. A “slave” module that has a higher priority has a statisically higher chance of getting to re-check the state of the bus when it is not free, thus having a statistically higher chance of getting a time slot to transmit its data. Also as a “slave” module spends in time the Bus Stop, it priority gets upgraded, preventing high latency even for low priority modules. Additionally an optional timeout feature can be implemented, preventing old useless the data to be trasmitted.

Master to Slave data transmission
Data transmission from “master” to “slave” module is in broadcast mode. This means that all modules that is connected to the bus receives all data that is transmitted by the “master” module.

 

Leave a Reply

Your email address will not be published. Required fields are marked *