Understanding Raspberry Pi/SBC's at the same level as microcontrollers

Question

I'm a fourth-year EE student and I have just recently started to dive a bit deeper into trying to understand how microcontrollers work at a low level when it comes to running code and performing its operations. I think I have a decent grasp on this subject with MCUs, but I am not nearly as confident when it comes to systems that utilize a Single Board Computer (SBC) such as the raspberry pi or beagle bone.

With a microcontroller based on an ARM-cortex-M, I think I understand the process of writing the code which is converted into assembly instructions for that specific processor and then finally converted to the binary file which is written to the flash memory on the MCU. Whenever the processor runs, a bootloader basically tells the actual core where to look for additional instructions to run. It then proceeds to run through the program and the program can interface with all of the various peripherals that are attached to the chip.

With an SBC, I'm just not quite sure where to start. Take the raspberry pi 4 B for example. I know it has a chip based on the ARM-Cortex-A series which includes a MMU, which is apparently very important for the features that an OS needs such as memory virtualization. But when I go to write a program that will then execute on the hardware, to me, it just seems like it executes on the OS, and I don't know what is actually going on in the hardware. I know that the whole point of the OS is to abstract away this hardware implementation, but I've done some initial reading and it just hasn't made too much sense yet. I've started looking into learning about the Linux kernel but I'm not sure if that's where I need to be spending my time learning. The first step that I've always taken when working with SBCs is to install Linux and that is a bunch of abstraction that I want to dig deeper into to actually know what is going on.

A couple of questions that have propped up in my research that I am still unclear on are:

1. What is the difference between a microcontroller and a microprocessor? Is it just the external chips needed to support a microprocessor?

2. Would it be possible to program the raspberry pi easily in a bare metal fashion to perform a hello world led blinky?

3. Am I taking steps in the right direction by trying to learn about what a kernel does and how it is programmed or am I better off starting somewhere else to approach this topic?

I think that most of where my questions come from are the result of me being unfamiliar with operating systems since I am not a CompE, but I would appreciate guidance and some answers on this topic and what the best way to approach this beast is.

Answer 1

The ‘code’ doesn’t execute on the OS - the OS provides services to the ‘code’ and schedules its execution. The MMU along with virtual memory create a ‘sandbox’ for the application. If the application tries to access memory it hasn’t been allocated, then an exception occurs that the OS handles. The application can’t get to the outside world (i.e access gpio, video etc) unless the OS has allowed it to or more commonly, the OS provides services for those features. The application is a bit like a babe in the womb - everything it requires is got via the umbilical to the OS. The application ‘talks’ to the OS via a trap mechanism which is basically a software interrupt. The exact mechanism varies for different architectures.

1. Micro-controller vs processor - a bit tricky to pin down exactly. A microcontroller generally has on board flash and is intended for control applications - no mmu or virtual memory. In the case of the Pi, the memory is external to the chip. Unfortunately there are exceptions either way.

2. Program the Pi ‘bare metal’ - sure, plenty of examples of people doing this. Just set the mmu to give a ‘flat’ memory space and from then on its the same as running code on an Arduino. Why isn’t it done more commonly? The peripherals of the Pi are intended for a set top box, not an Arduino style controller. Besides, you ‘ve got wifi, ethernet and a bit chunk of ram and your paying for the power consumption of a big machine, so it makes more sense to run the likes of Linux to get all your networking and filesystem features.

3. All knowledge is good knowledge. There’s plenty of resources on the interwebs regarding OS architecture. A common text is by Tannenbaum, the title I forget. Its not super complicated either - there are some very basic concepts to grasp and then it all starts to make sense. Google ‘demand paged virtual memory’

Answer 2

1. There's no fundamental difference between a microcontroller and a microprocessor. The former is smaller, cheaper, lower power, and intended to run embedded programs. The latter is bigger, more powerful, and intended for use as a general purpose processor, running many different programs. But a microcontroller today can be more powerful than a microprocessor of a couple of decades ago. That said, modern microprocessors support extra features, such as virtual memory and protected instructions, intended to run modern operating systems.

2. Yes, if you really wanted to. But initialising the hardware I/O might be more complex.

3. It depends where you want to end up. Operating system design is a massive area to study. And a Raspberry Pi is pretty much the same as a modern desktop computer. It just doesn't come inside a case as standard.

Answer 3

Cortex-A profile is not a microprocessor. There are a lot of answers on how a microcontroller (MCU) differs to microprocessor. Including other answers here. But this is about old style microprocessors, i.e. like Intel 8080. Modern Cortex-A chips are mostly so-called System-on-Chip (SoC). It's quite a bit more than a microprocessor and even MCU. While it shares some things from microprocessor (like not having embedded flash memory), it also has a variety of integrated peripherals, like MMU, WiFi, Ethernet, DDR RAM controller, Flash controller, PCI-E, LCD controller, video codecs, etc. And even built-in GPU.

You can view SoC as much more advanced than an MCU, but they share different applications usually. As SoC's are more advanced, they are much more complex. That's why they usually utilize OS to control all those things. But yes, you can run a so called "bare metal" code on Cortex-A and other SoCs usually. And you can some types of OS on MCUs (there are even Linux versions for MMU-less platforms).

There are still no strict borders. It's all more nominal and there are exceptions. But just as an instrument some things are much more better suited for the task. You wouldn't expect to have a fully fledged Linux boot up on a on simple fridge or a washer. MCU are just enough there to control those hardware. Consider you make it more complicated, adding an touch-screen LCD for example, and it will take to have SoC there for graphics & UI. Probably keeping MCU to control main functions, and SoC will just communicate with it over some sort of internal protocol.

Answer 4

The first step that I've always taken when working with SBCs is to install Linux and that is a bunch of abstraction that I want to dig deeper into to actually know what is going on.

Rpi has Raspbian OS that is based on Debian. At the very begining the RPi couldn't "swalow" the official Debian due to particularity of Broadcom CPU. With a lot of efforts they made a lot of software, drivers, examples this "useless" and cheap CPU became so popular.

Would it be possible to program the raspberry pi easily in a bare metal fashion to perform a hello world led blinky?

With Rpi this is almost as simple as using Arduino thanks to WiringPi and similar tools. The competitors make clones of WiringPI, but not all of them, so it might be not as easy.

Am I taking steps in the right direction by trying to learn about what a kernel does and how it is programmed or am I better off starting somewhere else to approach this topic?

You have to install kernel source, headers, compiler. Then you can do also your drivers if you want. A good thing is that Linux is opensource, so you can start modifying and installing device drivers that already exist.

At the time, the RPi didn't have eMMC, large RAM, onboard RTC, powerful CPU ,... so I moved to one another ARM board that was more compatible to Debian. There is a site called Armbian, they do remove features of official Debian that are not supported by those ARM boards, making a compact versions of Debian with the latest Linux kernel. I had no idea of Linux, Rasbian, Debian, kernel, ...but I managed to write a device driver (from a similar driver) for SPI OLED display and the application communicating on I2C power meter chip and storing data in database. But it took efforts, no way I could do it on Windows.