A video to mark a milestone:
Yarg now supports interrupts, with a Yarg function called when an interrupt is triggered on the CPU. In this case, a button connected to GPIO2 will run a function that lights the LED on GPIO3.
A video to mark a milestone:
Yarg now supports interrupts, with a Yarg function called when an interrupt is triggered on the CPU. In this case, a button connected to GPIO2 will run a function that lights the LED on GPIO3.
I recently spoke at IoT.London. This post extends the slides I posted earlier. I’m motivating my own Yarg project, and the general idea of languages specific to Microcontrollers. Interested? Sign up to my Yarg Notes newsletter!
C and MicroPython are both popular choices for Microcontroller software-“firmware”. Alongside many upsides, their limitations can frustrate development. Who wants to start from scratch in C? Python is much better for prototyping. Who wants to ship MicroPython? Awesome if you can, but a surprisingly hard path to follow at scale.
I believe the time is ripe for a new language targeting microcontrollers. As our use of microcontrollers increases, I believe that both our need for energy conservation and AI software development provide a need and opportunities for new tools to create firmware with.
“I could rewrite this in assembler, but MicroPython seems fast enough”
From a recent microcontroller project presentation.
The power of recent microcontrollers clearly makes spending resources on languages possible. We now have a profusion of work where people take their favourite language – Python, Go, Lua, Lisp, etc and port it to microcontrollers. Full compatibility is, however, never possible, so a new name is needed: ‘Micro’, ‘Circuit’, ‘µ’, ‘Embedded’ and so on. Somewhere the compatibility breaks are documented: what to do with ‘os’ dependencies; what to do for interrupt support, and so on.
C is perhaps well described as the devil you know. It is widely supported, and doesn’t expect much of the underlying system. Even this creates problems. Interrupt support will either need to be written from the ground up, or supported by a vendor-specific C SDK. Perhaps you need to depend on an adjacent RTOS. The standard library will certainly have limitations: how are files supported in the printf API, when there is no file storage?
Modern Microcontrollers are designed to spend their lives off, and to be awakened by an interrupt when something interesting happens. Without language support, especially for the implied multi-processing, it is too easy to fall back on a polling loop that simply wakes up from time to time and asks if something is happening. This is clearly wasteful, and especially so at the scale on which Microcontrollers are used.
Some claim that AI tooling writes code ‘equivalently to a junior developer’. Taking that at face value, would you want a junior developer using C without some sort of peer input, or extensive process and tooling support? AI’s are perfectly good at learning new things (VSCode already knows how to write functions in the language I’m writing…), and a more advanced language can make review of their output easier. How sure are you that there isn’t a pointer arithmetic bug in C code you’re reviewing? How sure is the AI?
I’m working on this problem, with the Yarg-Lang project. Yarg has an on-device repl, multi-processing support (including interrupts), direct hardware access and tools to produce production images. It is early days, so my call to action is to join me on the journey and sign up for my newsletter to be the first to get updates!
I plan to attend BarCamp Surrey. I’m intrigued by the idea of a tech conference that is local to me!
It is at Godalming College on Saturday 2nd August.