Book Image

Embedded Systems Architecture

By : Daniele Lacamera
Book Image

Embedded Systems Architecture

By: Daniele Lacamera

Overview of this book

Embedded systems are self-contained devices with a dedicated purpose. We come across a variety of fields of applications for embedded systems in industries such as automotive, telecommunications, healthcare and consumer electronics, just to name a few. Embedded Systems Architecture begins with a bird's eye view of embedded development and how it differs from the other systems that you may be familiar with. You will first be guided to set up an optimal development environment, then move on to software tools and methodologies to improve the work flow. You will explore the boot-up mechanisms and the memory management strategies typical of a real-time embedded system. Through the analysis of the programming interface of the reference microcontroller, you'll look at the implementation of the features and the device drivers. Next, you'll learn about the techniques used to reduce power consumption. Then you will be introduced to the technologies, protocols and security aspects related to integrating the system into IoT solutions. By the end of the book, you will have explored various aspects of embedded architecture, including task synchronization in a multi-threading environment, and the safety models adopted by modern real-time operating systems.
Table of Contents (18 chapters)
Title Page
Copyright and Credits
Packt Upsell
Contributors
Preface
Index

Interfaces and peripherals


In order to communicate with peripherals and other microcontrollers, a number of de facto standards are well established in the embedded world. Some of the external pins of the microcontroller can be programmed to carry out communication with external peripherals using specific protocols. A few of the common interfaces available on most architectures are:

  • Asynchronous UART-based serial communication
  • Serial Peripheral Interface (SPI) bus
  • Inter-integrated circuit (I2C) bus
  • Universal Serial Bus (USB)

Asynchronous UART-based serial communication

Asynchronous communication is provided by the Universal Asynchronous Receiver-Transmitter (UART). These kind of interfaces, commonly simply known as serial ports, are called asynchronous because they do not need to share a clock signal to synchronize the sender and the receiver, but rather work on pre-defined clock rates that can be aligned while the communication is ongoing. Microcontrollers may contain multiple UARTs that can be attached to a specific set of pins upon request. Asynchronous communication is provided by UART as a full-duplex channel, through two independent wires, connecting the RX pin of each endpoint to the TX pin on the opposite side.

To properly understand each other, the systems at the two endpoints must set up the UART using the same parameters. This includes the framing of the bytes on the wire, and the frame rate. All of these parameters have to be known in advance by both endpoints in order to correctly establish a communication channel. Despite being simpler than the other types of serial communication, UART-based serial communication is still widely used in electronic devices, particularly as an interface toward modems and GPS receivers. Furthermore, using TTL-to-USB serial converters, it is easy to connect a UART to a console on the host machine, which is often handy for providing log messages.

SPI

A different approach is SPI. Introduced in the late 1980s, this technology aimed to replace asynchronous serial communication towards peripherals, by introducing a number of improvements:

  • Serial clock line to synchronize the endpoints
  • Master-slave protocol
  • One-to-many communication over the same three-wire bus

The master device, usually the microcontroller, shares the bus with one or more slaves. To trigger the communication, a separate slave select (SS) signal is used to address each slave connected to the bus. The bus uses two independent signals for data transfer, one per direction, and a shared clock line that synchronizes the two ends of the communication. Due to the clock line being generated by the master, the data transfer is more reliable, making it possible to achieve higher bitrates than ordinary UART. One of the keys for the continued success of SPI over multiple generations of microcontrollers is the low complexity required for the design of slaves, which can be as simple as a single shift register. SPI is commonly used in sensor devices, LCD displays, flash memory controllers, and network interfaces.

I2C

I2C is slightly more complex, and that is because it is designed with a different purpose in mind: interconnecting multiple microcontrollers, as well as multiple slave devices, on the same two-wire bus. The two signals are serial clock (SCL) and serial data (SDA). Unlike SPI or UART, the bus is half-duplex, as the two directions of the flow share the same signal. Thanks to a 7-bit slave-addressing mechanism incorporated in the protocol, it does not require additional signals dedicated to the selection of the slaves. Multiple masters are allowed on the same line, given that all the masters in the system follow the arbitration logic in the case of bus contention.

USB

The USB protocol, originally designed to replace UART and include many protocols in the same hardware connector, is very popular in personal computers, portable devices, and a huge number of peripherals.

This protocol works in host-device mode, with one side of communication, the device, exposing services that can be used by the controller, on the host side. USB transceivers present in many microcontrollers can work in both modes. By implementing the upper layer of the USB standards, different types of devices can be emulated by the microcontroller, such as serial ports, storage devices, and point-to-point Ethernet interfaces, creating microcontroller-based USB devices that can be connected to a host system.

If the transceiver supports host mode, the embedded system can act as a USB host and devices can be connected to it. In this case, the system should implement device drivers and applications to access the functionality provided by the device.

When both modes are implemented on the same USB controller, the transceiver works in on-the-go (OTG) mode, and the selection and configuration of the desired mode can be done at runtime.