1.2 Framing and Device Addresses

Table of Contents Framing and packet structure Timing considerations Device addresses Sequence of a request-response data transmission Sequence of a broadcast transmission

Framing and packet structure

• The transmission of data is organized in packets made of single bytes.
• The transmission of one byte requires a constant byte time.
• A packet always consists of
  • one address (1 byte),
  • any number of data bytes and
  • a checksum (1 or 2 bytes) (see Checksums).
• Data bytes are optional: the smallest allowable packet consists of address and checksum.
• Only the master is entitled to initiate data transfers by sending a packet.
• The master is required to send packets as a continuous string of bytes.
• The master can either send a request or a broadcast packet, distinguishable by the address, see below.
• For the slave, a packet is considered received if
  • since the last complete reception of a byte, a time of 1.5 byte times has elapsed,
  • the packet address matches an address applicable for the slave device and
  • the checksum is correct.
• If condition 1 detects the reception of a packet, but condition 2 or 3 is violated, the packet is discarded.
• Slaves can only send response packets in reaction to a packet received from the master.
• The slave is allowed to send its answer in non-continuous chunks.
• For the master, a response packet is considered received when
  • the expected number of bytes is available,
  • the checksum is correct and
  • the maximum response time has not been exceeded.
• If condition 1 detects the reception of a packet, but condition 2 or 3 is violated, the packet is discarded.
• The master is not allowed to send a packet until it either received a response packet or the maximum response time is exceeded.

Timing considerations

One consequence of the above rules is that in most cases the master must ensure that a minimum time interval of 1.5 byte times is observed between two successive transmissions. This is the case, if

• slave A sends a response packet and the master sends a new packet to slave B or if
• the master has sent a broadcast (which does not require a response packet). In this case, attention must be paid to the minimum delay before each new packet. Practically the master must wait longer than that to account for processing time in the slaves.

Otherwise a slave device could interpret the response of a different slave or a broadcast and the following packet as one single packet, resulting in a checksum error. On the other hand this means the master does not have to wait between successive transmission with the same slave device.

The above mentioned maximus response time is not specified, but should be appropriately selected depending on the capabilities of the slave devices, which should hint their typical response times in their documentation. If a slave device starts complex operations upon receiving a command and needs to return a result, an asynchronous approach might be the better choice, meaning the first request starts the operation, indicating the successful start in the response. The master can subsequently poll for its completion with a status command.

Device addresses

The address is the first byte of every packet. It allows a maximum of 127 devices on the bus.

0x00	Broadcast addressed to all slaves.
0x01 ... 0x7F	valid slave adresses
0x80	master address used in response to a broadcast request
0x81 ... 0xFF	master address with coded address of origin

Sequence of a request-response data transmission

The master sends a packet of the following content on the bus:

Slave address	1 Byte
data (optional)	n Bytes
checksum	1 or 2 Bytes

The addressed slave responds with a package:

slave address + 0x80	1 Byte
data (optional)	n Bytes
checksum	1 or 2 Bytes

Sequence of a broadcast transmission

The master sends a packet with the following content on the bus:

Broadcast address 0x00	1 Byte
Device protocol ID + fast broadcast flag	7 Bit + 1 Bit
data (optional)	n Bytes
checksum	1 or 2 Bytes

The device protocol ID makes sure that the same broadcast defined in different device protocols do not lead to unintended behaviour.

Normally slaves do not respond to broadcasts. Yet it is allowed to define broadcasts with responses, if measures are taken to prevent bus colissions by appropriate means. A response looks like this:

0x80	1 Byte
data (optional)	n Bytes
checksum	1 or 2 Bytes

Normally implementations should aim to defer packet processing from interrupt to main or thread context. In special cases where fast response times and low jitter are required, device protocols may implement fast broadcasts which should be executed within the interrupt which received the packet. A fast broadcast is transmitted by adding 0x80 to the device protocol ID field. Thus normal and fast broadcasts have separate command spaces.