CircuitPython Weekly Meeting for March 9, 2026

0:00Hello, everyone. This is the circuit Python weekly eating for Monday, March 9, 2026. It's the time of the week where we get together to talk about all things circuit Python. I'm Dan and I'm sponsored by Adafruit to work on circuit Python. Circuit Python is a version of Python designed to run on tiny computers called microcontroller. Circuit Python development is primarily sponsored by Adafruit. So if you want to support Adafruit in a circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join any time by joining the ADAFRU.IT slash discord. We hold the meeting in the circuit Python dev text channel and circuit Python voice channel. This meeting typically happens on Monday, the 2 p.m. U.S. Eastern time 11 a.m. Pacific time, except going to go on-site with the U.S. holiday. In the note stock, there's a link to a big calendar

1:00you can view online or add to your favorite calendar at. You also send notifications about upcoming meetings via Discord. If you would like to receive these notifications, ask us to add you to the website circuit Python Eastwood discord role. As they mentioned, there's a shared note stock segment, which right now is a Google stock that we can put in the meeting and recording. You can contribute to this document beforehand. The final notes document includes timestamps to go along with the video. So you can use the document to skip around and view the parts of the video that interest you most. The meeting tends to run 30 to 60 minutes. After each meeting, you post a link for the next meeting's notes document for the circuit Python dev channel on the Adafruit Discord. Check the pinned messages in that channel to find the latest note stuff. So you can add your notes for the following meeting. If you wish to participate, but can on the 10th, you can leave 100 shorts of the status update to the documents for us to meet during the meeting. Okay, that's the

2:01boilerplate. The meeting is held in five parts and we'll begin. I'll explain each part as we get to it. So the first part is community news. This is a thing. I think I look at things all things sort of Python and Python and Harvard and general community. It's a set of items chosen from our Python and Microsoft controllers newsletter, which I'll tell you about later. Okay, let me play the time. Here we go for community news. First item is Rhovari Circuit Studio, a new circuit Python IDE. Rhovari Circuit Studio is a free and open source for the Python IDE built as part of the Rhovari embedded platform project.

3:03And there are some links and notes document to a discord and who are discord with us and also a YouTube link, which is a luxury video. It has everything you expect from you to quote from the description. It has everything you expect from you and the standard features include auto-board detection, a code form, airline highlighting traceback, built-in code snippets, a library manager with automatic bundling, a version matching a serial fodder with auto-format detection and safe file rights with F-sync. It's a more, no more silent code.py corruption and windows. It has a safe to remove indicators. So if you know, if it's safe, unplug the board or not. It's offline desktop application is currently in windows, but then making it cross-platform and they're adding support for BLE and Wi-Fi for your keyboard. It aims to support all boards from Rhovari centered on Rist5. Rist5 boards are first-class citizens of circuit Python

4:04and Swiss class, not an afterthought. So this sounds very interesting. It's great to have yet another sort of Python IDE and I encourage you to take a look at it and we'll be tracking it as it seems. Next step is about the MicroPython triage team. So on the MicroPython platform, Ants and Ants field writes about MicroPython triage team goals and processes. And the reason for this is that right now there are 1,392 open issues for MicroPython in order to 95 over the years, some are safe back as far as 2014. So the idea is to get a piece of tools for people together to triage this backlog into a series of more achievable short-term triage goals. So read the description in detail, let's look at the notes documents and there are some links in the notes, not even right now those links are broken and I'll fix that

5:05before I close the data. I would say, so let me explain where these these lose items came from, they came from the Python and the Microsoft controllers. If we newsletter, which is a circuit Python community run newsletter that we email every Monday with edited by Ann. Thanks very much Ann. There's a link to the archives of the lose letter. You very much appreciate you contributing to the newsletter, email cpnews.adifus.com with your lose item. It covers circuit Python, Python and Microsoft Python development. So anything that you think would have been for community and you might host a discord yourself or something send us a new statement to the new letters if you'd like to see it again. Okay, don't be next up, major section is the state of circuit Python, the libraries in Blinke. This section is a quantitative overview of the entire project. It gives us a chance to

