Why choose an RTOS environment for a Connectivity stack

[virgild]

A connectivity stack is basically a networking model and set of communication protocols tailored for a specific technological direction – small, cheap, low-power devices with embedded digital intelligence, connected in various topologies.

The communication protocols use well-defined formats for exchanging messages, specific communication phases for access management and tight time synchronization constrains, necessitating deterministically deadlines accomplishment.

As design, the communications protocols are structured using a layering scheme as a basis and usually follow a consecrated networking model – the Internet model. This allows the decomposition of single, complex protocols into simpler, cooperating protocols, but it is also a functional decomposition, because each protocol belongs to a functional class.

The correct vertical interactions, both logically and chronologically, between the layering protocols ensure the proper functioning of the system.

An RTOS simplifies the design process of a system dividing it into multiple independent elements – tasks, assigning them specific priorities (based on their importance) and separating logical, functional and executional context.

So mapping the protocol layers of a communication stack to tasks into an RTOS-based design is straightforward – assigning the correct execution priorities to the compositional tasks, being able to model prioritary actions or functions inside a layer by splitting it into specific sub-components – tasks with intermediary priority.

It is desired to use a preemptive RTOS, due to the unpredictable nature of the communication over the media. This feature allows to ensure that the high priority tasks, like a Physical Layer transmit or receive task, are execute deterministically, are not delayed and do not interfere nor impact with the execution of upper layer tasks or activities.

Since multitasking in an RTOS is basically a perceived concurrent execution of tasks, multiple activities can be achieved with no impact on the structure of the communication protocols, e.g. Rx or Tx in the same time as some (serial) data acquisition and human interaction.

The vertical communication paths – usually described as Control Plane and User (or Data) Plane are implemented either using synchronous, or asynchronous methods:

• Classical function/callback calls for synchronous aspects, aided by elements like events, mutexes, semaphores
• RTOS-specific data flow mechanisms (messages, message queues, mailboxes, shared memory).

Ensuring a fast time to market (rapid porting to additional or next gen-like platforms or ramp-ups or kickstarts) can be leveraged by benefiting of the RTOS’s defining characteristics:

• abstraction layer to the underlying microcontroller
• continuous provision and support for BSPs & Drivers
• middleware availability:
  1. File system
  2. USB
  3. User interface (graphics)
  4. Networking
  5. Device I/O
• tools integration & debugging capabilities