The serial nature of microcontroller communication with hosts and peripheral devices.

Most communication between microcontrollers and the outside world is some type of serial connection. I'm talking about host,  server, cloud communication, and peripheral device communication. Wireless devices may transmit or receive in some parallel fashion but the communication between the wireless chip/board and the MCU is actually a serial protocol. 

Input and output devices, sensors, and actuators or displays can often be directly wired to microcontroller pins or they can be serial I/O attached.  Direct connection gives finer control at the lowest cost.  Serial allows for more devices with fewer pins extending the distance a peripheral can be from the microcontroller.

This content primarily is backing images for the video talk.  Content may be expanded over time

This is the foundation for a couple articles that will be specific to control/data patterns and device communications.  It started like many others as a different talk and I realized I wanted to cover this as a baseline for the other talk.

See the YouTube Video

Common Serial Types and Virtual Types

The primary serial interfaces by which devices are attached to microcontrollers. This is a little bit of a mixed metaphor because the USB types are protocols built on top of the physical serial implementations.

USB is a serial protocol that acts as the transport layer for a variety of virtual devices and other protocols.   This lets us stream multiple different protocols across the same single hardware connection. Those streams often each appear as their own virtual device on the attached host.  This means a microcontroller can appear as multiple devices to the host if the microcontroller library supports it.  

CDC virtual serial ports are the basis for most of the interactive prompt and upload / download functionality that developers see in the hello world examples.  FT232 USB to serial adapters are common devices that implement the CDC protocol. A single microcontroller can have multiple CDC serial streams open to a host at the same time if the microcontroller libraries support it. This lets us implement things like separate control and data channels over a single USB cable.

Everyone is used to plugging USB-based keyboards, mice, scanners, cameras, and other devices. They all appear as HID devices and communicate over a single USB to the host controller. Microcontrollers can be implemented or appear as HID devices with the correct code.
RX/TX here stands for a variety of asynchronous, timing-based serial including UARTs and other protocols like those used to communicate with LED strings.  Some serial protocols include flow control like DTR/RTS/CTS.  The communication is still basically serial and the flow control is often optional or used for actual control purposes like when flashing a device.

SPI and I2C are addressable bus styles that let you connect multiple devices to a single 2 or 4 wire connection.  These buses are great when you have more devices than pins or if you want to use sensors some distance from the host processor.   

Serial-based wireless and other communication

Wireless channels are generally serial from the point of view of the microcontroller.  There may be some wireless channels that increase their bandwidth via QAM or other techniques.  Most of those are still single-pin rx and single-pin tx to the microcontroller.  There are exceptions but I've never used them.

Most serial communication can be implemented in hardware or software.  Serial protocols can be implemented in hardware or software.  Hardware SPI or I2C is faster and can be implemented with a lower processor load leaving capacity for other tasks like calculations and communications.

A lot of software development is over hardwire serial connections or JTAG.  There are a variety of computer and other interfaces that essentially terminate on the microcontroller as a type of RX/TX plus some flow control pins.  Optical communication is essentially just a light bridge of the serial protocol.  The most basic is a pin-attached LED on TX and an optical receiver to an RX pin. 

Serial-based attachments - Inputs and Outputs

A lot of Input and Output attachments communicate over serial buses. This lets you attach multiple I/O devices to a microcontroller on a shared set of pins. This comes with a tradeoff of latency and a bit of a loss of fine timing controls.  

Some microcontrollers have multiple hardware-implemented serial interfaces of various types effectively increasing the bandwidth by letting you attach sensors across the serial devices.  It is also possible to implement serial protocols in software and the cost of some CPU and control.

Example Serial Device Chain

Serial buses let you attach multiple devices with only a few wires. You trade off fine grain timing and control against fewer wires and the ability to attach more devices consuming fewer processor pins

Direct attached and embedded non Serial

Displays tend to have high bandwidth needs that increase with a power of 2 to the size of the display.  this drives a lot of displays to some type of parallel interface.  That is usually used to load the display frame buffer.
Microcontrollers can directly interface with external devices and control or sense through them. Direct attachment tends to be cheaper and more directly controllable for tight timing loops because it eliminates the bus overhead of the serial devices.  

Bus-based devices have more overhead and more latency but let you attach more devices to the controller because you can have multiple per bus and multiple serial busses.


Revision History

Created 2023 02


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs