All the posts and articles so far have been about staying “close to the silicon” on ARM µCs. Direct access to I/O registers to control and read out pins, and to activate the built-in hardware interfaces. It gets tedious after a while, and worst of all: very repetitive.
I’ve been coding for the LPC8xx chips in C/C++ with virtually no runtime library support. The reason was to expose all the raw stuff that happens as a µC starts up, very dumb, and needs to be told how to get a notion of time (SysTick), how to read/set/clear/toggle pins, how to sleep in various low-power modes, how to talk to the serial interface, yada, yada…
Figuring out how things work at the lowest level is a fascinating adventure. It’s no more than an indirect jump on reset, a run-time stack, and processing machine code – forever. But let’s not deal with these details all the time. Let’s think about sensors, conditions, decisions, actions – let’s define the behaviour of a system, not just deal with technicalities.
There are numerous ways to move up in abstraction level on embedded µCs. This week’s episode is about the bigger picture and the three broad categories of these approaches:
- So many abstractions to choose from– Wed
- A µC is just a small computer– Thu
- No wait, it’s a language runtime– Fri
- Or is it a data-driven engine, perhaps?– Sat
Warning: there are no conclusions at the end. I’m still exploring and evaluating. I’ve been on many long and winding roads already. I’m not too impressed by most of them. Treating a µC (any board) as the centre of a project feels wrong, particularly in the context of multi-node home monitoring and automation – which is still, after all, the focus of this weblog.
We really need to look at the bigger picture. How to evolve and manage the designs we create over a longer period of time. Old stuff needs to fit in, but it shouldn’t prevent us from finding a broader view. Adding and managing single nodes should not be the main focus.
(For comments, visit the forum area)