Stop staring at that screen! Dec 2016

Embedded software development can usually be characterised by the following diagram:

In other words: a “host” computer with a cross-compiler, where you enter code, compile it, and upload it to a “target” system which by itself does not have the processing power and memory to handle such a “toolchain”. Maybe you’ll also be using a “debugger” which lets you single-step, set breakpoints, and view variables values and raw memory on the embedded µC.

There is a lot to like about this approach: a very comfortable and powerful host environment is fast, offers excellent editing tools, adds version control, and has lots of storage (and backups).

But it’s also a bit like endoscopy: you’re not developing on the embedded microcontroller, you’re developing for one, while peeping through a fairly restricted “hole” in the wall, peeking and poking at the µC state from a distance.

During development, everything can and will go wrong. That’s the nature of the beast: we need to reason our way through everything unexpected that’s happening - whether it’s a bad assumption, a lack of knowledge, faulty hardware, or even a bug in another part of the code.

And so we add “debugging code” to report progress, and keep a watch on what is zipping by as the code is trying to do its job. We use the debugger to slow down the events and carefully check the state as the logic advances, and we hook up a logic analyser or oscilloscope to make sure everything is going well, and to capture specific events when things are not right.

It’s often a big puzzle, as we stare at our screens, comparing our code, observations, and event logs we’re collecting. It’s even fun when we finally deduce what went wrong and how to fix it!

But isn’t this all a bit backwards? Do we really want to be keyhole surgeons? Isn’t there a way to be “on site” to view and change the microcontroller’s internal state continuously? Can’t we just set or clear a pin or register value while trying to understand how to implement a feature?

A lot of work tends to go into understanding how things work, so that we can find ways to implement what we want on top of the existing system. A lot of time goes into learning how a micrcontroller works, or one of its hardware interfaces, or one of the attached devices. You can’t just read everything, come up with the perfect solution, implement it, and be done. Not as a casual hobbyist with limited exposure to all this technology, anyway. It’s an exploration!

Wouldn’t it be nice therefore, if embedded development were considerably more interactive?

Instead of developing in cycles, we’d be looking straight at the µC, see the values of variables, memory, and hardware registers, change them to see what happens, and see the effects right away. Every observation tends to lead to a new insight about what is going on - interactively, trials can be iterated so quickly that understanding and implementation get “fused” into one.

Think about it for a moment: what would it be like to no longer have a compile cycle, or at least not all the time? Instead, typing new commands which respond immediately, allowing you to try out things on the fly - the moment they come to mind. No host-side preparations would be needed, the main mental effort would be taking place while you’re trying stuff out.

Is this even possible? Of course: everyone who has programmed in BASIC will recognise this. The “host” computer becomes a terminal front end, while the actual thinking and coding takes place where the action is. Which means, in this context: right on the microcontroller.

Except… we’re not going there. Interpreted BASIC is slow and clunky. There’s another way.