As we hit the new year, the call has gone out to the greater Circuitpython community to contribute their thoughts, hopes, and projects for 2020. I’m excited to share some of the things I’ve been thinking about for the project.
I was brought on late last summer by Adafruit Industries to build and maintain the STM32 port for Circuitpython, working on the API code beneath the python interpreter that allows users to command the peripherals that power each Circuitpython development board. It’s been a blast working with the team and learning more about the project, as well as inspiring and humbling to witness all the progress that’s been made over this past fall.
But while I’ve spend plenty of time mucking around in the deep wizardry of the STM32 HAL, I’ve never properly been on the user end of Python. The limited experience I do have actually developing with Circuitpython has been pretty exciting; being able to tweak a calibration value or change an algorithm and see those results instantly rather than after 5 minutes of compilation and re-programming is a mind-blowing experience for an embedded C developer. But my python coding skill itself leaves something to be desired, something I’m forced to sheepishly admit on Github issues that straddle the line between Python and my C code.
Thus, one of my favorite people to talk to in my local network is Don Blair, a developer for an open source agricultural tech project who uses Circuitpython full-time for his work. What excites me so much about Don’s projects is the potential for Circuitpython to be a force for good in the world, not just as a teaching tool, but through the actual tangible projects it is used in. I felt a 2020 post wouldn’t be complete without a perspective like this, completely from the user side, and with the end goal of making the world a better place through code. So in preparation for this post, I sat down with him and we did our best to combine our ideas from both sides of the Circuitpython project, from the code.py file down to the bare-metal C and register-driven peripherals that make it all work. Here are some of the things we talked about.
Scientists, Activists, Programmers
Lucian: I think it’s an exciting idea for Circuitpython to be used by people who aren’t necessarily beginners to tech, but are simply beginners in hardware. Even for a seasoned programmer, switching to a microcontroller project from another field is a rightfully intimidating process – there’s a huge volume of material to learn and new skills you need to acquire if you simply jump into the raw C. Arduino made this process easier, but Circuitpython makes it accessible on a whole new level. I’ve found myself recommending Circuitpython to data scientists, environmental activists, and machine learning specialists alike who want or need a hardware component in their projects but can’t simply become embedded engineers on the fly. Python is a language that many of them already know – a 2018 study of 23,859 data professionals found it to be the most popular by far, with 83% of respondents using it regularly – and Circuitpython gives them the means to use their existing background with a real-world interface, reading sensors, controlling robots, and controlling remote systems.
Like I said before, I’m excited by how these projects spread good past the education phase. I think teaching people new skills is an intrinsic good on its own, but the prospect of Circuitpython helping scientists to diagnose our oceans and farmers to better understand their crop cycles seems like a whole new level of impact to me. In 2020 I hope we can do more to recognize and encourage this kind of Circuitpython use, and I hope to help add new features that better support these kinds of projects.
Don: I’ve been working with environmental scientists and researchers on monitoring projects for several years now, and I’ve learned from many of them how important environmental monitoring has become in land stewardship, wildlife conservation, and in assessing — and figuring out how best to mitigate — the impacts of climate change. And what I keep hearing from these practitioners is that they’re stuck using proprietary, difficult-to-operate, expensive monitoring hardware — often stuff that was designed in the early 90s, and encrypts its data (which could easily be a simple CSV file) so that using the instrument is only possible with an expensive software license — where the software typically only runs on a now-outdated version of Windows.
Researchers and farmers who have been exposed to the world of inexpensive, open source hobby electronics — with its wide range of easily-interfaced devices, connectivity options, and flexible data formats — are amazed by the capabilities they see. But as Lucian says, even the relatively accessible Arduino platform can be intimidating to novices, with the consequence that adoption and development of open source hardware in environmental monitoring applications seems slower than it ought to be. That’s why the *truly* beginner-friendly approach taken by CircuitPython recently has been such an exciting development for me: there is finally a platform that I can unhesitatingly recommend to farmers, hydrologists, agronomists, and resource managers.
Among programming languages, Python is particularly popular, and particularly easy to understand; and the hardware is often set up so that no special IDE is required — the code can be accessed and modified on the device as if it were a USB stick. This represents a huge leap in accessibility and usability for these communities. A detailed, high resolution picture of environmental dynamics is going to become more and more important in the next few years — we need to make deploying monitoring devices as frictionless and easy for practitioners as possible. I think CircuitPython really has the potential to make this possible, and to become the ‘beginner-friendly’ standard in farming and in scientific research.
A Sleep/Suspend Interface:
Lucian: I’ve worked on a number of low power projects in the last year that need to go months or even years without having the batteries replaced. The current version of Circuitpython doesn’t have much support for this kind of power efficiency – you need to assemble your own external power-off system, which makes for a bigger form factor and requires the device to be hard rebooted. This year I’d like to explore a suspend or Wait-For-Interrupt system that can smoothly enter and wake from sleep mode, so that Circuitpython devices can enter the Suspend state offered by most microcontrollers that sustains the device memory on only a few nA of power.
This is an essential feature not just for common hobby projects like alarm clocks, battery powered robots, or open-source mobile devices, but also for environmental sensing applications. Many data gathering devices must be left in the field for years at a time and only wake for a few minutes at a time every hour, day, or week. It’s a feature I think would be a practical addition for both sensor/device oriented beginners, and also the academic applications I’m excited about in data science.
Don: Because CircuitPython makes sensor measurements and datalogging so straightforward, I’ve been eager to deploy battery-powered field loggers using CircuitPython firmware. But one immediately runs up against the lack of any ‘low power sleep’ functionality on the CircuitPython hardware. My current method for getting around this when deploying CircuitPython hardware in the field is to use an Adafruit TPL5100 Power Timer breakout, which acts as an external power switch, turning the entire datalogging microcontroller circuit off between logging sessions, and waking up at intervals that are set with a resistor value.
This method works fine, as far as it goes — but it adds cost, and its range of functionality is quite restricted compared to what would be possible if the micro itself was capable of low-power sleep: waking on interrupt in response to an external signal (sensor reading, radio signal, or RTC); storing running parameters in memory rather than e.g. needing to write to flash or SD card; etc. It would be really useful if farmers and researchers who wanted to quickly and easily deploy dataloggers or remote radio nodes in the field could instead simply call a low-power sleep function in CircuitPython.
Dynamically Loaded C
Lucian: when discussing this post, I had a moment with Don where we remarked on how crazy it would be if native C code could be loaded dynamically into a Circuitpython program just by dragging them into the drive. Imagine my excitement when reading the other Circuitpython 2020 posts and learning via Deshipu that Micropython has just recently done this. Circuitpython benefits from a clean shared-bindings API that provides familiar access to basic chip functions across any supported development board. But one downside of this is there isn’t really a conceptual home for modules that are board-specific or so early in development that they haven’t nailed down their API. One way to handle this is to make it easier to add new modules, a process which I’m interested in providing more documentation for. But I think board specific modules could be an opportunity to expose chip specific features and enable developers to distribute new modules for testing that could later be turned into official additions.
I’d expect this to also be relevant to the use of Circuitpython in scientific applications. I’d love to see the door opened to unique modules like a machine learning or motor driver stack on chips like the i.MX RT, or enabling researchers to use a custom C library for a DSP project that they can’t justify adding to the main API but want to expose to novice researchers for use in environmental sensors. Without more experience, I can’t say with confidence what would and wouldn’t be possible with a system like this, but I’d love to at least explore the concept this year.
Supercharging SPI
Lucian: one less broadly applicable thing I’d like to explore this year is batching data to SPI and other communication methods via Direct Memory Access (DMA), which is relevant to a number of my personal imaging and sensor projects. I think a more advanced native C layer for buffering the inputs and outputs of the BusIO modules would be neat – a setup where python code is used to initialize and diagram a communication system, but not necessarily to run it realtime to save speed. My hope would be to allow things like faster DSP, data storage and DisplayIO outputs, without compromising the beginner focus of the API.
Projects for this year
Lucian: I have a lot of projects I’d like to do, which in conjunction with the above is probably stupidly ambitious. In all likelihood I’ll start a number of things and only keep up with my favorites, as per usual… but here’s my shortlist.
– Adding half-duplex UART and creating a library for the Dynamixel, my favorite kind of servo motor, which uses a shared addressable bus and has some great features like continuous rotation mode, torque detection, auto shutoff, etc. The bonus, of course, will be putting it in a robot.
– Porting my old SPUDwrite project to Circuitpython and open-sourcing it, using the E-paper, keyboard and SD card code. I’d also love to work on some new SPUDs (Single Purpose User Devices). A lightweight, hackable SPUDphone comes to mind…
– Finish the featherwing for my generic breakout board tester.
– Start a Circuitpython meetup here in Boston at Artisan’s Asylum! Hopefully more news on this soon.
Don: I’m planning on continuing to support the CircuitPython projects that we’ve deployed in Portugal (soil moisture monitoring via a LoRa — WiFi gateway, pics here), Nebraska (soil moisture via cellular modem, pics here), Maine (sea level rise — pics here), and on Martha’s Vineyard (tide monitoring, pics here) while continuing to develop more applications for research at sea.
In particular, I’m hoping to further develop and refine the CircuitPython-based satellite modem system that we tested out on the R/V Neil Armstrong (a research vessel based at Woods Hole — pics here) a few months ago, with hopes of using it as the core electronics for a ‘drifter buoy’ system that would temperature of currents off the Northeastern US coast.
We’re also working on the analog front-end for an impedance spectroscopy system that we’re planning on driving with CircuitPython to make it easier for laboratory researchers to get things up and running. In general, CircuitPython is becoming our go-to for making scientific research instrumentation as accessible and easy to understand and modify as possible — we’re really passionate about getting the word out about it, and showing people what’s possible now!
Lastly
I’d like to express appreciation for everyone who’s written Circuitpython 2020 posts so far, they’ve been really inspiring to read! Many of the topics people have brought up, such as package management and automated testing, have been covered so well I didn’t bother to include them here, but I’m super excited to see where they go and help wherever I can. I hope everyone achieves their goals this year, no matter how ambitious – here’s to an awesome 2020 for Python on hardware.