6:09look at the health of the project separate from our status updates. So we'll talk about the circuit Python project overall and then separately discussed the core libraries in Blinke. So first up overall what's been happening is that in the last week, there have been 15 poll reports merged by seven authors. I'm all our young known people and they were you by four reviewers and there's five issues closed by three people and five open by five people. And next up, Scott, are you busy or able to read the code? I think I can. Okay, thank you. So stats for the core. We have seven poll requests merged from four different authors. Phomyguy Dan and myself weblates the fourth. That's a bot. We had two reviewers myself. Dan, we had 25 open poll requests and we're right at our one page goal. Issues wise, we had three closed issues by two people, five open by five

7:14people. So we're up to for a total of 847 open issues. Now, we have eight active milestones. 10 1 x has four open issues. 10.2 has one. And then we have one issues not assigned to milestone as of the time these stats were taken. So we are I'd still think we're keeping up the date as in terms of issue tracking. And that's where we are with the core. Okay, thank you. All right, next step is the library section which Tim will talk about. All right, thanks Dan. This section covers all of the circuit Python libraries. We have those hosted on GitHub under two main library bundles. The Adafruit library bundle has 384 driver libraries in it currently. The community library bundle has 174 in there. So combined, there is a total of 558 libraries right now that support circuit Python. Across the Adafruit

8:22bundle this week, we had five poll requests merged by three different authors. Thanks to Tectrick Liz and myself, we had two reviewers. Thanks to Scott and myself of the poor requests that were merged. It was a couple of them up around the 35 day mark. Those were the oldest ones and then the newest ones were one day old. So brand new. That leaves us right now with 38 poor requests that are open across the Adafruit bundle. The oldest one is a draft that is right about 1300 days currently. The newest one is seven days old as of the time of these stats. Issues wise, we had two closed issues over the past week by one person. No new issues opened up and that leaves us right now with 770 open issues and there are two of them that are labeled as good first issues. You can find those too as well as all of the rest over at the website circuit python.org slash contributing, which is where you should head if you want to start getting involved in the circuit python project.

9:27When you first load that page, what you'll find is a list of open poor requests. These are links over to GitHub. They're waiting for a person to come along and review the code. That could be you if you would like to get involved with the project. You don't need a special permission or anything like that. You can just load up those links, click through, read about what the proposed changes. Look over the code for spelling, syntax, logic, anything like that. If you have the hardware for it, you can test it out on your hardware. Then just leave a comment there on GitHub letting us know what you found when you looked over the code. Does it look good to you? Are there things that stood out that you think need to be changed? That sort of stuff. If you did have hardware, let us know in that comment how it went when you tested it out. Leave information like your version of circuit python and what kind of outcome you got when you tested it. If you get comfortable with that process and would like to get leveled up to join the official review team that we have there on GitHub, we can work with you to get you added to that. If you would like to start contributing

10:28some of your own code, you can also do that from the same page. Again, it's circuit python.org slash contributing. If you click over to the issues link along the top, you will find a very similar looking page. It's a big list of links over to GitHub again, but these ones represent issues. They don't have a proposed change that they're waiting for a person to come along who would like to actually submit that proposed change to resolve whatever the issue it is. It might be fixing a bug or adding a new feature enhancement or something like that. If you would like to get involved but don't have experience with Git and GitHub, we have a guide that covers the process of using those to contribute. We also have folks who are here on the discord who are happy to help get you spun up. If you are trying to contribute or review on GitHub, you're having trouble with any part of the process. Let us know here on GitHub, excuse me, on discord. Let us know what kind of trouble you're running into. We would be happy to help you out. I will leave you with new libraries

11:28in the last seven days. We have new ones, the XTE Inc X4 and the SSD 1677 shout out to Liz for getting those display driver and the helper for that XTE Inc in this week. That's what we have for libraries. Thanks. All right, thanks again. Okay, I next up to play you about blinking. So what is blinking? It's a compatibility there for sort of Python and single-door computers, like right, very fast. So let's you run code that's a written sort of Python and it's actually going to be running in regular Python on those computers and it's like it is a wrapper that endulates a lot of the hardware central features that serve the Python. So in the past week, there were three full requests merged by two authors and we used by two key talk right now, 21 open call requests. There were zero issues closed and zero open and there right now 146

