 Hello, everyone. This is the Circuit Python weekly for Monday, February 26, 2024. This is the time of the week where we get together talking about all things Circuit Python. I'm Liz and I'm sponsored by Adafruit to work on Circuit Python. Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit. If you want to support Adafruit and Circuit Python, consider purchasing hardware from adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.it-slash-discord. We hold the meeting in the Circuit Python DevTech channel and the Circuit Python Voice channel. This meeting typically happens on Mondays at 2 p.m. U.S. Eastern, 11 a.m. Pacific, except when it coincides with a U.S. holiday. In the note stock, 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 Circuit Pythonista's Discord role. There is a notes document that accompanies the meeting and recording. You can contribute to this document beforehand. Final notes document includes time Sam's to go along with the video, so you can use the doc to skip around and view the parts of the video that interest you most. The meeting tends to run 30 to 60 minutes. After each meeting, we post a link for the next meeting's notes document to the Circuit Python DevChannel on the Adafruit Discord. Check the PIN's messages to find the latest note stock so you can add your notes for the following meeting. If you wish to participate but cannot attend, you can leave hug reports and status updates in the document for us to read during the meeting. This meeting is held in five parts. Versus community news, this will look at all things Circuit Python and Python on hardware in the community. It's a chosen set of items from our Python on microcontrollers newsletter. Second part is the state of Circuit Python libraries in Bolinka. This is a quantitative overview of the entire project. It's a chance to look at the project by numbers separate from our status updates. Third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. Fourth part is status updates. Status updates is an opportunity to report on what we've been up to. Take a couple minutes and talk about what you've been doing in the last week since the last meeting and what you'll be up to in the next week. And the fifth part is in the weeds. In the weeds is an opportunity for more long-form discussions. These discussions can come out of status updates or be something you've identified ahead of time as too long for status updates. And that covers how the meeting will go. And with that, we will get started with community news. And MicroPython version 1.22.2 was released. MicroPython was just updated. Changes are described as a patch release for our P2DMA UARTM BLE, ESP32 BLE, Renaissance I2C. That is on GitHub. And CircuitPython 9.0 Beta2 released with urge to update for Memento. CircuitPython 9.0 Beta2, a beta release for 9.0, is the Nuku unstable release. This release has known bugs that will be addressed before 9.0 final. That's on the Adafruit blog. And GitHub. And then Project for the Week, making a MIDI kalimba with Raspberry Pi Pico and CircuitPython, converting a kalimba instrument to MIDI use with capacitive sensing. Raspberry Pi Pico and CircuitPython, that was on Hackster and YouTube. That looked like a really cool project. And this and more is available in our weekly Python for Microcontrollers newsletter, which goes out via email on Monday mornings. Visit AdafruitDaily.com to subscribe to the newsletter. Thanks to Ann for putting the newsletter together. If you have any Python on hardware projects to share or find content you'd like to see included, please consider contributing to the newsletter. You can open a PR on GitHub. Mention Ann, engineer on Twitter or mast it on with hashtag CircuitPython. Or email cpnews at Adafruit.com with a link. And that is community news. Next up is State of CircuitPython Libraries and BELINCA. And this 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, then separately discuss the core, libraries and BELINCA. But overall, there were 32 pull requests merged by 20 authors. There were eight reviewers and 29 closed issues by 10 people. 22 opened by 18 people. And then Scott, are you available to read the core? Yep. Yeah. Thanks Liz. Okay, so for the core, we had 13 pull requests merged from 11 different authors. Which is awesome. Some newish names to the core. Hexta, BlitzedyDIY, JustMobilize, NoCueMan, MarioPesh, Romkey to Shippu, and W Tomorrow are all new names. So thanks to them. There were four reviewers including BlitzedyDIY. Thanks Liz for reviewing. We had 19 open pull requests at the times these stats were taken, which puts us well under our one page 25 goal. Which is awesome. We had 14 closed issues by six people and 14 opened by 11 people. So we're net even, we're net zero. And we had over 10 people opening issues, which is great. For a total of 669 open issues. We track prioritization for Adafruit funded folks via the milestone system. We have eight active milestones. And at the time these are taken, we had five issues not assigned to milestone, but there's a note here. I suspect Dan triaged them already. So thank you Dan. 10.0 has two open issues. These are things we don't want to forget to do when we get to the next major version. At this time we had seven open issues for 9.0, which are the things that we're trying to close so we can do a release candidate, which we're trying to do sooner, sooner, sooner. We have 17 open issues for 9XX. Those are things that we want to do after 9.0 is stabilized. We have zero open issues on 8.2X, which is great. That is the current stable version. And that's an overview of our issue priorities. And that's it for the core. Excellent. Thank you, Scott. And now we'll hear from Tim for the libraries. Hello. Thanks, Liz, for libraries this week. This section covers all of the circuit Python libraries, which are Python level libraries that help you either interact with specific pieces of hardware like a driver library or a helper library that allows you to create projects and not worry about as many of the low level details, such as things like the portal-based library and stuff like that. All these libraries can be found on GitHub under names like Adafruit underscore, circuitpython underscore, and then whatever the name of the library is. Across all of them this week, we had 19 pull requests merged by 11 authors, which is great to see. Of the 11 authors this week, the names that were newer or less frequent, less familiar to my eye at least were David Menting, Cry Vosa, and Reza N. So thanks to those folks as well as all of our other contributors whose names look a little more familiar to me. We did have seven reviewers for those 19 pull requests, which is also good to see. Thanks to our seven reviewers who are all more frequent contributors to the project. Of the 19 merged pull requests, the oldest ones were 114 and 110 days old respectively, and the newest ones like usual were just one day old. That leaves us after the week with 48 open pull requests, the oldest of which is 557 days, and the newest is only one. There were 14 issues that were closed by six people as well as six new issues opened up by five people. So we're net down a couple of issues this week. That leaves us with 737 open issues, and of those are 19 of them that are labeled good first issue, which you can find listed over on circuitpython.org slash contributing, which is the place to go if you are interested in contributing to CircuitPython on the Python side of things. On that page you'll find a list of open PRs and open issues. If you're looking to contribute, that's a good place to start. If you're interested in reviewing, then you can check the list of open PRs. Take a look at the code. If you've got the hardware, you can try it out. Otherwise, just look for syntax, spelling, comments, all of that kind of stuff, and leave a comment over on GitHub letting us know that you looked at it. Once you're comfortable with that, and you've done that for a few libraries, we can also get you leveled up to the review team so you can leave official reviews, although comments are just perfect as well. If you are interested in contributing on the coding side of things or documentation, you can take a look at the open issues over on circuitpython.org. You can sort by label, which is how you're going to be able to find those good first issues if those are the ones you're looking for. There's also bug and enhancement labels if you're looking for some more complex things to get started on. We do have guides for contributing to CircuitPython with Git and GitHub, and if you need help with any of that sort of stuff, there's loads of folks on the Discord who are always around and willing to help out. So if you want to get started with contributing but you're having trouble or you don't know where to start or you need help, feel free always to come and join us on the Discord. Ask for help there. We want to make it easy for everyone to be able to contribute no matter their skill set and backgrounds. Rounding out the library stats for the week, we got the PyPI stats, which show over the past week we had 116,563 PyPI downloads across the 325 libraries. The top tens list is here in the note stock if you'd like to take a look at those, as is the list of new and updated libraries, the most notable of which this week is the Connection Manager library, which was newly released and we'll be hearing a bit more about that later on. That's what we've got for libraries this week. Thanks. Excellent. Thank you so much, Tim. And now we'll hear from Melissa about Blinka. Hello! Blinka is our circuit Python compatibility layer for MicroPython Raspberry Pi and other single board computers. This week we had zero pull requests merged. There are currently six open pull requests amongst all the repositories. There was one closed issue by one person and two open by two people, leaving a net of 86 open issues. There were 13,166 PyPI downloads in the last week, 11,340 PyWheels downloads in the last month, and we are at 129 boards. And that's it. Awesome. Thank you, Melissa. And that is a state of circuit Python, the libraries, and Blinka. And next up is Huggerports. Huggerports 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 to give everyone a chance to participate. If you are text only or are missing the meeting, I'll read your notes when I get to them in the list. So I'll kick things off. Huggerport to Dan for excellent release notes for circuit Python 9, beta 2. Melissa for fixing the web workflow code editor and Scott for his fixes to web workflow in general, and a group hug. And then I'll read for Carter, who is text only. Huggerport to Dan for form help, finding a missing parentheses pair and troubleshooting a quote unquote feature with tiny code reader firmware. And speaking of Dan, we'll hear from him next. Okay, thanks. So thanks to Taylor U and ADCC for working on a fixing a USB CDC issue that's come up on RP2040 on macOS specifically. I'll put that in in a minute. And thanks to Justin for his connection manager code and all the revamping regularization of socket use across libraries that he's cleaning up. That's really a nice thing that's going on and it's getting smaller, which is really nice. Okay. Great, thank you. And now I'll read for DJ Devon, who is text only. Tanute for an informative deep dive on host USB and streaming bit rates. And DJ Ecken for reviewing and approving two CAD parts submissions. And now we'll hear from foamy guy. All right. Thank you, Liz. Huggerport's for me this week. Thanks to Scott for looking into some USB host issues that I had opened on the core repo during deep dive. And that was interesting to peel back the layers, so to speak, and see inside of what's in there. Thanks to Jeff for a change that allows using the USB host power pin with digital IO so that you can toggle the power. Thanks to Dan for looking into an issue with GitHub permission settings on the new library repo connection manager. And also thanks to Justin for working on connection manager and all of the changes in the associated libraries that will use it. Echoing what Dan said, I think that's a really great effort and a group hug for everyone. Thanks. Great. Thank you. And now ADCC. Thank you, Liz. First off, big thanks to Argonne Blue for diligent work on number 8824. That's the hard fault affecting macOS and RP2040 when disconnecting a USB CDC ACM endpoint. It's been a fun bug. And to Dan H for tremendous amount of help getting the USB tracing up and running. And that's it. Great. Thank you. And now we'll hear from Jerry N. Hi. Yeah, thanks to Jeff Jibbler. And everybody else who was responsible for the really great support for the pie cameras leading into the Mendo and the ESP32 camera support. It's really been nice to work with. And the group hug and my cats inside too. Thank you. And hello to your cat. Now I'll read for Justin who is text only. Tanute for pumping through my PRs. Dan H for getting connection manager on Read the Docs and in the bundle. And Jibbler for all their comments that help steer me in the right direction. And now we'll hear from Maker Melissa. I just wanted to give a group hug to everyone. And that's it. Thank you. And now we'll hear from Tanute. And now we'll hear from Jibbler. Thank you. Hugs to Tyeth, Snaky Maker cat, DJ, Devon three, and I data out Pekingian, Justin and Dishapoo for helping folks in help with circuit Python just over the weekend. So if you've helped before, I, I, this is not exhaustive, but thanks to those folks. Thank you. And now I'll read for Tectric who is not present. Dan H for trying out my CERC firm CLI tool. Thanks for helping to iron out some bugs and usability issues and a group hug. And that was Hug Reports. Next up is status updates. So status updates is our time to tell folks what we're up to individually. I will start and we'll go through the list alphabetically. When I call on you, take a couple of minutes, talk about what you've been doing since the last meeting and what you'll be doing until the next meeting. This 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 in the weeks. And with that, I'll get started. So I have missed the past two meetings because I was trying to get guides done in time for the Ask an Engineer deadline, which is kind of unofficially Tuesday morning. So often Monday afternoons I have to kind of get rocking. But I was able to get the cat thermal printer working properly with Memento and document it in a guide that went live last week. I'm really excited about this project and thrilled I was able to finally get working thanks to some added delays in the library. And I've also been working on a guide for the new Itsy Bitsy ESP32 board. I had a board deaf district of Python and was able to use it with Web workflow. And now we'll hear from Dan. Okay, so as mentioned last weekend above, we needed people who have the Memento board to update to 9.00 beta 2. So I published that in about five or six places. It seems to be working out just fine. People are updating and they're reporting success. So ADCC and John Romkey and some other people have also noticed we still have continuing problems with macOS Sonoma. The original bug has gone away, but now it's the case that when you write to drives fat drives that are less than a gigabyte in size, it's about 40 times slower than drives that are larger than that size. So ADCC has documented that and I think I'll do the same thing so that we can put more pressure on Apple to try to get this fixed. I've been working on 9.00 issues. Two of them I decided were not vital to 9.00, so I pushed them forward. Right now I'm looking at a storage leak on NRF when you do connections over and over again. And I'd also like to test a bunch of Circuit Playground Express projects or other projects on small boards to see if they're more prone to memory errors because we no longer have the long live storage that we intended to make storage fragmentation less likely. So I was going to try some Luring Guide projects and use CPX, but if anybody's interested in this, it would be great for somebody to do, it's just a matter of getting stuff out of the Luring Guides and trying to run the code or even just try to see if the code imports and if it doesn't import and you get a memory error, see if you turned it into an MPY file, if it works fine after that. So if anybody would like to try that, it's on some things, that would be great. I will plan to do it myself. Okay. Great, thanks Dan. And now I'll read for DJ Devin who is text-only. Received my ST7796S featherwing so I made one and it works great. There are no free pins left on the BFF except RX and TX, touch display and SD card work and he included a photo in the notes. Submitted a 2.5mm matrix panel model to Adafruit CAD parts repository and currently working on a model for the 5mm pitch matrix panel. Making models available to the public is important. So I made one and it works great. The 5mm pitch matrix panel, making models available to the public is important for those who want to design their own brackets, stands or enclosures. And now we'll hear from BomiGuy. Alright, thank you. Last week I submitted a PR for initial support of an overlay feature in the Pie Camera Library as well as a couple examples that utilize it on the Memento device. That was submitted and merged last week. We have made a few more enhancements to that library. I've submitted a new PR as one for supporting what I'm calling sticker overlays. The original overlays were full size and they were a frame around the entire photo. The new overlays now work better or can work at all with smaller images that are just small and not the full size of the photo. Then you can use the D-pad to change where the sticker is at. You can imagine putting sunglasses on top of your photo subject or something like that. That's the kind of thing that this will allow. I also, in a different PR, added support for using custom file names, which was an issue that someone had filed a little while back on that repo, which I thought sounded like a fun challenge to try and work out. The first example that I submitted with that is using Adafruit NTP Library as well as the internal RTC example on that NTP repo in order to save your photos with actual timestamps in the file names like some cameras and phones do, which I thought that was pretty cool. Then the thing that I've been working on mostly this morning is working through some infrastructure issues that are flagged by Adabot. Let's get listed over on circuitpython.org slash contributing in the infrastructures page. Mostly the ones I've hit so far around circuit instructions being incorrect, either having the PyPy names or having the short name without the rest of the library name in them. I've been working through those. I'm about finished with that, though. That is what I have got so far. Thanks. Great. Thank you. Now we'll hear from AdyCC. Thank you, Liz. I'm continuing work on BLEIO for RP2. Right now I'm deep into advertising. Also worked on investigating number 8824 with Argonne Blue and I think we're close to a resolution on that one. That's it. Excellent. Thank you. Now we'll hear from Jerry N. Thanks. I've been playing a lot with the OV5640 breakout boards. I've been using them with Metro ESP32S3 and a Feather ESP32S3 and was able to finally get the autofocus code from the PyCamera library to work with the breakout boards. That's been fun to play with. Before this it was kind of tricky to use those boards. They used a lot of pins. On the Feather board there's I think there's one pin left but it works and it's kind of fun. I just started working on trying to take the RFM 6.9 and RFM 9.x libraries and combine them together into one library that will support both since there's a lot of shared code. There could be a lot of shared code because most of the functions are the same between the two. Some of the registers are different. This library probably won't be able to run on the M0 Feather and M0 boards. The M0 RFM 6.9 or 9.x just won't fit. It just seems like it's a good time now to see if we can get those working. I opened an issue to discuss this on the RFM 9.x repository with a link from the 6.9. If anybody has any comments or suggestions for what they'd like to see added or changed about the way it works, they work, feel free to put them in there. My first goal was just to get it up and running without breaking anything and just make it so that it works the way it does now but one library to handle both. Then I'll start adding some new features if I can. One question I had is whether this should be considered a community library or you want it as an Adafruit library. Let me know if it's going to be an Adafruit library. I think somebody on Adafruit has to create the base repository so that I can then fork it and populate it. I'm starting off with just a private library that I can work with, but let me know how you want to handle that. Also, if you have any thoughts about what the name should be, I thought about just using Secret Python RFM. Again, I'll convert suggestions so you can just stick them in that issue or get a hold of me. In addition to that, there's a bunch of lingering issues for both those libraries. I'm trying to clean those up as they go along. A lot of them or several of them were ones that just have been languishing and hadn't had any attention and also weren't clear that they were really actual issues to the library. We'll see if they get reopened. If they need to be, that's fine, if I overdid it. That's it. Thanks. Thank you. I see that Scott put it in the chat and may just integrate into an existing library pod story. I'm not sure if anyone else on the team had thoughts they wanted to share before we move on to the next status update. We could talk in the ring soon. Okay. And now I'll read for Justin, who is text only. Got connection manager in the bundle and frozen onto boards that need it. Opened a few PRs that use legacy set socket methods that needed to be merged before the request changes to requests. The PR to request is set and ready for final review. Removed old socket code, updated all examples, and got code coverage to 85%. And random fact, so far 11 PRs have been open to make this change and are merged. And now we'll hear from maker Melissa. Hello. I fixed an issue with the circuit python code editor where it was refusing to connect via web workflow. I worked on writing a memento guide with web workflow. But I ran into a bug where the SD cards couldn't be accessed remotely. I filed the bug for that. For the time being, I'm working on GitHub issues and then I'll switch back to working on py eyes unless the issue gets fixed and I can finish up the guide. And that's where I'm at. All right. Thank you. And now we'll hear from Hello. We're doing roof repair at the house. That's taking some of my brain space. Ari got sick last night as well, so that this may be where my week goes. Last week I fixed SSL socket binding. I also fixed a PWM out crash on Sam D and standardized PWM related classes to using the finalizer only. The crash, as we saw in deep dyes, not last week but the week before, was caused by using bulk reset along with finalizer stuff. And those not working together well. So I standardize across all the ports on just doing finalizer stuff. I was working on two USB host bugs that filming I found but I need some feedback from TAC to finish them up, although I do have a PR out to do some improvements. And then I'm going to circle back on the 9.0 bugs and see what we can do to get those cleaned up and fixed so that we can get 9.0 into release candidate. Thank you. And now I'll read for Tectric who is not present. And the past week released my new CirqueFirm CLI tool which aims to allow updating CirquePython firmware for boards from the terminal. It was inspired by CirqueUp and also an issue where many boards had to be updated for the PyCon sprints. And then this week continue to improve CirqueFirm, prepare my other two tool, CirqueLink Auto-Syncing for updates including cross-platform usage. I'd love to make some small tweaks to how Adabot calculates library downloads. PyStats is a library that removes the dependence on performing BigQuery updates manually. And forever busy with grad school but please don't hesitate to ping me in Discord regarding issues I can help with. I likely will not see them otherwise. And that was status updates. And next up is in the weeds. In the weeds is an opportunity for long form discussions that either come out of status updates or the folks have identified head time. 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 anyone has topics. And with that we had the topic from Jerry N. about the RFM module libraries that came up in status updates. Some of those folks on the team want to talk about what they want to do for the naming. Yeah, so this goes back to Jerry's thing. I think I've always pushed us to have separate repos but I think in this case it makes a lot of sense to combine them. I would kind of like, I'd rather not lose the history of the current repos. So what I'm imagining is that whichever repo came first probably has more history and the other one was based on probably. So I would start basically make a pull request to the repo that you think should live longer where we kind of update it there. Update it in place rather than starting a new one. I guess that has a problem if we change the package name but... Yeah, I was thinking that since this new library is not going to run on M-Zeros, we're either going to have to tell people to use an old version with a different name. So I thought it was okay to make a new library. I don't want to have to maintain three libraries then though, right? No, but I think we could archive, we could just deprecate the old ones and just say these are only for use with on these M-Zero boards without flash. I mean I think it would be good to start from scratch. You're obviously not going to start completely from scratch. Yeah, I think it would also it would be confusing to use one of the existing names because they are specific to the RFM6 9 or 9x and they really are different radio modules. So I think using one or the other would be very confusing to people who have the boards. Isn't that an argument for not having a shared one? Again, the shared one the RFM is we could really go either way. It's not going to save any as I was looking into it and doing it. The only thing that this really saves makes it easier to write examples and guides probably. But maybe there isn't a real what I found in the past is that when I make a change to one I end up usually doing the same thing to the others. But that was when we were installing features that really were common adding things like the reliable data and stuff like that. Going forward, I think Dan thought it would be nice to add some asyncio support which again would probably be common to both but it's probably not a big deal to maintain. Is there a common would you make a common superclass or just some common code? We could have three libraries you could have a base library like portal base and then Laura and non-Laura versions. I don't know how much extra code there is. Is the API really similar or do the APIs kind of diverge? The goal is identical. The only reason to make any sense the real difference is I'm sort of modeling this after the idea of the radio head library on Arduino where there are several different radio protocols that are all done with the exact same API. So that was the goal but it's and it is communicating with the RFM modules also the same except for something I guess there really no difference is the protocol difference pushed down to the physical level and from the user's point of view there is no for the examples that we are using for them they are that's to do a basic packet transmission and so there are a lot of things you can do that they look the same and so the whole send and transmit and receive and acknowledgements and act packets and all the addressing modes and all that stuff really is the same between them and the one thing I was thinking about adding was a header list version which is just one that just sends raw packets with no protocol, it wouldn't support the radio hub but it would be compatible with some of the other libraries that are out there but that's just to send again basic just raw packets there are some differences in them the 6.9 can only handle a 50 byte packet where the Laura can handle a 250 packet there are differences but in our basic operation we use them pretty much interchangeably I think that sounds really good because that means also somebody could write some code and say now I want to use something that is longer range and their code doesn't change because that's my hope you can start a library yourself and use cookie cutter as documented in the learn guides and you can transfer that repo to Adafruit when you feel that it's ready that's easier and then rename it and stuff like that the kind of the repo the build specific files the difference between a community and an Adafruit library is pretty small and the transfer we can take care of those when we do the transfer that's what I started I'll go ahead and get a framework set I'll put a link out there for people to take a look and see if what I'm doing I'm not familiar with the best ways to lay out a library like this I've been using the RGB library as a guide for how to have something that has lots of different modules hopefully that was a good one to start with okay right now I'll just call it circuit python rfm and go from there that sounds good yeah my thinking was that on the two existing libraries essentially freeze them unless for bug fixes that turn up that are important to the M0 board but not try and add more features to those right and we have examples of libraries like that that we haven't archived so much that are prominently marked as deprecated that's good and then there's a process of rewriting a lot of the guides maybe that's a whole other story my goal is to come up with common examples that can be just ported from one to the other and I think there are a lot of users I'm hoping and I think people will tend to do that because they really functionally they are very similar that's my viewpoint and I think if you start with that then quickly if there's something where it seems like they really should be different it will be obvious to you but so far the answer is no okay well again as people see it feel free to poke at it sure thanks alright thanks folks and that is it for In the Weeds so with that I'm going to wrap things up this has been CircuitPython Weekly for Monday, February 26th, 2024 thank you to everyone who participated if you want to support Adafruit and CircuitPython and those of us that work on CircuitPython consider purchasing from the Adafruit shop at Adafruit.com it will be released on YouTube at youtube.com and the podcast will be available on major podcast services it will also be featured in the Python for Microcontrollers newsletter visit adafruitdaily.com to subscribe the next meeting will be held next Monday as usual at 2pm eastern 11am pacific this meeting is held on the Adafruit Discord which you can join by going to adafruit.it slash discord to be notified about the meeting and any changes to the time or day you can ask to be added to the CircuitPython easter's roll on Discord and we hope to see you all next week thanks everyone