Embedded device communication

An embedded device does not do its job in the ‘void’. It needs to interact (and communicate) with users and/or other devices. Even inside an embedded device, lots of communication is required between controllers and (external) peripherals, sensors and actuators.

Communication properties

In general communication happens

• one to one (e.g. a telephone call via a point to point connection), or
• one to many (e.g. radio broadcasting), or
• many to many (e.g. a meeting without moderation).

Is communication…

• full duplex: reading/listening and writing/talking can happen at the same time, or
• half duplex: also two way communication but if one talks the other must remain silent, or
• simplex: one way communication.

We can further differentiate by

• Is there a master – slave relationship defined, or
• can any member initiate communication, or
• a combination of both?

Even more properties that describe communication systems exist, but these will suffice for now. It is clear that they have impact on behaviour, bandwidth, latency, throughput, timing (determinability) and – let us not forget – cost.

Use a standard or design a custom communication protocol?

In the not-so-far-away past we were involved in creating a custom bus protocol: multi-point, master-less with Collision-Detection/Collision-Avoidance and at that time based on a UART peripheral with CAN transceivers. Creating a custom protocol takes a lot of effort: design, tweaking and debugging before reaching the required robustness level: Shortcomings and Bugs might creep up only late in the design or test stage depending on the (changed) use cases.
But before blindly engaging in the creation of a custom communication protocol, you must be absolutely sure that none of the existing (standardized) communication protocols fit the requirements. Using an industry standard means that pros and cons are well known and that at least several of the lower OSI layers have been properly analyzed, specified and designed.

In a series of articles to follow, we will discuss industry standardized communication protocols. Not many of these have real-time (and thus deterministic properties), but then not all communication has (hard) real-time requirements; it all depends on the system under design. Sometimes, the average latency (in this context, the ability to send a message as fast as possible) is more important than bus arbitration fairness in extreme conditions such as ‘bus storms’ (many bus members that try to send a message at the same time), as long as everybody is able to send its message within a reasonable time frame.