Submind YouTube summaries
Thumbnail for CircuitPython Weekly Meeting for September 14, 2026 @circuitpython #circuitpython #adafruit

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

Watch on YouTube

Video summary

The September 14, 2026 CircuitPython weekly meeting began with an overview of recent community news and developments within the Python for microcontrollers ecosystem. A significant highlight was the introduction of incremental garbage collection to MicroPython by Raspberry Pi, a feature that eliminates "stop-the-world" pauses and allows for high frame rates in graphics applications with large data allocations, though it remains in a specific branch rather than the main version. Additionally, the community discussed CircuitPython Remote 0.02, an early beta Visual Studio Code extension designed to browse and edit files on web workflow devices over Wi-Fi, as well as updates to the Snaky IDE which now supports a catalog of nearly 240 microcontroller boards. The meeting also provided details about the Python for Microcontrollers newsletter, encouraging community members to contribute news or projects via email to keep the weekly digest current. The core of the meeting focused on the health and statistics of the CircuitPython project, specifically examining pull requests, issues, and library bundles. Scott presented data showing a net decrease in open issues and pull requests across both the Adafruit and core libraries, attributing part of this progress to the increasing use of Large Language Models (LLMs) for debugging and code generation. However, with 41 open pull requests in the core alone, there was a strong call for community members to transition from authors to reviewers to help manage the influx of changes. Tim provided a detailed breakdown of the library bundles, noting that the Adafruit bundle now contains over 400 libraries while the community bundle holds around 185, with specific thanks given to contributors like Philipcom and GR Grant for their recent merges and maintenance work. Following the statistics, the team shared "hug reports" to recognize key contributions from community members such as Mikeyclar, Dan, Smidka, and Peter Bay. These acknowledgments highlighted critical advancements including the fastest MicroPython merges yet, significant speedups in Continuous Integration (CI) pipelines, and successful implementations of 5 GHz Wi-Fi support for ESP32C5 devices. The status update section revealed ongoing work on Turbo native modules and Viper compilation, with new support expanding to STM32, SAMD, Nordic chips, and the Pico game module. Developers also discussed plans to switch to a merge queue to reduce CI load and introduced new features like LittleFS support for USB mass storage compatibility and an experimental IO broker for managing pin usage across different ports. The final segment of the meeting allowed for deeper discussion in the "in the weeds" section, where the team explored technical challenges regarding translation file sizes and build times using LLMs. While initial expectations suggested that factoring out translations would save significant link time, testing revealed mixed results depending on the language and Link Time Optimization settings. Despite this, the team found success in making translation files smaller through other methods, opening up new avenues for optimization. The meeting concluded with a reminder of the upcoming schedule, an invitation to support Adafruit's work by purchasing hardware, and a promise that the recording would be available on YouTube and as a podcast for those who could not attend live.
Read the full video transcript
Hello everyone. This is the Circuit Python weekly meeting for September 14th, 2026. It's the time of the week where we get together to talk about all things Circuit Python. I'm Scott 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 microcontrollers. Circuit Python development is primarily sponsored by Adafruit. So if you want to support Adafruit and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to the URL adafru.it/isord. We hold the meeting in the Circuit Python dev channel text channel and the Circuit Python voice channel. It typically happens on Mondays at 2 p.m. Eastern, 11:00 a.m. Pacific, except when it coincides with the US holiday. In the notes talk, there's a link to a calendar you can view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you'd like to receive these notifications, ask us to add you to the at CircuitPython Nissa's Discord role. There's a shared notes dock uh that accompanies the meeting and recording. You can contribute to this document beforehand. The finals notes dock includes timestamps to go along with the video, so you can use the dock 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, we post a link for the next meeting's notes dock to the Circython dev channel. on the Discord. You can check the pin messages to find the latest ones so that you can add your notes to that doc. If you wish to participate but cannot attend, you can leave hug reports and status updates in the document for us to read during the meeting. Um, next up, uh, well, I'm just going to say the meeting is held in five parts and, uh, we'll go over those as we get to them and I will start now with community news after I take a time stamp. So, uh, community news is a a little slice of the Python for microcontrollers newsletter. Um, we'll show the details of the newsletter in just a bit, but um here's three things from uh today's newsletter as a preview uh kind of related to Circuit Python. Um, so one the headline thing is that somebody's done an incremental garbage collector for MicroPython. So Raspby uh 135 has added incremental garbage collection for MicroPython. Um I'll note that this is not in the main version of MicroPython. I think this is in their branch. Um it eliminates stop the world garbage collection which is one of the disadvantages of using MicroPython. It can keep high frames per second in graphics applications with massive data allocations. And there's a link to their GitHub there which um yeah is their branch of this um they also expanded the ATB to four bits um and the GC skip scanning for data types such as bite arrays. This is something Circuit Python already does. Um I think there's another PR for it in MicroPython but I don't believe it's been merged. Um what this branch can also do is uh the garbage collection can run partially in the background for scan and sweep uh which is not uh something that we can do currently. Um and then uh they have support for the ESP32 and the Unix port um for those. Um it says that it's easy to port to other boards but hasn't been done yet. All right. And next up is news around Circuit Python remote. Uh, CircuitPython Remote 0.02 is an early beta VS Code extension for browsing and editing files on the Circuit Python web workflow devices over Wi-Fi. It's designed around the standard Circuit Python web workflow API, but other boards, operating systems, firmware versions, and network configurations have not yet been verified. The author is looking for community feedback on the Adafruit forums. The and then you can look get it from the Visual Studio marketplace and on GitHub. All right, next up is Snaky now allows picking a microcontroller board from a list of nearly 240 devices. Uh Kevin Mleier's Snaky editor/IDE or integrated development environment for MicroPython and Circuit Python now lets you pick the board to code for and flash from a catalog of near nearly 240 boards. And these articles came from the Circuit Python newsletter. uh the Python on oh sorry the Python on microcontrollers weekly newsletter uh it is a circuit python communityr run newsletter emailed every Monday the complete archives are available at adafruitdaily.com/category/scircuit python um it does highlight the latest Python and hardware related news around the web including circuit python but also CPython or desktop python and microython developments um to contribute your own news or project email cpnewsafruit.com and we appreciate uh every contribution folks make to that. Next up we have state of circuit python libraries in blinka. Um this is a kind of statistical overview of the health of the project. Um before we get into kind of like the subjective parts um these are numbers that we've been actually keeping for quite a long time. Uh first I will go over all and then I will do the core. I'll kick it over to foamy guy for the libraries and then I'll do cover blanka here. So um overall between these kind of big core projects of the circuit bike python ecosystem we had 35 poll requests merged from nine different authors. Um some infrequent folks or news folks are um the Philipcom 4607 GR Grant 4 RH1T3 I feel like I should be able to pronounce it T3C 7. Those are relatively new folks. Uh we had five reviewers overall. Um so thanks to them. Uh issues wise overall we had 10 closed issues by three people and six open by four people. So we're net down which is great. Uh now I'll go over the numbers for the core. So within the core we had 28 poll requests merged. This is a lot. Um those names I said are infrequent before are also uh in the core here. Um we had eight different authors total. uh three reviewers including infrequent reviewer Lady Ada. Um and I just wanted to highlight um well we have 41 open poll requests. So uh we are definitely feeling the benefits of LLM uh debugging and enhancements. Um so I would encourage folks to make PRs, make them small um if they're separate things. Um I was we were talking in a previous meeting about how it's okay to have fixes go along with enabling things at the same time. Uh but we uh I'd encourage folks who are are diving into Circuit Python for the first time because of how easy LLM's make this to also start uh take a looking taking a look at other code that folks are making um and doing some reviews there to help us get through these 41 open poll requests. Um, again, there's like different degrees of like things that we have to pay attention to. APIs are really important because those are the things that we're kind of like committing to working in a particular way. Uh, but if it's like board changes or port changes, those are better scoped. Module changes, those are all better scoped and and may not be kind of like needing a lot of scrutiny perhaps. So, uh, call for folks to, uh, level up from author to reviewer. Um, I'm happy to help people. If you've looked at something, but you have questions about it, I'm happy to answer those questions. Um, and so that's that's how we're going to be able to handle this influx of changes and and how Circuit Python's going to change for the better, quicker, which is going to be awesome. Okay, issues wise, uh, we had five closed issues by two people, four open by three people. So, we're net down one for a total of 760. Um we track the priority of these issues based on um the m using the milestone system. This is priority for adafruit funded folks. Um our current stable release is 10.30 and we have four open issues on that. Um I know that Dan's planning on doing a 1031 soon as well, but I don't believe those four issues are addressed there. Um so yeah, we're we're early on in the stable cycle, which is totally fine. Um the next uh minor release will be 10.4 and uh main has been been kind of branched for that already. Um so any fixes to 103 will go in a separate branch. U but we kind of we do expect 104 to come pretty quick uh for those of you who are adding boards and want to get them out soon. Um we had three issues not assigned a milestone at the time that these stats were taken, but I suspect that's uh that's already not the case. Okay. And with that, let's ask Tim to give us an overview of the state of the libraries. >> All right. Thank you, Scott. Yes, this section covers all of the Circuit Python libraries which we have hosted on uh GitHub under two different library bundles. There is an Adafruit library bundle which right now is up to 401 libraries in the Adafruit bundle. There is also a community library bundle with libraries that are contributed by third parties by members of the community. That one is up to 185 libraries right now uh for a total of 586 different libraries that support various different pieces of hardware and helper functionality uh on circuit Python devices. Over the past seven days in the Adafruit bundle, we had seven pull requests merged by three different authors. Uh the name that jumps out to me as newer or less frequent was uh Philip uh VHIPCOM 4607. Uh so thanks to them. I will also say thanks to uh GR Grant who's continued to uh submit fixes in library land as well as go through and uh work on uh finding issues um that are either not reproducible anymore or have been fixed by uh prior PRs and stuff and making notes uh to get all that stuff closed up. Huge uh help there as well. Appreciate the work on that. Um the reviewers this week, we had three reviewers thanks to Liz, Scott, and myself. uh issues that uh excuse me, PRs that were merged with the uh the oldest one this week was 22 days. The newest several were uh brand new at one day old. That leaves us right now with 43 pull requests open. Um the oldest one of those is a draft that's out there still at 1488 days. The newest one right now is 2 days. Um issues wise, we had five closed issues by one person. uh two new issues opened up by one person and that leaves us with 767 issues open across the Adafruit bundle and there are two of those right now that are labeled good first issues. Uh you can find those two as well as the rest over at circuitython.org/contributing /contributributing uh which is a website where you should head if you are interested in getting involved in circuit Python uh especially on the Python side of things and uh in particular reviewing like Scott said uh is uh very helpful and very uh important as we have an increase in submissions. Uh so on that page the contributing page circuity.org/contributing when you first load it up you will see a list of open PRs. These are links to GitHub. uh they are uh pull requests that are uh either uh in need of a review or in some cases have been reviewed and are waiting for the the author to come back and make changes. If you would like to help us out by reviewing uh the ones that are in need of it, that is uh super helpful. You can click through that list, find something that is uh interesting to you or that you've got the hardware for or that you're willing to take a look at. click through to GitHub, read up on what the change that's being proposed in that PR is, and then uh leave a comment on GitHub letting us know um what you found when you look over the code for like spelling, syntax, um logic, all of that sort of stuff. If you have the hardware, that's even better. You can give it a try on actual hardware and then uh in your comment include how that went as well as like version information and what device you use and all that good stuff. If you get comfortable with that process, would like to get leveled up to join the review team that we have on GitHub so you can get some more notifications uh and other things that make it easier to find stuff to review, we can work with you to add you to that. Uh if you would like to start submitting some of your own changes as well, you can uh click over to the issues tab on the contributing page. You can find uh open issues where uh there is uh either a bug that's been reported or a new feature that's been requested or a new example, something like that. uh but there's no proposed change yet to go along with it and you can uh be the one to propose that change. You can submit a PR uh to resolve uh the bug or add the new feature whatever it is from that issue. Uh we do have a learn guide for contributing to Circuit Python using Git and GitHub and we also have folks who are more than happy to help you get spun up. Uh so if you are trying to review or contribute uh your own PRs to the libraries uh or core and you're having trouble with any part of the process like version controller actions uh pre-commit anything like that just come say hi on discord let us know uh what issue you're having we will be happy to help you out uh we want everyone to be able to contribute in a way that works uh for them uh and I will leave you uh this week with the new libraries in the Adafruit bundle TMF886 and 881 shout out to Liz for the new libraries this week there and in the community bundle bundle. Uh the Philipcom uh added PN7150 and ST25D uh V drivers over there in community bundle. Uh and that is what we've got for libraries this week. Thanks. >> Thank you, Tim. Okay. Uh next up, I will read the Blinka section. So Blinka is our um Circuit Python compatibility layer. So this brings the Circuit Python API that libraries are built on top of uh to non-circuit Python core things like uh CPython um single board computers like the Raspberry Pi but also um MicroPython. Um so within Blinkand there were zero poll requests merged um and six there are currently 16 open poll requests. Um there were no closed issues by nobody, none open as well. And there are still 180 open issues and 174 boards supported by Blinka. And that's a quick overview. Looks like it was a quiet short week last week for Blinka. All right, next up we have Hug Reports. A hug reports is a chance for us to say thank you to folks within our community for the work that they've been doing. U it's great just to recognize folks, but it's also great to emphasize the things that we value as a community. So I will start and go down the list. Um I will iterate that uh yeah we kind of hand off the mic to folks as we come along. Um although we don't if you say text only I will the host will read it off. Um if you're unable to make the meeting um you can uh go to the circuity dev text channel click the pinned messages find the notes so talk and put your stuff in there. Even if you're unable to like be here live so to speak uh we still want to give you a chance to participate. Uh this is the first of kind of three sections where you can do that. Hug reports status updates will be next and then also in the weeds are kind of three ways you can participate uh kind of like um out of sync with us um if you want. So that's through the notes talk. Okay. Uh my hug reports for today are a hug to Mikeyclar and Dan H for the fastest two MicroPython merges yet. Um Mikey uh used the power of LLMs to uh get versions 1.28 and 1.29 merged into uh Circuit Python for Microython. And uh thanks to Dan for doing the reviews for that. Um it's super cool that we're up to date and uh very excited about that. And then also thank you to Smidka for all of the CI uh speedups. Um, we're obviously doing a lot more, uh, PRs now and so, uh, the CI speedouts are really, really helpful to to get everything moving through quickly. Okay. Uh, next up is Aneata, who is tech only, so I will read theirs. They say, uh, thank you to Mikey Mikeyclar for the Swift 5 GHz ESP 32C5 PRS, especially for, uh, access point and monitor. I had been planning to spend days if not weeks on this and now I get I can get right to extending my Circuit Python application. So that's great. And next up we'll kick it over to Dan for his hug reports. >> Okay. Thanks. Uh, so thanks to Smidka, also known as Lind Smidka on GitHub, who has um Scott already mentioned there are submitted numerous improvements and speedups to the GitHub action CI and is also working on his Picoame um module edition, which is already merged and will be on war boards soon. um thanks to new contributor Peter Bay uh for a slew of bug fixes. He has been having an LLM look at certython for both changes and fixes and there are a whole bunch of things like oh this type is wrong or the argument validation is incorrect or isn't done or something like that. There's just a whole bunch of like kind of robust things making it robust and fixing edge cases and stuff like that. That's really appreciated. And thanks to Mikeyclar uh who's done many PRs and for the MicroPython merges that we mentioned already. Uh he did them by LLM. It used to take me days or weeks to do a MicroPython merge. It was a very uh sort of tedious and had to be really careful process and now the LLM has taken care of a lot of that. And that's it for me. >> Yeah, Dan. And I just I I think I should hug report you because you had the idea of putting these circuit pie comments in there and I imagine that LM would have done a lot worse job if those weren't in there. >> Yes, that's right. Yeah. >> Yeah. Because those are great great little like context hooks for for an LM when it's when it's doing the merging. >> All right. Uh next up is Foamy Guy. >> All right. I have a hug report this week. Uh thanks to Mikey Scolar for enabling the Turbo uh native modules and Viper compilation stuff for Circuit Python as well as another one uh related to PT for some of the initial demos and ideas uh for Turbo as well as the guide that is uh published out there now. Thanks. >> Thank you, Foamy. All right, next up is Mikey. >> All right, I have a few thank yous this week. So Dan, really appreciated your help over the weekend getting those MicroPython merges in and helping me. he tipped me off to a a ripple problem I was having that um making me do it more in a a standard style solution rather than what the LM really originally came up with. And thank you Anecdata for a lot of good 5 gigahertz AP requests and channel issues and monitoring. That was uh pretty easy to put the PRs together once you just nailed down what you wanted. So that was really helpful. And Scott for um also providing like the right um interfaces to use. That's really the part I struggle with the most and that got 5 gigahertz going um in the more circuit Python style. And then thank you Lady Ada for pushing in the RP2 loader um things we needed for Turbo last week. That really sped it up because the microython merges do take a while even with an LLM and uh having RP2040 and 2350 support with Turbo is already allowing people to start getting going on guides. So thank you everyone. Awesome. Thank you, Mikey. Okay. Uh, next up we have a similar round robin section. This time it's status updates. So, this is a bit about what you've been working on in the past week and what you plan on working on in the coming week. So, I will start and we'll go down the list just like last time. Okay. So, uh I I'm I'm doing many reviews. I said we're riding the LLM rocket ship. Uh most of them are really well scoped and improvements. Uh I think today I want to switch us to a merge queue. Um I I realized it's not just a setting, but I think I actually do need a PR to do it. Um but I want to switch us to a merge Q so that merges are batched instead of triggering CI for each one. Um I think what's been happening is that I come in in the morning and I do a bunch of reviews and merge a bunch of stuff and then like the CI is busy all day basically trying to catch up to that. Um because a lot of the optimization that SMIKA has been doing only applies to PR checks, not the actual like final merge. So I I want to give that a try. Um we can say like only ever run one merge uh CI at a time and then like all of the things that get cued once like as another one's running, they can get all batched up for a second run. So I think that's a better way to do it. Um, I have a draft PR out for little FS support in Circuit Python. U, this is something that MicroPython's had support for. Uh, but we've kind of like always wanted to do FATF FS for um, compatibility with USB mass storage. U,, but there are going to be some coming boards that don't have native USB like the NRF504 L15. And I really wanted to just like set a line in the sand and say that this will use little FS rather than fat FS. Little FS does a better job at um wearing flash evenly and also being uh more fault tolerant. So uh I'm getting that in for for the NRF 54 L15 in particular. And then I'm actually really close to drafting a PR for pinxing as well. So this is the ability to like put I squed C on any pin. Um, I'm starting with the NRFS. Um, but I have it abstracted out into a Zephr module that I'm pretty pleased with, uh, the API for. It's like super high level. So, you just say like, "Oh, I want I squared C on these pins." And if it's possible, it'll give you the Zephr device back to use with the Zephr IQ C API, for example. Um, this is also where we'll track pin usage and peripheral usage. Um, so that you don't like have two things doing something on the same pin at the same time. Um, I'm calling it IO broker because it's brokering like the things that talk to the outside world. Um, and I trying to do it in a Zephyr module way so that other Zephr projects can use it in theory as well. Okay. Uh, I'm hoping to get those two things like complete this week uh because we have a full week and should be able to get through that. Uh there will be follow on work on the pinmucks stuff for like other ports and stuff. So, but that should be pretty straightforward. So, we'll see. Okay. Uh let's go to Dan. >> All right. So, sort of uh early over the weekend and on Friday, I I got my Zephrs build builds working and uh I fixed a bunch of B workflow issues that we'd kind of seen on Espressive and some on Nordic as well. and Zephr needed some of the same changes. So, uh, that's they're now all working about the same. There's still more work that needs to be done on BE workflow to make it a little nicer. It tends to disconnect in certain places and it could try reconnecting automatically, which it doesn't do right now. Uh I had asked um an LLM a few weeks ago about can you make better do better compression of uh error messages which we translate which are translated in many languages as you know in circuit Python and we have a compression scheme. I asked it could it be improved and it came up with some quite clever ideas which are very similar to what they're just sort of enhancements of what we already have there and it could save like between 200 and 1600 bytes depending on the size of the build. So uh this is actually really good because we are hitting up against some limits recently and so uh and it it doesn't this it it adds very little runtime code. the decoding part is uh doesn't it doesn't it only needed a 100 or 200 bytes extra to decode it in a slightly more complicated way. Um over the weekend and actually kind of earlier I approved a kind of a a large number of CI and space saving and bug fixing PRs which we already talked about um from Mikey and Smith and Peter Bay. I'm working with Smidka right now on uh making getting Pico game uh getting making make sure there's space for it at as many boards as possible. Um and so you'll see that in releases soon. It's already on some boards right now. And I just released um Circuit Python 1031 which has about 56 PRs in it. A lot of those are these build improvements but there are also a whole bunch of bug fixes too. And also importantly, this turbo stuff that we'll be talking about is now enabled on some boards in 1031. So you can see that in the release notes. And we got a whole bunch more stuff in the queue that's uh I'll release a 1040 alpha uh really soon, like in the next few days. So that's what I've been up to. >> Thank you, Dan. Okay, next up, let's go to Fomy Guy. Right. Thank you, Scott. I uh last week finished up the guide that I was working on for a project called Picoaces running on the fruit jam. Um this is actually outside of Circuit Python World, but it's a generative uh uh AI model, so it can generate images 128 by 128 pixels only, so very small, but it runs on the RP2350. Um pretty cool stuff. And I mention it here even though it's outside Circuit Python uh because I think with the the ability coming in for turbo modules, I'm curious about what kind of uh small models maybe we can um be able to interact with from Circuit Python land. So I haven't gone down that road yet, but that is something that my mind is on for uh the future coming up. um into actual circuit python stuff. I started working on some demos using these new capabilities uh from turbo the the native and viper um compilation modules. So I started with uh visual simulations. I have uh one that I will work on the guide for first. So this will be the first one uh that gets kind of published as a uh a thing that people can replicate easily is for uh accelerometer sand. So this is a common demo that we show on uh like the matrix uh LED matrixes. Um, but I have ported it to work on a TFT screen um that's plugged into a Metro RP2350. It has an accelerometer and you can tilt it around and the different particles of sand uh will fall based on gravity and interact with each other, bounce off um and that sort of stuff. Um, a couple others that I have if folks are interested in these ones uh as well as the sand. Actually, you can find them on uh my stream from over the weekend. Uh if you want a quick example, I did that up at the beginning of the stream. Uh, but there's one for fluids uh in smoke. Uh, which is pretty cool. Renders quite nicely. You could play with it with a little stylus. Uh, there is one that does like coral growth patterns. Um, and you can change colors and do a couple of different things on that one. And then there is a uh fabric um physics demo. So, it has like different sheets of fabric. There's like a a flag and a cloth and a couple of other things um that are pinned up differently uh with different anchor points and it uh kind of blows in the wind and you can drag it again with the stylus and it um it interacts with you and uh renders quickly and cleanly. Um and all of these are uh actually taking advantage of two things I should mention. Both the new sort of uh Viper uh compiled modules but also the improvements with uh with rendering from Picoame. So these all use Picoame for the display stuff which proved to be um a really nice combination with the ability to do this physics math really fast in the in the compiled modules. Um the other thing that I got into uh on the turbo side was audio stuff. So uh audio filters and things. Um, and I have a working uh proof of concept with this one, but it requires some changes in um the circuit Python core to basically expose a way for Python code to interject itself in what we have now, which is like the streaming protocol um that is internal only to all of these audio filter effect um modules. So, uh I have some code that opens that up and then I have some Python modules that implement different effects. The first one uh besides the basic test that I'm working on is for fruit jam and it's like an autotune example. So you give it a wave file uh that's a recording of yourself or whatever you want and then you give it a MIDI file that has a bunch of notes in it and it will autotune uh the wave uh to the notes that are in uh the MIDI file. So fun little demo for that. And then the last thing I have uh which I was working on a little bit over the weekend I threw at uh an LLM bot here is USB host camera support. So, the ability to plug in a USB webcam to like a fruit jam, for instance. Uh, and I did get a uh successful demo with that. I can do kind of a live preview on the the DVI output. It doesn't run very fast. It's only a couple frames per second, but you can get a live uh screenshot from the camera, which is really cool. Um, and this is something that I will dive into later in the week and actually start reviewing the changes and figuring out um how to get that in a state where it's actually ready to be uh used by other people and stuff. So, that is what uh I'm up to. Thanks, Awesome. Thank you so much, Bomi Guy. Uh, last up we have Mikey. >> Okay. I've been working on Turbo last week and we'll be working on Turbo this week. Um, last week it was we got the initial RP2 support in and it was um just a kind of quick and dirty get it in there. But now we want trying to get more chips in there supported. So there PRs are in place. Some have already been merged for the STM32, for the SAMD5X and for the Nordic chips, the NRF52 series. Um, the M0 SAMD21 is kind of coming and you should expect to see that in uh the 104 alpha kind of phases. Um there's uh we got if you're if you're really into the turbo stuff in terms of graphics or in terms of encryption type work where it's excellent um you know you probably want to be closer to the main tip on 104. Um in terms of uh uh other 5 gigahertz work I was doing um the ESP 32C5 is our first dev kit we've been using to bring in a 5 gigahertz Wi-Fi. So there were several PRs in terms of getting it to run in access point mode and monitor mode and to support um different channels for different countries. So those PRs are u in place and um last week was a lot about just merging up to the newer micro pythons and dealing with one kind of nasty little ESP32 ripple bug that the LLMs are having problem because they're pasting in hundreds of lines of code. And so um I feel like those things are in place and and pretty usable. it's passing all our benchmarks and making it through the farm testing. So, uh, this week will be about really getting going with Turbo and more um in more ways that it's more accessible across more chips. >> Sounds good. Thanks a lot, Mikey. Okay, and that's it for status updates. Uh, we have one final section. Uh, this is in the weeds. This is a chance for any longer form discussion. Um, and I did just throw a topic down here kind of as I was listening to Dan because I thought thought I well I wanted to ask him about this. So, um, before I I do that, I just want to say that if folks do have questions like this that you want to ask even if you can't make the meeting, uh, you're welcome to drop them in the notes document if you that you can find the link on Discord for. Um, and we're happy to to try to answer any questions folks have even if you're not in the meeting. Um, so Dan, I you threw LMS at translations and I was just wondering if you had thought any more about factoring out the translations from the builds. >> Um, it's something I talked about before, but >> that was actually the first thing that I asked the >> and so I said like is there is there a way to do this and just like link the translations or make them separate? And it came up with two or three things but they were not wins actually. wins in terms of code size. >> In terms of code size, right? Or or well in terms of No, it was really more about CI time. >> But uh I asked both those questions, but when you mean when you say factoring out like it did for instance suggest something that we've discussed before is to make the language be a file in Circuit Pi, >> right? uh which is a possibility. And then there were some other things like is there a different scheme that we could use which would make linking in a new language be just like a link step or or even like concatenating it on right >> or something right >> and those things were not actually really wins. It's actually spending I thought it was spending a lot more time recompiling stuff for each language and the answer is it's very little. Hm. >> It was less than I thought. >> Okay. >> So, uh, the amount of time that it actually spends is less. That might not be true on all languages, but it's or you know what, maybe not on the CJK languages or something, but I was surprised. And I I'll send you what the chart that it made. I'll send you the stuff that that that it came up with in that early in my session about that. >> Right. So I was surp I was surprised. >> I I I kind of expected it to save link time as well. Um not just compile time but like link time especially for like the Sandy 21 builds where we're doing LTO, >> right? And it talked about that and it it did save some time but it also made them them bigger because it couldn't do LTO then in some cases. So, or it prevented some LTO enhancements. So, I'll I'll I'll I'll send you what it thought about. [laughter] >> And so, then I moved on to, well, if you can't do that, can you make them this translation smaller? And that's where it had a lot of success. >> Sweet. >> Yeah. It's a it's a whole new world of like just go explore this space. This is something we've been thinking about. go explore the space and get back to me and you either believe it or you don't. But >> Right. And I I might have asked it. I think I was asking Fable about it because I thought it was kind of a high level thing. >> Right. >> I'll see. And I could I might also ask another model >> to see if I get different. >> All righty. Cool. Well, um, thanks for letting me know on that. Um, >> sure. >> That all sounds good. I'm glad I'm glad I found some wins to to make it smaller. >> Right. Right. >> All right. Uh let's wrap up. Uh this has been the Circuit Python weekly meeting for September 14th, 2026. Uh thank you to everybody who participated. Um if you want to support Adafruit and Circuit Python and those of us that work on Circuit Python for Adafruit, consider purchasing from the Adafruit shop at Adafruit.com. The video of this meeting will be released on YouTube at youtube.com/adafrruit. And the podcast will be the audio will be available as a podcast as well. It will be also featured or at least included in next week's Python formic controllers newsletter. You can visit adafruitdaily.com to to subscribe to that. Let me double check the calendar. I think next week is normal time. Yes, it looks like it's normal time. So, I'm just checking. We have a we do have a document or a calendar you can add to your own calendar about the meeting times. So, next week will be the normal time at Monday at uh 2 p.m. Eastern, 11:00 a.m. Pacific. Uh the meeting is held on the Adafruit Discord server, which you can join uh anytime by going to the URL adafru. Uh to be notified about the meeting and any changes to the time or day, you can ask to be added to the Circuit Python Nissa's role on Discord. With that, we hope to see you all next week. Uh, have a great weekend everybody and thanks a lot.