I have really enjoyed working on CircuitPython as one of the core developers. I started contributing almost three years ago. I looked back at my #CircuitPython2019 aspirations, which were BLE support, real low-power sleep, asynchronous programming support, and general code cleanup. I’ll list those below, and add some new ones.

• BLE: This is reality! We’re shipping several BLE-capable devices, and will soon release CircuitPython 5.0.0 with comprehensive BLE support. I have some ideas for an “EZ BLE” library that will make simpler programs simpler, hiding some of the boilerplate now necessary for BLE.
• Code cleanup: There’s always more to do, but we’ve done a bunch of refactoring of the build process and board settings, and I’m feeling good about this now.
• Real low-power sleep: We didn’t do this yet, but it’s a lot closer on our agenda, and is high priority after 5.0.0 is released. We need to redo CircuitPython’s underlying time-keeping code to use a chip’s real-time clock (RTC) or low-power-capable timers.
• Asynchronous programming and multitasking: We have talked about this further, but haven’t come up with an easy solution yet. There are multiple parts to this problem, for different use cases, and there may not be one general solution. When we went to PyCon 2019 in Cleveland, we talked to some async programming experts, who didn’t have any easy suggestions. The areas I’m thinking about include:
  • “Soft” event handling: Hard interrupts are handled in C code. MicroPython provides hard interrupt handlers, but with many restrictions. Can we come up with a straightforward event queue mechanism? Right now you have to write your own ad hoc event polling loops in CircuitPython. Could we come up with something easier? Does it look like an event loop or callbacks to the user, or something else (futures, etc.)?
  • Multiple simultaneous tasks: It’s painful now to write something as simple as a NeoPixel animation that changes based on button pushes. You have to check for button presses at opportune times, perhaps in the middle of complicated animation code. Running multiple animations at once is also tricky. How can we code these independently running tasks so they get time-sliced nicely without having to know about each other?
• Automated hardware testing: We had simple smoke testing on hardware a long time ago (Rosie), but it did not survive some infrastructure problems. How can we automate testing of native CircuitPython modules and libraries coded in CircuitPython? We sometimes have regressions, and we don’t code and commit tests regularly, except for some library examples. @sommersoft has been doing some work on this, but it’s not a strategic focus right now.