I like to understand what I am doing. As such I don't like abstractions that I don't understand even if I have (black box) model of what happens when I invoke which function. Most tutorials, that I have encountered have however relied on exactly that acceptance of black box abstractions when they introduce concepts. This is especially true for software development where many things that are done commonly are in reality teribly complicated but also sufficiently abstracted over to make it simple to use, yet not so simple to understand of course. This is where I want to differ.

First I only want to show you one very small subset of embedded development that focuses on using rust to program microcontrollers produced by ST-Micro a French/Italian semiconductor manufacturer. I also want to locate these Texts in the wider context of computing in general, as to help when needing to make an initial choice of how to go about and what to use in different situations, even though these situations will then not be investigated much (exept for the one I am focusing on). I also want to make the text a nice read and want to avoid a instruction style guide to the topic, even though there will be sections that will inevitably be structured that way.

So without further adew, let's get into it.

What, where, when, why?

So as you may have noticed we are living in amongst hundreds of computers. Many of them are more powerfull than supercomputers of decades past, and the march of the computer has still to realize it's full potential. The computers we know of are the ones that sit on desks and have keyboards and mice and screens attached to them. However these machines only make up a fraction of the total computers produced because they are (compared to some of their siblings) terribly expensive. The less well known computers probably live inside the keyboards and mice of the world, not to mention any of the other more or less "intelligent" applience that can be found in a household, never mind a highly automated factory. These computers, however small, are still about as powerfull as supercomputers of decades ago, however in stead of costing hundreds of euros for a single maching they cost about 1-5 Euros per computer and integrate allmoast everything a desktop PC has into a single chip. They lack the typical inputs and outputs like keyboards and mice but have a single peripheral that is connected to different logical parts of the computer inside the package. This universal interface is a Pin, and the class of computers I am talking about are microcontrollers.

Microcontrollers are literally everywhere and as their price has dropped steadily over the last two decades while their performance has increased to the point that the more powerful specimens outstrip desktop computers of the 80s and 90s. The possibility to change the behaviour of a product after it's production is another mayor reason for putting these inexpensive if terribly complex little black rectangles into almost everything that has electronics inside it, replacing the formerly dedicated electronics and leading to a sharp increase of system complexity.

You can build essentially any gadget you can think of using these little rectangles and that is what makes them so enticing to a "hobbyist" and a tinkerer like me. The downside of this whole endevour is the astounding complexity of the devices. A small 5mm x 5mm rectangle can easily have Documentation that numbers in the upper thusands to of pages. Mastering this complexity is quite a challenge and I hope I can help you with this text, even though I still beleive that other than working with these things on a dayly basis you may need years to fully comprehend these devices.

