CircuitPython Weekly Meeting for September 21, 2026 @circuitpython #circuitpython #adafruit

Hello everyone. This is the Circuit Python weekly meeting for September 21st, 2026. This is the time of the week where we get together to talk about all things Circuit Python. My name is Tim and I am sponsored by Adafruit to work on Circuit Python. Circuit Python is a version of Python that's designed to run on tiny computers called microcontrollers. The Circuit Python development is primarily sponsored by Adafruit. So if you want to help support Adafruit and Circuit Python, consider purchasing hardware from them at Adafruit.com. This meeting gets hosted on the Adafruit Discord server. You can join the server anytime by going to adafru.it/isord. We hold the meeting in the circuit python dev text channel as well as the circuit python voice channel. The meeting typically happens on Mondays at 2 p.m. US Eastern time or 11:00 a.m. Pacific time except when that coincides with the US holiday. Uh the notes dock does have a link to a calendar which you can view online or add to your favorite calendar app. Uh we will also send out uh notifications about changes to the upcoming meetings via Discord. If you would like to receive those notifications, you can ask to be added to the Circuit Pythonistas role here on Discord. Uh which is the same role you need in order to speak as well. So if you'd like to participate, that really is the role that you want here on Discord. And uh if you do need that, just uh mention so in the Circuit Python dev channel anytime and uh somebody will be happy to add that for you. Uh there is a shared notes document that accompanies the meeting um and recording. You can contribute to that document ahead of time uh if you would like. Uh the final notes document includes timestamps to go along with the video. So you can use that doc to skip around to the uh skip around in the video to the parts that interest you the most. The meeting tends to go uh 30 to 60 minutes depending on how many folks we have. Uh sometimes a little more, sometimes a little less. After each meeting, we post a link for the next meeting's notes document in the Circuit Python dev channel uh here on the Discord. So again, if you would like to put your uh notes in there, your hug reports and your status updates, you can do that throughout the week as well. Uh following the meeting, there will be a new uh link posted with a uh ping there in the discord. Um we will hold the meeting in five parts as usual and I will explain each of them uh as we get to them uh instead of going through them all uh twice again today since we are running a little bit behind. So first up is community news. So I will take a time stamp for this one and then tell you about it. So all of these items come from the uh newsletter which I'll tell you uh more about the the newsletter at the end. But the items that I've picked out of it this week are uh Circuit Python goes Turbo. Um Circuit Python Turbo is a host side tool chain that compiles selected Python functions into native machine instructions. So the busiest loops run directly on the chip while the rest of the program stays in ordinary Python. Uh it targets computebound work uh like NeoPixel effects, fractals, audio processing, sensor filtering, and pixel pushing. Turbo is being rolled out to select boards with more planned and there are links here to uh Adafruit blog I believe or learn excuse me to the learn turbo guide and then to hack a day as well if you'd like to read up on that and uh I do uh also happen to know we have some other uh projects in the works. So if you are interested in turbo and more examples keep an eye on the learn system. There will be more uh popping up there soon. Uh, next up from the newsletter, we had Circuit Python 10.3.1 and 1040 alpha.2 were both released. Uh, Circuit Python 1031 is a bug fix version of Circuit Python. It's now the new stable release. Uh, Circuit Python 1040 alpha.2 is the new unstable release uh that has work planned for the next stable release when we get to it. Uh so there is uh links here to the Adafruit blog for 1031 as well as 1040 alpha 2. Uh and there are release notes uh there on GitHub as well. Uh there's a link to that too if you want to see the full list of changes. Uh and I will give you just the highlights uh from those changes. So on the stable side of things, so the new 1031 uh stable branch changes since 1030 include uh allowing the uh turbo imports. So app viper and at native decorators uh in mpy files on the uh RP2 uh boards Raspberry Pi port. Uh so this is the stable one has turbo support in Raspberry Pi. Um also in stable we have uh ESP32C5 support. We have expressive and Nordic B fixes that improve the B workflow. Uh we have some other bug fixes and then we have lots of infrastructure improvements and speedups for GitHub and our actions and all the ways that we test things. Uh next on the development side of things, uh 1040 alpha.2 the new uh development release. Uh this one includes uh 5 GHz Wi-Fi support uh importing turbo modules on more ports. So this one adds uh Espressive, Nordic and SAMD51 devices on top of the uh Raspberry Pi port uh that's in stable. Uh so more turbo is enabled there in the development release. Uh also in this development release, B numeric compression uh pin pairing on expressive uh merges up from uh MicroPython. We have uh merged in MicroPython 128 and 129 into the Circuit Python core in the development release and loads of other bug fixes as well. All right. Uh so is it for the Circuit Python updates. Next up uh from the newsletter is uh Git and Circuit Python. This one caught my eye this week. Uh Marshall Horn shows how to use Git directly on a Circuit Pi drive without theGit folder uh eating your limited flash or triggering auto reloads on every commit. Uh the trick is to create a git work tree on the computer and then copy uh the copy just the oneline.get pointer file to the device. Uh history stays on the host but the board holds just a few uh bytes of the relevant code. So I thought this was a very interesting little trick. Uh I am always looking for uh sort of improved ways to manage the workflow between um uh git repositories and uh circuit python drives and I'm always working on uh ways to backup and do all kinds of stuff. So, this is very interesting, right up my alley. I will definitely be uh trying this one out. Uh see how it fits within my workflow. So, cool stuff there. Uh next up is uh Chem Chemistry Lab uh automation stuff. So, Chemistry Lab uh automation. Chemlab auto is a lowcost microython platform that is built on the uh Raspberry Pi Pico. It bridges commercial lab instruments over their serial APIs with uh uh with all assembly documentation uh published so that undergrads can adapt it. Uh this one caught my eye as well as I thought this was just a cool uh article this week and a cool usage of uh microython and open- source hardware in general to be able to interface with these uh what I imagine are very uh expensive laboratory equipment devices. I I did not know that people were out there hooking up like Raspberry Pi Pico in there um in order to automate control over these things. So very cool stuff. If you are in a chemistry lab, uh this will be extra interesting to you, but I thought it was just neat from the uh the device uh and open source hardware and integration perspective as well. Uh next up and last one uh from the newsletter for this week. Uh I wanted to throw this one in. ESP32 Laura introduction uh how a $2 ESP32 and Laura module uh will let you text off-rid with no inter uh no internet or cell signal. This is a link over to How to Geek. Uh and I wanted to throw this one in uh to also mention if you are interested in Laura um stuff we do have now a meshfruit uh library which uh will come up later when we talk about libraries in the bundle and stuff uh there is a new circuit python library with support for meshtastic compatible um reception. So anyone who's interested in Laura and this uh meshtastic network which is what this uh article is talking about um you also can take a look at the new library for circuit python. We've got stuff going in that world uh in circuit Python as well. Uh so now all of these items came from the uh Python on microcontrollers weekly newsletter. Uh I'll tell you uh more about that now. It's a circuit python communityrun newsletter which gets emailed out every Monday. The complete archives are available at adafruitdaily.com and it highlights the latest on Python and hardware related news from around the web including Circuit Python, Python and MicroPython developments. Uh if you would like to contribute your own news or projects uh which we always love when people do uh you can email those to cpnewsafruit.com uh contributions always appreciated uh there. Uh all right so next up we will get into the state of circuit python the libraries and blinka. Uh this uh section is a quantitative overview of the entire project. It will give us a chance to look at the health of the project separate from our status updates. We'll talk about the project overall and then separately discuss the core, the libraries and Blinka. So, first up, I will tell you about the overall stats. I'll take a time stamp here. Uh so, lots of activity this week. Uh overall, we had 66 pull requests merged uh which I don't know if we have stats for uh records or not, but that certainly sounds like the largest number that I can recall uh hearing or seeing in one of these meetings. Uh so, that's very cool to see. We had uh 15 different authors, a number of which uh had names that I don't recognize. So perhaps newer or less frequent contributors uh or folks who have managed to slip by uh without my eye uh you know catching on to their name before but those folks uh this week who who I'll read off uh the the newer less frequent contributors. Um let's see here. So we had uh Routurus uh I don't know the pronunciation on that so my apologies if that's not correct. We had Mrovo. We had uh uh MMA uh so maybe mm Abby or perhaps something like that. uh Peter Bay, uh Securely Fitz, uh and then Video Pixel uh as well. So, thank you to all of those folks as well as our other uh authors this week whose uh names I see pop up in these lists a little bit more frequently uh or have in the past as well. Uh reviewer wise, uh we had five reviewers. Thanks to uh Mike Scalar, Liz, uh and then especially uh special uh thanks I should say to Scott and Dan. Um uh early hug report to those two for core uh PR reviews this week. I know there's obviously as the numbers show a huge uh influx in PR. So uh those two uh definitely deserve some special thanks uh this week for uh extra review effort. Uh issues wise we had 14 issues closed by four people, five new issues opened up by five people uh across all of the uh Circuit Python repos and then I will pass it over to uh Scott next if you are available to tell us about the core. Um >> can you hear me? >> Yes. second. >> Yeah, you have a buzz a buzzer. >> I know. But yeah, I can hear you. >> Yeah, I'm sorry. There's some some noise from outside. That's I don't know what it is, but >> yeah, I know what you're talking about. It's not something I I could close the window, but I' it take a little. Um, okay. So, for the core, uh, we had 58 poll requests merge. And I thought it was funny, Tip, that you were saying that because I'm pretty sure last week or the week before when I ran the meeting and it was like 30 something poll request merge. I was like, I think this is a record. So, I think it's safe to say that 58 or 66 are both records for us. Um, it's awesome. We're writing a bit of this rocket ship is kind of how I'm thinking about it of just lots of LLM generated fixes. They're all nice and small, which makes them easy to get in, which is great, too. Um, so thank you to the folks that you shouted out. And then I just wanted another shout out uh in terms of uh Mikey Sclar started doing reviewers reviews for the core. So thanks to Mikey for that. Um, not only is he doing a lot of uh PRs, but also starting to do reviews for us, too. So thank you for that. And if anybody else wants to start reviewing for the core, uh, let us know. We're happy to to add some more folks there. Uh, we have 28 open poll requests. So we are um over our goal of being 20 do doing 25. Um 25 is has been kind of my goal because that's a single page on GitHub. Um staying under that has actually been harder uh just because we're getting lots of good pull requests and um I I try to only look at them once a day and so they do get batched up a little bit. So we're we're right around 25. Not too concerned about it. We'll get back down there. Um, but again, we have like maybe 10 that or maybe at least five that are very old and maybe we should just close um because they're not being picked up. Um, and that would give us a little headroom as well. So, that's where we are for pull requests in the core. Issues wise, we have 12 closed issues by two people and four open by four people. Uh, we have a total of 754 open issues. Uh we track Adafruit funded prioritization um based on the milestone system. Um right now 10.3 is our latest stable release and we have five open issues there. Um but I do uh I'm not too worried about that. I haven't looked at those. But I I think 103 generally is quite stable. Um I know there are some fixes that Dan's getting in as well. Um and he can speak to that later. Um, we were just talking in our internal meeting that ran a little late. We think, uh, instead of doing 10.4, we're going to call it 11. Um, so I will say that 11.0 has 14 open issues. Um, I'm not sure that we'll actually do all of those for Circuit Python 11. The one that we definitely do want to do is the removal of the Broadcom port. Um, so don't be surprised by that. Um, that's a pretty quick change. We're just basically saying like we don't support um Circuit Python on the Raspberry Pi single board computers bare metal anymore. It's always been this a bit of a minefield because it was never uh really refined and so we're going to just remove that in 11. So don't be surprised that that comes up. Um otherwise we we're getting through issues which is great. Um did I read that we're at 12 closed issues by two people? Yeah, I think I did. Anyway, yeah, we're uh we're getting through issues, which is great, and our poll request volume is is growing, but we're getting through that as well. So, that's where we are at with the core. >> All righty. Thank you, Scott. Uh, next up, I will tell you about the libraries. Uh, this section covers all the Circuit Python libraries, which are hosted on GitHub under two different library bundles. We have the Adafruit library bundle, uh, which has 404 libraries in it right now, uh, all found in the Adafruit library bundle. We have the community library bundle with 185 that has libraries contributed by third parties, members of the community, individuals and uh small groups who uh contribute and uh maintain those ones. So we have a total then of 589 different libraries that support various uh pieces of hardware and helper functionality on Circuit Python. Over the past week in the Adafruit bundle, we had eight poll requests merged by four different authors uh thanks to uh video pixel uh pager I believe and then Liz and Tyth uh and then the fourth one is Tyth as well. Tithe AI assisted uh so a little uh LLM agent there. Uh and then reviewers thanks to Scott, Liz, and myself for reviews on libraries this week of the pull requests that were merged. Uh mostly everything was on the new uh side of things. The oldest one was only 5 days and then a handful of the newest ones were all at one day when they were merged. That leaves us right now with 42 pull requests open. The oldest one is a draft that's up to 1495 days. The newest one is uh 4 days old right now. Um issues wise over the past week we had two issues closed by two pisss uh by two people. Uh and then one new issue opened up by one person which leaves us with 766 open issues right now. Uh and there are two of those which are labeled good first issues. You could find those two as well as the others over at circuit python.org/contributing which is a website where you should head if you are interested in contributing to circuit python on the python side of things. Uh what you will find when you first load that page is a big list of uh pull requests that are uh links over to GitHub. Uh and the first place that we tend to point folks who want to get involved but don't have a specific thing they want to do is reviewing pull requests. Um as Scott mentioned we have uh increase in pull requests in uh the core. I imagine uh in the libraries that is a thing that will be happening as well. It has to some extent already. Uh but I imagine uh more and more as time goes on um we'll be getting new PRs in. So anyone who would like to come join us uh and help out with reviews is more than welcome. Uh again at that page circ.org/contributing you can click through there to GitHub read up on what the pull request is. Uh it might be fixing something or adding a new feature or something like that. And what uh you can do in this case is read over the code uh look at it for syntax spelling logic anything like that. If you do have the hardware that that supports uh the microcontroller and then if there's any other modules it needs if you have that stuff you can run it on hardware and uh what you can do is just leave a get uh leave a comment there on GitHub letting us know uh what you found when you looked it over. If there's anything you think should change or uh if it all looks good to you. If you did have the hardware, let us know how it went when you ran it on there uh and tested it out. Uh if you would like to get uh leveled up to join the review team that we have on GitHub, we can work with you to add you to there. It will get you notifications and a few other things to help you find stuff to review. Um we do have guides for contributing as well. So if you'd like to start getting your feet wet contributing some of your own code, uh we have guides for contributing to Circuit Python using Git and GitHub. Uh and we also have folks who are more than happy to help you get spun up here on the GitHub. So, if you're uh new to the whole process to version control to actions to all this stuff uh and you're having trouble with it, um just come say hi on the Discord. Let us know what you're up to, what kind of issue you're having. We will be happy um to help you out. We want everyone to be able to contribute in a way that works for them. Uh and then I will leave you uh with the library updates for the last 7 days. So, new libraries, uh lots of new stuff coming in. Mesh Fruit, like I mentioned, for meshtastic stuff. And then a couple of uh new uh hardware drivers, the TCS uh 3448 and the TSL 2585 uh new libraries this week. Uh and that is it for libraries. Next up, I will tell you about Blinka. Uh, Blinka is our compatibility layer for running uh, Circuit Python code on Raspberry Pies and other single board computers as well as under uh, MicroPython instead of uh, Circuit Python as it would be traditionally run. Uh, lightweek uh, this week in Blink and no pull request merge, no authors. Uh, and there are 2019 I should say uh, open pull requests right now uh, in Blinka land. Uh, a number of the newest ones related to Blinka display.io I think speeding up some of the rendering and stuff. So I have uh those uh popped open in a tab to take a look at later uh as well cuz uh Blinka display io is right up my alley uh too. Um uh so that is uh it for let's see the blink PRs. We do have uh 80 issues in Blinka land. There are broken out by different repos here if you're interested in those and we are up to right now 175 different devices that support uh the Blinka compatibility layer. So that is it for those stats. Next up, we will get into uh the hug reports. I'll take the time stamp here. Uh hug reports as a chance to highlight folks in the Circuit Python community and beyond for doing awesome things. I'll start then we will go down the list uh as they appear in the notes document here. If you're text only or missing the meeting, then I'll read your notes uh for you. Uh otherwise, I'll call on you and then you can take a couple minutes to uh to read off your notes. Uh so like it uh like I mentioned, I'll kick us off here. I have hugger report this week. Thanks to Pedro and Liz for working on the Meshtastic uh compatibility library uh library. Uh I was playing with that a little bit with some old hardware over the weekend. Uh very cool stuff to have that started and working under Circuit Python. Now uh next up, uh Fedy 2 has some hug reports text only. So I'll read uh Fed2 says hug report for Mikeclar for help uh benchmarking the Circuit Python Rust against the C examples. Uh hug report to Tanut. Uh, Scott, thanks for suggesting Circuit Python Rust a long time ago and for Dan for helping me fix my mag tag. Uh, and then next up, I will pass it over to Dan. >> I want to thank Smidka for further PRs for Picoame and also for more space saving PRs and a bunch of other fixes just really going strong. Thank you. And then thanks to Mikey uh for a bunch of quick PR reviews over the weekend and for numerous fixes that he also submitted. And uh thanks to Scott again for some discussions last week about where to head on Zephr work. And that's it. >> All right. Thanks, Dan. Uh next up is Mikey Schclar. >> Yeah, I want to thank Dan for all his flash savings. That was really some pretty incredible work to go in so quickly. and um the CI fixes as well, which has really been sped up. And Scott for um getting in a few PRs that were all kind of peacemeal last week, like the additional turbo boards and the 5 GHz um which uh seem to all be stable now and in. And also to attack for helping uh us move up to the latest tiny USB. We were just waiting on one little CDC ripple overflow issue well race condition and he uh kind of took my PR and remixed a version of his own and now we can uh we've already merged the new tiny USB pin. So main is now up another 440 commits on tiny USB and then um Hackadday for covering um the story. They actually covered the circuit python turbo in their blog and their podcast last week and um showed really strong understanding. I think they kind of missed the point about how we were using um a really small version on our boards just having a little loader, but otherwise uh really good coverage worth listening to. Thank you. >> All righty. Yeah, thanks Mikey. Uh and next up and rounding out the hug reports is Scott. >> Hello. uh for me uh Bob G who's been doing uh many fixes including having uh updating updating us to ES the ESP protocols subm module of ours uh to include some fixes for MDNS which will make MDNS discovery much faster which will be cool. >> Nice. All right, thank you Scott. And that is it for the hug reports. Next up we will get into status updates. I'll tell you about that one right now. Status updates is our time to tell folks what we're up to individually. Uh again, I'll start then we'll go through the list of updates as they appear in the notes doc. Uh when I call on you, take a couple minutes, tell us what you've been up to uh since the last meeting and what you'll be working on until the next meeting. And uh if a discussion becomes too long for SAS updates, we can always drop it down to in the weeds where we can have a more long form uh back and forth discussion on that. So uh let me take a time stamp here and kick us off. Uh I did realize that I forgot to put these in until just now, so I uh hastily wrote these in. Uh but uh a couple of the things I've been working on over the past week or so. So last week was mostly uh the pixel dust or sand uh accelerometer um demonstration. So turbo uh one of the first turbo guides that has uh demonstration code in it. Um this is an example that's been done a couple of times on the matrix portal and on a couple of other devices as well with TFTs, but in the past it was always using Arduino. uh it's kind of like accelerometer uh example where you can turn the device over and then all the pixels sort of fall with uh gravity and collision and stuff. So with uh turbo modules we're able to actually run this in circuit Python now um and uh with Picoame as well uh we're able to render this on like 320 x240 TFT display uh and keep everything running real smooth and stuff. So there's a guide coming out for a metro with the TFT and then the Matrix portal uh version of that as well uh that will be coming out uh later this week or next. Um after that the next stuff that I started looking into is uh mostly USB uh USB host work. So uh USB host with camera uh was something that I kind of started on. Um it turns out this requires a thing called uh isocchronous support uh out of the sort of underlying USB stack. So uh I started there and got a a USB camera uh example working and then uh from there actually built out uh audio next and it turned out audio is even a little bit simpler than uh video. Um, so I have sort of uh in development versions of libraries of these and I have some changes in uh Pico PO USB that support this work. Um, so this is stuff that we'll be looking to um get PR submitted already actually in fact for uh Pico PO USB. So there's PR there. Um, but we'll be looking to uh release these examples and things and the new libraries that support it once the uh the upstream work is in. Uh, and then the other USB host thing that I looked into actually this morning was uh SDR stuff. So, a little USB uh software defined radio and then picking up like FM radio stations. Uh and then in this case, what I was doing with it was uh outputting it over um DVI. This was an example that PT put together. So, uh in the past, we've been able to output uh video signals over DVI like from the Fruit Jam for instance. It has the the HDMI plug on it. You can output that to uh a standard display. Um and we are working on adding audio uh into that output channel as well. So, uh, in this case, the demo is using an SDR to load up, uh, FM radios and play that audio out of the the sort of DVI output there. Um, but obviously what we're looking to do is make this generalized to where you could use that audio output for any, uh, sort of source um, at the end of the day. And then also this SDR stuff will bring in some capabilities as well if you're into ham radio and that sort of stuff. So, um, that is where my head is at lately. Uh, so that's what I'm up to and I will pass it over to uh, Dan next. Okay, so uh in the past week or so I got a bunch of PRs to speed up and the Zephr builds and also to fix some problems with them. The uh non-English uh builds were actually not working and also as mentioned I've done a bunch of PRs to reduce the firmware size for on various builds and I'm kind of finished with both of those uh for now. Uh also now whenever the uh continuous integration GitHub action does um a build it builds a firmware size report. You can see that at the top of the list of artifacts in a run. So it's there's sort of this nice interactive uh browser for this firmware sizes for every board. I reviewed a bunch of PRs. I fixed some bugs like I fixed some bugs having to do with B fixed a bug having to do with B on the C6 which on the um fruit jam. Uh I released sort of Python 1031 and 1040 alpha.2 two uh as mentioned and we've decided I said need to decide but we've decided that we really are kind of working more toward Circuit Python 11 than Circuit Python 104. So that'll give us the freedom to make some incompatible changes that we've been waiting to make. And that's it for me. >> All righty. Thank you, Dan. Uh next up is Fetty2 text only. So I'll read uh Fetty2 says uh benchmarking to test how well uh is ESP32S3 uh DSP uh is already supported. So how how well DSP is already supported. Uh and then creating a library for calculating Mayan calendars in circuit Python and creating an example for mag tag that wakes up in the middle of the night and shows the current date in Mayan calendar. Uh today is 8 wind 15 cave. Fascinating. I've always been very fascinated by different um timekeeping systems. I'm glad I don't have to to do too much with them, but they are very very fascinating stuff. So, cool stuff, Fetty 2. Uh next up is Mikey Scalar. >> Sorry. Um yeah, the uh tiny USB update was what I was kind of driving towards multiple times last week and that has now merged. So, thank the Pico SDK went in over the weekend. So we went from 220 up to 231 and that has been merged as well. And uh so far both of those things are testing fine on the farms and stuff. So I don't expect too many new issues out of that. Um and then the uh RP2 alarm is kind of a new thing I've been looking at this week, which is we don't have um sleep and alarms and timing stuff for the RP2350. So um this is looking at adding a few of those. And I think this will be open as a draft for discussion for a while. It's not necessarily a solid PR. Um but that is in place for talking about. And in terms of last week I spent a lot of time looking at text to speech and basically we're kind of going two different routes. Um the moonshine clat uh looks like it's going to be good for the low-end chips. Um and by that I mean uh some of the older boards we're using like an M4 for example or an RP2040. Um it can produce text um about five times faster than real time. So we can actually uh do text to speech very quickly and not have to load audio files on the board itself. So it saves a ton of space. And then for boards that do have more flash, we can get a much better voice. So using the SVox Pico, we can get um we have to give up about 2 megabytes of flash, but we can start to do uh much higher quality voices like where you'd actually wanted to read you a book or do longer dict dictation types of applications. Um, so we're going to be looking at how we can merge that into libraries and have a standard interface where people can use speech. >> All right. Thank you, Mikey. And next up, rounding out the SAS updates is Scott. You are talking, Scott. I do not hear you. I see that you're unmuted. Is anyone else able to hear Scott? Maybe. Is it just me? >> I can't hear him either. >> Apparently my uh wireless mic died. Gotcha. Okay, figured out. Oh, you know, I think the case might be dead, too. That's why putting it in the case didn't charge the wireless mic. Um, luckily the other one's charged. So, yippee. Um, so I did reviews. Um, lots of stuff's coming in, so I'm trying to get through that. Thanks to Mikey and Dan who's who are also doing reviews. Uh, Dan did review my little FS change and I need to take a look at that and get back to it. Um, my pinboxing PR is out. Um, and I'm poking at that to get the CI working. Um, but I think it's close. And then I do have a follow-up for that which allows us to turn on finalizers for well I I will turn on finalizers for all core modules like bus.io digital in out um those sorts of things so that um we don't need uh bulk reset or never reset in the ZE report. And I'll put uh the never reset calls behind a flag so we can just turn those off and have we'll never have never reset in the ZE report. And then that will all also allow us to remove it from other ports as well um without doing some huge blanket refactor that I've I've started but is is unwieldy. So I'm going to do it first for Zephyr and then we'll go port by port. Um I did also find the I squed C scanning is broken on the LM20A. Um I'm not going to fix that immediately, but it would threw me off for the pin muxing stuff. Um, my kind of like focus is trying to be on the NRF 54 L15. Um, so I'm gonna get dust that off once little FS is in. The L15 is going to use Little FS and we'll figure I'll I'll go back to getting the bootloader stuff done for that um to get the L15 all ready for um some Adafruit hardware. >> All right, thank you Scott. And that is it for status updates. Uh, next up is in the weeds. As a reminder, in the weeds is an opportunity for some more long- form discussions. These can either come out of status updates or be identified ahead of time. Uh, if you do have topics that are not already in there, make sure you scroll down, add those to the docs. Now, we have a couple others, so you do have a minute. Um, but uh if there are none here, then we'll skip past the section. So, make sure you get those in before the meeting when possible. Uh, first up, uh, in the weeds topic is fed 2. I'll read this one out. uh is about uh Circuit Python Rust support. So, draft PR uh 11393 is in for Circuit Python with Rust. Um doing benchmarks as suggested two weeks ago. Uh more details are in the PR, but for the Metro M7, the Mandelro came out about 7.5 times uh faster than Turbo. The SANS demo, I think the Turbo Sand demo, like the one I was talking about, about 6.2 times faster. And then uh it looks like a plain uab square root of 1024 came out about 17.8 times faster than uh the C equivalent using this REST compilation chain uh that is in again this PR1393 for folks that are interested in this. Uh so the extra tools for building the O and adding it to intomppy could be integrated or modeled as uh modeled to look like the Turbo CLI. Um, now I need help with folks testing and giving suggestions or requesting ports/benches uh benchmarks and what ports would be good to add this. I think there uh uh also I have a handful of uh have a handful of circuit python hardware for testing on. So fed2 here looking for feedback on the rest stuff. What kind of benchmarks would be helpful? What kind of uh other devices what uh ports rather I should say would be good to add? Um and that sort of stuff. Uh the piece of feedback that I would give maybe is on the uh the compiling like the turbo CLI. I might um hold off for now cuz I I foresee the the Turbo CLI and the way we distribute the libraries and stuff potentially evolving uh at some point. So if you are uh wanting something more stable, it might be good to wait rather than model it off of exactly what's there for Turbo and the way that it does the different architectures and stuff cuz um I don't think we've settled there all the way like uh ultimately I think we'll want to get Circup updated as well as the bundler uh that the learn system uses and then um kind of have everything else follow the format that those two things put forth. So, I don't know exactly how the Rust layer um fits into that puzzle exactly, but that would be my my main piece of feedback right now is um on the CLI um either hold off for a bit until we get circup and the bundler set or uh or just know that it may shift at some point. Uh and also feedback on uh whether Rust is something that we want for Circuit Python. Um and >> yeah, go ahead. >> This is Mikey. I was um I've been looking at this PR and talking to 52 on this as well and um I think this is something that uh the initial PR still has a little bit of extra stuff we want to trim out of it. You know, it's got like specific chip support and other things that don't need to be in the PR. There's just a couple of um small uh things I had suggested that can be included here that you know we don't want to it was naming expressive and some other things that are already enabled through separate PRs but um I think the benchmarks have been helpful and it's been helpful to come in as a uh comparison of how we can use external languages and let them come in through this native code that um Turbo has enabled. So, it's sort of a learning process for all of us and uh I kind of like that the PRs are structured around uh more of a discussion because it it helps to actually see the code and what's being offered and what's being suggested. Um but uh I think um from Scott, I'll let him speak about this too, that it's basically been, you know, we're very supportive of using CC code with Circuit Python as the main harness, you know, using Rust code with Circuit Python as a harness. And you know, it'd be something that's outside of our support, but it allows people to use this robust platform that's in place and then have really fast code that they're injecting in. >> Yeah, I think I I think Mikey's right. It I saw that PR and it was actually not very clear to me why it was rest specific. Um, I haven't looked at it this week yet, so I I haven't refreshed it, but um, I think for Rust compiling down to MPY files or whatever we do for Turbo, I think like that's great and we should do that. Um, obviously like Mikey's saying, we haven't figured out exactly what the the build story for Turbo is. Um, but from the core side, I think we just need to like figure out what, you know, the native loaded modules look like and just and what API surface they're expected to touch. Um, I do want to make sure that like that code that we load is not system on a chip specific like it shouldn't be register writing registers. I would I would not want to do that. Um, I kind of imagine that it's only CPU architecture specific, not system on a chip specific. Um, so yeah, thinking more about like what exactly the the public API for those modules is would be good, but I don't see how that's different from like the API that we provide for the like turbo stuff which is either you know transpiled Python or like C generated stuff like I we don't actually care right like from the core side we only care about what native code are we loading and how is it um what API surface does it have? What do we what do we dynamically link to it? And how do we do that and make sure that it's stable? Um art specific, not chip specific. Um and then yeah, on the tooling side, I don't I imagine that we you know, this is kind of like the Pyth Pippi equivalent of wheels. Um and so we're going to want probably like some GitHub action that is standardized for h for how we generate that stuff. Um, and then for the broader question of circuit rust in Circuit Python, I think I I'm actually been keen on being able to do internal modules like basically common house with Rust as well, but that's not what this is. Um, and I'm not exactly sure what that buys us, especially in the Zephr world where Zephyr is primarily C or C++ still. Um, but I would be open to that too. Uh, if you if it was kind of isolated on a per if it was isolated on a per module basis, that would be interesting to me, too. Um, so that's my my take on Rust. All right. Uh, I do see FedE2 is typing. So, I'll hang out for just a minute before we move on to the next one to see if uh there's anything there we want to cap off. Let's see. Betty 2 in the chat says for anyone listening uh on here. Uh, in a way it is you can build ULAB and Rust to compare without uh to compare with the current u build ulab in Rust build. So like Mike uh like uh sorry Scott was saying sounds like maybe you can write those modules in Rust with this. Uh I'm using it for external modules like meshtastic client that I made. It should be usable for internal modules as well. Okay. Sounds like maybe either uh Python level code or internal code could be rewritten and use this. Okay. So yeah that uh discussion there is in the PR as well. And we got um some good stuff I think to work towards moving forward. Um and then we do have one more. Let me get the timestamper here. So uh I'll hand it over to uh Dan for the other in the weeds topic. Yeah. So this was inspired because I every time I want to load an example using circup, it actually turns out the naming scheme is kind of really really really confusing. It looks like a path name but it's not. And part of the reason is that right now the module names in the the bite the bundle that is if you look at the ad at the repo adafruit circuit python bundle they're short names instead of adafruit ble it's just ble for example and uh what this means is that yeah it's easier to type sometime and maybe it's a little easier to look up because it's not all adafer underscore But it means that there are two names for things. You're not sure what the name is. Um it's not clear which library it refers to. And there are exceptions like NeoPixel. There's no Adafruit NeoPixel. There's just NeoPixel. And there are a couple other examples like that like async.io. We don't have Adafruit Async. It's just async.io. Um, so my proposal would be to rename the subm modules in the bundle and then take out and then have CIRCUP handle that and also maybe and have CIRCUP be backward compatible for now. Uh, just so everybody knows what the names are and it's it's always been a slight support headache. The other thing is that right now the um the uh the libraries are divided up into um library or helper. So things like a breakout board is a library but a helper might be something else that isn't particular to a particular board, a particular peripheral board. And this is sort of interesting, but it's actually hard to think about and you have to kind of decide where is it is under under libraries or helpers. And again, just having everything al together seems easier to me in the long run and remove this distinction of classifying things as libraries or helpers. So I'd be interested in feedback one way or the other on both of these ideas. >> Yeah. Um, I I would offer up on the names. I'm I'm totally into changing the names to match the the repo as well. I don't I don't know of any uh thing in particular that that will absolutely break from that. There may be cases where uh different things need to update for sure. Like you mentioned circup um probably Adabot has some as well for the reports and the bundle releasing that it does. Um but I would be into changing them to match the repo names as well. Yeah, cuz that will uh like you said, we'll keep some backwards compatible stuff in, but ultimately that will mean we can um down the line remove some of the logic that's like essentially just a map between the short name that we ended up with and the real name because we do in in I'm pretty sure both Adabot and Circup essentially we have sort of like a dictionary or some kind of lookup that's like here's the the short names that map to the long names for for the ones that don't go cleanly like you were saying how they either don't have Adafruit or for whatever ever reason they got a different underscore in a different place or whatever. Um, so there's a few of them that that just get mapped sort of manually um by those. So it' be good to get rid of those as well, I think. And I think uh it's also probably a good time to be thinking about changing the bundle as well. Kind of dovetales into the previous discussion about Turbo at some point. Um I imagine a a few of the libraries uh we may want to sort of compile as Turbo. So like hashlib and a few others. there's there's maybe not a whole lot of them that make sense. Uh but for a few of them it may make sense to compile those with Turbo and um at some point we'll have to figure out like how does the bundle fit into that? Does it hold all the different architectures and if so how and all that stuff so so that's kind of a separate discussion but I do think um makes it a convenient time to be changing the the bundling al together because we kind of have a few things that would be sort of good to do. Um >> yeah, >> thanks. Yeah, I mean would you would you say that you want the names to be ad like Adafruit Circuit Python B or just the import name >> lower case? >> Um the import name is an is an interesting thought. I hadn't thought about using the import name. Yeah, we kind of we we sort of ended up with like three names, didn't we? because we had the name of the repo, we had the short name which ends up as this the subm module, the folder and then we have the import name which is sort of a mashup of the two in most cases. Um >> the import name is what I like. Yeah, but I don't know. >> Yeah, I would >> I I would go with the pi package name. >> Yeah, that one's like a third one. That one's like basically the repo name but usually hyphens instead or something, I think. >> Yeah, with dashes. That's even another thing, right? And we also have to fix the bundler that is in the learn guides. So when I wrote this in, I wasn't thinking about so many places and I was also not thinking of, you know, my idea of of the obvious naming like I'm always what what happens with me is I'm I'm I I I copy some code copy some code.pay PI and it imports Adafruit_FU and then I go to circup and I import I I install Adafruit FU and I don't care about what the repo name is. I just care about what it is in the code. So uh but I think maybe all these names need to be there probably should be more metadata in the library in in the bundle itself to find these things. Uh so yeah I I think I think this under advisement and I've also been saying like this is also just kind of make work. We don't really have to do this right now. It does work like it >> it doesn't work right now. >> So uh I I will mention too for the the other bit that you had in here the the distinction between helpers and drivers. I I'd be perfectly fine if that was not made by uh the folders anymore. I don't necessarily see a a specific need to keep that. If we ever wanted them to be labeled that way still, we could do it with tags or or um just a list like we have them in a markdown file separated anyway. We could keep the the markdown separate if we wanted rather than um the folders cuz occas I I will say uh removing the folders might be nice because occasionally either somebody will put one in the wrong one or they end up with like a driver instead of drivers or something like that and so it's like um and then we end up go back and change them with the extra layer. So I'd be fine losing those as well just going everything in the route. >> Okay. I I think I'll write up some of this as as issues. >> So, just to put it down on imprint and then we'll think about doing it at some point. >> Sounds good. All righty. Thank you, Dan. Uh that is it for in the weeds topics for today. So, next we will get into the wrap-up. Uh so, let me scroll here real fast. Okay. Uh this has been the Circuit Python weekly meeting again for uh September the 21st, 2026. Thanks to everyone who participated. Uh, as a reminder, if you want to help support Adafruit and CircuitPython and those of us that work on CircuitPython, consider purchasing hardware from the Adafruit shop, which you can do at Adafruit.com, the video of this meeting will be released on YouTube at youtube.com/adafruit. And the podcast will be made available on major podcast services. It will also get featured in the Python for microcontrollers newsletter, which you can visit Adafruit.com in order to subscribe to that newsletter. Uh the next meeting will be at the usual time next week on Monday at 2:00 p.m. US Eastern time, 11:00 a.m. US Pacific time. That's uh the uh 28th of September, next week on Monday. Uh so we'll be back for that. Uh as always, the meeting is held on the Adafruit Discord, which you can join anytime by going to adafru.it/isord. If you like to be notified about the meeting uh and any changes to the day or time, you can ask to be added to the circuit pythonistas role on discord. Uh uh so thanks uh thanks everyone for participating and that is all for this meeting. We hope to see you all next week.