Lesson 23 of 28 intermediate 7 min read

Programming microcontrollers: languages, use cases & limits

Q: What languages do you use to program a microcontroller?

**C and C++** dominate embedded work because they compile to fast, compact code with tight control over memory and hardware. **MicroPython** and **CircuitPython** trade some speed for ease, letting you script the chip in Python. **Embedded Rust** is an emerging option that brings memory safety to bare metal. Raw assembly is used rarely, only for the most timing-critical fragments.

Q: How do you get your program onto a microcontroller?

You **cross-compile** on your PC — turning your code into machine code for the chip's processor, not your computer's — and then **flash** it over USB into the chip's memory. There's no terminal or editor on the device itself. To see what's happening you usually print messages over a **serial** connection back to your PC, or for deeper work use a hardware debugger over JTAG/SWD.

Key takeaways C/C++ dominate — with MicroPython for ease and embedded Rust emerging for safety. A compile-flash-run workflow — you cross-compile on your PC, flash over USB, and debug over a serial link, because there’s no terminal on the chip. Tight limits by design — kilobytes of RAM, a strict power budget, and no OS conveniences are the constraints microcontrollers trade for owning real-time, ultra-low-power jobs.

You’ve met the microcontroller, the Arduino, and the wireless ESP32. This lesson ties the module together by looking at how you actually program these chips — the languages, the workflow, the jobs they’re uniquely good at, and the hard limits you design around. It also draws the line for when to stop fighting an MCU and step up to a single-board computer.

The languages of embedded

A handful of languages cover almost all microcontroller work, each with a clear trade-off between control and convenience:

Language	Style	Strengths	Trade-off
C	Low-level, compiled	Fast, compact, total control over memory and hardware; the industry default	Manual memory management; easy to make subtle mistakes
C++	Compiled, higher-level	C’s speed plus classes and libraries; what Arduino uses	Can pull in overhead if you’re not careful
MicroPython / CircuitPython	Interpreted Python	Very easy; fast to experiment; no compile step	Slower and uses more memory; not for tight timing
Embedded Rust	Compiled, modern	Memory safety without a garbage collector; growing ecosystem	Steeper learning curve; fewer libraries than C
Assembly	Lowest level	Exact control of every instruction	Painful to write; used only for tiny critical fragments

C and C++ dominate for good reason: they compile to fast, small machine code and give you precise control over the chip’s memory and peripherals, which matters when you only have a few kilobytes to work with. MicroPython and CircuitPython flip the priority toward ease, letting you script a chip in Python — wonderful for learning and quick projects. Embedded Rust is the rising newcomer, offering memory safety on bare metal. And raw assembly survives only for the rare, ultra-timing-critical fragment.

The compile, flash, run workflow

Programming an MCU feels different from writing a normal app because the chip is too small to develop on. There’s no editor, no compiler, and no terminal living on the device. So the workflow splits across two machines:

Write your code on your PC in an editor or IDE.
Cross-compile it — your PC’s compiler produces machine code for the chip’s processor (an ARM Cortex-M or RISC-V core), not for your computer.
Flash the resulting binary over USB into the microcontroller’s flash memory.
Run — the chip resets and immediately starts executing your program bare-metal.

Because nothing on the device talks back to you, debugging works differently too. The everyday tool is serial printing: your code sends text messages over a USB serial link to your PC, the embedded equivalent of print() debugging. For harder problems you connect a hardware debugger over JTAG or SWD, which lets you pause the chip, step through code, and inspect memory directly. There’s no log file to open later — you watch it live or you instrument the code.

The jobs microcontrollers own

There are whole categories of work where a microcontroller isn’t just adequate — it’s the right tool, better than any bigger computer:

