1 Abstraction Levels in Embedded Systems

When debugging embedded systems that are using serial communication, it can be challenging to identify the root cause of an issue since there are multiple components/processes involved, so one of the most important things to do when debugging is to split the problem into smaller sub-problems and resolve each one individually.

Likewise, it is also important, when debugging serial communications to map issues, to the different levels of abstraction that form the system, as this can be used to narrow down the possible causes. As an example, the mikroBUS™ header, commonly found on the Curiosity Nano Development Platform, will be split into distinct abstraction layers. There are five general levels of abstraction, as shown in the diagram below.

Figure 1-1. Abstraction Layers of a Serial Bus

From the bottom up, the first to be displayed is the Mechanical level. This level determines the physical interface of the MikroBus and how it will physically connect with other components and devices. The specific Input/Output (I/O) connector properties, pin arrangement, etc., belong to this level.

Next, there is the Electrical level. This level covers the electrical characteristics between the daughter card and the motherboard, and the MCU. Logic levels, pull-ups, directionality, bus capacitance, etc., all belong to this level.

Above the Electrical level is the Protocol level. This level is for the specific timing and communication characteristics of the serial protocol being used to communicate between the daughter card and the motherboard. In the case of something like I²C, the Protocol level would cover topics like 7-bit addressing, ACK/NACK, clock frequency, etc. The Protocol level also includes the on-chip peripheral hardware that implements this behavior.

The Driver level is responsible for executing interactions on the Protocol level. This level is where device-specific software drivers for serial communications, such as I²C, UART, SPI, etc., exist. Functions like I2C_writeBytes or UART_writeBytes are examples of an API at this level.

And finally above that, is the Application level. The Application level is for abstracting commands and interactions with a sensor or other element. At this point, the API would look like SensorX_getValue or SensorX_sendCommand.

In many cases, real world applications are not as cleanly defined as the diagram shown in Figure 1-1, but the general idea is still the same. The key takeaway is that understanding where the issue occurs reduces the number of possibilities during the debugging process.