Useful, efficient software matches the user's needs, knowledge and skill. Don't buy a swiss army knife when you need a wrench...

About Us

A young company still hungry for challenges, with 30+ years of experience with software development from small embedded systems to distributed real time PC networks and SQL databases. A reasonable design effort to deliver high-quality software e.g. for medical devices on schedule.

External Links




     Other sites


In the generic case we have a common medium where many nodes can communicate. Somehow the protocol must be able to determine which messages are relevant for the listening node, and possibly the origin of the message.
Simplest case is a point to point connection. In this model the receiver and receiver knows (by topology) that the message is sent to/from the other node.
One option for a multi-node network is that all messages are broadcasted and every node receives every message and from the contents of the message determine if it is interesteing or not. This is what we have done so far, but in many cases we want to organize the addressing part explicitly.
Defining some roles: a master or client initiates a transmission and one or more slaves/servers receive the message, possibly replying of performing some activity specified in the message.
If the master transmits a message ID the slaves can from this ID determine if it is interesting to them. Message IDs are meant like topics rather than addresses, thus any master can send a message about a topic and any slave can listen and act on any number of topics. Notably CAN bus uses this notation.
On many buses the message ID is structured where part of it identifies a node ID, thus dedicatig a message to a certain receiver. In a multi-master network it can be beneficial to also include the maser node ID in the message ID allowing the slave to send data dedicated for a dedicated master node. On a single master network no master address is reqired. Even if the slave initiates the transmission only the master will listen since no other slaves will listen to the slave address. It may also be omitted if the network guarantees that the response from the slave is sent back to the sending master before any other master can take control of the bus.
Often a message contains both the master address and the slave address. In some cases nodes are both master and slave meaning masters and slaves share a common address space. In other networks slaves and masters have separate adderss spaces they are not necessarily the same size. One byte could for instance support a network of 4 masters and 64 slaves (2 + 6 bits) or 8 masters and 32 slaves.
In a peer to peer network address space is symmetric and 8 bits can only address 16 nodes, each one being either master or slave.
Sometimes one address is reserved for broadcasts to all slaves (or possibly all masters or all nodes).
If a sender does not wait for acknowledge of one message before sending the next one there may be an ambiguity on which message is acknowledged and which is not. One way to deal with this is to supply an arbitrary id (frame ID) with each message and the acknowledge indicates which message the acknowledge refers to. This can increase throughput in a system where communication latency is long in comparsion with raw data transfer.
In general the sender should handle lost packets by e.g. resending or report to the master software that the slave could not be contacted. If the arbitrary IDs are created sequentially and the receiver checks that they are received in sequence there must be a means to restart the sequence in case there is a hard failure transmitting the message.
To be of any value you need at least three sequence numbers. With a single bit (2 values) only there is no way to tell whether the sender re-sent a mesage or you lost a message in transmission.

< Previous
Putting it all together
The frame ID can be considered part of the message ID.
With all this a message frame could look like this:
type master slave frame-ID data crc framing
Header fields may be bit-stuffed and master, slave or frame-ID may be zero bits in length. E.g. if you have an UART able to transmit 9 bits per byte they may be allocated as follows:
bits name Description
1 C/D 0 = remaining 8 bits are data
1 = control
1 D/A 0 = data packet
1 = ACK packet
2 M ID of master node
3 S ID of slave node
2 F Frame ID
Thus one byte header for a network allowing 4 masters, 8 slaves and 4 unacknowledged data packets per connection. Or skip the frame ID and allow 4 masters and 32 slaves.
Or add another header byte allowing more bits per field.
One byte must be reserved as framing char though, e.g. disallowing master0 to send a frame to slave 0 with frame ID=0. One way is to allow only frame ID 1-3, not 0.
On an 8-bit channel you would probably wnt to reserve fewer codes, e.g. reserving START, END, ACK and ESC bytes for type of frame (escaping these in the message), having 8 bits in the second header byte for addressing and optionally frame ID. E.g.
START head data crc END
ACK head ack-data crc END
Everything from head to crc (including) escaped when byte s reserved.
Maximum length
In general there is a fixed number of bytes of overhead for each message. This causes longer messages to contain less overhead in relation to the payload. The drawback of long messages is that they reserve the bandwidth for one transfer while other, maybe important messages are postponed until the long message is transmitted.
In general the solution is to split long transfers up in several smaller or just not allow messages over a certain length. E.g. CAN and LIN bus interfaces allows a maximum length of 8 bytes. Now that we have "error-free" delivery of packages it is easy to generate arbitrary length messages in the data bytes sent, e.g. having a length specification first, or a command implicitly specifying length. This would be the next layer in the protocol stack. In this case sequential frame-IDs may be beneficial.
Another option is to allow a higher priority message to suspend a bulk transfer and after transmission resume the bulk transfer again. Just add two more codes INTR and ENDINTR reserved in the message. If source is another node in the network some arbitration need be done of course.
A third option is to reserve some bandwidth, e.g. every 10th byte, to high-priority tasks. This consumes potentially a lot of available bandwidth for bulk transfers though.
Another reason to split up bulk transfers into shorter mesages is that messages are often buffered and you don't usually want to allocate large buffers, nor overwrite application data until correct message is received.
Copyright 2013 Useful Software Sweden AB E-mail:, Phone: +46 708 727662 
Useful Software Sweden AB