Real-time control. With no OS to introduce unpredictable delays, an MCU can guarantee a pin flips or a pulse fires within microseconds, every time. Motor control, power electronics, and precise timing live here.
Ultra-low-power sensing. An MCU can sleep on microamps and wake only to take a reading, so a battery or small solar cell can run it for months or years — impossible for a power-hungry SBC.
Motor and robotics control. Driving servos, reading encoders, and balancing a robot hundreds of times a second is exactly the tight, repetitive loop an MCU excels at.
Anything tiny and embedded. When the computer must disappear inside a cheap product in a small space, the MCU’s size, price, and simplicity win outright.

The common thread is focused, deterministic, low-power control of the physical world. That’s the microcontroller’s home turf, and nothing else competes there.

The limits you design around

The flip side of that focus is a set of hard constraints. Good embedded work is largely the discipline of designing within them:

Kilobytes of RAM. You count bytes, not gigabytes. Big data structures simply won’t fit, so you stream and process in small pieces.
No OS conveniences. No file system, no processes, no shell, no rich standard library you can lean on. You often build small pieces yourself.
Avoid dynamic memory. Allocating and freeing memory at runtime risks fragmentation in a tiny space, so careful embedded code prefers fixed, pre-allocated buffers.
A power budget. Especially on battery, every milliamp and every awake millisecond counts, which shapes the whole design around sleeping as much as possible.
Harder debugging. No log files, limited visibility — you lean on serial output and hardware debuggers, and you think carefully before you flash.

These aren’t bugs in the platform; they’re the price of being tiny, cheap, and deterministic. Embedded engineering is the skill of turning those limits into reliable products.

When to step up to an SBC

The clearest sign you’ve outgrown a microcontroller is that you start wishing it had an operating system. The moment you want a real file system, a full network stack, a display and desktop, generous memory, or general-purpose compute, you’ve crossed into single-board-computer territory — go back to What is a single-board computer? for that tier. A full app like GopherTrunk needs that world; an MCU is far too small to host it.

Often the best answer is both, a pattern the next module explores in Combining tiers: a microcontroller out at the sensor doing the precise, low-power, real-time work, reporting to an SBC or server that handles storage, dashboards, and the heavy lifting. Each does what it’s best at.

Quick check: How do you typically get a program running on a microcontroller?

Recap

C/C++ dominate — for speed and tight memory control; MicroPython adds ease, embedded Rust adds safety, and assembly is rare.
Compile, flash, run — you cross-compile on your PC and flash over USB; there’s no editor or terminal on the chip.
Debug over serial — serial printing is the everyday tool, with JTAG/SWD hardware debuggers for harder problems.
MCUs own their niche — real-time control, ultra-low-power sensing, motor/robotics control, and anything tiny and embedded.
Design around the limits — kilobytes of RAM, no OS, a power budget, and harder debugging are the constraints you build within.
Step up when needed — reach for an SBC when you want an OS, networking, a display, or real compute; often the best design uses both tiers.

Next up: the start of the final module, where you turn all of this into a method for choosing hardware. See Start with your requirements.

Frequently asked questions

What languages do you use to program a microcontroller?

C and C++ dominate embedded work because they compile to fast, compact code with tight control over memory and hardware. MicroPython and CircuitPython trade some speed for ease, letting you script the chip in Python. Embedded Rust is an emerging option that brings memory safety to bare metal. Raw assembly is used rarely, only for the most timing-critical fragments.

How do you get your program onto a microcontroller?

You cross-compile on your PC — turning your code into machine code for the chip’s processor, not your computer’s — and then flash it over USB into the chip’s memory. There’s no terminal or editor on the device itself. To see what’s happening you usually print messages over a serial connection back to your PC, or for deeper work use a hardware debugger over JTAG/SWD.

When should I move up from a microcontroller to a single-board computer?

Step up to an SBC when you need an operating system, a file system, a network stack with real software, a display and desktop, lots of memory, or general-purpose compute. If your job is real-time control, ultra-low power, or fitting into a tiny cheap product, stay on the microcontroller. Many projects use both: an MCU at the sensor and an SBC doing the heavier work.