Cloud and Software Architecture, Soft skills, IOT and embedded
The serial nature of microcontroller communication with hosts and peripheral devices.
Get link
Facebook
X
Pinterest
Email
Other Apps
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.
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.
I do a lot of my development and configuration via ssh into my Raspberry Pi Zero over the RNDIS connection. Some models of the Raspberry PIs can be configured with gadget drivers that let the Raspberry pi emulate different devices when plugged into computers via USB. My favorite gadget is the network profile that makes a Raspberry Pi look like an RNDIS-attached network device. All types of network services travel over an RNDIS device without knowing it is a USB hardware connection. A Raspberry Pi shows up as a Remote NDIS (RNDIS) device when you plug the Pi into a PC or Mac via a USB cable. The gadget in the Windows Device Manager picture shows this RNDIS Gadget connectivity between a Windows machine and a Raspberry Pi. The Problem Windows 11 and Windows 10 no longer auto-installs the RNDIS driver that makes magic happen. Windows recognizes that the Raspberry Pi is some type of generic USB COM device. Manually running W indows Update or Update Driver does not install the RNDI
The Windows Subsystem for Linux operates as a virtual machine that can dynamically grow the amount of RAM to a maximum set at startup time. Microsoft sets a default maximum RAM available to 50% of the physical memory and a swap-space that is 1/4 of the maximum WSL RAM. You can scale those numbers up or down to allocate more or less RAM to the Linux instance. The first drawing shows the default WSL memory and swap space sizing. The images below show a developer machine that is running a dev environment in WSL2 and Docker Desktop. Docker Desktop has two of its own WSL modules that need to be accounted for. You can see that the memory would actually be oversubscribed, 3 x 50% if every VM used its maximum memory. The actual amount of memory used is significantly smaller allowing every piece to fit. Click to Enlarge The second drawing shows the memory allocation on my 64GB laptop. WSL Linux defaults to a maximum RAM size of 5
The Apache Tika project provides a library capable of parsing and extracting data and meta data from over 1000 file types. Tika is available as a single jar file that can be included inside applications or as a deployable jar file that runs Tika as a standalone service. This blog describes deploying the Tika jar as an auto-scale service in Amazon AWS Elastic Beanstalk. I selected Elastic Beanstalk because it supports jar based deployments without any real Infrastructure configuration. Elastic Beanstalk auto-scale should take care of scaling up and down for for the number of requests you get. Tika parses documents and extracts their text completely in memory. Tika was deployed for this blog using EC2 t2.micro instances available in the AWS free tier. t2.micro VMs are 1GB which means that you are restricted in document complexity and size. You would size your instances appropriately for your largest documents. Preconditions An AWS account. AWS access id and secret key.
Comments
Post a Comment