 Hello, and welcome to the Circuit Python Weekly for February 16th, 2021. My name is Scott, and I work on Circuit Python for Adafruit. Circuit Python is a version of Python designed for tiny computers called microcontrollers. Adafruit is an open source hardware and software company based out in New York that funds development of Circuit Python. They sell hardware, and Circuit Python runs on that hardware. So if you have electronics projects you want to do, then take a look at Adafruit.com and also learn.adafruit.com. This meeting is hosted on the Adafruit Discord server, which you can join at any time by going to the URL adafru.it-slash-discord. We hold the meeting in the Circuit Python Text Channel and the Circuit Python Voice Channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with the U.S. holiday, as it did yesterday. If the meeting time has changed, we'll notify you via Discord. If you want to be notified about changes in the meeting, have us add you to the Circuit Python East as Discord role. There is also a calendar that you can add to your calendar to see when the meeting is as well. This meeting is recorded. We record audio from the Voice Channel and video the Text Channel. If you'd rather not have your voice recorded, you're still welcome to participate and we've covered that, how to do that previously by adding to the Note Stock. The video this meeting will be posted on the Adafruit YouTube and the audio is released as a podcast. If you find this podcast is not available and your favorite podcast server is let us know. There is a Note Stock to accompany the meeting and recording. If you wish to participate but can't make it to the meeting, you can leave hug reports and status updates for us in the document. We'll read them off during the meeting. The Notes document also contains timestamps to go along with the video so you can use the doc to review only the parts of the video that interest you the most. The meeting tends to run 60 to 90 minutes so that gives you the option to skip around. A link to the Notes document is posted in the Circuit Python channel on the Adafruit Discord every week. Check the pinned messages to find the latest. All right, so this meeting is held in five ports. The first is community news. This is where we talk about all things Circuit Python and Python on that hardware. It is usually a preview of the Python and microcontrollers newsletter but because today is Tuesday, the newsletter actually just went out this morning so it's not quite a preview. The second part is the state of Circuit Python libraries in Blinka. This is like a statistics overview of the entire project gives you gives us some grounding in some numbers. Third part is hug reports. It's a chance to say thank you to the folks that have been doing awesome things within our community. Fourth is status updates. Status updates is an opportunity to sync up with what we've been working on and can also coordinate, collaborate, and do tips or tricks for folks what they're doing. Last up is in the weeds. It's an opportunity for more long form discussion. Any sorts of discussions, they can be community related. They can be Circuit Python related and usually are. And they can either come out of status updates or something that folks have added to the agenda prior to that in the previous week. So that's how everything goes. And let's all get started with community news after I take a time code here. So first up, Visual Studio Code comes to the Raspberry Pi. So this says Visual Studio Code officially comes to Raspberry Pi as well as supporting Debi and Linux on X64. There are now builds for ARM and ARM 64, both of which can run on the Raspberry Pi OS. The ARM build on the Raspberry Pi OS, the ARM 64 on the beta of the 64-bit Raspberry Pi OS. And check the Raspberry Pi blog there. And there's a link in the channel there for those who are in the meeting. Next up, Focus MIDI, Digital Music. With MIDI baked into Circuit Python, getting new boards like the Raspberry Pi Pico using this music standard is straightforward. Below are some projects using MIDI posted on the internet this week. One is a drum machine with the Raspberry Pi Pico. So the USB MIDI 16 channel step sequencer for Raspberry Pi Pico written in Circuit Python v6.2. Twitter link and the code is on GitHub. Furthermore, a MIDI controller using Raspberry Pi Pico with a Pimaroni RGB keypad and Adafruit Circuit Python. Thanks to Sandy McDonald for the code in the iPad Pro. Receiving MIDI on the forthcoming RP2040-powered Tiny 2040 from Pimaroni. MIDI notes over USB make the LED light red. But you could hook up a whole chain of neopixels and have them blink in time to your music. Or it has solenoids to hit a real drum. You name it, programmed in Circuit Python. And lastly, MIDI in for 3.3 volt microcontrollers using Raspberry Pi Pico or Circuit Playground Express and Circuit Python and MicroPython. And the next focus we have here for projects that folks are doing is HID keyboards. So using Circuit Python boards for the USB HID human interface device standards, such as keyboards and mice, has been appealing to new Raspberry Pi Pico project builders. Keyboards, software control, and mouse control are all possible with the USB HID. Here are some projects using HID this past week. The Pico producer, a Raspberry Pi Pico-based 12 key HID keyboard, kind of like a stream deck. The Pico producer is an OBS controller, OBS being the open broadcaster software. I think that's what it is. Using Raspberry Pi Pico, a 3D printed case in Circuit Python. And that's it. So the Circuit Python weekly newsletter is a Circuit Python community-run newsletter emailed every Tuesday. The complete archives are available at AdafruitDaily.com slash Category slash Circuit Python. It highlights the latest Python on hardware-related news from around the web, including Circuit Python, Python, and MicroPython developments. If you want to contribute, please go to the GitHub dot com slash Adafruit slash Circuit Python dash weekly dash newsletter and check the drafts folder there. Please submit a poll request with anything you want on there. Or if you're on Twitter, you can tag atanengineer on Twitter. That is atanne underscore engineer on Twitter or email in underscore be at Adafruit dot com with all your latest tips for cool Python on hardware stories of the week. And with that, let's go to the state of Circuit Python libraries in Blinka. So this is a section where we talk about the statistics of the health of the project. It's the way to ground us in how things are going. So overall, sorry, I'm taking time codes, we had 54 poll requests merged from 23 different authors. Some new names I don't recognize on here is Tystra, Tramstra, KTBO, Jagger Park, the French one that was there last week, SAC, 917, IoT49, JF Abernathy, Max Beck, Sadie McDonald, Jay Francine, while this pixel are all new to me. So thank you to all 23 authors. We also had 11 reviewers, which is also excellent. As always, if you want to help us out, reviewing is super helpful, because the more reviewers we have, the more authors we can support. So if you want to level up from author, say, to reviewer, let us know when we'd love to help you do that. Issues-wise, we had 38 closed issues by 17 people and 15 opened by 13 people. So we're net down by, what, 13? 18? No, math. 23. Math is hard. So that's awesome. OK, let's move on to the core. Can you tell I had a long weekend? OK, so for the core, we had four poll requests merged from four different authors. Thank you to those authors. We had four reviewers as well. And AnticData is a new reviewer on here. So thank you to AnticData for reviewing for the core. We had 18 open poll requests, where a number of those are creeping up at age. So we need to take a look at those. But generally, 18 is not too bad. We had eight closed issues by five people and four opened by three people. So we're net down four as well, for a total of 395 open issues. Now, this number is growing slightly over time. And the way that we keep track of whether we're staying on top of the issues or not is by tracking or triaging and marking milestones. So we have four issues not assigned to milestones. Those are ones we need to take a look at. We've got seven open support issues, which we should probably look at as well. They don't tend to need to stay open very long, because those are questions and stuff, not necessarily things that we need to fix or implement. And we have 315 open issues marked long term. So those are the things that we'd like to get to at some point, but have no immediate plans to. So that's where we are in the core. Overall, we've been keeping on almost one beta a week pace, thanks to Dan, who's been doing those releases and getting lots of new stuff out, particularly for the Raspberry Pi Pico. So thank you to everybody for working on that. I think the plan is to kind of stay in the beta phase for a bit while we stabilize and add stuff for the Pico. At some point, we'll also, well, some point soon, we'll have other boards with the RP2040 as well. And so that's something that we're very aware of as well. So that's it for the core. Let's kick it over to Katnie for the overview or the stats for the libraries. Thanks, Scott. So this applies to all of the Adafruit Circuit Python libraries, so everything that begins with Adafruit underscore, CircuitPython underscore, as well as a few extras such as Cookie-Cutter and the Community Bundle. So we had 46 pull requests merged, which is a pretty high number, but I know we had a few of the CI updates still in the works, and those were merged, so that was good. But with 18 authors, there were definitely a number of non-CI related PRs, which is excellent, and 11 reviewers. In terms of merged pull requests, the oldest one was 166 days old, and I'm really excited to see this one. We updated our library Cookie-Cutter. It's now possible to have a more Community Bundle-friendly Cookie-Cuttered library, depending on how you answer the questions. So that was really great to see. And early hug report to FOMI guy for updating the guide to go with the sharing a library guide. The Cookie-Cutter section was updated to match it. Let's see. So that leaves us with, wait for it, 53 open pull requests. We had 26 closed issues by 13 people and 11 opened by 10 people, so we're net down, which is excellent, leaving us with 280 open issues. Seven of those are labeled good first issues. If you're interested in contributing to CircuitPython on the Python side, consider going to circuitpython.org slash contributing. You'll find all of this information and more, including a list of open pull requests, a list of open issues, and some library infrastructure issues. You can search the open issues. If you're new to everything, good first issue is a great place to start. And there is a guide on contributing to CircuitPython using Git and GitHub. So if that's something you're new to, don't let that intimidate you. The guide is there to help, and so are we. We're available on Discord all the time to answer questions. And we had one new library this week. And then the list of updated libraries was many pages long. So I removed it from the notes because we're still doing the releases on the latest library sweep of CI update stuff that we did. So that's why it was so huge. And that's where we are with the libraries. Awesome. Thank you, Catney. OK. Next up, we have Blinka Stats from Maker Melissa. Hello. So for Blinka, which is our CircuitPython compatibility layer for Raspberry Pi and other single board computers, this week we had four pull requests merged by three authors and two reviewers. There are three open pull requests left. And there were four closed issues by four people and zero open by zero, leaving a net of 50 open issues. There were 1,929 Pi PI downloads in the last week. And we are currently supporting 67 boards. And that's it. Awesome. Thank you, Melissa. All right, next up is Huck Reports. Huck Reports is a chance for us to say thank you to folks for what they've been doing within our sphere, CircuitPython and Python and all of those things. So I will start, and then we'll go through the list of folks both in the notes and then the folks who are in the voice chat as well. We covered details of that prior to the meeting. So first, a Huck Report for me to Sanity McDonald for Pimeroni examples of CircuitPython. Huck Reports asks Patrick W for the ESP IDF update work. Huck Report to H Wiguna for bug filing and asking really good questions on Discord. And lastly, Huck Reports to Starwitch for the ESP bug filed that Hierophag fixed. Thank you, Hierophag. But Starwitch also followed up with a huge thank you, which was always nice to get appreciation on being responsive. So that's it for me. Let's go to TG Techie. Just a community hug. Thank you, everyone. All right, thank you. All right, next up is ask Patrick W, who's not here. So I'll read that off. Patrick says, thanks to FOMIGuy, Catney, and Summersoft for their support patients testing and code review on the CircuitPython Library cookie cutter PR, which makes it more flexible for community and Adafruit bundle libraries. Thanks to Jeppler for adding the requirements.txt data to the library bundles as well. And next up, I have notes from C Grover, who says, a group hug for the team and community, amazing progress for the RP2040. And next is Charles. I have just a group hug, but I just wanted to make one comment that I'm listening to this group. I found a lot of good information, especially on the RP2040. And I thank you very much for that. Awesome. That's it. Thanks, Charles. All right, next up is Dan. Hello. So just two things that I can remember off the bat and looking at pull requests. One is Dave Putz. Thank you for fixing an RP2040 PWM out bug, which just it was there were some logic error there. And thanks to Southern Dragon and Discord, who found that an existing BLE example having to do with Adafruit services and the Circuit Playground Blufruit app doesn't work anymore as of CircuitPython 6.1 or so. So I'm trying to track that down right now. OK. Awesome. Thanks, Dan. All right, Dave P is looking. And I've got a note from David, who says, huggerboard to Dan H for helping with the unreleased LyWSD03MMC thermometer library. And now it is released. Huggerboard to wild this pixel that demonstrated in sharing code for using the Pico Explorer from Pimerone with CircuitPython. Huggerboard to Lamore for adding two independent pins, not SDA or SEL, to the STEMI QT connector of the RP2040 QT Pi. And huggerboard to Philip for fighting the self-promoted LEGO cops in maker forums. Next up is to Shippu. Right, so thanks to Dan for reviewing and merging my requests. Thank you to Scott for giving me advice on how to write those things. And thanks to, oh my god. And remember, the fancy bitmap for requests, that looks really useful. So that's KMatch98. Awesome, thank you. All right, next up is FOMI guy. All right, thanks Scott. This week I got a huggerboard for Jose David M for making a baseline alignment enhancement inside the display text labels that allows us to line up different fonts along the baseline, which is really nice. Also for working through all the changes in that PR. Jose has been sticking with it, I really appreciate that. To KMatch, same thing to Shippu just mentioned, that fancy bitmap is really, really cool. Being able to rotate and scale bitmaps is really nice. Also KMatch did a bunch of good work looking over some of my requests this week, the wrap text by Pixels1 and pointed out a bunch of issues to fix in there. So thank you for that. Ask Patrick W and Somersoft both for getting work done in the cookie cutter library that makes it easier to build community bundle projects to Hugo for working on the progress bar. He broke it up into a package so that we can have different ones and they will extend a base class. And then Hugo has also worked on the vertical progress bar, which is really cool. And then lastly, I'll just mention a group hug and I hope everybody is staying warm. I know there's very cold throughout most of the US and some people are losing power and stuff. So I hope everybody is keeping warm. That's it for me. Thanks. Thanks, Foby guy. All right, next up is Hierophat. OK, thanks this week to Jeff Epler and Dan for their reviews on the I-Squad C Repeated Start PR. Thanks, Dan, for his help talking about bugs in I-Squad C this morning, just now. Appreciate it. Thanks to Anikdata, Nerodoc, Bruce Siegel, and Thomas at BTTF and a number of other people for their help in testing the I-Squad CNS-PI issues, which have been present on the ESP32-S2. And thanks again to Bruce again and Ask Patrick W and Micradev for their work on updating the ESP32-IDF2 version 4.3. And then a group hug. Thanks, Hierophat. All right, next up is Hugo. Do you want to try your mic or should I read it off for you? I know you're kind of lurking. Hugo's typing. You're a bit quiet, but I can hear you. OK, I'm still getting this chord set up on the computer, so sorry about that. It's OK. Oh, first off, hug for K-Match 98 and Phone Me Guy for all the help, feedback, and information they've given me while I'm working on that progress bar library to stir for the patients in answering some of my more newbie-like questions while he was putting together a board. The Phone Me Guy for streaming on Saturday and the others who were there where I picked up a bunch of good information. And then group hug all around for just making this community as wonderful as it is. Awesome, thank you, Hugo. All right, Jason's lurking, so next up is Jeff. There's the Unmute button. You found it. Yeah, this isn't quite alphabetically, but I want to thank Patrick for even more upcoming improvements to CIRCUP's dependency management and Brent for Adafruit Daytime, which I used over the weekend or maybe on Monday, and it worked like a charm. Thanks to Lady Adafruit for keeping the interesting project assignments coming to Scott for taking over the meeting today for me. To paint your dragon, I may have done this one last week for doing the heavy lifting for RGB matrix on the RP2040, including the Pico, and to Harry, who is HWaguna on GitHub. He's a friend who has become a big CIRCUP Python advocate in our local maker community. He loves his Pico. He loves CIRCUP Python on it. I think every virtual meeting for a month, he's going to show how there's this CIRCUP py drive, and you just edit the file on it because that's amazing, and it's so fun to see his excitement. Anyway, and then finally, to a higher effect for taking a stab at this I2C Wi-Fi ESP32S2 issue that several of us have tried to resolve. I know one of these times we will figure out what we're doing wrong or figure out where the ESPIDF bug is, but thanks for taking your turn, and that's what I got. Thanks, Jeff. All right, next up is Jerry. Hi, everyone. Just a thanks to Admiral Maggie for putting in a PR at some enhancements and fixtures to the fingerprint library, fingerprint sensor library. Nice job. Thanks, Jerry. Is Johnny lurking? Johnny, are you lurking? I assume you are. I think Johnny's lurking. I think I saw that earlier. Next up, we have Notes from Jose, which I'll read off. I think you said it early, Johnny. I missed it. Johnny said, sorry, lurking. OK, so Notes from Jose. Jose says, hug report to FOMI guy for the live streams and all the explanations and allowing me to contribute. And hug report to Hugo, Kmatch98, Jay for seeing AskPatrickW and Neridoc for the community coding session. It's a lot of fun. And next up is Katnie. I just scrolled away from things. Hold on a second. I feel you. Trying to update the notes. OK, so I have a hug report for FOMI guy for picking up a bunch of PRs over the last week. RIP my inbox, but it's excellent to come back and archive 90% of what's in there, because it's all been merged. Hug report to AskPatrickW and FOMI guy for getting the updated cookie cutter PR going, as well as to Somersoft, who popped in. The PR was originally put in by Somersoft and then got dropped for a bit. And so in the final stages of that, Somersoft also showed up to help out. So that was excellent. And another hug report to FOMI guy for updating the cookie cutter part of the sharing a library in CircuitPythonGuide. That was one of the concerns I had was that we have very explicit instructions in that guide to go with cookie cutter, and we were breaking those instructions entirely. And so that all got taken care of all at the same time, and that was very excellent. And that's what I've got. Awesome. Thank you, Katnie. All right, next up we have notes from Kevin Thomas, who says, hug report to FOMI guy for helping with the Adafruit display SSID 1306 library. And next is Kmatch98. Thanks, Scott. First reiterate what FOMI guy said, thanks to Jose for finalizing the display text label with the new baseline. Definitely makes life a lot easier for typesetting. So that's a great contribution. Also, FOMI guy, thanks for the inspiration to use Blinka for debugging. I also find in some peculiar differences to look out for. So thanks for that. Also, thanks Hugo for contributing on the progress bar. And Deshapoo for introducing me to some of the lingo for some of the demo scene graphics, particularly in this case, the Roto Zoom lingo. So a lot of words to learn from what people have done before. And then next, thanks, Jeff, for the PCF font addition. Five times faster to find glyphs using that. And so every day I get minutes of my life back, thanks to you. And last of all, warm hugs to everybody. Thanks, Shell. Thanks, Kmatch. All right, next up is maker Melissa. Hello. I wanted to give a hug to anecdote for helping out when I was having trouble with the ESP home on the ESP32S2. Hug to FOMI guy and ask Patrick W for all your GitHub contributions and a group hug to everyone else. That's it. Thanks, Melissa. All right, now I've got notes from Mark Campbell, who says group hug. And I've got notes from Mr. Certainly, who says a hug for Catney for helpful conversations regarding ongoing projects and a group hug. Thanks for making this an awesome place. And lastly, we have Micradev. Are you text only? Or OK. I'll read off from Micradev, who says hug report to Bruce and ask Patrick W for the ESP IDF update testing. And that's it for hug reports. Thank you, everybody. Next up, we have status updates, which is a chance for us to talk about what we've been working on and what we plan on working on in the coming week. It's really helpful if folks are working on similar things or somebody's working on something that somebody has previously worked on to give tips or tricks. That's what we're going for with status updates. It's also a great way to just see all the different things that are going on within the sphere of CircuitPython, Blinket, and the libraries. So I'm scrolling down, and I will start. It's a short week for me. Monday yesterday was a holiday. Really, it's going to feel like Monday today because it's going to be very similar. And skiing Friday morning. So that means that my stream will actually be on Thursday. Even though I said last week it would be on Friday, we changed our minds based on the weather, how the weather is looking this week. So today is catching up with email and such. And then I'm going to try my darndest to wrap up with the I2S and the PIO PR. I was doing I2S, which is an audio protocol, and then I'm using PIO under the hood. So I've been expanding and elaborating the PIO support, which is something I wanted to do. Probably shouldn't have lumped it together with the I2S stuff. But now that we're starting to see people use it, there's things that we're finding that we need to do. So I'll probably add all of the initialization stuff today after I or tomorrow once I figure out my issues now. So hoping beyond hope to have audio bus IO done by the end of the week so that I can move on to whatever I feel is most urgent after that. So, yeah, hopefully, hopefully more of that. OK, let's go on to TG Techie. Hi, everyone. So last week was a lot of work on the Smart-ish Watch-open building with a friend of mine. I found a bug and patched it with a single diode. Now it no longer falls into a brown out safety handler when it hits low battery. And that leaves only one known issue, one known issue with it, which is Bluetooth, which still isn't working. Although I've made a little progress in debugging that. And lastly, last week I started for my job, actually, this is non-Python news, but making a C code formatter for the makerspace of my college. It's supposed to be a little bit like black, the code formatter, but for C. After trying and using black in my personal Python project, I was like, this is great. I want this for C to make it simpler and easier. And they said, go for it. So I've been working on that. Have you looked at A-style or clang format? I've not heard of A-style. I've looked at clang format. Neither of them are like black where you don't configure it, but they are both C formatters. I'll take a look at A-style. I couldn't find any files or people who successfully said it could be done for the style the makerspace wants. And I think I want to dive into making things with scratch when I shouldn't. I am, too. Well, that being said. I feel, yeah. I think it comes with a territory. Yeah. A-style is what MicroPython switched to. That's why it's on my radar. Otherwise, I would use clang format. Clang format, I think, is largely what people use. I think they're using Uncrustify, actually. Like they switched from A-style to Uncrustify. OK. Uncrustify? Or maybe I think it's Uncrustify. Right. But there are multiple issues and PRs about it. Right. OK. OK. Oh, wow. Looks like it does everything. I'll take a look at those. Thank you. Next week, I'm going to try to do some more Bluetooth debugging for the watch. Swap out the module with one on a feather to see if this is the watch board I designed or the Bluetooth modules I purchased. Or most likely, it'll be made up. And I'm programming it wrong. I want to pull some fixes from upstream Libs into the frozen libraries for Secret Python, since there has, from what I've seen, there are a couple errors that have creeped away into the standard Libs. And try to play with a suggestion on a simple rect PR I made a while ago that Scott Tanook made and see how efficient or possible it is to merge the two together, have a RAM efficient or possibly outlined rect. It should be doable, but I want to double check. And that's all. Awesome. Thank you, everyone. Thanks, TG Jackie. All right, circling around, I've got notes from Ask Patrick W, who says, circle up enhancement to pull requirements from the new requirements data bundle instead of fetching them from GitHub. And look into the Azure IoT C Python Sockets compatibility now that many MQTT support sockets. This will bring Azure IoT to the ESP32 S2 ports. And next up is Dan. OK. So last, I can't remember which night. I released Circle Python 6.2.0 beta.2. And it's amazing how many, there were only 10 days, I think, between beta 1 and beta 2. But they were like, as usual, like several dozen PRs. It takes longer to do these betas because there are so many things going in, which is great. Yep. Another minor thing I did is that we were trying to finish off the native Adafruit SPI device support, which was put in, removed, and then put back. And there was one more dangling thread there, which is that the Adafruit SD card library, which is a Python support for SD cards, was using something. It was sort of going into SPI device. And so I fixed it so it doesn't do that anymore. And now, and then we were able to undo making that property available in the native library. So it's all set now. And then finally, I released the longest part name for LIWSD03MMC library, which is from Xi'anbi Mijiji, Chinese, or is Chinese company. And it's a Bluetooth hygrometer and temperature thing, which is very cheap. It's in the store in Adafruit, but we haven't gotten stock yet. So it's coming soon. But you can get it elsewhere also. And then finally, I've been working on this idea of a secondary USB serial channel that doesn't interfere with the REPL. And I have it sort of half working right now. I'm adding some more features with it and trying to bug why it will receive characters. But when I write to it, I don't see the characters come out. OK. Sounds like progress, Stan. It is progress, yeah. Awesome. I think we underestimated how much people are going to like that. I think it's going to be really cool. Lamora is very interested in it. She has all kinds of, I think she has a backlog of products that she wants to do, of libraries and stuff, yeah. Right, warrior wire says that will be amazing too. OK. Let me read notes from David Glav, who says testing various firmware on the LIWSD03MMC thermometer. I have eight of them, five stock, two ATC 1441s and one PVVX. I don't know what those variants are. Connected a Pico to a mini-pi TFT, which is 240 by 240 using the Pimerone Pico Explorer pinout so that I can try the circuit-piping code from wildestpixel. I tested circuit-piping development with limited internet connectivity. The size of the US-2 file, do we have documentation you can download once and read offline? How do you program without doing GitHub or Google search? That's a good question. Learn guides you can get PDFs for. I do know that. Non-circuit Python lost internet connectivity from Saturday morning until three hours ago, including two days of teleworking with a phone doing 4G LTE tethering, which implies no Netflix, no YouTube, no IoT device, no online gaming. And next up is Dishapu. I finished, I'm focusing on a bit more on games for circuit-piping recently. I finished, actually ported the tetheries I have written a long time ago for the Halloween. Now I ported it to Pupu M4 and PyGamer and iBatch devices. And now it's a proper tetheries. So the lines get deleted and get a score and so on. And it's only like 140 lines of code, so it should be easy for people to adapt to their own devices. Yeah, now I'm trying to make a game with an isometric view where you walk around. And I will have an in-depth question for this. And I also started to try to write that library for, I think, controls independent of the device for the game. And I don't really like the way it came out, so I'm going to work on that a little bit more. That's it. Awesome, thanks to Shippen. All right, next up is FOMI guy. All right, last week I reviewed the PR for the cookie cutter and tested that out a bunch. I used that on some of my own libraries and I made the updates in the guide for that to go along with the new prompts. I fixed a few issues that were found in the still wrapping function that is going to go inside of display text. I tested and reviewed a PR that fixed a scale issue that we found inside of display text where it caused things to get extra scaled, like two times as big as they should be on Blinka. And I beat my head against that one for a while and never did come up with a fix. And somebody figured that out last week. I practiced the name. It's Le Samurai Porpe. I think it's a purple samurai, maybe. So shout out to them. Thanks again for that fix. That was really cool to see. For this week, I want to give a final look over to the base alignment PR, which is in display text as well and probably get that merged unless anybody has any objections to that. So anybody who is interested can check that out. I want to continue working on refactoring my what is now going to be a GUI layout inflator library. So previously, I had built this library that inflates some JSON layouts for you into display objects. And I also had included some layouts in there that would do some of the stuff that's now kind of in the actual display layout library. So I'm splitting that up. I'm kind of focusing mine just on inflating. And eventually those layouts will move over into the real library. So I'll be working on that this week. And then lastly, I want to test out the vertical progress bar specifically. And also there's a new matrix portal example that is in that same PR that I want to try out this week. And that's what I got. Thanks. Awesome. Thank you for filming, guy. All right. Next up is Hierophact. All righty. Last week, I finished up the I-Squared-C repeated stark bug, putting in all the IRQ infrastructure and stuff that was needed for that. That's on STM, right? Yes, on STM, yeah. So that should be all done. It's working well. I hacked at the ESP32-S2 I-Squared-C and Wi-Fi bugs, which I went in hoping, oh, let's just see if we can fix a macro or something. And no, they're weird. There's two different directions that we can go with them. And they're very hard to pin down with a debugger because they disappear when you step through the code. And they may be related to heap resets or interrupts or something. I don't know. They're weird. So I'm thinking I'm going to probably put that down until we update the IDF again, because it would really, especially if I solved it and then it broke again once we get the new version of the IDF in. So but yeah, I think we have at least got some good testing data. And there's a lot of different people working on in parallel. I'm confident it will make progress as we go on. I fixed some minor just little itty bitty PRs here and there. And I read through a bunch of the existing low power code across the different ports in preparation for what I'm doing this week, which is going to be getting started wholesale on STM32 Deep Sleep. And as I mentioned, just monitoring the IDF update, which just needs to be coordinated. A lot of people, separate people, have different work on their own PRs. So we just need to get all that stuff together and then retest once that's in. And that's all I have planned for right now. But I can take on anything else. But that's it for me. I think a week focused on Deep Sleep is well-earned at this point. All righty, thanks. All right, next up is Hugo. I'll read out for Hugo, unless Hugo interrupts me. Sorry, I muted. I learned, but I did not. Go ahead. So last week, I did finish the progress bar refactor, but it is very rough and has some visual quirks. So I just need to port some of the code. I originally written it to fix that up. So that's going to be this week. And then I also dug into using pylint with pre-commit instead of separate because I burned several builds on GitHub just due to pylint issues. All right. Did you talk about this week, Hugo? Oh, I kind of did in passing. But yeah, this week is progress bar, the basics for the horizontal vertical, especially since PomiGuy intends to do some testing on that. And then just kind of clean up what's there, the samples that I've added, and then some of the other features in the other issues that were opened for this different quality of life improvement. Okay, awesome. Thank you, thank you. All right, next up is Jeff. Hello again. I was typing this, but I'll say it aloud to Hugo. Don't worry about the CI failures on your pull request. Those are there to help all of us. I mean, it's great when we can do it locally. I think it would be a good step to take, but don't beat yourself up. Just when the automated system gives you a red X, it's there to help you and it's there to help all of us. And don't let it get you down. And I say that as somebody who lets it get him down. No, I understand, it's a two minute cycle, always something must go quick. Right, yeah. The benefit of making it faster is what counts. It's not the computer gave me a red X. So yeah, absolutely. Anyway, so I'll kick this off with my other stuff. My state has been affected by what are called controlled outage areas that's rolling blackouts to you all. Due to a severe winter storm, reducing electrical supply and increasing demand. So I was worried I wouldn't make the meeting, but it's been fine and we are fine and safe and warm. So no worries there. Anyway, as to circuit Python work, last week I worked on protomatter for the RP2040 and it was working fine for me, but when Lamore tested it, she ran into problems, particularly when copying files over USB. So I will investigate that further. In PIO, I eventually got over some humps that I had in my understanding of the PIO peripheral of the RP2040 and implemented first a spy peripheral in PIO. And that meant enabling reading from the PIO peripheral. Scott has this in his I2S branch that he mentioned and I think we're gonna take his version instead. And I did find one bug that affected inputs only that he's also incorporated that fix. For my own project, I love timekeeping and there is a radio broadcast time signal in North America called WWVB. And I have a receiver now that works in circuit Python. It can receive and decode the signal, then convert it to local time and show it. And that's where I was working with date time. Let's see, I figured out how to read the RP2040's boot cell pin from C code while your code is running. To do it in circuit Python, it requires a modification of the core. It feels pretty hacky. So I'm just inviting a comment from Scott or from anybody else who has an opinion. Do we wanna polish this and add it to circuit Python or is it best to just leave it alone because it's kind of yucky? No. No, all right. People should not be pressing boot cell unless they wanna select what to boot. All right, let's see. I worked on a document on how to participate in the circuit Python meeting. We haven't really circulated that yet. It does change a little bit how we work with lurkers. So it'll finally take the onus off of lurkers to state their lurking status. And instead we will look at the note stock as kind of the canonical. If you're gonna speak, you put your name in there. And I think it's gonna speed up the meeting because when the notes takers like me miss that somebody said they were lurking, it creates a little detour in the meeting. So that's the main change, but also we will have a document for people who want to review how better to participate. Let's see. And then finally, I added the requirements.txt files to the Adafruit and community bundles. So in the future, as Patrick W has volunteered to use this in circup to install the dependencies of each library. Circup does understand the dependencies now, but it has to request the information from GitHub and that subject to API rate limits. So like hypothetically, if you wanna do a circup 100 different boards within an hour, GitHub might have gotten across with you now or once this change is made, it won't be a problem, it will probably also be faster. Anyway, this week at least some of the following, I've made a second circuit Python sculpture. It's physically complete. The thing to do next is make a short video about it. Next, protomatter for the RP2040. Like I mentioned, there are these crashes under certain use cases and I need to debug those. And while I'm in there, I plan to debug the failure of storage data race file system on the RP2040. And finally, and the thing I've actually been working on the past two days is more with the PIO peripheral. I've got a PIO program that can drive eight NeoPixel strips in parallel using only three digital IO pins. So the main advantage of this is potentially a faster refresh, although it also takes time to reformat the data. And I'm looking at needing to add a core extension to do this. Basically, you have to rearrange it. So instead of taking the bits of the first pixel and then the bits of the second pixel, you have to take the first bit of the first pixel and then the first bit of the eighth pixel and then the first bit of the 24th pixel or something crazy like that. And it's really slow to do this in circuit Python. It can be really fast to do it in C where you have fast bit manipulations. So for this to really be viable, we will need to put a function to do that in the core. But man, it is really neat to be able to drive eight independent NeoPixel strips and they update so fast. It's wonderful. Anyway, that's what I've been up to and what I'm going to be up to. Thank you. So for the proto matter thing, just I think we turn when we erase, we're supposed to turn off interrupts. But just it's weird on the RP2040 and the IMX has us too and the ESP has us as well as like, remember that running code can do flash accesses, right? So if you're in a state like where we're, we think we're modifying the flash, because of the drive stuff and we get an interrupt that is trying to run off of that, like you're going to have a bad time. So I think we have it off, but like that's where my brain goes when I hear something like that. All right, I will investigate that. All right, next up is Jerry. Hi. So I always find it hard to resist when somebody in the forum has a question about the RFMs and sometimes I was like playing with them. So spent a lot of much time helping somebody get an RFM9X project working. It was kind of fun. I learned a lot. And then somebody else had an issue. They posted it actually into the RFM9X library as an issue. Not sure really it's an issue there, but it's a good place to track this. They were getting some interference or thought. So when they're using the RFM with the GPS, but the, I don't think it's any real issue there, but the cool thing was that this would not have been possible before we built the new RFM9X board, with the built-in libraries and there's a cat. And so it was really, actually, I was really having fun seeing just how much could be fit into that code. Something that I really never even thought about being able to do on an RFM, on an Fether M0 RFM board. And then another user is, or actually that same user is having, is also trying to use an M0 blue fruit with the RFM9X. There, it's a little different because nothing's built in and it's tight memory, but just playing with it now and trying, you know, the new, new version of Python and all of the memory is getting better. So it looks like it might, it might be usable, a bunch of testing to do, but it's been a fun project to play with. And it's really, you know, reminded me a lot of stuff about blue fruit and I'll bring that up in the weeds later. And so my next week is to keep poking around with that RFM9X and blue fruit stuff. And then for fun came across the guides that said how to set up an RPI-4 as a home assistant. And the guides, there are a bunch of guides on it and they're really nice. And one of the really cool features was that you can read and write NFC tags. I have a bunch of NFC tags and you can program them from the home assistant and then use them to trigger events. So it's actually kind of a cool tool. Learning lots of things about the home assistant and triggering stuff. Awesome. Thank you, Jerry. Yep. All right, next up is Katni. Hello. So let's see. Last week, finished up a new page in the Circuit Python Essentials Guide, which is talked about board, import board, Dura board and built-in modules in Circuit Python. It's all stuff that we use, but something we never actually explained. So there's a page for that in the Circuit Python Essentials Guide and it has been mirrored into every single Circuit Python-compatible board guide that we have because it's very important and these questions come up a lot. If you find a board guide that it didn't get mirrored into, please let me know. I'm pretty sure I got them all, but they can sneak in. I got some blogging out of the way we always blogged new and updated guides and I had a whole slew of them get kind of backed up. And so I did that. Published the ISO 1540 guide, added a couple of things to the welcome to Circuit Python Guide, which was the explanation of Circuit Py file system use and the explanation of what Circuit Python does when your code ends. Updated the Circuit Python Essentials Audio out page code for Circuit Python 6x, which just meant taking out some try accepts that were necessary for 5x to 6x compatibility. And now that we have 6x stable, updated that, published the AW9523 guide except for the Circuit Python page and fixed the Feather Sense pinouts page layout to be more readable and started the data logging page in the Getting Started with Pico guide. So this week, I'm adding or continuing the data logging page in the Pico guide. I actually finished that earlier today and then I'm adding reading a Potentiometer and PWMing and LED to the Getting Started with Pico guide. I'll be updating the MLX 30393 guide for the QT Rev. There's a couple docs that need to be added to the Feather CAN guide and I will be starting to train up on taking over temporarily the Python for Microcontrollers newsletter publishing. Ann's gonna be out for a bit and so over the next few weeks, I will be working with her to learn the process and then I will be handling that for the time that she's out and I wanted to make a note as of 10 minutes ago. We have a new email address. It's cpnews at adafruit.com and that is the place to send your Python on hardware projects for the newsletter instead of sending them directly to Ann, you can now send them to this email address and it goes to both of us. So that way we can make sure that everything gets in. And I didn't note in the notes, but for fun, I've been working on building a website using a static site generator called Pelican that runs on Python and decided to basically write a theme from scratch. And so I've been working on that and I guess belated Huggerport to Coreola for heading into a mire of JavaScript because apparently doing integrated search on a static site is much more difficult than it sounds. So that's been days and days of fighting with JavaScript and it's been, but it's working finally, basically. It's basically done. So I'll be pretty soon pushing that new theme and the new features to my site and that is what I've got going on. Awesome, thank you, Kenny. All right, next up we have notes from Jose who says, last week, base alignment for a display text label, PR for Pico and the example for the Jupyter Notebook, PR for Adafruit Circuit Python DHT, correcting the trigger values. This week, base alignment for the bitmap label, documentation and read the docs for a bitmap label and other requests are accepted. Be careful what you wish for. Thank you, Jose. Oh, and that was out of order too. Oh well, next up is Kmatch 98. Yeah, thanks, Scott. Okay, so I guess the prior week I had demoed a Roto Zoom bitmap copy function in Python this week put into the core. So it worked a lot speedier. Then I revised the widget and control classes. This is for the GUI elements that are envisioned to work with the new grid layout function for managing touch and display on screens. And then I just put together here rather than put what's new, maybe it's easier to capture what's out there and the list of widgets that are available. They don't necessarily all conform to those classes, but at least there's quite a few things that are out there that people can start trying out. Maybe not complete or released yet, but at least they're getting developed. And so this week I want to try out Hugo's new progress bar or advancements on that since I'm kind of new to that. I want to see what that looks like. And then on the new widget and control classes for the GUI, I've got a kind of a major giant PR there that's draft. I want to pull out just those main classes and get feedback on those to see if those are shaping up to what people think are useful. And a related note, I want to also figure out how to use the Sphinx documentation tool on my machine so I can see how it actually documents those to see if that's useful, particularly how to deal with all the inheritance of different layers of classes and subclasses. As for next, I want to document at least one widget and make sure it is fully compatible with the new grid layout function. I think that'll probably be the key goal for most widgets to make sure they resize and get placed well with the grid layout. And then last, I want to get that roto zoom function in the core organized so it'll be useful and I guess figure out how folks can build it if they want to add those bitmap tools into their build of circuit Python. And I think Scott envisions that a place for any bitmap manipulation tools. And I already thought of another one to actually do color remapping from copying from one bitmap to another. So that's up for this week. Okay, thanks everybody. Awesome, thank you Kmatch. Next up is maker Melissa. Hello, so last week I continued working on ESP Home for a couple more days, but got stuck on an issue with Wi-Fi and nice for seed not working at the same time. Like it was disconnecting me from Wi-Fi. I've worked on some GitHub issues and PRs and I added some bug fixes to some of the Raspberry Pi scripts. I attempted to get an alternative ST7789 driver working on the Raspberry Pi, but it ran into the same issue where it's like not drawing it or whatever. And I started working on a first e-e-ing guide and a series of e-e-ing guides. So this week I'm gonna finish working on that one. Start on the next and repeat. That's it. Awesome, thank you, Melissa. All right, lastly we have notes from Microdav, who says, I should take a time code, who says, update the ESP IDF to 4.3, add NVM support to the RP2040, which I think is almost done, and then the UR is in progress as well. And that's it for status updates. Next up, and finally, we have in the weeds, which is a chance for us to talk about any sort of longer form discussion that we want to have. The way this works is you put your notes in the note stock, kind of your name, and then kind of what the topic is, and we'll just go kind of calling one by one. If you are lurking, I'll just read it off and then answer the question. So first, I will kick it over to Hugo. And hopefully, I will be able to chat without meeting myself first. I can hear you. Excellent. Yeah, what I was thinking is for the pilot run from running them on as part of the CICV pipeline this week and last week, I started running it manually on my environment, just command line for both the library and the examples. And it seemed to me that it would be a good place to use pre-commit as well, so that if someone's running pre-commit locally, they would get that feedback as well as any other changes from Black or from other feedback tools. And I believe I heard there was an issue or there was some uncertainty about getting other hooks in there. So I did some digging and found a way to do it. I don't know if it's something that would be worth putting in or not, or we want to keep it separate. No, I think standardizing to stuff that's run by pre-commit is a really good idea. Like, we're already finding that we need to push more people towards doing pre-commit. So if pre-commit becomes a one-stop shop, that's a good place to be. So I think that's the right way to do it. I see here on the notes that you're a little worried about having to update everything, but we do have ways of doing that. Like Dylan in particular is really good at doing, like here we need to change all of our libraries this way. Like Dylan's really good for that. He does a mix of automated and manual and is really good at running everything down. So I would suggest if there's not an issue for it, let's make an issue for it and then we can coordinate there. Like what needs to be done first, which is like the cookie cutter side and then figuring out how to do the like a patch, apply patch sort of thing that the patches all of the repos with it. So start with a PR on cookie cutter, though, you think? I think just an issue, either an issue on cookie cutter or yeah, I think cookie cutter is probably the best spot. And you tend to want to start there because that makes all the new libraries up to date with it. Yeah, and it's easy to forget about it once you're in the library's proper circle back around to really the starting point. Right, yeah. I'll open an issue with that and put comments and information around what I've had to do to make it work. Awesome, yeah, that sounds perfect. And for those just listening, there's three folks in the chat that all plus one the idea of standardizing on pre-commit. So thank you Hugo for doing that. Looking at your gist of the pre-commit, the concern I have, and I raise this because I was burned by trying to add something to pre-commit within CircuitPython is that there don't seem to be commands to install the required version of pylant. And if you, if those tools aren't there, which they won't be in the context of the CI system or if the version is different, then you can get different results or just get an outright failure. So I think some work will be needed on that pre-commit script so that it ensures those are installed, but otherwise it looks like a good start. Okay, is that something that would be worth having in the requirements TXT file? I'm not sure the correct way to install these dependencies for pre-commit. I think normally when you run it, it creates virtual environments and things, but when you're directly calling the pylant command line program, it's not gonna do that. And so this quickly gets beyond my expertise in pre-commit. It's just reminding me of the trouble that I had when in CircuitPython, I wanted to move the make check translate check into pre-commit and it led to problems that I wasn't able to resolve. So just something to be aware of, but I don't actually know what the fix is. Okay, I appreciate that. I'll bear that in mind and see if that comes to be a problem, how to go about resolving it. Yeah, I think Python usually has the notion of like development requirements as well. Like I think there is actually like a dev-requirements.txt that is used occasionally. So it's possible that there's like a second way to specify requirements that are only for development. Okay, I've made note of that because I'm sure I'll be there. Okay. As a side note, it's worth noting that pre-commit requires an actual revision number. It's something we have to update across all the libraries. So using latest and stable is not supported. You're not doing that in the pylant section. And you must have copied the initial section from one of the non-updated libraries, but I just wanted to make a note of that for anybody who's working with pre-commit. You have to give a revision number. You have to choose it and pin it and deal with that and then deal with updating it as time goes. I will do that. Awesome, thank you. All right, I'm gonna move on. Next up, we just have a question from Jose. So Jose asks, just wondering if there's a long-term plan speaking to implement I-squared-C peripheral for the Pico or even if this would be possible. And I would say it's possible. I believe that the peripheral can do it. It's not high on my list because frankly I'm a bit overwhelmed by all the other stuff people want. So I don't expect myself to get to it before I wanna get onto something else. But if you'd like to take a crack at it, that would be awesome. I think it is doable. It's just like, it's a relatively new module for us and I don't think a whole lot of people use it. So I'm hoping somebody else will do it. Is this short of it? And Jose is typing so I'm just gonna wait to see their response before we move on. Yeah, so looking at the SAMD implementations, I think are the only ones we have there. That's where I would start and of course if you have questions, Jose said thanks, I will see the M4 implementation. Yeah, so if you have any questions about modifying the core of circuit Python, this goes for anybody. If you ever wanna get into it, you're struggling with something or have any questions, like I promise you I will take the time to walk you through it. It is in my best interest and it's in all of our best interests to get more people working in the core. So if you've ever wanted to do that but needs some help getting over a hurdle or two, please reach out. We'd love to get more folks working in the core. Okay, with that, let's go on to the next one. Next up I think is from Jerry. It's Jerry's. Heather M. Zero, Bluefoot SPI. And there's a library that supports that and it works with the Bluefoot SPI friend as a breakout board as well. And I was just curious, a while ago we talked about one thing that people have asked for a couple of times is why don't we support the UART Bluefoot friend? And I think it's not a big change or it wouldn't be too hard to add it but my question is, is there any interest in continuing to support that library? Or are you really looking to deprecate it and ignore it given that BLEO is so much more usable? I think generally Adafruit's approach isn't to stop supporting something. I think generally we'll keep it working but we won't necessarily add anything more to it. So if it's interesting for you to add UART like I think if it was added we'd be okay fixing it but you're right, like if people want to do Bluetooth we would point them to an NRAF, a native NRAF option. Okay, it just comes up from time to time because people try and use this thing and there's one, there's not really a great guide out for it. There's a good example for how to use it. The library, but... All right, well I'll play with it because there are a couple of bugs that were found and issues have been opened for three years on that library. But I guess I'll take a look and just see. So there's no objection to it being added or updated but no real push for either. Right. I think the place we would start is we would have to start by not selling it. Right, and we still do sell them, that's that and that was my point on it, yeah. Okay. Yeah, I think generally like just the same D21s are in this boat too, like we're not really adding anything more. Yeah, and I think long-term support for the M-Zero Bluetooth is pretty limited just because it's limited usefulness. I could play around a little bit, I suppose with trying to play with the build for it to see if it could be made more usable but that wasn't the focus. It was really more for the two breakout boards, the UART and the SPI breakout whether those are useful tools to be used with some of the other processors or not. Or there isn't, because there is no, if you have an M4, a SAM-D51, there's, is there a useful way to add Bluetooth to that? Well, Dan added the ESP32 co-processor. You can do it now through the NINA, okay. Yeah, all right, so maybe it really, that really is a much better solution, I think. Certainly it's a better solution from us, from a support standpoint, because we're speaking HCI commands across. Yeah, that makes a lot more sense. Is that, I don't even know, like with the Blue Fruit Friend, is that possible? Like maybe that's the best way to go about it is actually changing the software on the Blue Fruit Friend to be HCI. Yeah, but we'd have, it's a lot of work to refit, we have the firmware and if there are only half of the people in a year who are, who ask about this, it's totally not worth it. All right, you're starting to check in on it, thanks. Thanks, Jay. All right, next up is Dishapu. Okay, thank you. So, as I mentioned, I'm trying to focus a little bit more on games for Secret Python and right now I'm trying to make a game where you have, when you are walking around the screen and one problem I have is that you need to arrange the order of the sprite, order of draw, sprite, pretty much dynamically every time you change the position of the sprite and you don't care, generally I notice that with the order of drawing things in a group, you don't very much care about what position in that group exactly item has, you more care about whether it's in front of or behind something else that you care about. So, I want to work on the display.io.group to make the interface a little bit useful, maybe. And the first thing I would like to do is this sorting thing, but maybe also later, then maybe some move behind, move in front of something like that, methods on it. And yeah, of course, I would like to ask what people think would be the best approach to sorting it, because generally I can imagine three approaches. Right now already we can sort a group by just removing all items from it, sorting them in a list and adding them back. The group one by one in the sorted order. But obviously that's not very efficient and if you want to do it every frame, then probably are going to run into trouble. The group is bigger. Next thing is to simply add a sort method to the group using the same code, reusing the same code as on the list simply. And then you would just call the sort method on it on every frame, which possibly, well, the Python sort is pretty efficient, but with partially sorted things, maybe not the best. And the last option I can think of is to have like a sorter group that would automatically keep things sorted by using something like a priority queue, maybe, something like that, and would basically sort things every time something is added or changed it in that form. And then you don't have to worry when it's sorted. If it sorted, basically it would use the dirty flags that are already there to do that. So I don't know which one. I mean, either all of them work for me, except maybe for that pure Python approach which might be too slow. And yeah, I would like to ask about opinions on that. I mean, I think the core challenge is that there are M0 boards that have this class built in. So adding anything to them is gonna be a struggle. Yeah, we could have an additional class. We could have fancy, we could have fancy group. Right, exactly. Yeah, just like the bitmap stuff. I think that's one option. The thing that I think would get us much further is simply, you know, to use list internally in group. Like the only reason, like a lot of people... Sorry, go ahead. Oh, I was thinking about basically reusing as much of this as we can. It's also like jarring for me that the interface of the group is completely different. Well, completely different. It's a very small subset of the interface of the list. Right. And that's... Lists would be great. Right, and like people regularly run into the like size, the fixed size limitation and things like that. So I think if I were to do work on group, I think that's probably what I would do is I would figure out either how to be a subclass of list or have a list internally that then people could access. But that would need to be like a two-way connection if you want to start it at least. Right, you would have, what do you mean two-way connection? Well, if you have an, like give me a list from this group. You would also need a method that they take this list and make a group out of it. Well, not if you're actually giving the like internal list object back. Oh, right. Right, because then you can mutate it in place. Yeah, yeah. Jeff E asks, is there concern about the time to sort or the dirty rectangle that results from it? Yeah, I think that's something we have to consider as well as like if you're doing a sort every frame, making sure that you don't dirty like the whole bounds of the group, if things do not change sort with respect to each other. Yeah, of course. But I think group over the hand with that. If you enter anything in the group, it becomes dirty. It usually propagates down to it's, yeah. Yeah, I think you're right. It takes the bounds. I don't remember. I'm open to it and you know the constraints, which is like it's still got a fit on the Halloween build for M0. But if I were to personally do the work, I would probably get us away from the, like try to be a list, but not really be a list. So basically, there are two options. First is to, the desired, the more desired one is to just use the list or somehow wrap the list inside. Right. I will try that first. And if that doesn't work, then maybe the fancy group can separate. Yep. Maybe that bitmap tools could be renamed to graphics. I would keep them separate. I would keep them separate. Lots of small modules is always better. Right. Yeah. Unless there's like one API that would make it easier like a swap or something. Otherwise I would. It's fine having a module that has secret access to under the hood stuff. Okay. All right. One more here. So let me just read it off. David Glad asks, is github.com slash Ghidorah ninja slash PIO disassemble, a PIO disassembler anyway useful for the PIO assembler library to try to make sure it's complete and gives the right result. How many PIO assembler syntax exist and is the canonical syntax? What features are we missing in current PIO assembler library? So this is all for those of you who don't know risk about the PICO and the RP2040, PIO is a special peripheral on it and it has its own assembly language. It is helpful if we did want to start writing tests of being able to like go to and from text and back, text and bytes and back. I don't have plans on adding it. There is not really a canonical syntax because if you read the data sheet, they're like, oh, commas are optional, which means that I originally implemented it without commas. Jeff added comma support. Most of the examples have commas. Is there a canonical syntax? I don't think so. There's, so the last question is what features are missing? So the actual PIO ASM can do like variables and basic expressions. So you could say like define foo is one and then later in some places use foo plus two or something, which is not supported by the circuit Python PIO ASM version. The proper PIO ASM allows you to like inline C code, which I think is kind of absurd, but that's the way that they handle like there's, this is something that we're having to figure out in PIO as well of like, how do you declare all of the setup that happens before your code runs? And there's like no canonical way of doing that in PIO ASM. It's just kind of like, oh, we just put inline C that does all this stuff for us or we put these magic declarations for MicroPython that gets converted into the MicroPython code. Like there's no unified way of defining stuff like that, which is what I've been thinking about on the circuit Python API side, but I think in terms of the actual ASM, like in terms of the actual instructions, I think it's basically complete. It's the metadata around PIO that the PIO ASM library for circuit Python doesn't handle like wrap targets. Like if you're not wrapping or like circuit by them, we'll always wrap around the whole program. It won't, in PIO ASM, there's ways of designating that you want to wrap in different places as well. So I, you know, my approach to new things is always to try to like get at the essence of what is interesting and what people you use and only add this stuff as people demonstrate how things should be used. So with the I2S stuff for PIO, like we're finding things that we need. So like I'm doing reading and reading right at the same time, but that was kind of just happenstance. But like Jeff had this problem and another other people have had the problem of like getting the pin state to be what you expect it to be by default. And so I think that's one thing I just, I just want to do this week to make it easier, which is like, if you have output pins, they will default to being output unless you override this keyword arc that makes it not. If you have set pins, they'll default to output except if you override it, like just like having some logical defaults that people are already assuming around the initial state of things is something that I think I'm just going to tackle by making more keyword arcs on the PIO state machine class. Keyword arcs, they can like, if you've ever looked at like the E-ink display stuff, like I can get kind of wordy in the docs, but I think keyword arcs are a great solution on the code side because you only add the ones that you want to be non-default. So on the code side, the code side I think is clear. It's just like the APIs can get a little hairy if you have like 20 keyword arcs that you can put into a class constructor. It's a little weird, but. So yeah, I saw that the disassembler thing go by and that's certainly helpful for like making sure that the code that we generate, the bytes we generate with PIO ASM represents what we think it represents. And I was thinking about writing a disassembler myself for that reason, but it's also, the other thing is that like, PIO ASM is only nine instructions depending on how you're counting. So it's not a whole lot to understand and programs can only be up to 32 instructions. So there's not like a ton of instructions to look at either. So it is doable to just like go one by one and make sure that it's correct. So that's one thing to consider as well is like you don't necessarily need a ton of tooling for a program that's only ever 32 instructions long. And in practice, like most things are done in just like four to 10 instead. Yeah, I mean, if you wanna use it for unit testing and regression stuff, that would be awesome. It's just like, I literally wrote that library in like a day just to get it going. So that's something that will come with as it matures. So just to clarify, Scott, you would be happy to see somebody begin writing unit tests for PIO ASM. I would love to see that, yes. And that is broadly true for all of the code that I ever write. Like the thing with unit testing is like, getting the framework set up is often for me the hardest part. And so if anybody wants to get us over that hurdle for just about everything, like the other thing I would love to see us do is actually C level unit tests and circuit Python core. But like, I don't know how to set that up. But when it comes to like adding unit tests, it actually can be easier because you can just copy existing tests. So yeah, it's a lot of activation energy for me to add that first initial test. So yeah, it would be good. And like, this is something I've feared since like circuit Python became a thing of like, at some point we're gonna get so big that like the lack of tests is going to really bite us. And I still think that's true. So it's a good intuition. Awesome, well, too big to test while we were tiny when we started. Okay, let's wrap this up. Thank you everybody for joining this circuit Python weekly for February 16th, 2021. As always, if you want to support circuit Python development, it's open source. So we'd love to have you contribute, but also you can support those paid of us paid by Adafruit to work on it by going to adafruit.com and purchasing some hardware there. The video this meeting will be released on YouTube at youtube.com slash Adafruit. The podcast will be available in major podcast services after that. It literally takes the audio out of the YouTube video. This will also be in next week's Python for microcontrollers newsletter. You can go to adafruitdaily.com to subscribe to that. The next meeting will be held on Monday. So not like today, which is Tuesday, but next week is Monday. So be aware of that at 11 a.m. Pacific, 2 p.m. Eastern on the Adafruit Discord server, which you can join by going to the URL adafru.it slash Discord. If you would like to speak in the meeting or be notified about the meeting, please ask to be added to the circuit Python NISA's role. You'll get your username will turn purple and that's one way to check that you have it. And with that, we'll see you on Monday and see you on the Discord before then. Thank you to everybody who took the time out of their day and take the time every week to join this meeting. It's always puts me in a good mood to hear all of the awesome stuff. So thank you and we'll talk to you next week. Thanks, everyone. Thank you, Scott. Thanks, Scott. Thank you. Thanks a lot.