12:29open issues and the current number of supported boards under Glenget is 166 different. So that's it for the state of certain Python and now we'll move on to the major section called hungry ports. I agree for it's a chance to highlight folks in a certain Python community and beyond for doing all some things. I'll start and then I'll go down the list and other other hungry ports alphabetically. If you were text only or send you a meeting, I'll be happy to region those and I get to them in the list. Okay, so first of all, I just have a group hug for everybody, a lot of computers that was going to single out issue people who write issues and people who do the bugging, but there are a lot of things that are going to happen. So thanks very much Ernie. And next is Tim. All right, thanks Dan. I also just have a hug report this week.

13:30Thanks to everyone in the community, everyone who watches the live streams, who contributes on the discord, who works on stuff on GitHub. It's all all for the community and very much appreciated. Thanks. Okay, thank you. And next up is Scott. Hello, two hugs for me. One for Liz for doing the XTE Inc. build. I've got one of those and I'm excited to try to start Python on it. And then also to PPSX who is doing QSPI display support. They're doing it via LLM agent, which has caused extra back and forth. But I think there's a human behind it and they've managed to get everything where I want. So thanks to them for persisting. It's so easy to get a fire and agent off and then set it off, but actually having the persistence to get it all the way checked in is awesome. So thanks to PPSX for that. Okay, thanks Scott. And finally, I will leave an extra contribution.

14:36Thanks to Pandu, that Scott, for the ZechroNatives and Python construction of the TORR, very helpful to reference for the implementation that we get to have action work for. And then agree on it. Okay, the next step is status updates. It's our time to tell folks what we've been up to individually. In the past week, I'll start and then we'll go to the list as before. You can take it up for minutes to talk about what you've been doing and what you've planned to be doing. And if there's a discussion that seems to get long, we can move it in. Right. So it's it. I'll start. So I've been mostly fixing bugs. It fixed the NAPL-SAMD bug that caused the crash when usually on the second time when you were trying to use an SPI bus on NAPL-SAMD, to run a full-wire display. It's kind of obscure, but it was recent.

15:42It's a bug that's been around for a while, but it has manifested a little more reasoning. And I expect to put that in there. I'm going to be doing a certified on 10.1.4 release today or tomorrow, which includes that one fix and we're two other things. Then I'm working on the kind of a kind of a multi-pronged PR that's trying to improve USB-SD card access, which was not so reliable. The one's called crashes. There were a variety of things that were a problem here. One was that USB-Card access was using SPI. If there was a display, there was also using SPI. The SDI display was not, so it was locking the bus properly, so that's fixed. Also, SD card, the way it was written is that it would talk to the SD card and then wait forever for an answer. So if something went wrong to the SD card, then it might move indefinitely.

16:47Another problem was on expressive. There was a separate task that we were running USB, and we were running at a high priority, which kind of locked out the other SPI bus, except that sometimes you'd get priority inversion and then that would lock out the USB task, so that was a problem. And then another problem, which wasn't a problem, which was very confusing, is that like I had an at-mell board, an SD card and an expressive board, and the expressive board was much slower. And I couldn't hear what that was going on. Why was it so slow? And it turned out it was because the card was much larger. It was a 16-dig card, and on my at-mell board, it was a, it was a 64-megabyte card, and so those are completely different sizes and as much less data to read. So the 16-megabyte card appeared on the host computer much more quickly, so that says something about making sure that

17:50your test conditions are exactly the same. Finally, I've started working on merging MicroPython 1.27, that'll also include a merge of 1.26, the merge 4.25. So I've just started, but it doesn't look like it's going to be a big issue to move this merge, so we'll be able to catch up. All right, next up is Kim. All right, thanks, Dan. I last week fixed an issue with full width glyphs that we're only showing the left half of the glyph in LVFontio, so if you happen to use a custom font in the terminal that showed full width glyphs, they would get cut in half, and that is now fixed and merged in. I installed this intercept signal dashboard thing on a Raspberry Pi and started learning a little bit about SDR stuff, which is what this dashboard is. It plugs