Despite my somewhat negative view on abstraction when it comes to teaching, I think that it is the only way to be able to be productive with these devices. Creating software abstractions for different usecases and systems make it simple to build useful things. This is why I will be recommending the use of either ready made libraries or other abstractions and why I have chosen rust as a programming language (I trust in the rust compiller to do it's job and catch the more blatent errors and reduce the elaborate abstractions to nice and fast code when compilling).

The microcontroller Zoo

If we look at the laptop/desktop market you find mostly three different manufacturers and two somewhat different types of computers. Intel, AMD and recently Apple are the major consumer facing companies that produce the Chips that are at the core of most modern PCs and servers and both Intel and AMD build chips that, when viewed from the perspective of software are essentially identical (They differ vastly in the manufacturing and architecture but present the same interface to the software (we will be talking about that interface shortly)). Apple has not sold any of their new laptops and desktops that will be utilizing a chip that was initially developed for their Phone yet. This chip has come to be powerfull enough to run at least part of their laptop lineup (even though I assume that they will be modifying the design of the chip somewhat when putting it in a laptop due to the much larger battery and better thermal performance that the larger size offers). This chip is effectively a distant relative of the microcontroller that I'll be using to build (hopefully) interesting stuff with. It also is a testiment to the fact that, even thoug for the untrained eye a phone and a laptop may seem vastly different the phone is catching up fast with the performance of a laptop making the only real difference one of the user interface.

The Apple products will be based on a chip that features a version of the ARM RIS (reduced instruction set) (the name of the company that designed the architecture, it is an acronym for Advanced RISC Machines). That shares some similarity with the instruction set of the chip I will be using.

The difference to the laptop/desktop market and the microcontroller market is that there are way more usecases that are different enough to warrent a different chip in the microcontroller market. Laptops and desktops have only few (however very high bandwidth) connectors to the outside world and are promarily used to produce pictures and sounds we humans can understand. Microcontrollers on the other hand moslty talk to other integrated circuits, be it sensors or motor control ICs or even other microcontrollers using a host of different communication methods and used in anything from a babyphone to control computer in an airliner. Every larger silicon vendor essentially has a family of microcontrollers that sometimes even have their own instruction set (AVR controllers are a nice example). Just to list a few different vendors, there are ST Micro, Texas Instruments, Infineon, Samsung, Microchip (AVR and PIC), NXP, Cypress, Broadcom and Freescale. Every single vendor has dozens of different chips in their portfolio catering to all kind of different applications.

So that is overwhelming. At least it is for me. The question quickly arises which one to use and what tradeoffs you face for picking one over the other. The good thing (at least for the hobbyist) is that you are not producing a product at volume, so many of the tradeoffs are entirely not your problem as ththe price difference of a few cent per unit makes a noticable dent in your pocket when producing a million units but is utterly unimportant when building a one-off project. Most of the more expensive chips have more IO and faster processors and more memory (the usual things really). But for most parts the computational power of these chips will be more than enough to accomplish your goals. Software support is way more important here.

Choosing your Controller

While you have the choice of thousands of different controllers with all kinds of features as last part of this article I'll cover what I think are imprtant criteria for choosing a microcontroller that will work for you.

The most important criteria of all is software support. That means how much software is allready available for your device. For learning purposes it is interesting and even useful to implement certain features yourself but in the long run you don't want to write every abstraction for every part of the controller by hand or write a new driver for every chip that you want to include in your project. So software support is key.

The second most important part after software support is the available tooling and documentation. Tooling should make it easy to get started using the controller and trying out new things with it. Easy to use toolchains are important to making the barrier of entry to writing software as low as possible so you can be as productive as possible as quickly as possible (again this is important outside learing how to do things and how things work). Important tools are the compiler, linker, programmer, programmer interface software, and lastly the debugger. Trust me a working debugger on a microcontroller is heaven. Debugging can be done multiple ways but a debugger is truly the most useful tool in the long run. Good documentation is another important thing. Datasheets and reference manuals will be essentially allways open when writing anything close to the hardware and a good reference manual will avoid much pain on the side of trying things out. Some manuals have unclear wording that can make all the difference when you are trying to implement something confidently. So look out for good manuals. I have however not come accross many manuals that where terrible (at least not for microcontrollers but I have had paragraphs in the STM32 reference manuals that where somewhat confusing and I'd have loved some more precice wording from time to time.

Lastly is the performance characteristics of the device. More is not allways better because it brings with it a higher complexity that you have to master. More powerfull chips may also only be available in packages that are difficult to solder onto your board so be aware of that when and if you are working with self designed electronics. The nice thing as a hobbyist is that you can essentially pick whatever chip you want without having to look out for the price. The most expensive chip I could find from STM on digikey was 17$ and that thing has a graphics and signal processing accelerator tons of ram has a display interface and lots more hardware to play with and it's reference manual is 1954 pages long. I doubt you will be needing even a fraction of that computing power and the problem will be you being able to master it's features more than the price of the device.

Outlook

So for the next installment I'll take a stroll through the architecture of such a modern ARM based microcontroller and explain the different features usually found there and how that interfaces with software. Then I'll look at ecosystems of controllers and development environments and try to describe their interplay. Hope you enjoyed it so far. Untill next time.