#CircuitPython2026
CircuitPython feels like it’s in a pretty good place. It supports a variety of CPUs, a very useful subset of Python, and is actively developed and supported. The CircuitPython crew has put a lot of effort into normalizing interfaces and I believe is working to make AirLift wifi-coprocessors appear to be native. Libraries and hardware support have grown and CircuitPython is tracking improvements in CPython and MicroPython while also evolving on its own.
Every year Adafruit solicits wishes for how CircuitPython might evolve. Here’s my spitball, seat of the pants wish list.
Updating CircuitPython OTA
My top wish is probably the most difficult one. I operate a number of continuously on devices running CircuitPython-based applications. I can update libraries remotely using circup, which is fantastic! But I crave being able to update CircuitPython itself over a network.
This would help make routine management of the devices easier — I could even update some of them remotely over a VPN.
There are definitely some challenges here. Storage is a big issue. CircuitPython isn’t tiny and a lot of boards just don’t have a lot of extra flash space available, so there may just not be enough room to store a second copy of CircuitPython, even temporarily. And you can’t safely overwriting the copy that you’re running.
It might be fun to support netbooting via PXE but that would be a lot of friction for users who’d just like to get the latest version of CircuitPython on their board without having to connect it to a computer to flash it.
Probably a moonshot.
Thread and Zigbee
Some Nordic and ESP32 devices support Thread and Zigbee. Thread requires IPv6 while Zigbee is entirely independent of TCP/IP and has much less overhead. ZigBee support in particular would enable an entire class of low power, non-Internet connected CircuitPython-based sensors and controllers (switches, lights, similar devices).
This would require defining interfaces for talking to Thread and Zigbee stacks in CircuitPython.
It also requires either re-using OpenThread and Zigbee SDKs by creating CircuitPython bindings to them and linking them into the CircuitPython binary, or re-implementing them in CircuitPython.
Neither choice is wonderful. The former leads to bloated binaries when only a small percentage of users would be likely to use Thread or Zigbee (and likely no one would use both at once, if the underlying SDK even allows that). The latter is a huge amount of work up front and a very large support burden over time.
Web Workflow over Ethernet
Most CircuitPython boards that use ethernet use an SPI device like the WIZnet W5500. This integrates with CircuitPython using pure Python external libraries.
Web Workflow is compiled into the CircuitPython binary and currently has no communication path to talk to external libraries.
Some devices like the ESP32-P4 have native ethernet support, which could be made available in CircuitPython itself so that Web Workflow could possibly make use of it. It’s also possible that Web Workflow could be made accessible to the application running in CircuitPython, which could bind it to an external pure Python driver. This would almost certainly be a fraught relationship, though, very fragile in the face of misbehaving applications or libraries. But it would be handy to be able to use the Web Workflow with boards that have native ethernet support.
What about Matter?
Matter is a protocol suite that runs over TCP/IP and can be used over WiFi, Thread or Ethernet (or for that matter, it should be possible to use it over any lower level network hardware that supports broadcast or multicast and TCP/IP).
Get John Romkey’s stories in your inbox
Join Medium for free to get updates from this writer.
Thread and Zigbee are link-layer protocols — supporting them in CircuitPython means libraries must call SDK routines for the platform that are written in C and must be linked into CircuitPython. That’s not true of Matter — it’s more amenable to be implemented natively, even if that is a lot of work. And in fact it’s been done — see CircuitMatter- although CircuitMatter is currently written for CPython and not CircuitPython.
Regardless, Matter support does not have to be built into the CircuitPython binary. For both Thread and Zigbee, at least some support would need to be in the CircuitPython binary itself.
Web Based Build System
Maybe another moonshot in that it’s a large project.
Anyone can build CircuitPython on their own. Anyone can add support for custom or unsupported boards using supported hardware (there is a little issue of properly dealing with USB vendor and product IDs).
Except that most people don’t have the skills to do this. It’s easy to say “go learn them” but it can be a steep hill to climb for a set of skills that they may not use anywhere else.
I’m envisioning a web-based build system that would guide you through the process of creating a board definition, let you save or export it, and then actually build CircuitPython for that board. If you’re not publicly distributing the CircuitPython binary then it doesn’t matter as much if you have correct USB vendor and product IDs.
This would also make it easier to build variants of CircuitPython firmware that saved space by dropping unneeded libraries, or to include large features (like possible support for Thread or Zigbee) that the community in general wouldn’t need.
Something like this could be packaged in Docker to make it easier to distribute and download… but people who would have trouble defining a new board in CircuitPython would also be likely to have a lot of friction trying to use Docker.
I doubt that it’s practical for I doubt that it’s practical for Adafruit to host a CircuitPython building service and wouldn’t wish that on them even if it were, but there might be creative solutions using GitHub actions on your own repo or other ways to grab some CPU time here or there.
Better LLM-based Code Generation
Probably another moonshot…
Using LLMs to write code is controversial in some quarters but they’ve improved incredibly over recently and certainly are here to stay. I’ve been using them to write code recently and have been impressed with the ease of use and overall quality of output.
Writing code, for me, is not about writing the most idiomatic Python ever or the least comprehensible best performing C — it’s about using tools effectively to create better tools. If tools write decent code for me I’m very happy about that.
While LLMs have improved, they’re only as good as their training material. They’ll do best with very common languages and frameworks, like Python, Ruby, C, NodeJS — and less well with less common languages like OpenSCAD.
CircuitPython occupies an unusual space — it’s a fork of MicroPython, which is a fork of ©Python. The three of them most of their syntax in common (except for version skew issues) but their library support varies greatly. Looking at code it may be difficult to tell whether it’s regular, Micro or Circuit-Python. There’s a lot of Python documentation and code online, much less MicroPython documentation and code, and probably a bit less than that for CircuitPython.
Which means LLMs won’t be as good at generating code for CircuitPython as regular Python, at least.
It’s really not something that Adafruit or the community can do but the more we talk about CircuitPython online, the more we publish tutorials, write articles and share code which is clearly identified as CircuitPython, the better job near-future generations of LLMs will do generating code for it.
What I’d like to contribute
I hope to do more work on circremote soon. I started work on some simple benchmarks that would be fun to compile to see relative performance of various controllers running CircuitPython. I also have some ideas about chaining together commands to build simple programs without actually programming.
I have too many big projects at PDX Hackerspace right now to dig into anything major but I hope at least to publish more code and text related to CircuitPython in the coming year.
