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
|
![]() |
|
Customers
Other sites
|
|
![]() |
|
Addressing
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).
Sequencing
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.
Sender:
Receiver:
| 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.
|
|
