 Hello everyone, this is CircuitPython Weekly for Monday, October 16, 2023. This is the time of the week where we get together to talk about all things CircuitPython. I'm Dan and I'm sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to support Adafruit and CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join any time by going to adafru.it.discord and there you'll get an invite to the server. You hold the meeting in the CircuitPython dev text channel and the CircuitPython voice channel. This meeting typically happens on Mondays at 2 p.m. U.S. Eastern Time, 11 a.m. U.S. Pacific Time, except when it coincides with the U.S. holiday. In the notes doc, there's a link to a calendar you can view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you'd like to receive these notifications, ask us to add you to the AdSign CircuitPython Easter's role on Discord. There's a notes document in Google Docs to accompany the meeting and the recording. The final notes document includes timestamps to go along with the video so you can use the doc to skip around and view the parts of the video that interest you most. The meeting tends to run 30 to 45 minutes. After each meeting, we post a link for the next meeting notes document to the CircuitPython dev channel on the Discord. Check the pin messages to find in that channel to find the latest notes doc 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. We hold this meeting in five parts. The first is community news, second state of the CircuitPython libraries, and we look at third hug reports for status updates and fifth part in the weeds, and I'll explain all those parts as we get to each one. All right, so we'll start off with the first part of the meeting, community news, and I will take a time stand here. Okay, let's see. Okay, I just have, this community news comes from our weekly Python for Microcontrollers newsletter, which I'll tell you about at the end of this section. So the first, I have two items of interest this week that I've selected. The first is Bookworm, which is the new version of Raspberry Pi OS. It's the version that's needed for Raspberry Pi 5, which is not quite out yet, but it's pre-orderable from various places, or you can get on waiting lists. And it comes from Debian Bookworm, which is mostly made up of incremental updates of the software that was in the previous Debian Bullseye release. There are a few small changes. Have a look here for the list. There's a list that's in this thing that I linked to in the notes document, but they mostly won't affect Raspberry Pi users. However, for the last year or so, we've worked on some major architectural changes to the Raspberry Pi desktop, and these are launched for the first time in the Bookworm release. Some of the changes under the hood in the release include Wayland as the default display system for Raspberry Pi 4 and 5, use of the PipeWire audio system, and Firefox as a supported alternative browser to Chrome. And then probably the thing that we'll notice the most is that, very importantly for how you use Blinka, the compatibility layer for certain Python libraries, there are changes for how Python modules are installed on Bookworm. Basically, you have to use a VM, a virtual end, and we were just talking about this in an internal meeting. It's going to be a big obvious change for people who need to use Python and Python modules. So as we figure out what to do here, we will write up some things. And everybody uses Python modules on Raspberry Pi OS is going to be affected by this, so there's going to be a lot of information and complaints about the changes, I'm sure. Okay, next up is an educational item, Raspberry Pi Pico with CircuitPython, a primer. This is a YouTube and blog post by Dronebot Workshop. There's a link in the note stock and it's on the channel. And this looks like a really nice introduction, I looked at it very briefly. So take a look at that if you're just getting started. Okay, so where did all this news come from? It comes from CircuitPython Weekly Newsletter, which is a community run newsletter emailed every Monday. Complete archives are available from AdafruitDaily.com. Newsletter highlights the latest Python and hardware related news from around the web including CircuitPython, and MicroPython developments. You can contribute to the newsletter in a variety of ways. Really easy way is to email news that you think is of interest to cpnews at Adafruit.com. You could also tag us with the hashtag CircuitPython on Twitter or Macedon or you can submit a pull request to the draft of the newsletter which is in GitHub. So all those things and feel the free to contribute any way you want. We're really interested in things that you've read that you think would be of interest or your own projects that you think would be of interest and news. So take a look at that. All right, let me take another timestamp. The next step is section is the state of CircuitPython, the libraries and Blinka. 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 qualitative status updates. We'll talk about the project overall and then separately discuss the CircuitPython core, libraries and Blinka. This report data is generated in the previous night so it's a little bit out of date, but it's largely up to date. So overall, in the past week, there were 20 pull requests merged with 19 authors. There are some new names I recognize, J-I-N-S-T Komota, Minor Demon, and Lin Smitka, maybe that name has already come up. I'm not sure, but anyway, welcome to the new people and thank you for your contributions. So as I mentioned, there are 19 authors, there are seven reviewers, and there were eight closed issues by four people and nine opened by nine people. So still roughly keeping par. And we assigned the Hectoberfest label to zero issues, but we assigned a bunch of issues to actually, I don't know if we did or not. But things that you do, PRs that you do and other confusions that you make are eligible for Hectoberfest in our repos. So take a look and sign up for Hectoberfest if you'd like to get recognition. So next up is the CircuitPython core and Scott, would you mind reading that? Sure, happy to, thanks, Dan. Okay, numbers for the core. We had seven pull requests merged from nine different authors, which is awesome. Thank you to all of our authors. And we have three reviewers, myself, Dan and Lamor. We have 20 open pull requests, so we're still comfortably under that 25 one page mark. So thank you to everyone there. Our oldest is 468 days old, and I believe that's the multiple one mass storage stuff that I think is waiting on tack are the eight of person that works on tiny USB. But there's also a number of board open PRs in there. So if you have some boards that are not Adafruit, check those out and see if there's some pinnakes up there. Issues-wise for the core, we had six closed issues by two people and three open by three people. So we're actually net down for 725 open issues. We have six active milestones, and this is used for prioritization of Adafruit-funded work. At the time these were taken, we had one issue that was not assigned to the milestone, so we'll just want to keep track of the triage list. We have 11 open issues for A2X, and we have 54 open issues for 9.0. So we're going to continue working there generally. A2X is the current stable releases, and then 9.0, it will be the major release coming in the next couple months. And that's the update for the core. Okay, thank you very much, Scott. Okay, next up is an overview of the libraries, and FoamyGuy, are you available to read that? Yeah, we can do that. This section covers the CERC Python libraries, which is all of the repositories on GitHub that start with Adafruit underscore CERC Python underscore, and then whatever the library name is. This is the Python layer of code that allows you to interact with various different pieces of hardware, or provides helper utilities to just make it easier to do things that are common in CERC Python projects. Across all of those libraries in the past seven days, we had nine pull requests merged by eight authors. All of our authors, I think I have seen before, but I will just say thanks to our authors, Cedar Grove, BlitzCDIY, BabelockB, and Michael Pocusa, who are perhaps slightly less frequent, but very good to see them. And then thank you to all of our more frequent contributors as well. For those nine PRs, we had five different reviewers on them. So thanks to our reviewers and thanks to Liz for reviewing PRs this week as well as the usual folks of Jeff, myself, Scott, and Dan. Of those merged pull requests, the oldest one was 255 days, so still knocking out the oldest of our PRs. There were a handful of other older ones, and then all the way down to the one day brand new ones at the bottom of our list here in the note stock. That leaves us with 40 open pull requests, the oldest of which is 424 days, although I believe that one is a draft. The newest of which is one day, so we've got some new ones in the mix as well. Over the past seven days, we did have two issues closed by two people, and four new issues opened by four people. We do not have any issues labeled Hectoberfest, but as was mentioned in the Discord, that is tagged on the repos. And so the individual issues and PRs don't actually need it, they still count. We do have 653 open issues currently, with 19 of those labeled good first issue. If you are interested in getting involved in contributing to CircuitPython, head over to circuitpython.org slash contributing. On that page, you can find a list of the open pull requests, as well as open issues. And you can filter those issues by their tags, including the good first issue tag, which is a great place to find stuff if you are brand new or don't have as much experience, but still want to get involved. Across the PyPy stats for this week, we had 60,738 downloads from PyPy over those 314 libraries. And the top 10 looks relatively standard. Most of the usual suspects in the top 10 list for the downloads this week in libraries. There are a list of libraries that have been updated in the last seven days in the note stock, as well as the one new library. If you'd like to take a look at that, that's in there. But that is what we've got for the libraries. Thank you. All right, thank you, Tim. All right, next up is Blinka, take a timestamp. Melissa's off today, so I will read the Blinka section. And just to explain, Blinka is our compatibility layer for CircuitPy found on single board computers like the Raspberry Pi. So in the past week, we had four pull requests merged by four authors. And one reviewer, there are three remaining open pull requests. Most of which are pretty old. So there were zero issues closed by zero people and two open by two people. There are now 73 open issues. There were about 10,000 Pi downloads in the last week. That's amazing. And there were 4663 Pi wheels downloads in the last month. We're now supporting 121 boards with a single board computers with Blinka. And that is it for Blinka. Okay, next up is Hug Reports. Hug Reports is a chance to highlight folks in the CircuitPython community and beyond for doing awesome things. I'll start and we'll go down the list alphabetically after that to give everyone a chance to participate. If you are text only or missing the meeting, I'll read your notes when I get to them in the list. All right, so as I said, I'll start. So thanks very much to Scott for running the meeting last week and picking up extra tasks while I was away unexpectedly for a couple of weeks. And also thanks to ADCC for detailed diagnoses of the macOS Sonoma problem. We'll talk about details of that problem a little more later. Next up is Algorith C Grovers. Hug Reports, thanks to ADCC and DNH for continuing analysis and efforts to address the macOS delayed, say, reload issues. That's the Sonoma issue we're talking about. And thanks to Foamy Guy for illuminating how RTD and Sphinx work to build code documentation. Very enlightening. Next up is ADCC, another timestamp. I've been hanging around this project for the past several weeks and I want everyone to know how refreshing it is to find group of people to play with a big hug to everyone. Thank you, ADCC. And next up is Deshipu. Okay, thank you to Scott for the reviews. You really drag with you sometimes and don't do reviews all the time. All right, thank you very much. Okay, let me make up a pretend timestamp because I forgot to take one. The next up is Foamy Guy. All right, thank you, Dan. Hug Reports for me this week. Thank you to Mechamalisa, who gave me a nice point in the right direction on a issue I was working with with Blinka Display.io and trying to get it to interact with PIL. And also, thank you to Todd Bot for a reminder to update the cookie cutter along with some changes, some other changes that I had mentioned down in the weeds to talk about later. And that's what I've got. Thanks. All right, thanks. And next up is Liz. Hello. Hug Report to Carter for working with me on the AD 5693 Circle Python Library. I really appreciate your patience and excellent feedback. And then Hug Report to Scott for assisting with adding the AD 5693 library to the bundle and getting it all set on Read the Docs. All right. And now next up is Retired Wizard. Do you want me to read yours or will you speak? All right, I'll read it. Thank you. Okay. Thanks to Tanu for the work he's doing on PySigRock. The ability to see digital signals makes troubleshooting issues that were previously next to impossible for me to solve accessible. And a group hug for a community that's always quick and heavy to lend a hand, and especially all the aid of food folks. All right. And next up is Scott now. Hi, Dan. First to Hug Report to Foaming Guy for filling in on Deep Dive last week. And also to you for tag teaming and collaborating on the 120 merge. I'm enjoying it. I'm enjoying working with you. So thank you. Thank you very much. Okay. And finally, Todd Bot, I'll read his contributions. Thanks to Naradak for helping me understand CIRCUP-related library packaging setups and custom bundles. CIRCUP ad bundle can be really handy. Thanks to Deshi Poo and Dan H for talking through comparative data structure efficiencies. And thanks to Foaming Guy for helping me be less done when adding libraries to a library to the community bundle. Okey-dokey. All right. Thanks, everyone. We'll now move on to status updates. Okay. Well, I'll fix that in a minute. I'll start. 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 to talk about what you've been doing since last meeting and what you'll be doing until the next meeting. This is also an opportunity to provide tips and tricks relevant to what people are working on. If a discussion becomes too long for status updates, we can move it to the in the weeds section. All right. And I'll start. Okay. So I'm continuing on the MicroPython v1.20 merge. I think all the ports now have boards that build. We'll be ready for a draft PR very soon and maybe even a regular PR because things are looking good. And I'll be doing a circuit Python 8.2.7 release soon as well with I think one or two fixes and a bunch of new boards and board updates. And one more thing I'll say here is that I'm looking at Mac OS Sonoma problem. So Sonoma cannot in late September and it has this problem that it delays rights to USB drives or maybe all drives is not really clear and it can write part of the data, then wait 10 or 15 seconds and then write the metadata. So if you try to look at the file system between those two times, then the file system is in a completely inconsistent state or it is not completely, but it's in inconsistent state. And this really messes up auto reload because auto reload only wakes three, three quarters of a second. It assumes that when you do do a write that the data all arrives pretty promptly. We have had delayed rights in the past on Linux and Windows, but they don't tend to delay. When they just get around to doing a write, they write everything at once. And this business where there's a partial write makes things really bad. It gives you IO errors during auto reload, for instance. So ADCC has done a lot to characterize the problem, has noted like which, whether it's the data or the metadata that's getting written first, and we will start to complain to Apple more about this and we encourage you to write up your issues and submit them to the feedback system that Apple has for Mac OS so that we can lean on them to fix this problem. And there's a PR, not a PR, there's an issue about this. Maybe somebody can find that and paste it in the notes in the chat. That would be great. Okay, next up is C Grover and I'll read theirs. Submitted the Chime Synthio voice helper library to the community bundle. Working on two more voice classes. String, plucked boat and hammered lutes, zithers and harps, an aerophone, flutes, etc. Strings are a particular challenge because the string wave shape gradually changes after the string starts oscillating. The objective is to simulate instrument voices using overtones and envelopes rather than samples, since samples become unwieldy for overtones that are not imager harmonics of the root note's frequency. For example, an open tubular chime second overtones 5.4 times the root frequency. That's interesting. Okay, built and tested a custom PCM510XA I2C stereo DAC breakout PCB. It's a replacement for the discontinued Adafruit UDA1334 using currently available stock chips on an Osh Park board. A Playground article is in the works. I'll just remind folks Playground is a new feature available on the Adafruit website. I think it's at adafruitplayground.com where you can write up things that look like your own mini learn guides and share them with other people. And finally developing a generic accelerometer tap detector library for sensors without built-in tap detection. I have working test versions for the BNO055, 9DOP, and non-check sensors. The BNO055 is sensitive enough to detect single or double taps on any axis. The less sensitive non-check sensor works best if only the X-axis is used. Okay, and next up is Deshipu. I got the QRIO. I added a method to QRIO that lets you get all the QR codes that are visible on the image and get their coordinates so that you, for instance, you control the camera somehow. You can redirect it towards that, then the biggest QR code, for instance, read it. And it also returns all QR codes, not only those that could be decoded. Well, hopefully it can detect smaller ones this way. Right now, and that's in review, and we are working on making the code nice. Looking right now into MicroBeat's speech module, that was a huge, huge fun when MicroBeat... MicroPython for MicroBeat feels just landed. Everybody loved it. It's basically code ported from Commodore 64 for a speech synthesizer. And if MicroBeat can manage to synthesize a speech, then most of the circuit Python boards should be able to do it as well. So I'm looking into porting that basically audio core. I'm not sure yet if I will manage to make it work in the background, like it does on MicroBeat, or if it will just generate a buffer that you need to audio core, then that would work as well. You will see. And I'm not making much progress with the adversion of it, I initially wanted to use interrupts, but I really can't figure out how to do it on the SMD that I wanted it for. I looked into just doing the touch detection regularly, but doing it in-between the system ticks, so as to not slow down the system, as to not wait for return value. So I would initialize the check and then check it on the next tick. But unfortunately that hugs the ADC. You cannot use analog IO in the meantime. So I'm not sure that's such a good idea, but I'm out of other ideas about how to implement it. So for now I'm just letting it lie for a while, maybe I will. It's my inspiration. That's all. Thank you. Thank you. Next up is ADCC and I'll read theirs. Other priorities have cut into the time I'd rather spend on CP. So no real progress on either of the CP related tasks to report this week. The items I'm working on are underscored BLEIO support for PICOW and a macOS workaround for the Sonoma file system synchronization problem. And next up is FOMI guy. All right. Thanks, Stan. Let's see here. Let me get back to the notes. This past week I worked on a couple finishing touches in the template engine library, mostly getting the Read the Docs project set up and making a release and adding it to the bundle. During that process, when I was working with Read the Docs, I noticed that the Read the Docs builds were failing. Not only on this library that I was working on, but actually across all the libraries, if they have commits that are recent enough, if they don't have recent commits, then it wouldn't have built, so they haven't failed yet, but I have a little bit more in the weeds to talk about what is going on with those. Some of the other stuff that I was working on though over the past week was a FunHouse IoT dashboard that you can access through a browser. It uses the library. That's kind of a demonstration of using those things together. And then I was also working on the changes inside Pi Game Display in order to make it work with the new version of Blinka Display. I have gotten closer on that front. I managed to get colored images out of it, but the colors aren't what they are expected to be based on the input, so I still have some work to do. I think maybe it needs to handle the format conversion to perfectly, or something like that in the code. I found some reference code that makes that conversion, so I have something to try, but haven't actually plugged it in to give it a go yet. And I do on that front also want to explore trying to just cut out PIL from the middle. PIL used to be used in Blinka Display a little bit more, and so the Pi Game Display was taking that PIL object and painting it inside the interface, but Blinka Display I.O. does not use PIL as much anymore internally, so I'm thinking it might be possible just to skip PIL and go directly into Pi Game, but I'll have to read up a bit more on the Pi Game Display APIs in order to make that happen. But that's what I have got in the works. Thanks. All right, thank you. All right, next step is Liz. All right, at the end of last week I started working on a Serger Python 3.8 breakout, and this is a breakout that lets you control USB PD power supplies. This involved looking at chatGBT4 log that Lady A had started a few weeks ago and referencing the existing Arduino library. I also wrote some project code for this week's project from the Ruiz Brothers. It's a prop from the Five Nights at Freddy's games, which I've never played before. But luckily, Pedro's son is an expert and he was able to offer good guidance to us on how it's supposed to look and act, and he is having a lot of fun of it now. So that learn guide will be out a little later this week, and that's all I've got. All right, thank you. And finally, Scott. Hello. I'm booting up after a long weekend. I was at my parents' with the kiddo. I should be around all this week, including DeepDive on Friday. I've been working with Dan on the 120 merge and I think we're really close. I'm looking at the dock build failure right now. And I want to put it on a few boards and just make sure that there's no obvious bugs. And then I'd like to get to 121, actually, because 121 has heap growth stuff that I'd love to switch us over to. So that's where I'm at. I'm in merge land. The only other thing that's going on, or one of the other things going on, I'm sure there's other stuff. But I'm working with SyLabs on a presentation about CircuitPython on their BLE chips. They're MG24s, I think. So I'm doing a bit of a generic CircuitPython portion of that talk. So if you want to sign up for that, it's really early in the morning for me. It's 7 a.m. Pacific time. I think I assume they'll post it afterwards. But they did all of the work for the SyLabs port, so I want to give some props for that. And put them there. And yeah, if you're interested in CircuitPython BLE on some SyLabs chips, check that out. That's it for me. All right, thanks. So finally, we're now at the in the weeds section. This is where we talk, have more longer form discussions that people have identified ahead of time, add stuff to in the weeds beforehand so we know what's coming up. But this allows us to get community input and brainstorm a bit on some things that maybe having an active verbal conversation would be better than just bringing it up in the posts in Discord. So for me, Guy, why don't you go ahead and describe what you would you like? Yeah, thanks. So I have found this blog post. Let me also put the link in Discord if anybody wants to see the blog post. Basically what boils down to those is that on October 3rd ReadTheDocs changed some of the default behavior when builds are made inside of their system. In particular, the change that affects us most, I believe, is that they no longer install Twinks RTD theme by default that used to get installed sort of automatically even when it wasn't specified inside of our code or anything. But it no longer does now or hasn't, I should say, since the 10th 3rd, rather, of October. So all of the builds from libraries, like any library that has commits after 10.3, those will have failed when they try to build and ReadTheDocs. I don't have a list of all of them, but I've spot checked a few and found them all in the same state. There's a link in here to one of those specific, like, log messages for the build failure. But it's basically just they can't find the module Twinks RTD theme when it tries to import it. I did test the fix in the test repo just adding Twinks RTD theme to docs requirements.text, which we we already have that file and I already had a few docs related things in it just not the RTD theme specifically since that was handled automatically in ReadTheDocs and actually also is handled inside of actions sort of automatically separately as well. So it gets installed inside actions, even though it's not currently in requirements, but it no longer gets installed inside ReadTheDocs unless we put it into requirements. So I think that's the fix there. I did test it successfully on the test repo. I submitted a PR and adabot for a patch to roll that out to the rest of the libraries and then I will this afternoon make a PR for cookie cutter thanks again to Todd bot for the reminder on that because it totally did slip my mind. So I'll make the PR and cookie cutter to change that as well, unless if anybody has any concerns or other ideas on how we want to approach that, but I think that's everything that I know about it so far. That sounds good and thanks for running that down. I would always start with cookie cutter because that prevents more re-pills that you need to fix. But yeah, thanks for running that down. For sure. I missed whether you were discussing whether we might remove some of the pinned requirements versions in Docs. Does that seem okay? I don't know what all is pinned in there. So I do think that Sphinx RTD theme does not need to be pinned. I tested that with no version. It got the latest and that seems to work. Currently what we have pinned looking at least at the test repo, it should be the same as all of them. The only one we have a version on is the base just Sphinx itself and we have a greater equals 4.0 I could test out. I have no idea what the current version of Sphinx is. What do I even have installed? I could test out newer ones though. If it's possible to unpin that, I would say I'm probably relatively in favor of it and it's the same file so we could easily add it to the same patch if it is possible. Is that something we want to try is using the latest Sphinx? I think it's on 7.26 because I'm running it right now. Oh wow, okay, so 4.0 I guess is pretty old at this point. I generally think pinning is for pinning it to a particular major version but I guess I would look at what the policy on the read-it doc side is. Okay, I will check into it. Off the top of my head, my first guess is because almost everything they changed to is now the latest of everything. So my guess is they give us the latest. So yeah, starting 10.3 and their blog posted us say you'll get the latest release of Sphinx will be installed automatically. So yeah, we can match that in our requirements that way we'll get the same thing when we build locally. And then I'll double check and make sure that it still builds and everything which I should because actually I have that installed locally as well and I don't notice any other issues building locally so I'll double check it but I think we should be good to change that version as well. The less pinning we do we have to make it work eventually. Yeah. We'll discover it sooner or later that it needs to be fixed up and especially in the case of the library since they don't all have to change like if they made some incompatible change in Sphinx or something for instance. We don't have to change them all at once and we can do that over a period of time. Okay. I will test out the latest on that in the test repo just to make sure that it still builds successfully inside of actions and inside read the docs. As long as that's all good then I'll update that PR on adabot to make the patch do both add R2D theme and unpin unpin Sphinx and then I'll do the same thing in cookie cutter when I make the change there if it does end up working out. Okay. Great. That sounds great. Okay. So I think that's it for in the weeds. Let's sit here. I don't see anything else. Scott did you want to ask about the glossary? I think I decided to just put it back. Okay. Yeah. I think I looked at that too and I decided the fewer the changes the better or something. So all right. So I will wrap up now. This is I'm typing camps by hand because I forgot to start my timestamp generator at the right time. So. All right. This has been the CircuitPython Weekly for Monday, October 16th, 2023. Thank you 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 The video of this meeting will be released on YouTube at youtube.com slash Adafruit and the podcast will be available on major podcast services. The newsletter will also, oh sorry this meeting will also be featured in the Python for Microcontrollers newsletter. Visit adafruitdaily.com to subscribe to subscribe. The next meeting will be held next Monday as usual at 2 p.m. U.S. Eastern 11 a.m. U.S. Pacific Time and on the Adafruit Discord where you are now you can go to adafru.it slash discord to go there and if you want to be notified about meeting and any changes in its timing you can ask to be added to the AdSign CircuitPythonista's role on Discord. So we hope to see you all next week thank you everyone and I'll stop recording now.