 Hello, everyone. This is the CircuitPython Weekly Meeting for March 25, 2024. This is the time of the week where we get together to talk about all things CircuitPython. My name is Tim, and I am sponsored by Adafruit to work on CircuitPython. If you are new and you don't know what CircuitPython is, it is a version of Python that's designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit. If you want to support Adafruit and CircuitPython, consider purchasing hardware from adafruit.com. This meeting does get hosted on the Adafruit Discord server. You can join any time by going to adafru.it-discord. We hold the meeting in the CircuitPython Dev Text Channel as well as the CircuitPython Voice Channel. This meeting typically occurs on Mondays at 2 p.m. U.S. Eastern Time, 11 a.m. U.S. Pacific Time, except when that coincides with the U.S. holiday. In that case, typically it will get moved to the Tuesday, or rarely on occasion it will be skipped. The calendar, which is linked in the note stock, contains all of those details. If you would like to add that to your calendar app or download it to your desktop, you can do so using the calendar link that is in the note stock. The other thing that we do is whenever there is a change to the upcoming date or time, we'll send out a ping over in Discord to the CircuitPythonistas role. So if you've got that rolled, then you'll get a ping in Discord whenever we change the date or time. There is a note stock that accompanies the meeting and recording. You can contribute to the document beforehand. The final note document includes time stamps to go along with the video, so you can skip around and view the parts of the video that interest you most. The meeting typically runs about 30 to 60 minutes. After each meeting, we'll post a link to the next meeting's note stock to the CircuitPython dev channel over on Discord. You can always check the pinned messages there throughout the week to find the latest note stock, and you are totally free to add your notes at any point throughout the week once that doc has been created and pinned. If you wish to participate but can't attend, that's no problem. You can leave hug reports and status updates in that document, and the host will read them for you during the meeting. The meeting is held in five parts. The first part will be community news. That's a look at all things CircuitPython and Python on hardware. That's a sneak peek, or it's no longer a sneak peek, but it's a couple items from that day's newsletter, which now goes out on Mondays, so we'll talk about a couple items that were pulled from there. The next part is the state of CircuitPython, the libraries in Blinka. That one is a quantitative overview of the entire project. It's a chance to look at the project by the numbers separate from our status updates. The third part and the first of our two round robins is hug reports. Hug reports is an opportunity to highlight the good things that folks are doing. It can take a moment to recognize awesome folks in our community and beyond. The fourth part is status updates. Status updates is an opportunity to report on what you've been up to. It can take a couple of minutes. Talk about what you've been doing in the last week since the last meeting and what you plan to do over the next week until the next meeting. The fifth and final part is in the weeds. In the weeds is an opportunity for some more long form discussions. Those can be discussions that come out of status updates or have topics identified ahead of time and put into the note stock. So if you have something that you would like to discuss or think of something throughout the meeting that you'd like to discuss, feel free to go ahead and scroll all the way down and throw that topic down in the weeds section of the notes. And then once it comes time for it at the end of the meeting, we'll read off those topics and go around to discuss them. So with that, I will get our first timestamp and we'll take a look at the community news for the week. This week, CircuitPython 9.0.0 was released. CircuitPython 9.0.0 is the latest major revision of CircuitPython. Now is the new stable release. You can check out all the new features and there are links here to the Adafruit blog as well as the release notes on GitHub and it looks like a post that was covering this fact on Tom's hardware. So check that out if you would like to learn more. I think there were a couple items mentioned last week, so I didn't get out the bulleted list of anything, but the release notes will contain those details for anyone who is interested. Next up, CircuitPython plans a new feature for the Raspberry Pi RP2040, which is going to be runtime-defined USB device support. CircuitPython is planning this new feature for the Raspberry Pi RP2040 runtime-defined USB device support. It's expected to land in 1.23 and there are links here to Hackster IO and the documentation. Worth noting, it's very, very early stages and it's relatively low-level from what I understand. You need to have some knowledge of the inner workings of USB, most likely. So this is not like a high-level, easy-to-use thing, but it's really, really cool to see that coming to MicroPython and then ultimately potentially having a chance to come into CircuitPython further down the line. Next up, the project of the week this week was a desktop lunar display. Loran Underwood completes her desktop lunar display, which uses a Raspberry Pi PicoW programmed in MicroPython. There are some links here to Element 14, Raspberry Pi, I guess probably just RaspberryPi.org or something. YouTube and GitHub, so check that out. I grabbed this one. There are pictures of it in the newsletter. I did not copy those over to the notes, but if you haven't seen this, do check out the newsletter and in particular the video as well over on YouTube. This is a really, really cool project that visualizes the phases of the moon using an actual, I think it's 3D printed or if not just built up, you know, craft style moon piece and then a light behind it that kind of rotates to show you the size of the moon. I thought it was a really, really cool project. So check that out if you haven't seen it, if you didn't catch it in the newsletter. And then the last of the newsletter items for today that caught my eye was a UC8151 MicroPython driver. This is a MicroPython driver for the Badger 2040 e-ink display. This is a new driver that was released. There are links to GitHub to the driver directly as well as a post on Twitter about it. And the really, really cool thing about this one that caught my eye is this driver supports 32 levels of gray. So you can actually achieve some really amazing kind of photorealistic style stuff, obviously. It's still limited to some extent, but you can achieve some really neat looking effects. There is a picture here that I clipped from the GitHub, I believe it was showing an example of a black and white photo that just looks really great for an e-ink screen, definitely. So that's super exciting as well. So all of these items have been from the Python on MicroControllers Weekly newsletter, which is a circuit Python community-run newsletter that gets emailed out every Monday. The complete archives are available at AdafruitDaily.com. It highlights the latest in Python on hardware-related news from around the web, including circuit Python, Python, and MicroPython developments. To contribute your own news or projects, edit next week's draft on GitHub. There is a link in the note stock to that. You can submit a pull request with your changes. Or if you would like, you can also email to cpnews at Adafruit.com or tag a post with hashtag CircuitPython on Macedon, Blue Sky, or Twitter, now known as X. Thanks as always to Ann, of course, for all the wonderful items that come to us each week in the newsletter. All right, so let's get the next time stamp. And next up is going to be the state of circuit Python, the libraries, and Blinka. This section is a quantitative overview of the entire project. It gives us a chance to look at the health of the project separate from our status updates. We'll talk about the project overall and then separately discuss the core, the libraries, and Blinka. These are the overall stats for the week. Overall, this week we had 37 pull requests merged by 15 authors, which is great to see. However, I will admit I forgot to go through and bold the names. So off the top of my head here, the names that are a little bit newer or less recognizable, less frequent, less frequently popping up, at least to my eye are Jay Kittner. And is it probably, I don't know if it's a capital I or a lowercase L, but maybe I, FF5 or L, FF5 over on GitHub. So thanks to those folks who, again, are perhaps newer or less frequent contributors or just names that I don't quite recognize as much. Thank you to the rest of the folks as well who do have names that are a little bit more familiar popping up in GitHub, again, at least to my eye. There were five reviewers for those 37 pull requests. So thanks to our reviewers. It is mostly the usual folks. So thanks as usual or thanks as usual to Scott, Melissa, Tektrick, Dan, and myself. As always, we always like to say it during this section, the more reviewers we can get, the more contributors we can support. So if you would like to get involved, reviewing is definitely one of the best things you can do. One of the things that can really, really help out the project overall to get more contributors able to contribute. There were 27 closed issues by nine people with another 23 issues opened up by 20 people. So we are net down a little bit on the issues side. And that is it for the overall section. So with that, I will ask if Scott, are you available to tell us about the core this week? I am, yep. And 20 people opening issues seems kind of high to me, which is awesome. Okay, so for the core, we had eight pull requests merged from seven different authors. Kibbe Sriram is a new contributor, along with C Darius. So thanks to them. We had two reviewers, myself and Dan. We have 23 open pull requests, so we're comfortably, well, we're under the 25 mark, which is like for more than one page. Issues-wise, for the core, we had six closed issues by two people and nine opened by eight people. That's probably a little bit more than normal, but due to not too bad considering we just did 9.0 stable. We have 665 open issues. We have three open issues for 9.0X, which is kind of like the next stable patch release. Kind of the most urgent thing. And then we have two open issues for 9.0, which will be the next feature version. So yeah, it's like major feature patch version for the different numbers. And we had three issues not assigned to milestones, so we'll need to make sure and triage those if we haven't already. And I put those out. Yay. And that's it for the core. All right. Thanks to you. Thanks, Scott. Next up is the section covering the libraries. So this covers all the CircuitPython libraries, which are Python level code that typically fall into one of two sort of overall umbrellas, either driver libraries that interface with some specific piece of hardware or helper libraries that are just higher level libraries that allow you to create your project without worrying about as many of the minute details involved in some of the stuff we do. All these libraries can be found on GitHub under names like Adafruit underscore, CircuitPython underscore, and then the name of whatever library it is. So across all those libraries this week, we had 23 pull requests merged by eight authors, a couple of the names that stuck out to me as newer. Jay Kittner, I think I mentioned before, but I also wanted to say thanks this week to SCUR. SCUR is a longtime community member that pops up with hardware and stuff like that quite a bit, but it is a little bit more rare to see them on the GitHub, so that's really cool to see. Thank you to SCUR. So that was eight authors for our 23 pull requests. There were four reviewers, which again are mostly the usual folks, so thank you to our reviewers this week. Of the 23 pull requests that were merged, the oldest one was almost 300 days old, so got one of the older ones in this week. The rest, there was a handful that were about three weeks old, and then the rest are one to three days, so mostly newer after that. That leaves us after the week with 62 open pull requests, the oldest of which I believe is a draft, it's 585 days, the newest is only one day. And over the past seven days, we had 16 issues closed by nine people, with nine new issues opened up by eight people, so net down a little bit on issues in the libraries. That leaves us with 737 open issues, and of those there are 18 of them that are labeled good first issue, which you can find over on circuitpython.org slash contributing. Before I tell you about that, I will mention too, I did see ahead in the weeds section, there's some discussion on this, so if you're interested in these good first issue ones, you might stick around to listen to the weeds discussion today. But let me tell you about circuitpython.org slash contributing now. If you are interested in contributing to circuitpython on the Python side of things, head over to circuitpython.org slash contributing, there you're going to find a list of open PRs and open issues. If you're looking to contribute, that's a great place to start. If you are interested in reviewing, check out the list of open PRs. Take a look at the code for the PR. If you've got the hardware for it, go ahead and give it a try. Otherwise, just look for the syntax and spelling, et cetera. You can leave a comment over on GitHub letting us know that you have looked at it, and once you're comfortable with doing that, we can get you leveled up to the review team, so you can leave official reviews over on GitHub, although comments are appreciated just as much. If you are interested in actually getting your hands already contributing some code or documentation, you can head over to check on the open issues. There is a dropdown at the top of the page that you can use to sort by the labels on those, which is how you can find those good first issue items. Those ones are intended to be items that are good for folks who don't have as much experience, maybe haven't contributed to circuitpython or any Python projects before, so these are identified as, you know, hopefully not requiring as much in-depth prior knowledge. So those are good for that, and if you do find yourself wanting to contribute but are having trouble with some step or don't know what to do next, we do have guides covering the process of contributing with Git and GitHub. Also, we have loads of folks on the Discord who are available and more than willing to help you out. So if you are trying to contribute and having trouble, check out the guides, join us on Discord, ask questions. There's gonna be folks who are more than happy to help you be able to contribute no matter what skill set you've got. So thanks, as always, to everyone who does that. In library PyPI stats for the week, we've got, let's see, 136,279 PyPI downloads across the 325 libraries, and the top 10 list is listed here in the note stock. One thing interesting to note, Connection Manager has actually cracked the top 10 already, so that's really cool to see. There's a relatively brand new library up there. The list of libraries that are updated or new in the last seven days is also here in the note stock. I'll call out the ICE Python library over in the community bundle. That's a new library for interacting with some, I believe, FPGA types of hardware. I'm not 100% certain, though, but it looked pretty cool to me. And then update-wise, we've got GPS RSA and it looks like another hardware driver for the AT42QT that was updated. With that, I will send it over to Melissa to tell us about Blinka. Hello. So Blinka is our second Python compatibility layer for MicroPython, RaspberryPy, and other single word computers. And this week, we had six pull requests merged by four authors and four reviewers. There are currently six open pull requests amongst all the repositories. There were five closed issues by two people and five open by five people, leaving a net of 86 open issues. There were 17,567 PyPI downloads last week, 12,271 PyWheels downloads in the last month, and we are at 132 supported boards. And that's it. All right. Thanks, Melissa. And next up is our hug reports section. So hug reports is a chance to highlight folks in the Circuit Python community and beyond for doing awesome things. I'll start and then we'll go down the list alphabetically as they appear in the notes doc to give everyone a chance to participate. If you're text only or you're missing the meeting, I'll read your notes when we get to you in the list. Otherwise, I'll call on you and you can read them aloud here in the Discord. So I will get us started once I take a timestamp. There we go. Hug reports for me this week. Thank you to Kevin T. on Discord for helping folks out in the help with Circuit Python channel. Thanks to DJ Devon 3. Also for answering questions, helping people and even going so far as to reproduce issues that are brought up over in the Discord. All very much appreciated. Thanks to Tech Trick for reviewing some, I should say a handful of circuit instruction read me fixes over the past couple of weeks. Really appreciate that. Thanks to Justin this week for trying out the effort to switch the libraries over to rough and submitting some PRs with the initial changes for that. I really appreciate Justin digging into that. So with that, I will send it over to Dan H. next and then DJ Devon 3 will be after that. Okay. Thanks to Justin who's doing a lot of rough experimentation and thanks to everybody who kivits done this in Discord. And we'll talk about that more in the weeds. Thanks to GitHub user Vladak who's been looking at a number of pertinent issues pointing out problems that has submitted PRs, some of which they reminded us of and I reviewed there in other libraries, not necessarily Circuit Python. Thanks to Scott for moving ahead quickly with ESPIDF 5.2.1, which fixes problems. That's really good. And thanks to Jeff for spending a lot of his time on floppy drive support, which is not Circuit Python and yet he's dedicated to working on that as needed. Okay. All right. Thanks, Dan. Next up is DJ Devon and then Jeff after that. Thank you. I have a lot of hugs this week. Hug to Fummy Guy, Tech Trick and Dan H for guidance on opening and closing some issues this week as well as helping with Git issues. Hug to Melissa, Fummy Guy and Dan H for looking into an issue with the Circuit Python RSS speed. Hug to Fummy Guy for having to review 16 PRs I made to Adifurt Request Library this week and he probably woke up to five more this morning. Hug to whoever came up with the warning implementation for the new display bus types. It really helped transition my project from 8.0 to 9.0. I don't know who came up with that idea. It was awesome. Hug to Justin for all the work he's putting into updating things towards rough. I know there's a lot of back-end work that has to go into something like that and I think everyone sees you in the work that you're putting in and appreciates everything that you're doing. And a hug to Tanute, also known as Scott here for a great deep dive this week. Thank you for taking a look at the Electric Smith Daisy while on stream. It's an N8R65 board. And thank you, Scott, for all of your advice including the most recent one that is definitely going to look into trying to port this now. And to Katnie for being around this week it's always nice to see when she's participating and to see her pop in. All right, thanks, DJ Devin. Next up is Jeff and then it'll be Justin after that. Oh, hey. I just wanted to first give a group hug and then specifically mention some folks who were reporting and testing on an issue filed today or last night about SO reuse adder not being available on the PicoW and that's GitHub users, StudioStep, AnikData and DJ Devin3. Yeah, that's what I got. All right, thanks, Jeff. Next up is Justin and then after that will be Katnie. Yeah, excuse me. I just wanted to give out a hug report to DJ Devin3 for all the updating he's doing to the request examples when I made that change to Connection Manager. I did not spend the time to kind of update all of those and so he's been just plowing through those which is awesome to see. Also, for AnikData, for making the ESP32 spy more like the other radio libraries which is something I'm hoping to work on as well. And then a hug to all the people that kind of helped talk to me about linting over the week that allowed me to kind of open up some PRs over the weekend and that we'll talk about towards the end of the day. Thank you. All right, thanks, Justin. Next up is Katnie and after that will be Maker Melissa. Hello. All right, my first hug report is for you, Tim, for helping work through figuring out some weirdness on display with an e-ink display. To scare for teaching me a bit about capacitors today and also for offering to try to test an issue I ran into but not having enough LEDs still I appreciate that you were trying to do that. And also to Tyeth for answering a number of questions for me over the past week or so. That's what I've got. Awesome. Thanks, Katnie. Next up is Maker Melissa and then Scott will finish us out after that. I wanted to give a hug to Dan for quickly reviewing my Blinka display IOPR. Jeff for PR that sorts the RSS feedboards. He kind of went through into like a huge formatting on all the different boards and stuff. To Katnie for a nice chat last week and a group hug to everyone else. All right, thanks, Melissa. And next up and rounding out the hug reports will be Scott. Hello. For me, a hug to Paul and Todd for the bootloader show about the Circuit Python 9 release. I just listened to it on my walk into work today. It's a podcast if you don't know what that they do. Hugs to Henry Gabb and Peter Fox for the encouraging comments on the ESP-Beauty issue. I thought I'd highlight those because a lot of the time when some people convey that they are excited for something, they do it in a way that makes me not want to work on it by like being kind of demanding. But these two chimed in when I mentioned on it and actually were encouraging. So I wanted to highlight that and thank them for that. Lastly, thanks to Kyle Moore and URE on GitHub for adding new boards to Circuit Python. All right. Thank you, Scott. And that is it for the hug reports. So next up will be status updates. Status updates is our time to tell folks what we're up to individually. I'll start and then we'll go through the list alphabetically. When I call on you, you can take a couple of minutes to talk about what you've been doing in the past week since the last meeting and what you'll be up to until the next meeting. This is also an opportunity to provide tips and tricks relevant to what people are working on. If an opportunity does, excuse me, if a discussion does get too long for status updates, we can move it down to in the weeds to expand further. So I will get us started after I take a time stamp. There we go. I have been working on updating the learn guide code and pages that reference display IO stuff, in particular the 9.0 changes to the API. The code and the pages are done as of this morning. Next up is library example code which does get embedded in some guides and I noticed there is a note about that in the weeds as well. So we'll talk about that a bit more later on. I also did a bit of tinkering locally with circuitpython.org specifically to the RSS feed to change, to sort the order that the RSS feed appears in, but also to try to fix the images which I noticed when I was testing the sort order that the images weren't rendering. It was interesting to work inside of, I think it's called liquid the templating engine which is not something I'm super familiar with but it behaves pretty similarly to one that I am so it's always fun to dive into the .org website and play with that a bit. One of the other things I've been working on is RSA encryption. I've submitted a few PRs to Adafruit RSA. Specifically I've been trying to work on integration between the Adafruit RSA library on the back end of an HTTP server running on a microcontroller like ESP32S3 and then using JS encrypt module on the front-end page which is hosted by that server. I was initially having a bit of trouble of this square-hole round peg variety because I was trying to use this JS library in a way that it wasn't really meant to by trying to get rid of module importing and exporting. I did eventually give up that fight and had some success on delivering the public key via cookie from the server, encrypting a message with it in the front-end, sending that message to the back-end and then successfully decrypting it in the back-end with the private key. So that was really, really cool to see after a lot of failure. I finally managed to get that, which I'm super stoked about. I did start trying to integrate that with the larger project that I've been working on which is on the CardPuter device and it's kind of a messenger project that allows different users to send messages back and forth between the handset. I started having all kinds of weird memory errors and other issues that were very difficult to troubleshoot and not being reliably reproducible. So I kind of am getting the sense that my original plans might be just too big. So I am brainstorming what parts of it I'm okay with cutting out to get down to something much less complex to try to get rid of some of those issues. And then the other thing that I've got listed to work on this week is some e-ink display testing and to start building out a basic tic-tac-toe game that will run on e-ink displays. And that is what I've got. Next up is Dan H. And then DJ Devin 3 will be after that. Okay, thanks. So as everybody knows, I released Certify 5.9 final last Monday evening. Thank you to everybody who worked on that over the past year, basically. I updated some guides that referred to eight things that are gone from 9.00 or deprecated, particularly like an e-ink dot show in display. There was still some guides that mentioned that. And also there was some stuff in the learn guide repo in the code in there. But there was also just some pasted in code that needed to be fixed. And if you notice anything like that, just note a feedback item in the guide and we'll try to get to it. And since 9.00 was released, there have been various reports of issues. And so I've been investigating those and triaging them. Some of them are real, some of them are not. Thanks to Jeff for fixing the SOReuse adder, which was not implemented in PicoW. And there was also an interesting problem with pin sleep support. We went to ESPIDF 513 in the last few weeks of 9.00. That broke pin sleep wake-up but it's fixed in 521 so it'll be fixed in 9.1 something. And so I'm also, besides fixing all these bugs and researching the bugs, I'm working on some changes for 9.1 as well because we have plenty of issues in that milestone. All right, that's it. All right, thanks Dan. Next up is DJ Devin 3 and after that is Jeff. What Scott said in the stream is relevant. You go backwards, you get bugs, you go forward, you get bugs. This week I started going through good first issues to see what I could help clean up now that 9.0 is stable and here I've been updating a lot of my boards to 9.0 and bug hunting this week. Help test an issue with Adafruit DateTime from CircuitPython7 Alpha4. This issue was probably fixed long ago but was left dormant, was able to test and confirm the bug is gone in 9.0 and that helped close a 967-day-old issue which is something to be said about getting. You can just go through the good first issues, find something. Sometimes you just need to give someone a nudge that originally worked on it to revisit it and then it just closes itself with a newer version of CircuitPython. I found a bug in the CircuitPython RSS feed not updating in chronological order, finished updating all Adafruit Request Wi-Fi API examples to use Connection Manager for 9.0 I'm sorry this is so long. I've had a really busy week. I deleted the Twitter API example with permission because I couldn't get their new API to work. Their documentation is in shambles with three different API versions and none of their OAuth tutorials work easily on a microcontroller. Compare that to a PRS submitted to update the YouTube API example which was an absolute pleasure to work with because their documentation and examples are outstanding. They even have REST examples specifically designed for microcontrollers which is the first time I've ever seen that. Submitted a PR to add display rotation to the IS31 FL 3731 CharliePlex library. It should make chaining CharliePlex matrices in any orientation much easier. If you know those, you know they have like STEMI connectors at the top so you can really only orient them in like two directions but this way you can orient them, you can rotate it and orient them in any direction that you want. Submitted a PR to update the 3.5 inch TFT featherwing display driver with 9.0 transitional code and I updated my FeatherWeather MQTT touch project to 9.0. There were a few hiccups like needing to update the TFT featherwing driver but other than that it was a great transition and I will be porting all of my projects to 9.0 and that's what I got. Alright, thanks Studio7. Next up is Jeff and after that is Justin. Hi again. So I've been working this morning on updating the floppy IO module. This will be going in the main branch only. It makes incompatible API changes and where I'm at right the second is I'm close to building it and while I built it and so I'm close to testing it on hardware. As a couple folks mentioned I added a little change to add SO reuse adder support for the PicoW and other RP 2040 boards with Wi-Fi. That's pending testing from one of the folks who reported the bug. I've been working on a branch called SSL Anything that will allow SSL to work on Wisnet sockets and within that branch I've added support for setSockOpt. It will just call the method on the underlying socket object and that would eventually allow removal of this workaround possibly from the Adafruit HTTP server library works around setSockOpt being missing but not failing. That's what I'm referring to here. And then the other thing I've done is I've built a little test setup on the swirly grids for the HUSB238 which is this board for USB power above 5 volts. A friend tried to make a project with HUSB238 and saw some reliability problems. They were using a Raspberry Pi Pico and I'm using CircuitPython and a specific KittyPy and anyway it's working for me in that I can query my power supply 4 million times in a row without an error but they were seeing problems after they had requested different voltages from the actual USB power to the power supply so that is next. And the troubling thing there is it seemed like it was maybe damaging the HUSB238 chip so that it became unreliable for just doing the scan test so that's not fun and I'm trying to reproduce their experiences and in non CircuitPython stuff Dan mentioned I've been doing a lot with the floppy stuff there which is true that is close to done. The next thing that I will be taking a look at on that side of the fence is updating Arduino support for RGB matrix on ESP family microcontrollers which turns out to be needed due to changes in the version of ESP IDF which just has a few incompatibilities so I'll be taking a look at that maybe later this week and that's what I've got going on. Alright, thank you Jeff. Next up is Justin and after that will be Katny. Yeah, pretty short and sweet this week I'm playing with the rough upgrades trying to see what kind of made sense and talking back and forth with a lot of people on Discord to get their opinions on things and then kind of finished up with some draft PRs over the weekend that we'll talk about later. Awesome, thanks Justin and next up is Katny and after that is Makar Melissa. Hello. So I finally got around to building my multiple grow light setups they're now each 60 dot star LEDs 40 cool white and 20 RGB wired up to an ESP32 S3 for the most part there's one S2 involved Feather and a Neopixel 8 as a level shifter. The code turns on and off the LEDs based on a specific time using A to 4 to I to keep track of the time. They were working on 3D printed cases the they're mostly good to go but they have magnets on the back which is super keen because the terrariums that they're in are magnetic so I can just stick it to the side with no issues and then the last feature that I don't know about last but the next feature I want to add is the temperature and humidity sensor which needs a needs its own 3D printed case because I missed the plants regularly and I need to make sure that I'm not directly missing a sensor board. So the ESP32 S2 version has been running for about a year now and it was rebooting multiple times per day and it was running 8x I noticed that the reboots have stopped since I upgraded the build and circuit python however I also learned a little over a week ago that you can't max out power supplies or you will run into issues like rebooting a microcontroller regularly which is almost certainly what the issue was the LED density went from about 220 down to 60 and so the power draw dropped significantly and I didn't I deliberately calculated it so that it would be just under the max of the power supply and that was not supposed to be a thing so that's really what's been going on and then with the new setups I ran into issues with flickering but only on the ESP32 S3 versions and after a lot of unnecessary shenanigans it turns out a capacitor and the power lines fixed it I have never in 7 years of doing this added a capacitor to my LED strips but here we are separately I picked up a Pimeroni Badger 2040W and finally got around to starting some code for it it was real simple code which should just cause the display to refresh on a button press I found that it would refresh on the first button press since reload and then stop refreshing after that until the board was reloaded or reset Fumiguy tested things on a mag tag and we eventually figured out that if there is no change to what is on the display it will not refresh so if you make it so that each button displays something different it refreshes on every button press but if it remains static it doesn't refresh which seemed weird but at least we figured out what was going on and it's not so much an issue because eventually the plan is for the code to have it the button press has changed what is on the display so it's not as though it needs to refresh with nothing changing but my simplistic test code was not working properly and then very finally belated report to Fumiguy for clarifying that black and white e-ink displays background default is black and not white which threw me for a loop until I added a white triangle and then also for helping me with my badge code that's what I've got thank you catney next up is maker melissa and then I will read notes for tectric after that hello I updated blinker display IO to match the circuit python 9.0 api I added pwm support to blinker for the raspberry pi I updated blinker rock pi s board to use libgpiod instead of sysfs I added pwm support to the jets nano and I'm continuing to work on gfprs and I'm currently fixing an issue with the circuit python installer for windows and that's it alright thanks melissa next up I will read some notes for tectric and then scott is after that so tectric writes for status updates this week continuing to update cirqfirm with new features I'm hoping that in the next couple of weeks it'll be in a more steady state fully ready for general use there is a link here to that github project if folks would like to check it out it looks like a command line tool for installing and updating the firmware on your circuit python device which is pretty neat tectric also has here working through prs that have been tagged on or assigned so thanks to tectric for that and last up rounding it out these status updates I will send it over to scott hello so I've got a pr to merge in fixes to the esp32 camera library for the idf 5.2 update I think that's the last thing I need before I can get the idf 5.2 update into main and then I think after that we'll probably end up doing a 9.1 beta maybe we'll talk to dan dan's inventory just releases generally now I wrote that I was for the usb host feather rain support I was waiting on work from tact but after I wrote that down I saw that he actually merged it in so I will try to get back to usb host feather rain in the next day or two and then I'm getting back into after usb host feather rain stuff is kind of either out for review or back to tact I'll then get back to the esp ble support that's kind of the next big big work item for me then I'm anxious to do because I'm a huge fan of the s3 and that is a pretty big gap in what we support on the s3 yeah that's me alright thank you Scott and that is it for status updates so next up and the last section for the meeting is in the weeds as a reminder in the weeds is an opportunity for long form discussions they can either come out of status updates or be identified ahead of time if you know that you've got an in the weeds topic that you'd like to discuss please go ahead and make sure to add it down at the bottom of the note stock now we've got a couple others so we will start on those and first up is a topic from djdevin you want to share your topic djdevin thank you yes I have two in the weeds topics I've been pretty busy this week so I've come across a lot of things first the good first issues are littered with typing issues and there's a lack of information about the types and at first typing was very basic with string and float types but now as we become more complicated with bus types and many more other types that I'm not even aware of with documentation listing the different types possible without documentation listing the different types possible in my opinion typing issues are not within the realm of good first issues for beginners anymore tetrick is taking on updating the typing repo with some examples and I'd like to see more documentation on typing become beginner friendly again as it's becoming more infused with Python development workflow and that's open for discussion although I know tetrick has already taken that on and is hard to work I just wanted to bring that up as being kind of like a breaking thing for beginners to take on good first issues is it? yeah I would and as Dan writes here as well that we do want to remove the tricky typing ones from good first issues and I think we did do a pass on that at one point but it sounds like it's probably time to do that again I do think that is the basically it for the good first issues the last couple of times I've looked through them it hasn't been necessarily this week or last week but the last time I went through them I think this was basically the bulk of them so I will say we could go through and remove them I definitely agree the ones that are left are probably not so much good first issues at this point because all of the all of the easy ones have thankfully been been knocked out honestly so we could remove those I would kind of caution that basically will leave us with none I think it would be good if we can maybe try to identify something else that maybe is a good first issue I would love to have something to be able to point folks towards who do want to get involved but don't have as much experience so that would be one of my takeaways from that topic is maybe we could try to brainstorm as a group what might make good first issues to add after we remove these yeah I would say maybe we should plan on going through and removing all the ones that are left unless like we happen to see any that are actually super duper easy although I doubt that there are going to be any that are really in that column left at this point so I know there are 33 good first issues in all the repos right now another thing that I would like to bring up maybe I'm misunderstanding good first issues with good beginner issues it was always my assumption that good first issues were supposed to be like beginner friendly yeah I think that's correct yeah I look at them as the same basically good first issue good beginner issue I feel are essentially the same yeah and PyCon did knock out a lot of them cause I was working on some from PyCon and like somebody at PyCon would knock one out as I was working on one that was actually pretty cool okay so it sounds like the action item there is go through the list or move any that don't make sense which is probably going to be all of them at this point and then we can maybe try to brainstorm some or maybe eventually try to rework our wording during the meeting or the filters on the site and stuff I just worry it will be a little bit awkward if we are sitting at zero for too long if we're still saying stuff like that each week in the meeting and having the filter on the site and stuff so well I like the the typing issues as long as there's documentation to support that then a beginner can go in and I still honestly consider myself a beginner to go in as long as I know all the types so I mean one problem is it's difficult or impossible to actually have a comprehensive list of types because some libraries could create their own class and then the types used in that library could be that class and so it would be difficult or impossible to really have a super comprehensive list of every possible type I think we definitely should have a list of all the common ones like string and int and number all the super basic ones that are not customized plus I do think the documentation being added into a circuit python typing all the custom ones that we have created that you I think mentioned Tectric looking into those I think would be super beneficial as well but I would caution I don't necessarily think we can get to a world where there is actually just one big comprehensive list that could have every possible type that any library would need the other thing I would just add is the typing issues that remain I think are just not good first issues at all really even if we had better documentation I think the ones that are left are actually on the much harder side of things so even if we did bring that documentation up to date I still don't think that they probably make great candidates for a good first issue at this point the large majority of them when we first started doing it when we still had lots of driver libraries that were only a few lines of code and it was typing two or three functions and an initializer or something like that I think those fit the good first issue label a lot more closely than what's left now which are some of the more advanced libraries that have many files and many functions and many different things that need doing so my experience having been at two pycons where the main source of quote good first issues with typing issues is that people really struggled with them there was the fact that most of the things remaining are hard like one of them is matrix portal or something and the types in matrix portal are kind of complicated but also I don't think that typing is for beginners. Beginners may have an intuitive grasp if it makes sense to add two numbers but not a number and a string but it's like not something that they wouldn't necessarily encountered by now so just based on my experience of being at pycon and trying to offer these to people who were interested in contributing and people were right there in the room to help them was it didn't go that well and I don't think there's like one unifying kind of good first issue that we can create 300 of again I think adding typing to the easy cases was unique in that respect it probably needs somebody to look at the open issues and say and think about it and say I bet this would be tractable for a beginner not create one new issue in each GitHub repo that is potentially a good first issue based on some idea we have because you know like change this code until it makes pylon happy is not a great first issue because it's not a good first issue should also be fun to work on and I felt like the typing issues were not we're not fun they didn't offer a benefit it's not it does something now that it didn't do before so maybe maybe I'm a little negative on typing overall but I just the experience of being at the corner trying to help people work with this was not the best I wish it could have been better so I want to go through since I have a search open I'll just go through and remove the first issue of most of these and we can keep an eye out for other good first issues kind of like organic issues that exist that might be good so if anybody happens to be filing issues or seeing issues pop up that makes sense this would just be the reminder if you see those go by and they look like they are fitting in this mold of relatively basic and I think what Jeff brings up is a really good point as well like I'll call it fulfilling whatever the change is something that's interesting that could actually grab the attention of somebody do feel free to either add that label if you've got the capability to do so or if you don't have access I don't know what rights that requires in GitHub or whatever but if you just leave a note in CircuitPython Dev somebody can definitely get to it if you're not able to so keep an eye out for those right there's also most of them were also labeled with Hacktoberfest and I think I'll probably take that away also yep yeah and the Hacktoberfest we eventually I think the first time we did it we had it to where they were applied it was applied to individual issues and then after that first time I believe we changed it to where it's like tagged on the repo somehow now I don't recall if it's a tag or a category or what but there's like a repo level thing that controls that as well so I can definitely be removed from the shoes and I'm not bothering the ones that are closed already I'm not gonna bother to fiddle with so obviously yeah alright does anybody else have anything to add on typing or good first issue front or if not I'll pass over DJ Devon for the next item I ran into some display drivers not being updated in time for 9.0 if the 3.5 inch 3.5 inch TFT feather wing wasn't updated with at least transitional code it makes me wonder what other displays drivers aren't 9.0 ready as well so I'm sure that's probably something that you out of fruit folks are going through the process of looking into maybe I just came across one that hadn't been updated yet or maybe there's many of them I don't know but it's something that I would like to bring up and bring your attention to I just I think if you just open an issue that'd be great I tried it was with me retired wizard maybe Justin I can't remember who were working on these and we thought we had most of them we shouldn't we should we haven't stopped building 8x bundles yet 8.x bundles so we need to not remove the transitional code to convert it to 9.0 only code yet so any code that's what I was doing or should be should be work for both 8 and 9 yeah I fix the driver like I can go in and fix the driver and then submit a new one it's just I don't know which other ones might exist that I might have to do that I I grew up through all the bundle I tried to find them all obviously we missed some okay I got it it was an imperfect survey or something yeah Tetra left a comment he was like nice fine and I was like okay well that's promising you know that I found one that needed to be fixed yeah yeah we did this like several months ago but we obviously missed some and I know there are a couple of examples in that state as well that I ran across this morning while I was looking at LearnGuides. LearnGuides can embed code either from the learn repo or from the library examples inside of the library repos I did see a couple I think all the ones I saw today had the transitional code so it had both support for 8 and 9 so it sounds like we want to leave those alone for now but I do have a search pulled up here in my terminal as well to go through that list and see if there are I can check and see if there are any that are not transitional that actually have only the old one if there are I can submit the R's for those but looking at the full list including even the ones that are transitional it's not super long so I don't necessarily think there are going to be a whole lot of these that got missed at this point so and then if we if there were an amazing number of display if there were an amazing number of display repos actually yeah the drivers there's a lots of them yeah let's see jebler mentioned the the circuit warning from ssd is that the same one or a different one did oh well okay I guess we don't know for sure DJ Devon mentioned the feather 3.5 inch feather wing I'm not sure if that's ssd 1306 or a different one so it sounds like maybe there are two but I've got the 3.5 inch has two versions one is the HX8357 and then not yet the other one filming guy probably knows I've got the full list of them in my background to go through later on this afternoon so I will submit PR also there's the 2.3 inch TFT feather wing which I haven't checked out yet okay cool yeah my grep should find anything in the bundle and then definitely I would say feel free to open issues on any that you do find alright anybody else have thoughts or discussion on displays or updates to display IO driver API type stuff I will hand it over to Justin next for the next topic great thanks so long story short I updated a bunch of stuff in Connection Manager and in requests I'm a long time user of iSort so I had started by making some PRs to potentially update iSort in the cookie cutter which spiraled into a bunch of other things and potentially changing to rough because it's faster and different things like that which will reduce build time things so basically based on feedback I got a couple libraries that might be good to run it through and I basically ran all of those libraries through the same set of commits just so we can basically see what each one did so the format are first and then iSort and then lint and then I did the upgrade and I blocked off any number that they anything needed anything that would change code and then I brought those over the weekend and so then I kind of removed a couple of them that Dan had mentioned would be good to follow those rules as well and then I finished up by adding the badge in the readme just to kind of make things similar because obviously if we're not using black we wouldn't want that badge and so for me personally like things I liked on it so there's a lot of comments that get removed from the pilot stuff the mass majority of the changes for everything happen in examples just because typically the examples I see are made from other people right that they built out an example like he did jump in three for example and like this is to me where things like iSort and formatting things come in handy because it helps everybody kind of have the same type of code so when I picked a couple other random libraries just looking at stuff the more examples they had the more you know those were were a bulk of the changes were so kind of at this point the ball's back in you know data fruit court to kind of figure out what they want to do I'm happy to help however I know there was talk last week of doing commits directly to Maine which I know I don't have privileges to do on such and I know other and technic most of the people here I don't know if they want to go in depth on the comments they made to further down or kind of where we think next steps or how we'd want to go about the next that's I'll read tech tricks comment who's not here tech trick here in the note stock I think these great I think these are great changes whenever it's time to bring these changes over to the rest of the libraries I can help with the eight about patch can use one of the draft PRs to see how complicated it would be to patch IE can eight about do it herself or will we need some extended tooling or some other scripts that will be available to do it for us in a more customized way a technic also says I'll handle flagging libraries that need work afterwards with issues that's all good stuff and sounds like at least one person who's interested in helping take the next steps as well Dan has a question here which I think is definitely a good question is it effectively it looks like it boils down to is it possible to put the rough settings inside of a separate file from can I go into like a rough or something that is specific to that that way anytime if we would want to make a change to that it would be easier to patch since it would be on its own in a file which presumably will end up being identical across all the whereas project will of course differ due to the different names and project repo locations and all that kind of stuff it's like mostly formulaic but still different so if that can have a separate one I would agree with the gist of what's written here is that basically that would be probably the preferable way to do it you happen to know Justin if rough can work that way or is it only pyproject.toml that's a statement oh sorry okay that's not a question okay yeah I am definitely in favor of that then because I do think it will make it much easier if and when the time comes to make changes to that yeah and I'm a pyproject type of person so that's typically where I put all my settings just because it's one spot but definitely for you guys since you have it across all the libraries having that separate totally makes sense answering the other part of that you could also have it in one of your other building libraries and have it use that every time and then if that one changes you'd open your PR and it would fail at which point it would probably tell you oh you should probably go update your rough settings in your PR to fix it so that would be a choice whether or not that made sense for you guys right so kind of like the thing that failed the totally different projects I forget actually the project that was on that I helped track down the old issue you could do that with both requirements and like the rough and things like that and so tests whenever they ran always ran with a very specific version and then if you had failures it would help let the individual opening the PR know that their stuff was out of date you could create a rule to check that and have it fail to tell you hey before you can open the PR you actually have to go this stuff needs to get updated first so the question I had was I mean we have cases Tetrick did this put out a bunch of things into a common repo which is pretty tricky to do actually it doesn't work in all cases so the question is could there be a common rough.toml which is referenced when you use pre-commit locally not when you submit the PR and I'm not sure how to do that because can you set up the pre-commit install for instance so it fetches it you know maybe it's not a good idea but in other words I want rough.toml to be a pointer to a factored out common rough.toml in the default case yeah so you could do that typically so when I've done things like that in the past you run pre-commit with local installs and so you would have rough potentially be a requirement and so when you run it you can run it yourself and that way that pre-commit thing could actually have another pre-step so it's kind of almost like a pre-commit wrapper around rough that would do that download each time in things I don't know if someone's trying to do some level work offline and then they like can't pre-commit can't check their code because they're not online or whatnot if that's a good thing so maybe I'll ask Tetrick about this when they're online again about whether it's because I know you've done this factoring before but it's mostly in terms of the CI that would be super convenient though I will give a plus one to that on my end if that rough.toml could live in either the action CI library repo or a separate new repo that's like a centralized place for it that way it could be downloaded before it runs and then when and if there is a change to it it's even easier than an adabot patch because then it's actually just go change it in one place and all the rest of everything it goes against without it being a submodule it kind of goes against the philosophy of git is that your snapshot is your snapshot and it doesn't have external dependencies but I think I would mention that the I don't necessarily look at it as a huge deal breaker if offline local pre-commit no longer works because I think pre-commit if you hadn't run it before it's trying to install stuff anyway so like unless you've already done some setup I don't think offline is gonna work anyway pre-commit install I do that all the time so that I avoid unnecessary commits I mean that's the whole point is that it's pre-commit right right I think there's several steps there that we'll be trying to use the network for various stuff so if we were to decide to try to centralize that and then it's a deal breaker for folks who are offline because they can't download that config file personally I don't think that's a reason necessarily not to do it I think still the benefits outweigh that but yeah I think it depends how the user works right so for me like through the request library once I've set up pre-commit once I can now do hundreds of commits without having to actually down like redownload that cache and everything like that so um and I often work offline but that's just me and I'm not so it could be a blocker or some people may not be right I think also like anyone in the know can also go grab that file separately and copy paste it in to make their thing work locally as well it's not a like literally can't do it nothing whatsoever will make it work it's just a doesn't work in the default case mm-hmm so I don't know Tedrick and I will have a discussion about this when we're all I don't know if it's related or not but I've been having still having the CRLF issue is there a way that with github actions when something is submitted that has CRLF line endings that it automatically converts to LF so that it won't complain yeah so that was one of the things I actually put into my pull requests so there's a you can have a dot get attributes where you can define like text files like what line item you want to have on commit and it actually it'll supersede whatever random settings a user could have so when you want to guarantee that no matter what everybody always commits which is regular line feeds because you know you're working in a mixed environment or with you know people that might have different settings it'll disregard whatever you set up as your global things right so it's global you can set per repository and then you can set it in the repository so they waterfall down so with get attributes it will override whatever setting the user would do so I would have high hopes that that particular file also gets included whatever we do for rough because that way when you do commit some things like that it changes all the files and that way everything gets back to sync to where it's supposed to be yeah because you ran into those issues I've made sure to put that one in there for discussion for people oh I ran into hundreds of thousands of those issues not directly related to rough but in the same PR where we were testing rough it's the fix yeah um Scott did ask are there any friendlier names for the checks there's an example here like UP0 28 and Scott mentioned that pilot has both so like for folks that don't know and pilot every particular pilot rule has a specific name it's given some ID I don't know off the top of my head any of the IDs but it's something formulaic like this with a couple letters and numbers but every rule also has kind of like a more human readable name where it will say something like you know consider f strings which is much more like actual words that you can make sense of so the question is effectively does rough have both of those types of names as well the ID the other legible one that doesn't mean anything to the person and then also the human readable one that actually is a bit descriptive and tells you what it is Tectric has mentioned in here I don't believe so and linked to an issue over on rough so it sounds like not yet but maybe they have it kind of it's an open it's an open issue to add it so I just subscribed to it and said okay like we can switch to it once it's supported like I'm not the first person to bring this up yeah and I don't know Scott if you looked at my PRs I actually I wrote both so I did the Noqua on the number but it actually wrote it out so anyone looking at the code would see what it actually was it's definitely a lot wordier at that point you know but yeah we could search and replace at whatever points and require or ask users to do whatever method they wanted so yeah that's fine to me I wouldn't block it I just wish they had added it already alright anybody having other thoughts or discussion on rough I have I can only speak for myself on the PRs I saw those PRs go in I haven't had a chance to take a look at them yet so I've still got a couple of things in my stack before I do it but I am hoping to take a peek at some of them this week and leave my thoughts there but now's the time if anyone else has thoughts otherwise we'll get started wrapping it up I guess I'll just end with real quick I'm kind of at a standstill so I'll work on other things at the point that there's things I can help on this just please at me wherever and I'm happy you know I'm happy to do whatever work and dig into things that I can so yeah Justin I think your next step is to work with Tectric because we at least paid Tectric for this work for a while so if he's talking to you about it he that made me and he has time to do it right now so I'd say work with Tectric on it right so with that I will wrap us up this has been the circuit python weekly meeting for March 25th 2024 thank you to everyone who participated as a reminder if you want to support Adafruit and CircuitPython and those of us that work on CircuitPython consider purchasing hardware from the Adafruit shop at adafruit.com the video of this meeting will be released on YouTube at youtube.com and the podcast will be made available on major podcast services it will also get featured in the python for microcontrollers newsletter which you can find at adafruitdaily.com if you'd like to subscribe to that the next meeting is going to be held at the normally scheduled time on Monday at 2pm eastern time 11am pacific time that's on April 1st so it is not an April Fool's joke our meeting will be on next Monday at the normal time that as always is held here on the Adafruit Discord which you can join by going to adafruit.com if you'd like to be notified about the meetings as well as any changes to the day or time again just ask to be added to the CircuitPython Easter's role on Discord and we'll send out updates to that role and that is all for this week thanks to everyone and we will see you next week