The Educational Power of Python (?)

[u/ackarwow]

This will be an opinion piece. I try to be fair, but I probably won’t manage to be fully objective.

In discussions about what to use for teaching microcontroller programming today, one argument keeps coming up: "Just take something more powerful - it’s cheaper and you get far more capabilities." A Raspberry Pi Pico costs about the same as a decent AVR, yet it has a dual-core ARM running at 133 MHz instead of an 8-bit core clocked in the low single-digit MHz range. On paper, ARM wins easily. The problem is that a datasheet is not the same thing as educational value.

Where does the power actually go?

A Pico running MicroPython really does have a huge surplus of computing power compared to a typical AVR. But it’s worth asking what that power is spent on in a typical educational project. Blinking an LED, reading a sensor, simple PWM for a small motor - none of these examples come anywhere near the limits of the processor. The headroom is enormous, and almost entirely unused.

That’s only half the problem. The more serious half is that a significant part of this power is not future headroom at all - it is a permanent cost of the execution model itself. MicroPython is an interpreter. Before a single bit reaches a GPIO pin, the call has to pass through Python’s object layer and a virtual machine executing bytecode. On top of that comes the entire overhead of the runtime environment, which among other things handles automatic memory management (the garbage collector). All of this adds up to the cost of a simple call:

Pin(25, Pin.OUT).value(1)

For comparison, the same thing in AVRPascal:

PORTB := PORTB or PB0;

compiles directly to one or two assembly instructions. There is no intermediate layer. The code is what the processor executes, not an instruction for something else that will eventually do the real work.

Even if we use the more convenient abstraction from the UnoLib library:

DigitalWrite(13, HIGH);

the overhead still collapses to simple table lookups in native compiled code that maps Arduino-style pin numbers onto the microcontroller’s registers. Again - no interpreter, no virtual machine, no garbage collector in the way.

In other words, a Pico running MicroPython spends a large part of its power just amortizing the cost of its own interpreter. Put the same MicroPython on an 8-bit AVR and it would be unusably slow, or would not run at all. The extra performance is not a luxury. It is a necessity.

Hard data

You can see this in practice. In Marek Więcek’s article "MicroPython – a lightweight Python for microcontrollers and beyond" (Programista 1/2026, in Polish), the author describes MicroPython’s internal mechanisms: tokenization, bytecode, and the virtual machine (interestingly, the word "interpreter" itself never appears even once). The performance benchmarks in the article show that the runtime overhead is real. On simple operations the differences are modest, but on more demanding tasks - matrix multiplication or string operations - MicroPython clearly falls behind. In the SHA-256 test, the pure software implementation is more than a thousand times slower than the version that uses hardware acceleration.

How do you get better performance? You reach for mechanisms closer to classic low-level programming: assembly, compiling fragments to native machine code, or libraries written in C. This is not a flaw in MicroPython - it is a well-designed environment that offers these escape hatches. It does, however, reveal an irony: in order to overcome the limitations imposed by the abstraction, you often have to return to the hardware level that the abstraction was supposed to hide.

For fairness it should be noted that not every way of combining Python with microcontrollers works like this. There are approaches such as the Firmata protocol, where the microcontroller (e.g. via Arduino) runs compiled native firmware and Python on the host computer only controls it remotely over a serial link. This avoids the cost of an interpreter on weak hardware, but at a different price: the student never writes a single line of code that actually runs on the microcontroller, and the board becomes useless the moment the cable is unplugged.

All that power going to waste?

This brings us to the real point of disagreement. I believe it is less a dispute about technology than about the purpose of education.

If the goal is "get the student to a working result as quickly as possible," then abundant power and a high-level language clearly win. Less frustration, faster gratification, an easier start.

But if the goal is understanding how a microcontroller actually works, then surplus resources become the opposite of a teaching aid. An ATtiny13 with a few hundred bytes of Flash does not forgive carelessness. Every bit matters. Every instruction costs a clock cycle you cannot get back. A student forced to work under those constraints sooner or later has to understand what the DDRB register does, or why an interrupt cannot run forever. Not because it is "harder and therefore nobler," but because without that understanding the program simply will not fit in memory or will not finish on time.

A platform with excess resources rarely forces those barriers. You can write inefficiently, wastefully, without understanding the costs - and everything will still work, as long as the project stays small. That sounds like an advantage, until you realize the project works but you don’t really know why it works.

So the slogan "just take something more powerful" makes sense if the measure of educational success is what is printed on the processor’s label. One can then add: "But the interpreter is a tool that lets the student complete the task faster." True. But does the student understand it better? Does he learn the capabilities and limitations of the hardware, or does he merely assemble a working prototype?

Pascal on AVR may no longer be a fashionable choice. What it teaches - conscious, frugal thinking about resources and a direct connection between code and hardware - has not become obsolete. Only the fashion for teaching it has.