I took part in the making of this Scratch-based CS textbook for Italian primary school (6-11).
To keep in line with tradition, I managed to fit in a couple of microbe-sized graphic adventure games :-)
A manager at an electronics company once told me: “Many job seekers come here thinking they are embedded programmers, just because they can program an Arduino“.
What did he mean? Was he referring to the limited capabilities of the 8-bit Arduino Uno? To the lack of a true operating system? To the relative simplicity of the device?
Not at all: he meant they could not think as embedded programmers, because they were used to see things through the filter of the Arduino libraries. They did not see the hardware they were programming.
What is embedded programming?
“Embedded programming” has in fact a range of meanings, going from programming a regular computer nested within another machine (say, your bank ATM) to programming a piece of hardware ‘bare-metal’ (or ‘bare-silicon’) as in the case of the chip controlling the microwave oven that bakes your dinner.
In the electronics industry the term, sometimes spelled “firmware programmer” (not exactly the same thing, I will not go into the differences here) generally tends towards the latter meaning.
In this post too I will refer to an “embedded programmer” (or “microcontroller programmer”) as somebody who, given a piece of hardware, can fully understand and control it.
The Arduino libraries are a great idea
Don’t get me wrong: the Arduino libraries and its simplified IDE are great ideas: they are designed so that a ‘regular’ programmer could easily control hardware devices.
With the Arduino base libraries, plus libraries written by other people, you can ‘make‘ things just by putting together pieces of pre-made code, without needing to be a specialist. If you want to turn on the on-board LED, it is certainly easier to write:
than to write (and fully understand the implications of):
PORTB |= _BV(PB5);
Moreover, the former code has a much higher change of working on different devices (say, a 32-bit Arduino) with minimal or no changes.
Also, you will definitely start learning embedded programming with the Arduino libraries. So, why am I saying “Don’t stop there”?
The price to pay for comfort
There is no such thing as a free lunch: using the libraries keeps you away from the underlying physical device. Let’s consider the cost of programming only through library calls:
- The libraries do things behind your back. For example, the base Arduino library keeps track of time, allowing you to call functions such as millis(), micros() and delay(). This is very useful, but it can disrupt any precision timing you are trying to achieve. There are many such implications and surprises, some rather subtle.
- Library calls take time. Calling digitalWrite() is roughly an order of magnitude slower than controlling a digital output directly. You are using only a small fraction of the available power.
- You do not really understand what is going on: that means you are not in control. Being in full control of the hardware is what ‘real’ embedded programming is about.
- If you look into library source code, you will probably not understand much of it. You will also be unable to write your own library. You are missing an important part of microcontroller programming.
- Last but not least: you are not learning reusable skills. Try switching to a non-Arduino board and you will find yourself marooned on a strange land. The underlying concepts are identical, but the available libraries will be completely different.
Keep a healthy balance
In short: using libraries is like programming a computer, not like programming hardware. It is much easier, but it is also rather limiting.
As a proof, have a look at my play-v6 to see (or rather, hear) what ‘bare-metal’ programming can do.
Generating real-time music requires very precise timing control; it is quite difficult to achieve it through library calls, even with a much more powerful and fast microcontroller.
Am I telling you “Ditch the libraries, use only bare-metal programming”?
Not at all! By all means, use the libraries to get results fast, to ‘make’ things, to get fun.
But don’t stop there! Learn to control the hardware directly and you will be able to combine the best of two worlds: in time you will became a real embedded programmer. You will wield real power over all the microcontrollers of the world!
(insert evil overlord’s laugh here)
As soon as I started posting, I found myself under an unexpected (though welcome) work overload.
I apologize to readers and I ask for a bit more patience.
With a little bit of C optimization:
For those interested in the workings of the Medusa compiler, here are the slides from the Lua workshop 2014.
I talked today (via remote connection) about the Medusa compiler at the Lua Workshop 2014 in Moscow.
I should really think about writing some documentation…
I open this blog, kindly hosted by quintadicopertina, with good news and bad news.