CircuitPython 2026

It's the time of year when thoughts about CircuitPython are invited by its loving parents. I'd hoped to get a post together last year, but failed, and I'm squeezing this in as the train door alarms are bleeping before closure. Next stop: somewhere interesting!

(Note for my mother: this isn't a mum-friendly post.)

How I got here

I'm not a hardcore Python programmer. I think in Javascript, even if I refuse to capitalise the 'S'. After discovering ActionScript for Flash and loving it, then having to do PHP for money, settling back into an ECMAScript variant was easy. I love JS, despite its quirks and occasional awkwardness, and would happily use it everywhere for everything.

At the same time, I like fiddling about with microelectronics. I'd been using Arduinos (Arduini?) for a while, but getting in a pickle with tiny amounts of memory and handling it in C, so when I discovered Espruino I jumped in immediately. Hardware Javascript, joy of joys!

But now, for hardware, I've moved on. Espruino is, essentially, a one-man operation (that man is the amazing Gordon Williams) and has remained a bit niche. I found myself wanting I2S audio and it just wasn't possible. I went back to the Arduino ecosystem, and the PlatformIO alternative, but I didn't enjoy it.

Some time ago, I forget who I was speaking to, but I explained that with the availability of more powerful microcontrollers with multiple speedy 32-bit cores and wodges of memory, I felt there were two options for me. Either try and bumble on with what I'd been doing, getting frustrated at memory management and the likes but doing it at a higher clock speed, or take the hardware buff and use it for a quality-of-life improvement, like Espruino provided. Obviously I chose QoL, otherwise I've just typed more than 300 words for a daft laugh.

I chose CircuitPython, over MicroPython. The two main reasons were the company making it happen - I've loved Adafruit's style, drive and principles since my first encounter with them - and the development environment. No need to prod bits down a UART cable like with MicroPython when your project will expose its filesystem as its own drive in your file manager. As far as I'm concerned, this is the greatest thing ever. I can take a piece of my homebrew hardware somewhere and if it plays up a borrowed computer is enough to make the changes on the spot.

A friend is making a prop that needs to be able to play samples. I did the electronics, created a samples directory and dropped test WAV files in there. When he's ready, he can drop his own samples in there and it will just work. The microcontroller board I favour has a load of flash memory so I didn't even have to consider an SD card.

At this point, if I need a development board, I'll only buy ones that have a CircuitPython build unless there's a really good reason. I've been kicking around ideas for my own development board - basically a shortcut for making synth nonsense easily - and if I do this, I'll be configuring a CircuitPython build specifically for that.

What I would like to see

WebDAV and/or FUSE-like connection

Most CircuitPython boards support the plug-in-and-it's-a-drive connection, which is brilliant. Some might say "the greatest thing ever". But CircuitPython also runs on devices that don't have the hardware chops to pull that off - older ESP32-based devices - and for these boards you either need to be plugged in with the UART cable or use the Web Workflow. With this you don't get the direct access to the files stored in flash memory, and you don't get seamless operation with your choice of editor.

The Web Workflow documentation includes information about REST endpoints for manipulating the files on these devices, which is what gets used for the basic built-in file manager. This is good... but not nearly as good as double-clicking on the CIRCUITPY drive to open things.

My wish: swap in, or supplement with, WebDAV so that any operating system since the millennium can connect semi-natively to the built-in file system. Alternatively, wrap up the REST calls in a user space file system like FUSE provides to Linux/macOS (and something similar for Windows). I've tried to do the latter but got nowhere because I, um, didn't know what I was doing. Maybe it's a vibe coding exercise...? We'll see.

VGA/Composite video

The hacker in me loves analogue video formats, and getting composite video out of the Espruino was fun. It would be great to be able to do this in CircuitPython, potentially leveraging the multicore nature of many microcontrollers now (perhaps). Similarly, if anyone can get CircuitPython to output images through the HDMI port of the Waveshare RP2040-PiZero, please make yourself known - I'm simply not clever enough!

Fruit Jam in the UK

I've watched the development of the Fruit Jam since the first rumbles of an announcement, and would LOVE one to join my first party boards (two NeoTrellis, a PyPortal and a MacroPad RP2040). It does All The Things and would be a brilliantly odd base for a Cyberdeck. Just look at it!

Between getting the earlier boards and now, there's been some sort of collapse of society in the US resulting in whatever the hell 2026 is. Waiting for them to show up at the usual outlets (Pimoroni, Digikey, etc) is frustrating. Getting them outside the US before transatlantic tensions explode would be amazing. Part of me would have a go at making a work-alike but I know from experience how that sort of thing ends up.

VS Code extension

Like many programmers, VS Code is my editor of choice. I've watched it grow since 2015, displacing the likes of Atom and Sublime Text along the way by being an actually good product that people want to use. (The shoehorning of everything sort of AI into it over the past 18 months or so is tiring, but everything is tiring now.)

There's a VS Code extension for CircuitPython and it's really rather good, but if you look in the extensions within VS Code you'll see it labelled as V2, because it's a fork of an earlier version that was rather good until the developer just abandoned it, and left it in a broken state for a year or so, ignoring all pull requests that would've gone most of the way towards fixing it, and offers of help ignored too. I reached out to him when the new forked version came onto the scene and asked if he'd consider removing the old broken version from the marketplace so that newcomers wouldn't get confused and frustrated - also ignored. Meanwhile his GitHub contribution graph was lovely and green from other work, so the ignoring was clearly a choice.

This really shouldn't have happened. I'd love for Adafruit to step in and ensure this can't happen again.

My plans for 2026

Apart from "get to the end of it in one piece", I have several synth ideas that have been bubbling in my noggin while being too busy to think about actually trying to do something about them. (For me, my electronics hobby is 90% synths - a fairly even split between analogue and digital - and more so the making than the playing.)

The most fleshed out one, and so the one I can share, is a bit of a continuation of my drum sample player, N'cha.

This is running CircuitPython with an I2S audio PCB, and plays and mixes 44.1KHz WAV files as triggered. It works really well, because I put the effort into it 😄

My plan - a looping sample player combined with a configurable clock divider and a couple of inputs to choose the sample to use. One output would pulse at every loop, another every half loop, another every quarter... or possibly have them all go a bit mad for polyrhythms. Get one set to 32nds for ratcheting high-hats through N'cha when other conditions are met. Lots of possibilities.

Anything else?

Not right now. I'll get back to you when that changes.