18:52in with a USB SDR antenna, and then it can show you a bunch of different things that it's able to find from the radio frequencies around you. I haven't poked very far into it. I did see that it can, it can pick up transponders from airplanes, so you can kind of see when there's airplanes that are nearby you, which is kind of cool, and there's lots of other stuff in there that I will dig into as I get time. But for now, I did kind of set that one aside and started working on a couple of circuit Python drivers, which is my next item here. Circuit Python driver for the APD S999 is functional and checked into GitHub, but I am still working through issues with the actions, and then I will work on the guide for that one, and I have the AS7343 up next as well to do. One of the interesting things I've been doing for this driver is working with an agent running on a Raspberry Pi and getting it set

19:52up to where it's got a microcontroller plugged in, and it can run kind of like right and run its own tests for the sensor. So it's a light sensor with this device, APD S999. I have the sensor pointing back at the neopixels on the device, and then I have an agent that is writing different tests that test the different functionalities of the sensor by setting the neopixels somewhere and then getting readings from the sensor and validating that they show as expected, which is kind of a cool sort of hardware test validation loop going on. But that is what I'm up to. Thanks. Hello, I am home with Sick Toddler. She's got a tummy thing, so I think she'll probably be good to go tomorrow, so I should be in the office tomorrow. I'm not going to. I merged in heap

20:54stat tracking and the native sim, so if you just run anything in the native sim and get the Profeta trace output, it will show you the heap usage over time, which is helpful for tracking how much like an import would take or just how much is used just to run something. I'm also merged in BLE Connect and Disconnect and the native sim. I'm doing a bit of a detour into containers. This is one of those things where it's like it's good software engineering practice that I've never had the brain space to pick up and really understand, but I've been thinking about isolated stuff for running LLMs and then also dev containers have come up when getting new contributors going and then also using it to speed up get have actions. So being able to do certain commands once and then just copying images over instead of having to do the commands and hitting servers every time. So I'm poking at that. Not only is LLM stuff causing me to think

21:56about that, but the display work that I have of getting Zephyr displays going is blocked by the fact that there's an SDL version mismatch between my local dev environment and get have actions and I don't know how to like get it building in both places, which is kind of annoying. So containers will help me solve this by having some isolated environment for doing this both locally and then get have actions. So I'm going to block in those two things and then cloud did continue working on BLE. So the next step I had cloud do for BLE was server, which is being able to create a server and have something access it. So it claims it's done based on tests, but I haven't had a chance to look at that yet. So that's the... I'm always trying to have one BLE ball in the air so I can get BLE implementation moving forward. So that's my BLE ball and then containers and Zephyr display.

23:00So that's how I'm working around, working off. Very thank you. Okay, so finally I'll remove Patrick. He has completed my initial implementation of data classes with libraries with Python. That's very interesting. Data classes was something that was added to regular Python. So we will see how that actually has done the circuit class. And then prototype running Zephyr and native SIM tests from Identify to the library. I created a reusable data action. It had actually worked for actually running the Zephyr singular reading the output. Beginning the process of creating additional action is most on top of the reusable simulator. I'll open a PR with a proof of concept. For example, the processor is both in air. Here it's gone. So this sounds really interesting to this. Like I'm talking about using

24:01a workflow and using native SIM to actually test something immediately that we want to test. This is really great. Okay, so that's it for status updates. There's nothing for you in the weeds. That's somebody has anything to add. So I'll just wrap up now. Just to remind of the next meeting is a week and today on Monday, March 6th, every usual time of 2pm, you have these three on Monday and the specific time. Note that the US is today like saving time yesterday, which is different from the time we have calendar for being at Europe in other places. If you're not in the US, check what time it really is here. All right, that's it. Thanks very much. Thanks for your everyone's patience for beginning. I was dealing with audio trouble.

25:12Give myself even more time and advancement and getting to test that out. Because everyone gets the right to do this job. All right, stop for a little further.