Last week I gave a talk to the tech meetup Virtual Coffee giving software engineers an introduction to the world of electronics. I showed three different ways to flash an LED using Raspberry Pi, Arduino and a 555 timer. One of the questions at the end was why would we use one approach vs another.
This used to be clear-cut, but there is a much larger overlap now.
I’ve taken the approach of expanding this from Raspberry Pi to all embedded Linux Computers and Arduino all Microcontrollers.
Size and Form Factor
In general, embedded computers are larger than microcontrollers. However, you don’t have to look too far to find exceptions to that rule. Over the years, boards have been reducing in size.
For example, there is the Linux based Pocket Beagle a board was designed to fit inside a mint tin and measures 35mm x 56mm. The board has an SDCard socket and a micro USB along with some general purpose I/O (GPIO) for interfacing to the outside world (such as flashing an LED)
Equally, the Pi Zero and the Pi Zero W are both 66.0mm x 30.5mm which is smaller than the Arduino Nano which is 18 x 45 mm. As well as the GPIO the Zeros also have USB, Camera and a mini HDMI port.
Looking at the big Microcontroller based boards, there’s the Arduino Mega. This board uses its large size (101.52 mm x 53.3 mm) to provide lots of GPIO pins and multiple serial ports.
So size may be a deciding factor in picking a board but not in selecting if you go down the embedded Linux or Microcontroller route.
Similar to size, embedded computers are generally more expensive than microcontroller boards. However, the Raspberry Pi team have again taken away that differentiation with their Pi Zero costing (at today’s price) just £4.80. This is below many microcontroller boards. The notable exception is their own Raspberry Pi Pico which is just £3.60.
At the other extreme is the Arduino Portenta H7 costing £90.66. This board has a main processor consisting of two cores, one Cortex® M7 running at 480 MHz and a Cortex® M4 running at 240 MHz and is capable of image processing and running machine learning such as TensorFlow™ Lite.
The computing capability of the board is another key differentiator. As the Portenta demonstrates, there are microcontrollers out there with highly capable processors. The general rule though is that the embedded computers have more processing power than the microcontrollers. This does not mean they will be automatically faster at a particular task than a microcontroller-based solution as that is highly dependent on how optimised the code is.
Like compute power, memory is typically higher in embedded computers than in microcontrollers. So tasks that need lots of memory such as image processing, video or databases would be more suited to an embedded computer. One of the reasons that the Portenta can process machine learning models for images is that the images have been reduced to a smaller frame size. Often microcontroller projects can solve memory issues by storing data externally on a SDCard or flash memory. It is even possible to have a microcontroller hooked up to a Floppy Disk drive although that wouldn’t get you much more capacity.
Another thing that typically uses a lot of memory is having a display of some form attached to the project. This of course depends on the resolution. A small character-based display may only need a few hundred btyes of memory but a HD or 4K image will require many megabytes. There are ways to compress and stream the data but most video displays require a good amount of memory which pushes you down the embedded linux route. So for an arcade machine or media centre that would be your best choice.
Both embedded Linux and microcontrollers can talk to USB devices which means access to a wide range of storage devices and other hardware. Although, not all microcontrollers can support the higher speeds needed by devices such as webcams.
It used to be the case that there was a wider range of devices you could connect to your microcontroller vs embedded Linux computer but that’s really not the case now. There are a wide range of input and output devices, sensors and actuators that will work well with both. The plug-in accessories are called “Hats”, “Shields” or “Capes” and many of the boards designed for one can be adapted for the other. I’ve used both boards designed for a Pi with a microcontroller and those designed for a microcontroller with a Linux board. The key thing to watch for is the voltage of the I/O pins. This is often 5v, 3.3v but can be lower such as the 96Board spec which has a 1.8v range. Mixing the boards designed for different voltages may sometimes work but more often it results in unreliable communication or even blown up parts. There are devices called level shifters if you need to fix this issue.
The last thing to mention is power and the side effect of power which is heat. Most microcontrollers have power-saving modes which allow them to be put to sleep and run from small batteries for a long period of time. This is good for monitoring applications where a sample is taken once an hour or even once a day. This can be done with embedded computers but is typically a lot harder. The embedded computer often takes a few seconds to boot to the point of running your code where as the microcontroller is instantaneous. So if you had an application which needed to sleep (to conserve battery) but wake up and respond quickly then a microcontroller would be a good choice.
The nature of a Linux based embedded computer means that tasks such as writing to the disk or checking the time might interrupt some critical behaviour of your system. If you need to have control over this for say balancing a robot or controlling a machine tool then you will need to have some kind of real-time capability. The Beaglebone series provided this capability with their “Programmable Real-Time Units” but it is also possible by using a “Real-Time Operating System” although that may detract from one of the benefits of using Linux which is familiarity. The microcontroller provides much more deterministic behaviour as it does not typically have all these background processes happening.
Why not both?
Similar to the Beaglebone approach described above it is possible to create a solution using both a microcontroller and an embedded computer. The Dragon Detector shown above is an example of this in that the interface board to run the servo and lights is based around a microcontroller. The issue with this approach is increased part count which can lead to an increase in cost and size. Although a Raspberry Pi Zero and 3 Pi Pico will still cost considerably less than an Arduino Mega.
Should have used a 555!
The advantage of a microcontroller or computer is the flexibility but if your requirement is clearly defined then dedicated hardware can be a simpler solution. I’m not sure that a 555 timer is the best approach for many problems but I am planning to use at least one in my next project.