 Alright, hello everyone. This is the CircuitPython Weekly Meeting for September 18th, 2023. This is the time of week when we get together to talk about all things CircuitPython. I'm Dan and I'm sponsored by Adafruit to work on CircuitPython. You might ask, what is CircuitPython? It's a version of Python designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to support Adafruit and CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.it-discord. You hold the meeting in the CircuitPython DevTex channel and the CircuitPython Voice channel. Typically this meeting happens on Mondays at 2pm US Eastern time, 11am US Pacific time, except when it coincides with US holiday. In a note stock, which we post weekly, 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 would like to receive these notifications, ask us to add you to the CircuitPythonistas Discord role. There is a notes document to accompany the meeting and recording. The final notes document includes timestamps to go along with the video, so you can use the doc to skip around and view the parts of the meeting that interest you most. The meeting tends to run 30-45 minutes. After each meeting, we post a link for the next meeting's notes document to the CircuitPython DevTex channel on the Adafruit Discord and we pin that message to that channel. So check the pin messages to find the latest notes doc. So you can add your notes for the next week. If you'd like to participate but cannot attend, feel free to leave hug reports and status updates in the document for us to read out loud during the meeting. So the meeting is held in five parts, Community News, the State of CircuitPython, Libraries and Blinka, hug reports, status updates, and in the weeds. I'll explain each of these as we get to them. And with that, we'll now start with Community News. I'll take a timestamp. So these items come from the Python and Microcontrollers and Weekly Newsletter. I'll tell you about that more in a minute. So first item is the IEEE Spectrum Survey of Top Programming Languages for 2023. There was a ranking of this. Python and Java are on top with Python a leader by a considerable margin. Python has become the jack-of-all-trades language and the master of some such as AI where powerful and extensive libraries make it ubiquitous. And although Moore's law is winding down for high-end computing, low-end microcontrollers are still benefiting from performance gains, which means there's now enough computing power available on a US 70 cent CPU to make Python a contender in embedded development. So this is great. We're basically saying that CircuitPython and MicroPython, they mentioned them in the first paragraph of the description, which is fantastic. Or maybe it's not the first paragraph, but it's prominent. Okay. Next item we'll talk about is that CircuitPython 8.2.6 was released last week, early in the week. The most notable change to 8.26 since 8.25 is just that the TLS root certificates list was updated to make sure that it supports servers that use let's encrypt certificates, which is used by many, many, many, many web servers. So there was a brief regression in 8.25 when those certificates didn't work and we put them back. So feel free to, if you still have trouble connecting to HTTPS sites from CircuitPython, let us know and we'll look at the root certificates list, but it's been considerably cleaned up in the past few releases. And then finally, for our news items this week, Lady Aida was interviewed on the podcast, which is from Tom's Hardware. It was on September 12th. There's a link to it in the note stock and in the channel. And she, the subject is the following, writing libraries to support our favorite microcontrollers is a big task. What if ChatGPT could lend a hand? Adafruit's own Lemur Lady Aida Freed has tasked ChatGPT to write Arduino drivers in her own style, creating a mini Lemur bot to handle the task. We sat down with Freed to talk about AI can help Adafruit and wider community to write drivers and improve workflows. And I'll note, I was actually skeptical of this, but it sounds very interesting. And also importantly, what Lady Aida does is she uploads stuff to ChatGPT so that it can have more context about what's going on and it seems to make fewer mistakes that way. Okay. And finally, just to talk about where these news items came from, they came from the Python for Microcontrollers Weekly newsletter, which is emailed every Monday. It's prepared by our own Ann Varela who's in the chat. And the archives, there's a link to the archives in the note stock. It highlights the latest Python and hardware related news from around the web, including CircuitPython, Python and MicroPython developments. We'd love to have you contribute things to the newsletter, either your own stuff or things that you see on social media or on the web or in the news. You can do that by emailing cpnews at adafruit.com. You can send us a tweet on Twitter. I won't use the other name. Or you could submit a pull request to the GitHub repo. There's a link in the note stock to submit under this item. Any of those things is fine. Okay. So now we'll move on to the next section, which is the state of CircuitPython, the libraries in Blinka, which is a quantitative overview of an entire project. It gives us a chance to look at the health of projects separate some of the status updates we'll present later. We'll talk about the project overall and then separately discuss the core, CircuitPython core libraries in Blinka. So first step, overall, in the past week, you've had 22 pull requests merged, 17 authors. There are some new people, but I think they were mentioned last week, though I don't remember FAST 9516, Max last week, or N3059HF. There were eight reviewers of those 22 pull requests and there were 36 issues closed by eight people and 15 open by 14 people, which is a nice improvement on closing open issues. So next up is a discussion of the core, CircuitPython core, and Scott, if you're available, could you read that? Sure. Although I am distracted and I want to find it in the doc here. Oh, and my fans let me still. Sorry. I was thinking. Okay, so for the core, we had 12 pull requests merged from 12 different authors, so that's pretty awesome. I won't go over new names because I know Dan just did. We had five reviewers, which is higher than normal for us too, so special shout out to BlitzCityDIY and Tyeth, who have done some reviews for the core this week. We had 20 open pull requests, which is well under our 25 single page mark, which is great. We do have a number that are quite old, although I think the IDF merge that I'm working on is one of those. So as always, please take a look if you're involved in any of these old PRs and see if we can close them or update them or what we can do. Issues-wise for the core, we had five closed issues by three people, seven open by six people, so we're now up to again, and I have a number of folks involved. We have 712 open issues, which is two more than last week, obviously. Not too bad. We do kind of grow in issues a little bit over time. The way that the IDF-funded folks prioritize is through milestones. We have A2X, which is stuff we want to get stable pretty quickly. We have nine open issues there, and then we have 53 open issues for 9.0, which is our next major stable version, which is probably months away from being stable. But then we also have long term, which we have 605 open issues. These are not priority issues for IDF-funded folks, but if you're interested in working out of them, we're happy to support you in doing that. And then lastly, we have two issues not assigned to mouse, so those issues need to be triaged, and that is a priority for us to do. And that's the state of the core. All right. Thank you, Scott. Next one. Thank you. Two libraries by FOMIGuy. All right. Thank you, Dan. This section covers the CircuitPython libraries, which is the Python level code, the libraries that interact with drivers and other various helpers and things that run on top of CircuitPython. Across all of those libraries in the past week, we had four pull requests merged by four authors with two reviewers. In terms of the newer names, I think the two that I don't recognize from before are ADCC and FAST-8516. So thank you to those folks who might be newer or less frequent, and thanks to everybody else as well, who we see more frequently in this list. Of the merged pull requests, the oldest one merged this week was 85 days old, and the newest one was just one day old, so we got a fresh one in as well. That is leaving us with 46 open pull requests. The oldest of those is 396 days, and the newest is two, although I think it does count drafts as well. I believe our oldest ones at this point are down to just drafts. I will echo what Scott mentioned about the PRs in the core, if any of these are yours and you need help or guidance or anything like that, definitely feel free to ping me or ask up in the Discord to get help on those. Back to the stats for the past week, we had six closed issues. Those were closed by three people, and then we had four new issues opened up by four people. That's leaving 635 issues open overall, and there are 19 of those that are labeled good first issue, which is a great place for folks who don't have much experience, but want to get involved in contributing to Circuit Python. If that description matches you, head over to circuitpython.org slash contributing. There's a list of the open PRs and issues there, and I would also encourage you to join us on the Discord here, which is where this meeting occurs. Lots of folks are around there that can help you get involved as well. Wrapping it up, we have the PyPy weekly stats. Let's see what is that, 63,816 PyPy downloads over the 313 libraries, and the top 10 libraries are listed here in the note stock. I'll let you look at those if you'd like, and there is also a list of the libraries that were updated in the last seven days, if anybody wants to check those out, and that's what we've got for the libraries this week. Thanks. Okay, thank you very much, and now we'll move on to Blinka, right by MicroVelisa. Hello, so Blinka is our circuitpython compatible layer for MicroPython, Raspberry Pi, and other single board computers. This week, we had six pull requests merged by one author, which is myself, and for reviewers, there are currently four open pull requests amongst all the repositories, and there were 25 closed issues by five people and four opened by four people, leaving a net of 86 open issues. We had 15,539 PyPy downloads in last week, 6,047 PyWheels downloads in last month, and we are at 121 boards. So overall, a lot of activity this week in Blinka, as I've been working on closing a bunch of issues, and so it's looking really good. All right, thank you. Hold on just a second. All right, and now that we're done with status reports, we'll move on to a hug report. So what is hug reports? It's a chance to highlight folks in the circuitpython community and beyond for doing awesome things. I'll start and we'll go down the list, which is mostly alphabetical usually in the note stock, to give everyone a chance to participate. If you are text only or missing the meeting, I'll just read your notes when I get to them in the list. So feel free to submit text only notes if you need to. Okay, so I'll start. So first of all, re-upping. We're very sorry to see Catney leave us, gigantic hugs to Catney for your work on circuitpython guides and libraries in the community over the past seven or so years. You shepherded this community to the excellent state it is in today, brought on board many people who are now volunteers or are paid to work on circuitpython or in the community and kept a clear vision of what the community should be. We will miss you greatly. And I remind you, Catney will be participating, I understand, but she's no longer going to be sponsored by Adafruit to work on circuitpython. She's charting her own course for a whole bunch of very interesting things that are coming up. So thank you again. Thanks to ADCC for redoing the HID library timeouts. So devices will wait patiently until the host is ready. That's been something that we wanted to do for a long time, but thank you for setting that in motion. It was really needed. And thanks to Jeff, who I did some pair merging with this morning and it was really successful, working on, you know, relying on his knowledge of a whole bunch of things that I didn't know very much about in the core that I used his expertise and together we were able to merge three rather recalcitrant files. All right. Next up is 2231 Puppy, who is text only, who says just a group hug. Okay. And next up is Carter, also text only. Thanks to FOMI guy for pushing some final code tweaks and merging a semi-stall PR for fixing an EMC 2101 library import issue. Thanks to Dan H for some time spent unfortunately wasted helping chase a weird pie portal issue that ended up just being a bad SD card. And thanks to Katnip for all the years of amazing contributions to the circuit pipeline community and everything else you helped us with at Adafruit. Happy trails.show. Okay. Next up, C Grower. Thanks to Katnip for preparing to write a new chapter after years of enthusiastically bolstering the circuit Python community. You set the standard for tireless and empathetic community participation that we can only hope to emulate. I've grown as a contributor largely due to your help and example. Best of luck to you as you turn the page. Thanks to GJ Devon three for amazing and somewhat overwhelmingly huge, the amazing and somewhat overwhelmingly huge RGB panel project besides conquering the mysteries of extending the circuit Python to make it work. The 36 ampere power supply capacity is getting close to what a welder might need. Yeah. Okay. Thanks to John Park for the new fundamental synth IO learning guide. It clearly explains the basics of how to make synth IO do its thing. The symbolic nomenclature used is perfect for documenting and sharing synthesizer configuration and operation. And thanks to whoever came up with the idea for the playground notes section of the Adafruit learning guide system. Thank you. I published a few project documents out there to give it a try. All right. Next up, DJ Devon. Thank you, Dan. I have a hug for maker Melissa for advice on cherry picking matrix portal library layers to avoid unnecessary overhead. A hug to Tanute for an interesting stream on merging ESP IDF into the core. I've never seen like the ESP IDF stuff that you guys have to deal with. And I'm glad that you deal with it. And I don't have to do anything about it. A hug to foamy guy for great Saturday morning stream. I'm working with HTML templates. And of course, a huge, massive hug to Catney for her last week as discord admin, as well as offboarding. You've been absolutely stellar for everything you've done behind the scenes from GitHub to learn guides to all the stuff that nobody sees, but it is felt like your presence is felt more than seen. And I will miss you. And I will miss fearing you more than Dino bot. Love you. Bye. All right. Thank you very much. Okay. Next up is foamy guy. All right. Thanks, Dan. Echoing what a lot of folks say, hug report for Catney. Thanks for all the work you put into the project and the community. Plus all of the help that you've given me when I joined Adafruit and first started getting involved. Very, very much appreciated. Hug report for Michael Pocusa for continued work and coordination on a templating library and group hug for everybody. Thanks. Okay. And next up is Jeff. Hello. Catney will be seeing you around. I know you're going to but keep the channels of communication open with this community and with me personally. You've been a tremendous force for good in this community. And that's even before I account for the fact that probably 90% of what you have done simply goes unnoticed. Well, now we'll notice. Dan, thanks for your work on the merge. And I look forward to being of assistance as I can. And also a second thank you for agreeing to take on extra discord responsibilities. And I also want to give a big hug report to the micro Python developers. So your Python is a friendly fork of micro Python. So besides supporting Adafruit through your hardware purchases, you can support micro Python, for instance, through the GitHub sponsors feature. And lastly, I have a group hug. All right, thank you. And next up is catney. All right, that's a big one. So first up a group hug to everyone. This community has been a huge part of what started this chapter in my life. And my involvement with it has been one of the most fulfilling and amazing things I've ever done over the last seven years. I was the source of code plus community equals circuit Python Phil showed up on discord early on asking for help coming up with a tagline for circuit Python. There were a lot of excellent snake related ideas. But to me, the thing that drew me to it was the community. I ended up typing up a pretty long message explaining how important the community was to me and how critical it was to my involvement. Circuit Python made coding more approachable to me. But the community is but the community provided a safe and welcoming place for me to learn more about it code plus community equals circuit Python. I believe this is still a completely valid statement. So thank you for being amazing. Thank you for being a part of the welcoming positive supportive place that we've created together. And finally, thank you for welcoming me as a community leader and giving me the opportunity to gain the experience of building an open source community. I want to thank the community moderators on discord. Thank you for being an amazing mod team. This community would not be so safe and welcoming without you. We've built it to the point where we have little to do other than catch spammers. But that was not without an immense amount of work on all of your parts. I appreciate your help and your part in creating what we have. To the discord helpers, keep being great and don't stop recommending new helpers. Everyone that has been recommended by one of you has eventually accepted and have worked out amazingly well. Thank you for being willing to be more visible in your respective spaces and for all the work you put into this community. To Dan, Jeff, and Scott, thank you for being a great team to work with and for all your help and support throughout the years. I would not have reached the levels I have without some nudging along the way from each of you. Liz, I'm grateful for the opportunity to have worked directly with you on guides over the last nearly a year. You're fantastic at what you do and I appreciate all the help you've given me with guide work, especially when I couldn't think of good guide taglines. To Ann, thank you for all your personal support throughout the years. As much as the newsletter is a huge undertaking, I'm glad that I was asked to take it over so you could have time away when you needed to because it gave us the opportunity to work together. And thank you for picking up the blogs that I miss on a regular basis. I really do hate WordPress. Carter, thanks for always being willing to dive into a schematic with me or explain some fundamental electronics concept that I miss due to my learning path to get where I am. You always take the time to explain everything from the ground up and I've learned so much from you. Melissa, I'm really glad I had the opportunity to meet you in person multiple times. I greatly appreciate your insight on things and all the help you've given me with questions related to things in your wheelhouse. I look forward to you getting back to creating personal projects and posting videos. To Tectric, for always being available to jump into CI issues, being willing to break things and being perfectly happy to fix them. It's been great to work with you and I appreciate all the CI and library help. To Tim, thank you for always being up for helping out with pretty much everything I've come up with in the libraries, etc. Especially thank you for all the help with the personal projects and ideas such as my fantastic PyCon Pie Badge this year, where folks can interact with it over wireless to change the LED colors and play a snake game. It was everything I was hoping for and it really gave people an opportunity to interact with Circuit Python without actually having to do anything with it themselves. To Bruce, thank you for a million things, but especially for being so helpful with wording things. Your help with the community code of conduct has been invaluable. It's always been useful to be able to bounce things off you as you almost always have a better way to say it. Thank you to everyone that I've met throughout the years, whether online or in person, and to everyone who supported me in so many ways, including reading my guides, helping me with code and bugs, letting me know when something I suggested worked out, and so much more. One of the most amazing things has been you telling me your stories of how something I created or helped create had a positive impact on you or folks you know. I will still be a part of this community, albeit in a different capacity. Please don't stop sharing your stories with those who have that sort of impact on you. It can end up meaning more than you know. And to anyone I miss, know that you have not gone unnoticed. My brain can only process so much at once and this was already a lot. Thank you. Okay, thank you so much, Cathy. And I would say a group you're welcome, you're most welcome for everybody you've mentioned. And we'll move on to Maker Melissa. I have a hit for Cathy. I'm glad I was able to get to know you and wanted to thank you for encouraging me to try out some live streaming on Circuit Python Day, both last year and this year. I'm also glad about the opportunities that we've had to work together on various things, including attending PyCon together. And also, I'm glad we'll be able to keep in touch and get everyone else. All right. Next, Mark Gambler. Thank you, Cathy, for pushing and helping me to get involved as a reviewer, which led to my eventual contributions to libraries and then the core for proactively reaching out to ensure roadblocks were removed. And for your countless guides, I rely on weekly to help me with my own projects. I hope you still drop by the community from time to time to say hi. Next is I'll read Macao Procusas. Thanks, Fomigai, for helping with test, help with testing the template engine Saturday stream and Sunday pair programming session. Next is Paul Cutler. Thanks, Catney, for everything you've done for this community. I can't wait to see what you do next. And next up is Scott. Catney, thank you again. Yeah, it's hard to imagine Circuit by the without you and I'm working on it. Circuit by the and then the community surrounding it wouldn't be what it is today without you. I, everyone, everything that everybody has said is true, but I also wanted to highlight that you've managed the libraries, the libraries for Circuit Python and you've done a great job doing that. And it's a core reason that folks come to Circuit Python. So thank you for that. And I too, I'm excited to see what you do next. And then also, I got to give micro dev a shout out as well, because I just, I just made the PR for the idea of 5.0 merge and micro dev did the vast majority of the hard work of that. So thanks to them. All right. Thank you so much. Thank you so much, everyone. Okay, we'll move on to status updates. Status updates is our time to tell folks what we're up to individually. I'll start and I'll go through the list. When I call on you, take a couple of minutes to talk about what you've been doing since the last meeting and what you plan to be doing until the next meeting. This is also an opportunity to provide tips and tricks relevant to what people are working on. If a discussion becomes too long for status updates, we can move it to the end the weed section. So as I start, as I mentioned, I released Circuit Python 826 last week to add just to add a certificate for let's encrypt. There are a couple of other minor fixes. So that worked. And we don't have anything really imminent for 827, but I'm sure there will be an 827. And as I mentioned, we're working, I worked a lot more on the MicroPython v1.20.0 merge. I pruned down hundreds of merge files, merge conflicts to about eight files. And then I was kind of stuck on those. So Jeff and I did pair merging this morning to go over some things that he has a lot more knowledge about. We did three of those files and we'll continue in that same vein for the remaining files later today or tomorrow. And so once these merges are done, I can finally do the first commit of the merge and stop saving things by hand. Because when you're doing a merge, you have to finish it before you commit, unfortunately. And we'll start trying builds. And then I probably will also make a second pass through the changes, which was helpful last time to catch some rough edges. All right. Next up, I will read 2231 puppies, got Kaikad running on Android. And there's a link there for that in the notes about how it works in Puppy's blog. It's in the channel too great. Okay, continue working on the e-fidget. It's almost time for version six. All right. Next up is C Grover. I'll read that. Release the code for the windlass IoT weather times project. The summary is available here. There's a link. Built a few matrix portal twister adapter PCBs from Oshpark, of course, the PCBs allow a matrix portal board to be turned 180 degrees. So it will be completely contained within the RGB display panel shadow, rather than sticking out on one end essential for mounting the panel any picture frame. That sounds very interesting. And maybe it's gonna be something that we have in the store. Okay. We built the remaining physical patio wind chimes using one three second stainless steel cable and crimp ferrules rather than nylon fishing leader. Didn't realize there was a system of cable and ferrules of that size out there. I've been living under a rock and there's a link for that too. Okay. Next up is DJ Devin. Thank you. Last week, I went from four matrix panels to nine driven by the matrix portal S3. I fixed a driver with open AI taken lead from Lady Aida on her open AI session to read an ST7796S display to refresh in landscape mode. I went on show and tell last week with 12 matrix panels that were jumbled out of order as a surprise progress update. Unfortunately, it did not work due to the incorrect ordering. This week I figured out why the 12 panels were out of order. The RGB matrix is extremely particular about the first panel placement in the serpentine order. I'm extremely happy with 12 panels. I might attempt to add more for science because I had not hit the limit yet. I created a quick graphic for someone on Discord to easily differentiate between a QDPI ESP32S3 with eight megabytes of flash, no PS RAM versus four megabytes of flash, two PS RAM. They are visually identical except for the model printed on the ESP32 chip that you need a magnifying glass to read. Liz asked to use the graphics in the QDPI S3 learn guide. So I cleaned up the image a little bit for better illustration and credit goes to Todd Bot for spotting the differences. I only made the graphic for it. There's that. And then I finished 3D printing 26 brackets for the 12 panel LED matrix that will be going on show and tell this week with a working 12 panel demo. The only difference in the code between four panels versus 12 panels is height, width and column count. All right. Thank you so much. Okay. Next up is FOMI guy. All right. Thank you, Dan. Last week, I continued working with Michael Pocusa on the templating library that we have been working on. Got a lot of great progress on that. It's getting to the point where it's about ready for publishing. Have a note in the weeds to discuss that a bit further. A couple other things that I was doing some testing on last week. There was a ethernet wiznet PR. So I got that featherwing back out and ran through all the tests on that to try it out. Before that last week, like last Monday, I was working on the patch for the docs theme fix and getting that ready to go, test it out and submitted into Etabot. And then over the weekend, I tried out the new TFT shield on the Metro S3. I was particularly interested in trying to get the SD card to see if I could work with that, since it's a separate SD card from the one that's on the Metro. I did not have luck, but I do have a Metro S2 that I can use for the same thing I have in mind. So I can still kind of continue on with that. It's no biggie. This week, if nobody has any concerns on that RTD patch fix, then I'm going to get the Etabot PR merged and run that today. Later on, or later on this week, if anybody else wants to take another look or if any concerns come out. And then the new PR that I have lined up to take a look at this week, which I just got some hardware for as well, is the ADT-7410, which is a temperature sensor. And there's a PRM that makes many improvements and rewrites the library to use register class. So that's what I'll be taking a look at next. Thanks. All right. Thank you. Okay. And Jeff is up next. Hello. So last week, I wrote the BitBang SPI over IceGridSeaBuzzExpander. The pull request is green, and I'm at least as of earlier was waiting for a review on that. So hopefully that will go in soon. And with that pull request, the Espressif ESP32-S3 LCD EV development board now boots to the display, which is pretty cool. Even coated in C, it takes a fair bit of time to send the initialization code. Based on an internal discussion, that boot time initialization is now happening with the IceGridSeaBuzz at 400 kilohertz instead of 100 kilohertz. So it takes about a second and a quarter. The other thing that I did last week was some small improvements to the RGB matrix documentation in Read the Docs. The air quality here is pretty lousy right now, so bear with me as I clear my throat. Anyway, this week, I've got those two PRs to get to completion. I'm starting to help out Dan with the merge, as he told you about, and I'll be doing a lot more once he is able to commit and push some code, then we can kind of divvy up the errors or whatever it is we're grappling with. And I'm a bit late to the party as the guide was published last week, but I will be reading through that Synthio guide to A, learn things, and B, to see if I have any feedback to give. But I think it's probably pretty much a perfect guide. And anyway, coming up soon, I'm going to be out starting on October 4, and then my day back to work will be November 13. And in the Note Stock, there is a list of a number of cities where my vacation will take me. It's in Spain and Portugal. If you wanted to meet me, show me around, or just get a cup of coffee, you can talk to me here on Discord, and I would be more than happy to see if that would work out. And that's what I've got. Thank you. All right. Thank you. All right. Next up is Kat, for Status Report. All right. So last week, I put the Metro M7 SD guide into moderation. It has been moderated. I haven't had a chance yet to look at what needs to be fixed up, but that'll be good to go, and that'll be published this week, I'm sure. Otherwise, this week, as any fixes found in the guide, I'm wrapping everything up and off-boarding. My final day contracting with Adafruit is Friday, September 22, which is this Friday. And so it's just sort of wrapping up loose ends and getting info to people who want it and so on and so forth. That's what I've got. All right. Thank you. All right. And Makar Melissa is now up next. So last week, I looked on GitHub issues with the focus on the Blinker-related ones, and I updated the RA-8875 Learn Guide, and this week, I'm going to continue going through and bearing down other GitHub issues. Okay. And finally, Blast of Ozzie Scott is up for the last Status Report. All right. So for me, I said the 5.0 was pretty much ready for review or for PR. I just merged it in. So, all right. I merged in the IDF changes that I was needing for the IDF5 merged PR. So I just made the PR at 84.11, I think. On Friday, on my stream, I started the 5.1 merge. It doesn't look too bad. It looks pretty minor, but I will do that up as a follow on PR still. If I remember right, on Friday, I got the S3 working, but I also wanted to add the C6 and the H2 as well. So I'm fully in IDF land, and then if I manage to get out of that by the end of the week, I will also be doing some enhancements to the Web workflow stuff. Okay. All right. Thank you. Thanks. Next. That's it, right? Okay. Scott spaced out. Next up is in the weeds. This is a section for long-form discussions that come out of status updates so that people identify ahead of time. So if you have any in the weeds topics, please make sure they get added while we're discussing other things. So we're not waiting around to see if you have something and you can just type up some background. So we've got two things today or more than that today. Three things. So this will go longer than usual. So first, 2231 Puppy says, I love Mu, but it's pretty beginner-oriented. I'd love to see an officially endorsed VS code or other code or editor extension for Circuit Python that's a little more capable. The existing one is a little buggy and doesn't have official backing from Adafruit. I'm sure full support for VS code, as in helping people with it, is too much to ask, but having a Circuit Python editor set up for more advanced users would be much appreciated. So I'll just make a couple of remarks here. We don't even support Mu officially because obviously maintaining one of these things is a noticeable amount of work. So we recommend Mu, but it's not officially supported by Adafruit. Besides VS code, there's also PyCharm. I don't know if there's a separate plugin, but it works pretty well. And if anybody else has comments, please go ahead and say them. And if anybody would like to work on an extension to any editor, that would be great. So you might check out PyCharm, I guess is what to say. I think the challenge is that those of us that are more advanced are all used to for things. Yeah, I don't know. It comes down to personal preference or tradition. Yeah, and I have no love for VS code, so that's part of it as well. Okay. All right. Thank you. And 2231 probably Euromisha in the chat. Is that right? That's right. It looks like I see a puppy. I think it's Micah. Micah? Okay. All right. Next up is Jeff, who is interested in talking about I2C bus locking. Yeah. So the question for my lightning talk is, what if we abolish I2C bus locking? And I'm thinking about this because it seems to be the largest problem with the idea of I2C bus expanders working kind of generally like digital IOs with background things like keypad. Spy bus locking makes sense. There are two reasons that we need to do it. One, you have to use the spy bus and manipulate the chip select pins. And each device on a spy bus can have a different frequency because when a device's chip select is not selected, the device just doesn't even monitor the rest of the bus. On the other hand, the I2C bus, there is no chip select pin, and there's no setable frequency. All of the devices on the bus have to work at the frequency that is selected. Although we had an internal discussion about this, and that turns out not to be exactly true, but bear with me and just pretend that's true. So I've looked at our implementations because another thing is, can an I2C transaction be interrupted for the background tasks? And this can only occur in the STM and Broadcom ports. So preempting long I2C transactions has not been seen as necessary. We would have to remove those calls and replace them with just busy waiting because otherwise it would be possible for, for instance, a display IO update to an I2C display to start happening in the background during a foreground I2C transaction if we changed that. A possible historical reason that this existed is originally we didn't have the function write then read into, or we didn't consistently use it. And in order to get the repeated start transaction, the locking would have been required so that nothing else could grab the I2C bus between the write and the subsequent read that has to be done under the repeated start condition. If we decided to do this, then the try lock and unlock functions can remain in the core during a transitional period and they would simply not do anything. Try lock would always say, yes, I succeeded and unlock would always do nothing. So anyway, that is the brain dump of what's on my mind. That's the why we should do it. That's the why it looks like it would be a minor change. And that's what's on my mind. Thank you. Okay. So, and I added, I was wondering if we ever added threads, would we get into a state in which something like a write, a write then read into would be interrupted in the middle? For instance, that would be what I worried about. Also, if we implement some kind of async support, basic IO support for I2C, I don't know. I didn't write that down, but that's another possibility. Another question is whether in the case of preemptive multitasking, whether there could be there could be internal invisible locking if the size of a transaction is only one of these function calls. If the size of a transaction is longer, like if there's a sort of a semantic transaction in which you have to have control of the whole thing for longer, then you need kind of external locking. But if it's always the case that the locking is internal to one function call, then we could do internal locking. And that would solve the problem of some of those things. Right. And that, I think it speaks a little bit to what that Shippu said in text. He writes, we still need I2C locking because there are I2C based displays that are being used in the background. But if, for instance, when you call into the I2C write function, that can only go into refreshing the display if there is a run background tasks call there. So by saying that those should be removed in the two ports where they are, the STM and the Broadcom, that would mean it was no longer possible for the background task to interrupt. But there could be other future forms of concurrency, such as hypothetical multicore or threading. And those would have to put some kind of lock around just the write function or the read into function because they can't all access, like the microcontroller registers that control the I2C bus. They would have to wait for the previous in progress operation to finish. And that would be some kind of locking. But I think it could be at the function level, not an explicit lock that's taken in your circuit Python code. Right. Now, have you looked at what does micropython do, any locking? That would be a good thing to look at. I haven't. I suspect they don't, but I don't know. I don't think they do. They do? I don't think they do. I don't think they do. Also, Scott, can you say anything about, was it Tony who originally came up with this or was it you to have it? It was me. Okay. And I think, so I think just right pointing to the like write then read into was two calls originally, and it was like Linux that forced us into one call. I'll tell you, I'm really scared of removing it only to find that we do need it. Because like the other the other thing that the other thing to take into account is like one of the reasons we added it is that we knew we were going to build code on top of it. And so if we're now we're like, not only are we talking about like at least stubbing it out in this API, but potentially removing it from all the code built on top. The moment you like, I'm scared of doing that because I think we could find out that we need it, right? And we already have this code that does it. I think Jeff, I think it would help to be more explicit about what you're trying to prevent. I think there's one more level that we need to talk about why you want to do this. And I think it might be that by having these APIs, we risk people mislocking, right? So like in a world where you agree, where you can lock it, there's possible abilities that user code locks it for too long. Or they simply never unlock it. You know, when you don't use a bus device I2C, you could write a try lock and then have an exception, including hitting control C. And you end up with the bus locked in a variety of bad things happen then. The lock doesn't get unset by reset. I think it does by reset. I guess I think it's okay for these internal uses like IO expanders to not work in the case that like mislocking happens. I'm not convinced that it's worth removing all of this locking because of this case. This is something display IO has to worry about because it takes that lock for the display and it just doesn't update, right? Like it doesn't crash, it just doesn't update if it can't get the lock and I don't see why that can't be the case for other uses like IO expanders. Well, so suppose that you've got a keypad.keys and some of the pins are IO expanders. I guess the keypad.keys would have to first check every pin that it's going to talk to and say, are you an IO expander on a locked bus? And if all of them say, no, I'm not an IO expander on a locked bus, then it would be okay to scan the keyboard. Right. And that feels, that gets a long ways away from we could just pass in a different kind of object and have keypad.keys work. We would have to go through and explicitly in every place make these new checks. But you're assuming that it has to do a lock check. Whereas if you were passing it in a generic Python object, you would have to handle exceptions. And if you're handling exceptions, generally, then the underlying code could also do the lock check and raise an exception to you. And then your outer code is generic in exception handling. Yeah, I guess. Right. And this is something I want to have, we need to talk about the BitBang stuff as well for the same reason. Like if we moved to a world where like your BitBang IO takes in digital in out like things, then there's no reason to have this other code because we already had BitBang IO that could do these sort of weirdo abstractions of like, I have a pin over I squared C and now I want a BitBang spy. Like you could create a BitBang IO spy with the digital in outs that use I squared C under the hood and achieve the same thing. Yes, although it would probably be slower. It would probably do additional I squared C bus transactions. But it's true. I don't know if it could do it. And you know, if you're alluding to the fact that you could like maybe, I don't look into detail, but maybe you're setting two pins at once, right? Yes. Maybe maybe that's the optimization we would need to worry about because you know, that's something that's an optimization. I think people would like from Python as well, like a multi pin digital in out sort of thing is something that I could see people wanting. And then maybe that's the right abstraction instead. Yeah, this. So I mean, if hypothetically we there's this PR that you're alluding to that is an open PR right now, and that's like just give the minimum functionality we need to enable these displays. And you know, not spend five seconds or 10 seconds initializing them because we have a loop coded in Python, but spend the least amount of time because it is kind of lengthy. It adds over a second to the initialization time when you do it as fast as possible. If we did IO expanders later, the implementation of that function would become much simpler. You just delete it all and turn it into into use a bit bang IO. So that would get simpler. And then we could drop the this function in circuit pipe on 10 or 11 or whatever. But I'm trying to get trying to figure out. Can we get to where there there's like few caveats around IO expanders because I feel like caveats like reading a digital pin might throw an exception now. I feel like that is not going to be super usable and we'll just end up irritating people. I wouldn't like that. This is kind of what I'm feeling. So maybe we need to like have a separate meeting or discuss this in an issue or something. One thing also that is you're talking about IO expanders in particular, but it's also true that people often don't understand how to use the locks. And Adafruit bus device, you give it a low level object and then it wraps it in a higher level object. And I'm just wondering whether we might have a constructor on Adafruit bus device or convenience functions that do that. So you would never see the locking. For instance, the fact that the scan operation is on the lower level object like why? You know, I always every every two or three weeks, somebody says, right? They forget to call trial lock before doing scan. And that's just it's like, why should they shouldn't really see that object most of the time? Yeah, that was a problem I had early. I remember exactly what that was like and how it was kind of like, oh, this is this is really fiddly. I'm not sure how I feel about this. Right. It was like, it should be like underscore I2C or something. And and and Adafruit bus device should actually take care of that management. I mean, you might have to tell it, oh, this is a bit buying IO object or this is a bus like a logic. And you want to use board, you know, you usually want to have the bus. But on the other hand, you don't want to use the bus except through Adafruit bus device. So I don't know. Right. Yeah. The other thing about having a discussion about this is it would be good to bring GitHub user Zodius infuser into this because they are working on code to support upcoming Pimeroni board. And they have probably thought about this and thought of things that we haven't. And so I don't know if we have lines of communication open with them to try and like get a video chat or something, but it might be worth doing. Yeah, I mean, I can arrange that. I think they're in the UK. So it's just mostly time. Deshi Poo is also saying very important things. Oh, I haven't been paying attention to the text. Let's let's read that. Yeah, like he says, Treating pins on IO Expander's regular GPO pins is a huge can of worms. And people won't understand why it's slow. That's yeah. That's right. I mean, so this sort of idea of we've also had a discussion which really unrelated to this about the fact that like digital in and out encompasses both pin naming and also pin state, like whether or not there's a pull up and things like that. And so this whole thing might be perhaps ought to be we've thought in some way. But I don't know exactly what that is. So I mean, you're alluding to the pad idea. The pad idea, right, which it's not it's not naming because we have a pin object, which is separate from just right. If you look at so if you look at MicroPython, MicroPython uses numbers and now occasionally strings for pin names. Right. Okay. But the pin object is actually a pad in our way you described pad. So maybe that whole thing needs to get rethought in some way. And maybe there's some higher level abstraction that would that would that would work for all this. I mean, that's what we're that's what we're discussing in in the issue around drive strength. Yes. Yeah. Pad again. Right. But I don't I don't I don't think that applies to this IO Expander idea because like in IO Expander really just has one kind of peripheral that's connected to the pin. So I think the right abstraction for that is the digital in and out and yeah. But then then again, it does have drive strength and things. So I mean, I think the short term conclusion, maybe I'm wrong, Jeff, for you say like, well, maybe we have to it isn't just as simple as drop again. Yeah, I can accept that. Yeah, it was just I felt like the argument could be made, but I appreciate that we shouldn't just willy-nilly throw away these protections that we have against the access. And yeah, it puts me back to we're doing the right thing right now by creating the one higher performance thing we need for one purpose. And we need to understand more before we try to create a generic IO Expander that works with objects in the core like keypad. Because of course, we do have objects that implement the digital IO, like in a duck typing way that we have for seesaw or whatever. And those work fine, but you just can't pass them to these kinds of functions. Like keypad or BitBang IO. And I think that's what I'm getting at is like, we already have Python libraries that implement digital in and out like things. And maybe we need to make like native BitBang IO work with those things. Like it could do the Python dictionary lookup of like what is my function that I'm calling to do this set or whatever, right? It could optimize that out once and still run the like clock set data loop in C and it'd be faster than the Python version. Yeah. And I think we did something like that with the core implementation of a bus device where it does work with with any kind of object as long as it has those method names. Right. It may be a little bit different because value is a property rather than a function call. But that's I don't know what that exactly ends up looking like. Yeah, that's true. I don't know if the I think you might have to set it through the lookup mechanism, unfortunately, but there is caching on them under under the hood that would probably mean that it's not too expensive to look it up at a second time. I agree with you, Jeff, that like we'll just do this one method to do it fast at the start. And then we can worry about it later. And like you said, we can reimplement it differently and then take it out. All right, I agree with that. So I'll get back to you on the pier. All right, it it feels in a way like we're going around in a circle, but it's really helpful to just reinforce that what we're doing right now is probably the smart thing and grabbing some big, big elusive goal is not the thing to do right now. So thanks to all of you. And that's all I need. It is worth thinking about because it's possible that we we could decide on something for 9.0 because we're not imminently like switching what I think of between alpha and beta where once we're in beta, we don't really want to change. We don't want to break any APIs when we're in beta. It's more about like adding any other features and then when we're bug hunting, it's release candidate. So we do have a little time if we do want to try to get 9.0. But it feels like one of those ideas where it's really going to take till a circuit by then 10 to decide how we want to evolve all things. All right, I think we should we've said about 20 minutes on this. So you probably should move on to the next in the weeds. Those things we have so many, but thanks for bringing this up. And I think it's caused provoking stuff. Okay, I will I will move on to the couple cruises. Next one is which is about the templating engine library. And I'll read it since it's text only. Sometime ago, Foaming Guy did try implementing U-Template library to work with Circuit Python and the Adafruit HTTP server library. Due to the Adafruit, due to the API exposed by U-Template, the whole process required some not so obvious steps and some boilerplate code in order to make it work. Over the last two weekends, me and Foaming Guy have worked on the prototype of a Django like templating engine with a more intuitive API. There are plans for creating examples in HTTP server that show its uses with the templates. In the current state, it seems like it is ready to be released as v1.0.0. The main question is, is it possible to release it as Adafruit Template Engine as part of the main bundle? It is closely related to Adafruit HTTP server, but could also be used independently. That is why for now, it was not added as another modulation view server. Main reason for this purely the repository owner aspect as in other bundles, if I'm correct, I would be the owner of this requiring me to adapt to the docs generation methods and keeping the actions updated, etc. If the main bundle is not the correct place, it should be added to the community bundle or the circuit python bundle. Foaming Guy suggested adding Adafruit as collaborator to my repo, which would allow others than me to publish changes without me accepting the PR. From the two, community bundle seems like a better choice. I would say, for instance, the CSV module presents the bundle, present in the bundle offers a somewhat similar set of functionalities, meaning they could be used in multiple scenarios and is not directly connected with a specific board, sensor, etc. In regards of the bundle that it should go to, the second question is, what should be the next step for releasing it? And then he links to the circuit python library guide. So I would just say, Foaming Guy, a library that is in Adafruit is supported by Adafruit, which means that somebody who gets paid by Adafruit will work on it and we're willing to work on it indefinitely. That's really the main criterion about whether it's in Adafruit or something else. So if, for instance, Foaming Guy, you felt that, yes, you're willing to maintain, you're willing to respond to bug reports about this, if McCall is not available, then it could be an Adafruit library. Like I was very happy, for instance, I wrote the original Adafruit HDP server library, which is completely different than it was. And I was really happy for community members to take it over, but I'm still ultimately responsible for fixing bugs or Adafruit is not me in particular. So does that sound like it seems like a useful enough thing that maybe it should go in, but it means we write a guide about it, but at least we have to support it. That's what it really means. Yeah. Yeah, I mean, personally, I'm definitely up for helping support it either way, no matter where it lands, truthfully. I just didn't know McCall had asked me about this and I didn't know. I wanted to bring it up here and get thoughts from everybody. And we didn't want to add it to initially, at least in my mind initially, there was the thought to add this functionality to HTTP server library because that's my kind of intended use case for it. But the more we started thinking about it and actually getting some of it done, it made sense, I think, to keep it separate because there are potentially a few use cases that are outside of that. It's the main thing that I want to use it for, but you could also use it for generating XML, for instance, it's something we don't have another library for, and this could help you with. I think there are a couple other uses. And we always try to solve libraries up so they're as small as possible, so that we don't use a memory. Yeah. Okay. Yeah, I mean, I am totally up for supporting it in whatever capacity is needed on going, but that's definitely something that stands any which way, no matter where it lands, really. So if there is interest or if it seems like something that there could be other interest in to make a guide, like you said, or any other projects around, I'm up for supporting it in under the Adafruit bundle. But if it makes more sense in the community bundle or the CircuitPython bundle even since there are a couple of us so far that are working on it. One of the other things that I had thrown out as an idea, which I'm interested to get thoughts on as well. So there are groups on GitHub like the librarians, for instance, CircuitPython librarians. Are there any instances of or are there any thoughts around like, and is it even possible, I'm not sure, like sharing community repos with that group. I think maybe one thing that some potential library owners might feel is like not necessarily wanting to be on the hook for that ongoing support. If they had a group where they could give access to that group, and if that group is willing to, they could then have access to do reviews and stuff like that. I don't know if it's technologically possible, but if it is, I wonder if that's something that is encouraged for members of the community, or if it's not not so much for them to try to like add the group or organization or whatever that is as a, kind of like a lab. Well, we add people who are outside collaborators and they have privileges. You can give them privileges to do things. So I think all of the ways for, I think all of the ways for doing that involve transferring the repository from an individual to some organization, whether that's the Adafruit organization or the CircuitPython organization. I don't think you can add name groups of people to a repository that is in a GitHub user. Oh, okay, okay. Yeah, I know we could share user to user, I knew. And then I knew, I can like mention CircuitPython librarians. I don't know exactly how that group exists, but I wondered if that could be shared too, but it's like maybe not. Do you want to recreate this? Does it make sense to recookie cutter this library? Yeah, definitely. The code we have now is just, it doesn't have the cookie cutter stuff in it at all. So I think either way it will be good to cookie cut that and get like, read me and all the other boilerplate and stuff that comes along with that. If you do that, we'll make it an official Adafruit library and you can add McCall as a collaborator. Okay, cool. Yep, I can do that. And then I did, I added that link at the bottom. The second question that McCall had put in there was about what are the next steps and I can help work with them on that as well. I added that link to there, but it's cookie cut and then it's, once the library is created and released, it'll be create a PR in the bundle, in the bundle repo. So I'll work on, I'll work on that with them. We'll get it cookie cut it and then once that new library is set up, or I think I don't have the rights to create it, we'll work on creating the repo and then I'll need help from somebody to create it inside GitHub and then we'll check in the initial code to it. Sure, no problem. Yeah. Okay. All right, great. I think that we can progress on that. Okay, I think that wraps it up for in the weeds. We had a lot of lawn mowing today in the weeds. So that's great. It means that we have interesting things to work on. So I'll finish up. I'll wrap up here. This has been over an hour, which is unusual. It's been a while since they've run this long. This has been the Circuit Python Weekly for Monday, September 18th, 2023. Thank you to everyone who participated. If you want to support Adafruit and Circuit Python and those of us that work on Circuit Python, consider purchasing from the Adafruit shop at Adafruit.com. The video of this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will be available on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. Visit afruitdaily.com to subscribe. And our next meeting will be next Monday, as usual, at 2pm US Easter and 11am US Pacific time. You can join the meeting by going to adafruit.it slash discord. And if you want to be notified, ask to be added to the AdSign Circuit Python Easter's role in Discord. So we hope to see you all next week. Thank you everyone for a great meeting. I appreciate it. And I will stop recording.