ESP32 + Raspberry Pi = UNO Q?

A defining feature of the new Arduino UNO Q is the combo of a Linux computer along with an Arduino microcontroller (MCU). It's the idea of combining the processing power of a microprocessor (MPU) along with the real-time control of a MCU.

Now, this is a new idea for a single board computer (SBC) in the maker world. However, it is not a new idea in general.

I've done a number of projects with this architecture: MPU + MCU. In the past, I've connected a Raspberry Pi to some Arduino-supported MCU board via serial. The serial connection allowed for easy data transfer between the Arduino and the Raspberry Pi.

In fact, Arduino has chosen to do the same thing. Connect a STM MCU to a Qualcomm MPU via serial. Let's dive into this a bit more.

Serial communication

There's a reason I did this in the past and why Arduino has chosen to do the same. Some reasons include:

• Serial is incredibly flexible in the data you can write.
• It's supported well in Arduino libraries and in Python libraries.
• It is easy to debug and is human-readable

One can get an Arduino and a Raspberry Pi communicating in minutes by either connecting serial over USB or using the breakouts on the headers.

There are some trade-offs, however. These trade-offs include:

• With flexibility, means you need to define a communication scheme/protocol.
• It's not the fastest communication method.

With the UNO Q, Arduino has solved the first trade-off with the Arduino_RouterBridge library. An older, simpler version of the library can be seen in their Bridge library that was meant for the Yun, that had a similar MCU+MPU architecture. I've always written my own serial protocols for my applications.

For the second trade-off (speed), I'll make the case that you do not need speed. The point being that the intent of the architecture is to not rely on speed.

Why add an MCU to my Raspberry Pi?

The reason you do this is so the MCU can independently control time-sensitive control. For example, if.you are using an Arduino MCU to control motor position, the MCU merely needs to be told what position to be at. All of the low-level controls for monitoring a motor (like a servo) happen inside the MCU. The Raspberry Pi MPU will be completely unaware of that control. The Raspberry Pi just needs to know if the action is complete (or what state the motors are in).

This frees up the Raspberry Pi to do higher-level tasks. For example: image detection, connecting to the internet, displaying a user interface (GUI), or even deciding on the next action to take. Essentially:

MPU = The Brain, MCU = The Body

This brings me to why the ESP32 as the MCU.

Why the ESP32 + Raspberry Pi?

After diving pretty deep on the Arduino UNO Q and its new App Lab, I can say the programming of this board can be confusing. There are a lot of layers of software happening in the background to enable the App Lab experience. And, these layers make me uneasy.

The reason I have always gravitated to Arduino in the past was because of simplicity, which I lightly cover in another post as well. This new App Lab with its Docker and the MCU's specific implementation of Zephyr RTOS makes things very complicated. So much so that you don't always know what is going on when programming the UNO Q.

If simplicity and understanding are what we are after, the ESP32 and Raspberry Pi are great candidates. They provide great community support and there are plenty of examples on how to use them. And, plenty of makers already have them in their toolkits.

The only additional layer you need is a communication link, which would be serial in this case.

And, the nice part about this combo, is that you can get as complicated as the UNO Q, if you so desire.

Make it as simple or as complicated as you want

The simplest setup is serial over USB. From there, you have most of what the Arduino UNO Q has. It's just in two boards rather than one (we'll get to that later). However, what I would suggest is to make a Raspberry Pi Hat that connects a ESP32 to the serial ports of the headers. That way it is nice and clean. It also frees up the USB port on the ESP32 for programming.

If you want to make it truer to the Arduino UNO Q setup, you could add another layer. Connect an SPI interface between the two. This is the only other connection on the UNO Q between the MCU and MPU. This enables programming the MCU directly from the MPU. In essence, it turns the MPU into a programmer. However, I think this isn't necessary to gain the benefits of the architecture.

Two boards isn't really a trade-off

Some people on my TikTok have argued that it isn't really a Single-Board Computer (SBC) any more. But, I ask, what does that gain you?

Sure, the UNO Q packages two computers on to one board. But, you'll need to add other shields/hats/boards to make it useful. So...

Either with the UNO Q or the Raspberry Pi + ESP32, you'll still have a stack of boards. You'll need shields, hats, or breakout boards to get utility out of either.

Is one extra board really that bad?

Maybe we should call it the Double Board Computer (DBC)?

To the Double Board Computer (DBC)

At this point, I think I've made my case. An ESP32 + Raspberry Pi DBC. You'll get the benefits that the UNO Q but with less complexity. As a recap, all you need have is a serial connection.

ESP32 + Raspberry Pi + Serial = DBC