 Hello, everyone. This is the Circuit Python Weekly for November 29, 2021. This is the time of the week where we get together to talk about all things Circuit Python. I'm Scott, and I'm sponsored by Adafruit to work on Circuit Python. Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support them in Circuit Python, consider purchasing hardware from adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join any time by going to the URL adafru.it slash discord. We hold the meeting in the Circuit Python Dev Text channel and the Circuit Python Voice channel. This meeting typically happens Mondays at 2 PM Eastern, 11 AM Pacific, except when it coincides with the US holiday. If the meeting time has changed, we'll notify you via Discord. If you wish to be notified about changes to the meeting, we can add you to the Circuit Python NISAs Discord roll. There's also a calendar available that we try to keep updated if you'd like to subscribe to that. This meeting is recorded. We recorded the audio from the Voice channel and the video of the text channel. If you'd rather not have your voice recorded, you're still welcome to participate. The video of this meeting will be posted on YouTube and the audio is released as a podcast. If you find this podcast is not available on your favorite podcast service, let us know. There's a notes doc 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 the document and we'll read them off during the meeting. Please do mention that you won't be in the meeting after your name there. The notes document also contains timestamps to go along with the video, so you can use the doc to view only the parts of the video that interest you most. The meeting tends to run 60 to 90 minutes, so this gives you the option to skip around. A link to the notes document is posted to the CircuitPy then Dev channel on the Adafruit Discord every week. Check to the pinned messages to find the latest notes doc. This meeting is held in five parts. The first part is community news. This is a look at all things CircuitPython and Python on hardware in the community. It's preview of our Python on microcontrollers newsletter. The second part is the state of CircuitPython libraries in Blinka. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers separate from what we're all up to. The third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. The fourth part is status updates. Status updates is an opportunity to sync up on what we've been up to. Take a couple of minutes and talk about what you've been doing in the last week since the last meeting and what you'll be up to over the next week until the next meeting. The fifth and final part is in the weeds. In the weeds is an opportunity for more long form discussions. These discussions can come out of status updates or be something you've identified ahead of time as too long for status updates. Just drop a note in the weeds section so that we know what's upcoming. And that covers how the meeting will go. I will take a time code and then get started on community news. After I scroll up here. So community news is a preview of the Python for microcontrollers newsletter. It covers all things, circuit Python, Python on MicroPython. And I'll tell you a bit more about the newsletter at the end here. First, let's cover the topics. So first up cooperative multitasking is added to the circuit Python seven beta. Cooperative multitasking is now in circuit Python using the async IO library and the async and await language keywords. The async IO library is included with CPython, the host computer version of Python. MicroPython also supplies a version of async IO and that version has been adapted for use in circuit Python. To learn more, check out the new learn guide, learn.adofruit.com slash cooperative dash multitasking dash in dash circuit Python slash overview. Next up, let's see. Gom Jabber from Dune with Raspberry Pi. Recreate the pivotal Gom Jabber scene from Dune using Raspberry Pi ultrasonic sensor and a servo and a bit of Python code with links to Instructables, GitHub, and YouTube. Next up, a native and fully featured Raspberry Pi Pico basic interpreter. The Pico might is a Raspberry Pi Pico running the free MM basic interpreter. MM basic is a Microsoft basic compatible implementation of the basic language with floating point, integer and string variables, arrays, long variable names, a built-in program editor and many other features. MM basic includes communications protocols such as I squared C or spy to get data from a variety of sensors. Data can be saved to an SD card and displayed on a color LCD displays. Measure voltages, detect digital inputs and drive output pins to turn on lights relays all from inside this low cost microcontroller. The Pico might firmware is totally free to download and use from Jeff's projects with a link to Hackaday and the GitHub source as well. Next, the Python developers survey last chance. Heads up that the Python developers survey will be concluding in the coming week. The more diverse the response space, the better. So please help share the link this week as well as, as well to regional communities. The survey takes about 10 to 15 minutes to fill out. I'm gonna open it in a tab for myself right now. And yeah, so that's that. Please take a look at that. And thanks to Foaming Guy for the links. Next, give back to Python by pitching in to the Python Software Foundation, AKA the PSF's last fundraiser of 2021. The PSF would love for you to be a part of the big plans they have for 2022. You can join their end of 21 fundraiser in two ways. First, you can buy a discounted PyCharm license. JetBrains is supporting the PSF by donating, providing a 30% discount on PyCharm and all proceeds will go to the PSF. You could take advantage of this discount by using the promo code supportpython21. Or you can donate directly to the PSF, get back to Python, grow the global community of Pythonistas and make PyCon US 2022 the best yet in person again at long last, and there's links there to donate. Lastly, for this section, with the help from Paul C, the community is revitalizing the awesome CircuitPython repo. Community members are invited to review the awesome CircuitPython page and suggest additions, changes like articles, podcasts, via poll requests or noting in an issue. Check that out at github.com slash Adafruit slash awesome dash CircuitPython. As always, this is a preview from the CircuitPython weekly newsletter, which is a CircuitPython community run newsletter emailed every Tuesday. The complete archives are at adafruitdaily.com slash category slash CircuitPython. It highlights the latest Python on hardware related news around the web, including CircuitPython, Python and MicroPython developments. To contribute your own news or project, edit next week's draft on github. You can go to github.com slash Adafruit slash CircuitPython dash weekly dash newsletter and check the draft folder there and submit a poll request, which you can edit by clicking the pencil icon with the changes. You may also tag a tweet with hashtag CircuitPython on Twitter or email cpnews at adafruit.com. Oh, and a late breaking news story. Thanks to Melissa for pointing this out. It is CircuitPython Monday at Adafruit. You can use the code ADATY. I assume that's Ada, thank you. To get 20% off CircuitPython category items and 15% off items store wide. So that's a update just for those folks that are listening live or listening today on Monday the 29th. Thank you, Melissa. Okay, let's go to our next section here. The status of CircuitPython libraries in Blinka. This is a statistical overview of the health of the projects. It's meant to ground us in some numbers so that we're not just thinking everything's going well, but we can actually see some numbers that we think are valuable and how it's going. So let me start with the overall numbers. So overall we had 20 pull requests merged from 17 different authors, which is awesome. So names I don't really recognize or maybe pretty new are Pixel Clay, Ginger Industries, Liss Apple are all new authors. So thank you to those authors. We had 10 reviewers for those 20 pull requests. So thank you to all of the reviewers. We couldn't do it without you. So thanks to the reviewers. Issues-wise we had 15 closed issues by eight people, 14 opens by 13 people. So we're net down one, which is great. And a good number of people that are involved as well. So now for the core. In the core we had 12 pull requests merged. I won't read off the new folks because a couple of those are the same. We had 11 different authors for those 12 pull requests and we had five reviewers. So thank you to all of our reviewers. We have 11 open pull requests where the oldest is 86 days old. And then it's kind of a few every 10 days or so. And we have one that has just been opened. So if you want to check those out, you can go to github.com. Such data fruit slash circuit python slash pull and check it out. Those are the open pull requests. That's why reviewers are awesome to help get those completed and merged in. Issues-wise for the core, we had 10 closed issues by three people, four open by four people. So we're net down six, which is awesome for a total of 453 open issues. We keep track of triaging issues and prioritizing issues through the milestone system on github. We have six active milestones. The most imminent one, the one that we want to finish the quickest is the 7.1.0, which has one open issue. We have 22 open issues for 7.x.x, which are the things that we think are relatively important, but may not get to immediately. And then we have seven open issues on the 8.0 milestone, which is the stuff that we need to change when we do a major release version. And we have zero issues not assigned to milestones. So that means we've gone through everything. That is it for the core. Let's kick it over to Katnie for libraries. Thanks, Scott. Thank you. So this is the library section. It covers all of the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore circuit python underscore and a couple of extras. So across all of those repos, we had eight pull requests merged from six different authors and six different reviewers. And all of those PRs that were merged were one or zero days old, leaving us with 67 open pull requests. There were five issues closed by five people and nine open by eight people, leaving us with 642 open issues. 258 of those are labeled good first issue. If you're interested in contributing to Circuit Python on the Python side of things, go to circuitpython.org slash contributing. You'll find all of this information and more. You can search the open pull requests. You can search the open issues. You can search them by label. Good first issue is a great place to start if you're new to everything and bug or enhancement is good if you are looking for something a little more complicated. If you wanna get started reviewing, take a look at the open pull requests. If you have the hardware, test it. If you don't, you can take a look at the code and let us know what you think. Leave a comment and once you're comfortable with that, we can look at leveling you up to joining the review team. In terms of library updates in the last seven days, we had no new libraries, but a number of updated libraries, which I will not read off. So overall, an issue was found with Read the Docs, early hug report to FOMI guy for finding it and fixing it, but it has been resolved. I'm continuing to see folks contributing updates and fixes to libraries, thanks to everyone who's been contributing. Things may slow for a bit over the holidays, which is expected, but if folks are finding that they have more time, please feel free to submit whatever you like. We will still be around, so we'll be able to help you out and review your code and so on. Because I know for some folks, it actually means more time versus for others, it means less time. So whatever works for you, and that's what I've got. Thank you, Katnie. All right. Next up, we have Blinka. So let's ask Major Melissa for an update on Blinka. Blinka is our MicroPython and CircuitPython compatibility layer for Raspberry Pi and other single board computers. And this week we had a zero pull request merge. We currently are at five open pull requests. There were zero closed issues and one to open by one person. That leaves 65 open issues amongst all the repositories. And there were 14,377 PiWheels downloads in the last month. And we are currently supporting 77 boards. And that's it. All right. Thank you, Melissa. And that is the state of CircuitPython libraries and Blinka. The next section we have here is HuggraPorts. HuggraPorts is a chance for us to say thank you to the folks in our community for the awesome work that they're doing. This is the first of two round robins and we are slightly changing today how we do round robins. I will start and then we'll stop start at the top of the list and go through. So just as it is in the note stock, what we used to do is start with the host and go down kind of like the next person alphabetically after them. So we're changing it just a bit. We'll always, after the host, we'll always start at the top of the list. And the note stock will mirror that. So let me start. First, HuggraPorts.DNH for the Broadcom PR review that this PR I did last week. Thank you to Microdiv for the ESP 4.4 updates. Hopefully get that in soon. And lastly, thanks to Gambler for the PIN changes reviews that happened over the weekend. So thank you for taking a look at those. Next up, we have Charles. Well, first of all, a group hug to everybody because I don't know what else to say but I very much appreciate and I enjoy listening to all the things that are going on in this group. Thank you very much. Thanks Charles. Next up is Dan. Okay, thanks. I'd like to thank Ann and Lady Aida who reviewed the additional version of the ASYNC IO Cooperative Multitasking Guide. That's now live. I'll talk about that more in later. And a Thanksgiving group hug to everyone. It's past Thanksgiving, but I am thankful for the community. Thank you, okay. Thanks, Dan. Next up is Deshipu. Oh, sorry. Can you hear me? Yep. Okay, so group hug because I haven't been able to attend this meeting for a long time. So there was a huge amount of awesome work done in that time. And specifically thank you to Dan for the USB CDC data serial because it's working very well with this type. And thanks to Jeff Epler for the camera support that I am now testing. Awesome, thank you Deshipu. All right, next up is Foamy guy. All right, thanks Scott. This week hug reports for a user on Discord TBJures, I'm not sure exactly how to pronounce it but I've got their name in there who started working on and getting interested in display IO widgets. So I'm always happy to see folks getting interested and involved in that as well as I also had a good conversation with them about possibilities for making the board module inside of the stubs a little bit more helpful with some pins which I'll talk about a little bit later as well. GitHub user RS Bone who left some really thoughtful reviews on a couple PRs that I've been working on recently. So I really appreciate all their work looking over stuff and offering up really good suggestions to Deshipu and AT Makers Bill who both provided a lot of help and guidance to me while I was working on troubleshooting something in the core with GDB for the first time could not have done what I did without both of them. Maker Melissa who pointed me in the right direction on a question I had about the pallet object in Blinka Display IO to fantastic Dan, a GitHub user who pointed out some possible improvements on the awesome Circuit Python page and where it gets mirrored on CircuitPython.org mostly around mobile layouts and how to do things a little bit better to make them appear nice on mobile. They reviewed a PR that I put in to do one of them they also did some of the work themselves and submitted a PR to do another fix as well which I got stucked on so I appreciate them. And then lastly to Ginger Industries on GitHub who added some new functionality to the grid layout in the Display IO layout library they made it so that you can change the color of the divider lines which is really cool new feature and again I always appreciate seeing folks getting involved in Display IO stuff so a huge thanks to them as well. Thanks. Awesome, thank you for the guy. Next up I've got notes from G3 holiday who says a group hug and a hug to Arduino for 10 million unos. We probably wouldn't be here without all of the success of the Arduino Uno. Okay, next up is Jephler. Hi, just finishing my notes trying to figure out what I want to say. First of all a group hug because I've been away for a couple of weeks and I miss you all. And then a hug to a couple of community moderators who helped me understand something that was a harmless pop culture reference. I didn't know what was up because I do not understand jokes. And lastly I also want to give a hug to Microdef for the ESP IDF upgrade PR. It is very much appreciated even if I wasn't ready to merge it right away. The PR is good it's just we don't want to make a trade off right now unnecessarily. And yeah, just want to make it clear that we appreciate what you're doing. So thank you. All right, thanks Jephler. Next up is Jerry. There's your unmute. Yeah, thanks to you Scott for getting the Broadcom support up and running. Looks like fun. And that group hug to everybody. Thanks. Yeah, I was thinking about this like what can we do in circuit Python if we had like multiple gigs of memory. All right, next up is Katnie. All the things. Right. All right, first up a hug report to Criella for helping me with organizing all of my Adafruit hardware and designing and 3D printing dividers for my containers that didn't come with enough to fill the entire thing, which was incredibly annoying. I'm not half of the containers came with enough. The other half did not as though they just expected you would have larger items. It was frustrating. To Dylan for learning how to do pretty pins diagrams and working through her first set of them to Lady Aida for helping out with reviewing the AT tiny pretty pins diagrams that Dylan was working on. I do not know those boards well enough to know when things are wrong. I can tell whether the layout looks good, but that's about it. And when Laura's been doing the reviewing on those and that's been super helpful to FOMI guy for finding an issue with read the docs on the libs and pushing a fix to the bundle to Phil for PT for being on moderation duty over the holiday weekend. We did not have any issues, which was excellent, but we had somebody prepared to deal with them. So the rest of the moderators wouldn't have had to deal with it if something did come up. And a hug report to Jepler for swapping running the meeting with me later in December. Turns out it worked out for both of us because we both needed those exact dates switched. So bonus, but thank you for doing that and a group hug. Awesome, thank you, Katnie. Next up is maker Melissa. I just wanted to give a group hug to everyone. All right, thank you, Melissa. Next up, we have notes from Mark who says a hug report to Dishapoo for some info on Python tuples versus lists versus arrays. And that's it for hug reports. Thank you all for participating. Next up is another round robin. This time it's status updates. Status updates is a chance for us to spend a little time talking about what we've been working on and what we plan on working on in the coming week. So I will start and then we'll go through the round robin again. So first up for me, the Broadcom port was merged in and I added ice grid C support kind of at the last minute. What I need to do this week is kind of fully flesh out pin in use checking and full pin muxing. I was kind of like waffling on how I want to do to do all the pin muxing stuff, but I think I've decided. So I'll be doing that this week. And then I also want to add SPI and UART support for all of the different combinations that it has. Particularly the Pi 4 has a lot of different spies in UARTs. So I want to kind of like do all of that more properly than I'm currently doing it in the Broadcom port. And then I also want to add the Broadcom builds to circuit pipe down to org slash downloads and drop a line to the Tom's Harbor folks and start to get people testing it. Even though it's not perfect, it's still very alpha, but I think it's time that people can test it. So I just realized I did not put a time code for myself, but I will do one for Dan and keep going. So go ahead, Dan. Okay, thanks. So as I mentioned, I finished the initial version of the co-offered multi-tasking guide using async.io. There are a bunch of simple examples in there. If you'd like to please try it, it's especially meaningful to try it instead of just reading about it. So it's just blinking LEDs. It's really easy to wire up. So the next, I have a bunch of things to continue working on this guide and async.io in general. There are some problems with task cancellation and handling interrupts properly, which I need to debug. And then I'll write some examples about how to do task cancellation in the guide, add some more pages, which are empty right now. I'm going to look at some devices that have interrupt pins and show how to kind of do soft interrupts with those pins, like an SCD-30 carbon dioxide sensor, and there's some other ones. There's a gesture sensor too also. We'll look at some NeoPixel task examples. The NeoPixel library doesn't really need async.io, but it's actually easier to code with async.io tasks. So I'll show some examples of that. And then finally, as we need to do, we need to get back to doing just some regular 7XX bug fixing so that we can get some more releases at. Okay. Awesome, thanks, Dan. Next up is to Shippu. So I've been trying to figure out this bug I found with PyGener and PyPort, where it basically prevents people from using stage on it. And I traced it down to the reinitialization of the displays specifically to setting the backlight. PWM, for some reason, it's stuck in a loop when it tries to change the PWM value waiting for sync. No idea about that. So if anybody has any ideas about this and any suggestions when come. And second thing, I was trying to get the cameras to work using less tutorials and code. So far, I made my own breakout board for the camera and instead of 1.2 volt, I used a 1.5 volt regulator which turns out doesn't work. Probably I have fried the sensor. So yeah, now I'm waiting for more parts for it to use proper voltage and we will see again. That's it. Thanks, Shippu. All right, next up is foamy guy. All right, thank you, Scott. So this past week, I attempted to do some troubleshooting on RP2040 devices with an issue that I noticed around NVM which was definitely a fun experience. It was my first time trying to use GDB to debug things in the core. I found some stack choices that lead into what I think is assembly code possibly, but it's definitely a bit over my head. I'm not really sure what to do with what I found but I did leave all the information that I did get out of it on the open issue for that problem. So if anybody else set up in the future, there is some extra stuff in there now. I did some thinking about different ways to add pins to the board module in Circuit Python stub. Right now in the stubs, we do have a board module but it pretty much has only the buses, I think, like spy and ITC and UART maybe, but there was some conversation this week about trying to add pins into that so I got a couple of ideas around that that I've put to discuss later in the weeds. Added a new feature to grid layout called the cell anchor point feature which is allowing you to choose where your content goes within the cells, basically. If your content is smaller than the cells, you can anchor it to the center or the top or the bottom or whatever you want with this new feature and then I resolved a small difference in behavior of the pilot object in Blinky Display IO versus the core, although I do need to follow up on that PR and do another quick change on it. And then this week, I'm not entirely sure what I'll get into but the one I do know for sure is kind of getting myself back into the core and trying to add a width and height property getters specifically I'm most interested in to tile grid so that things can check the height and width and pixels to make it easier to center tile grids and other things. Kind of goes along with the grid layout work I did and that's what I got, thanks. Thanks, foamy guy. All right, next up we had notes from G3 holiday who says, took a little break for Thanksgiving but resuming today. Next up is Jepler. Hi again. So my time has been a little spotty recently between Thanksgiving and doing a little travel. This week will be normal but more travel is in the works during December. So I did fix some bugs. Those would be up in the closed circuit Python issues if you're interested in finding out what they were. I'll continue to fix bugs. In the internal meeting, we discussed some problems with spy and we thought maybe there were two issues but the only one that we were able to find was one with RP2040 and SD card. So that is what I'm gonna look at number one. And then when I need a break from coding I have a microcontroller free 3D printed lamp project and that will end up turning into a guide on learn hopefully sometime during December. And yeah, that's what's next for me. Thanks, Jepler. Next up is cat knee. All right, so last week, actually this is before last week I don't remember when it was but I hadn't mentioned it. I updated the pretty pins read me and it now has more thorough instructions on creating pretty pins diagrams. Thorough enough that the idea is that anybody should be able to do it. So if you happen to work through it and find something missing, please file an issue on the repo or let me know directly. And also it's probably worth asking whether or not the diagram has been done because there's a number of diagrams that are already finished that we just haven't posted yet. If you decide you wanna do it. So actually last week, created a new analog in template for non-standard A-Ref boards. The templates are designed to be very board specific so that you're not reading through a guide and seeing how to do things on four other boards. And it turns out that there are a few boards including the new Feather ESP32-S2 that have a non-standard A-Ref because it's non-linear beyond a certain point. And so they just stop providing infobia on that point. So it doesn't go all the way to 3.3 volts is what I'm getting at. And the template shows it going all the way to 3.3 volts. So instead I had to generate a copy of that template that allows you to enter whatever a specific voltage and a specific analog number, analog value rather from the pin. And that will go into both the ESP32-S2 also probably S3 and the N-R-F boards are also non-standard. So it has more than one use, which is good because that's the point of templates. I adapted and simplified an A to Fruit IO example for Feather ESP32-S2. And actually that is a hug report I forgot to give this to Jerry for giving me the code to start with. I've never worked with A to Fruit IO. And so I would have been floundering and instead I had a completely working example that all I needed to do was simplify it. So that was super helpful and it's still running. I wanna say for five days and I'm only down to about 50% on a 400 milliamp hour battery. So putting it into deep sleep for 10 minutes, I think. And then running the code. So that's pretty good, I would say. And then published the ESP32-S2 Feather guide partially completed, but the core of the guide was done. So folks needed a place to start. There were people starting to ask a lot of questions about pinouts and so on. So we wanted to at least get the guide out there. So this week I'm gonna finish the Feather ESP32-S2 guide. I'm gonna be working with Ann to get her spun up and adding CircuitPython Essentials templates to board guides. It's relatively easy and now I get to find out whether the instructions I wrote in the templates are good enough for somebody else since I'm really the only one that's been dealing with them. So my own instructions are obviously clear to me. So we'll find out how that goes. And then also the KB2040 guide is next. And this past weekend I ended up with an entire garbage bin full of Adafruit packaging as I went through nearly everything here and I have it organized into divided containers. My takeaway from this is Adafruit makes a lot of temperature, humidity and pressure sensors and I have a lot of Circuit Playground Blue Fruits. And finally I wrote a new post on my site, catney.com. How do I get into programming? It obviously does not cover all of the possible ways you can get into programming, but it does cover how I got into it. And then talks in detail about how that can work for you if indeed it is a path that would work for you. So that's what I've got. All right, thank you, catney. All right, next up is maker Melissa. Hello. Yeah, so I had a short week this last week. I started on a guide on a non-check control blazer and this week I'm planning on finishing it and I'm not sure what else yet, so that's a format. All right, thanks, Melissa. And last up we have notes from Mark who is lurking. So I'll read those off after I take a time code. Mark dove deep into the core, found a native class cannot be a subclass of another native class. Exceptions are an exception, no pun intended. Determined how to use PixelBuff with the IS-31 and going to start working on it. And I need to look at releasing a library with the IS-31 LED maps. Thank you, Mark for looking at that. All right, that's it for status updates. Thank you to everybody for chiming in on that. Last up we have in the weeds, which we haven't had a lot of topics in the last few weeks, but we have a lot this week, which is awesome. So the way this works is that in the weeks is just longer form discussions. We have a number of topics listed. If you have another topic for in the weeds, please just add it with your username to the bottom of the list. We'll kind of go from one to the next for that. And we'll start with Jeff here. All right, I hope my mic is working again. Am I here? Yeah, I'm not here. I can hear you. Okay, good. All right, so I'll actually start with the item I deleted, but in a slightly different form. That is we have added to the calendar a meeting on I think it is the 27th of December between Christmas and New Year's. We debated internally about whether to have this, but there are high chances we will have a special guest. So hope you can stop by that weekend or that Monday rather between Christmas and New Year's. But then what we really want to talk about or what I want to talk about is this poll request, 5615 that adds the ESP 32S3 and C3, but the part that is salient to me is there's a regression in the support for RGB matrix and the poll request would just turn it off for ESP 32S2. Phil B, who is the Adafruit person who wrote the Proto Matter library that powers RGB matrix was looking at the poll request to update IDF there in Proto Matter. And I'll let you read what he wrote on our internal Slack in the document itself. But basically it looked like there's something about timer interrupts that is just broken in the 4.4 ESP IDF. So basically that makes me really reluctant to merge this before 710 goes out as stable if we're releasing 711 from the main branch. And I want to open the discussion to what are the alternatives? I know we talked about some in the internal meetings so maybe Scott, you want to pick it up from here? Yeah, I think the alternative I was talking about was if we wanted to merge this as three-step in but not have it in 711, we could actually create a branch for 711 because there's only, I think I suspect a few issues that we want to get fixed before 711 is stable. And so I think one option for us is to merge the S3 stuff with the Proto Matter regression kind of temporarily and that will go, but that will be released post 711. So then that version would become 7.2 or 8 or something higher than 7.1. Correct. Even though 7.1 doesn't come out yet. Right, right. So the main branch would be post 7.1. And only people who, sorry, go ahead. And we could even tag it like 7.2 alpha zero just so that the builds get marked as such. And only the people who were preparing PRs to fix bugs in 7.1 would need to do anything different than they do with their workflow of four requests now. Right, and I suspect that's a small number. A small number, right. Cause we talked about just having a handful of bugs that are really 7.1. Right, that's my theory. Anyone else who'd like to chime in? Right, the reason to merge in this, the 4.4 stuff is so that we can fix it. Yeah. Fix it in the main branch rather than having to rely on micro-devices. Yeah, we don't want that pull request to get stale if we can avoid it. Yeah. I think you probably know a little better than me the steps to go through on Git and GitHub to do that. Can you do that? Make the branches and the tags that you were... I can do that, Dan. And also, Katni notes that it would be nice to have another release soon so I can make a branch at that time. That sounds good. All right, well then, I guess, I mean, Katni's topic kind of follows onto that, so take it away. All right, so, sorry, I tried to open another program and now it is popping up in front of me. So basically, there was a pin rename on the Feather ESP32-S2 from I-squared-Z-Power to I-squared-Z-Power inverted and it is not in the current beta and the guide is live with code that uses that pin. So there is code in that guide that does not work and there's about to be a lot more code in that guide that does not work unless you're using latest and I really don't want to put a caveat all over the guide saying please use the latest version and then have to go back and remove it and all of that. So I had talked to Dan last week already about doing a release and he said he could do it early this week. So it kind of needs to happen as soon as possible. I don't particularly care what type of release it is regarding beta, alpha, release candidate, whatever. I just need something on circuitpython.org slash downloads that actually shows up as a link. So I will, after this meeting, I'm gonna take a walk and then I will work on the next release and get it out by tonight or tomorrow. Okay, that's perfect. And it'll have in it what it has in it. I don't think we won't wait for any new bug fixes or anything. Have you started the note stock because I should probably add a blurb about the Broadcom port. No, but you can just send me the text that you want and I'll, I don't edit it on GitHub anymore because GitHub still has a bug where it duplicates parts of the release notes. It's really strange. So I just edit it locally. But yeah, just give me some sentences and I'll be happy to put them in. Okay, all right. I'm gonna, I wanna update the circuitpython.org with that stuff too. So it'll be kind of all the same, like warnings about, this is really early. Right, this is alpha, alpha. Yeah, alpha, right, or something, yeah. Yeah. What is the letter before alpha? Okay. It's alpha, alpha's fair, I think. Right. And that's all I had. I just, I needed to make sure that that was going to happen so that I don't, I needed to know what I could do with the guide. So that is my thing. Thank you. Yeah, it's good. I think we need to get releasing more often. Like after we got 7.0 out the door, we kind of had a bit of a lull. So I wanna, I'd like to see us pick that pace up a little bit and Dan's been doing all of them. So thank you, Dan. It's fine. I don't mind actually, because I'm picky. Sorry. All right. Okay, we have a plan. So next up, let's go to FOMI guy. All right, thanks, Scott. So this came out of a discussion I had with TB jurors. There's a thread that's under the help with room and discord here if folks are interested in reading a little bit more of our discussion. I'm not entirely sure how to link it, but I'm gonna figure that out afterwards maybe. The gist of it is though, we wanna try to add some more helpful information to the board module inside the circuit python stubs. Right now I think it has, I wanna say just the buses. I'm not looking at it right now, so I don't remember for sure, but I think it's like I2C, SPI and UART and that's I think the only things in there. But it'd be really great to have pins in there as well. But of course that presents a problem because not every device has the same pins. So kind of the, I think suggestion that we've landed on to start with is trying to add every possible pin from every possible device. So essentially basically parse the files inside the core and just compile a list of all the possible pins and then add those to the board module PYI file so that no matter which board someone is using they'll have a list of all the pins. This is not necessarily 100% the best possible outcome because then it does necessarily mean some folks like they might be using a board that doesn't have a particular pin and the IDE is still gonna suggest it for them. A way to go kind of above and beyond maybe is provide some other tool like a command they could run or something they could do to try to specify a device and then once they do that it will kind of shave it down to just a specific device's pins. I don't have as much of a clear idea on how to do that but we did find some code in, I think it was in a VS code plugin that existed at one point or possibly still exists where they actually wrote some code that does this. You kind of pick out a device as far as I understand it and it does parse the core and then find all the pins for that board. So there is some code floating around out there to do that but I wanted to get input from other folks both on the idea of putting all the pins in there and see if anybody had other ideas on how to try to make it specific and really the main thing I'm concerned with is if anybody can think of kind of unforeseen sort of downsides to including all the pins. I definitely don't, I know it will end up misleading folks because they will see pins that might not be on their device but I'm looking to see if that's like possible to create a real bad problem or not. So I don't have as much of a background in the electrical side of things. So I definitely don't wanna do it if there is any possibility that somebody see in the wrong pits could somehow bribe their device or anything bad like that. So I wanted to open it up and see if folks had ideas about those things. I'm not sure whether this is a good thing or a bad thing but if it actually goes in the PYI files I think that means that the documentation would also include it, the read the docs. So that's worth considering. I don't know if you could do something similar to the support matrix where you would actually keep track of which board has the pin and put it in the doc string that you would create. So we could say, D4 and then the doc string is available on these boards colon and then a long list. That would be neat if it could include, I hadn't thought about that. That would be really nice though if it could also include which boards have it that way they would still be listed. They would at least have a note that lets them know. Which ones are there? I do like that idea. That makes me think of how Python documents like the OS specific APIs it has. I think it's also like available on this platform. What is this in that you're trying to have it show the pins? It's basically in the IDEs essentially. So like I use PyCharm but I believe like VS Code would be able to make use of this as well and really any other IDE. I don't have much experience with them but basically if you were writing your circuit Python code in PyCharm or some other IDE and you type like board. And then it would give you a list of pins that are available. So you could do like board.d or something and then you would get a list of numbers that are actually valid pins on certain devices. Okay, well here's an idea then. You could do it where you could choose your board but to narrow it down to even a smaller selection maybe you could detect like the VID and PID for the of the USB device in order to narrow it down to maybe a few boards that use that. I don't know for sure if the, well so one option maybe is changing the board module in the stubs. I don't know if it can be actual Python code but my understanding is PYI code it can't necessarily run things. So I don't know if it could see the USB port to discern that but that would be really slick as well if it could or if that could be changed over to an actual Python file and it could try to look up the board that's currently plugged in. That would be really cool also. Yeah, also I think if you're editing on a board itself there I think it's a board.txt file that appears on there which has some information as well. I'll have to look into that. We've seen that before. Huh? The bootout.txt has the board. Yeah, that's, I think that might be what it was. Oh yeah, yeah, the ID is in there now which is quite helpful. Right, then we go ahead and we have to look at the PID vid so the vidpid. And then they can have it automatically selected based on that possibly. Yeah, that would be really cool as well. I think the challenge is just what ID's are capable of doing for stubs. Right, like maybe we don't ship it as a stub we ship it as a proper Python file and then that runs under the environment and so you could set an environment variable maybe. Well, I like that idea as well. Yeah, that was kind of where I was getting to is it in my head at least it was kind of like I think there's probably a lots of things that it could do but it may end up needing to be not UII. It may need to be installed as a more traditional Python module. Right. It could ship alongside the stubs as a separate install or something like that. And then folks would be able to do it and set the variable or however we want to make it instruct them or if it could be automatic that'd be awesome too. Yeah, I don't have a lot of background on it because it's really dependent on what the ID's can do. Okay, I'll play around a little bit. I think the sort of the lowest hanging fruit is trying to include everything and that gets us further along than we are today because you'll at least see the list of pins. And I definitely really like the idea that Jeff mentioned of trying to note out which boards have which pins. So then when it popped up it would also give you that little blurb I think. So you would see like D4 and then you'd have a list of boards. I think that's probably a good first step maybe and then from there you can try to figure out how to enhance it to actually be board specific. Do you think that it would be too wordy just to put, I was gonna say you could list all the boards for each pin but maybe that's kind of excessive. I guess it would, especially on the common one, so it would get to be kind of long. Might be difficult to actually end up reading, wouldn't it? I think at some point you say what boards don't have it. Yeah, I don't know. I think it's worth exploring so thank you for taking a look at it. Okay, yeah, for sure. Thank you for all the great ideas and input from everyone, I definitely really appreciate it. Let's do our last topic from Jerry. Yeah, so I was just trying to play a little bit with the Broadcom stuff and actually most of my original questions already got answered, so. But, and Jeff pointed me to where I can find out about, apparently I do need to get a special version of NKFS.fat. But once I've done that, and if I finally, I get a build to create, it creates a bunch of files or if I go to S3 I can find some files that are out there. How do I actually use them? Yeah, so the Broadcom port generates two different files. It does a disk.image.zip and that is a full disk image, very similar to any of the other disk images you would have for Raspberry Pi. So you can open that in Imager, Raspberry Pi Imager. You can do it in Belina Etcher. What that will do is they can open that zip file. You don't even have to unzip it because they will. And that will image your SD card. And the way that I have it working is that that disk image actually only has a single partition in it. It has the partition table and then a single partition that is like a 255 megabyte boot partition, just kind of like what Raspberry Pi OS would do. And then what CircuitPython will do is it will actually see that when it starts up, like we normally do on Spy Flash, we check for the file system. Well, the Raspberry Pi, or the Broadcom port will actually check the partition table. If it has a single entry, it will make a second entry for the remainder of the SD card and then kick it over to the regular flash formatting stuff that will start kind of at that second partition. And so if that second partition already has a file system that like the partition table didn't see because it got overwritten, it will just reuse that file system. If there's no file system there, then it will create one. And so if you use the disk image over and over, it's possible it may not work because at least the Raspberry Pi imager tries to erase the entire SD card before doing it. It turns out mine, the way that it's working, it says a message like, oh, I can't erase the whole thing, so I'm gonna erase the first megabyte and the last megabyte. And so the second partition, I make it a megabyte too short as well. So it should be like preserved in that case, but you can't rely on that. So that's the disk image. And then the other image that we create is just a kernel 8.image file. So once you have a disk image, what you could do is you can rename the kernel 8 version and just replace the existing kernel 8.image on your SD card to update CircuitPython, because CircuitPython is entirely contained in the kernel 8.image. Okay, so you could, you could just copy that over if you make anyone build. Yeah, yeah. Okay, so, and just off-hand, are there any other things? So right now what I have is it runs through, it gets through the build, and then it tries to run this mkfs.fat and it fails because it doesn't like the offset. Right. And I assume that if I get the right version, that'll pass. Yeah, so the challenge that I had with making the disk image is that the old way of doing it was like mounting a loopback device and that requires sudo. But it turns out in the newer version to make FS for fat, which is part of DOS FS tools, in the latest version, they've added a dash dash offset, which allows you to say in this file, the file system starts at this offset. Okay, and that sounds great. Just looking at the, Jeff had pointed to the workflows file. So you just download the source for DOS FS tools, build it, and then install it on here. Yeah, that's what I do for the CI. I've run Arch day to day, so it already had the new version, so I only had to figure that out once I updated. And I think actually the latest Ubuntu does have new DOS FS tools, it's just the LTS version that doesn't have it. Oh, I see. So I tried to look for a back port, but I couldn't find it, and I was just like, the simple is like, it's not a big build, it's not a big repo or anything. So it was like simplest to just make it every time. Okay, and you have any problems with it causing any problems for other things you're doing? It's backward compatible as far as you can tell. Yeah, yeah, I mean, like on the CI, I'm not installing it anywhere special. And then on my regular box, it's, I mean, it's just for making fat file systems, so. All right. Okay, thanks. I assume things get better. Try to play a little bit more. Yeah, so I think the Pi 4 stuff is pretty solid, but the USB on the Zero 2W is not particularly stable. It's, it's. Clearly, there's no, there's no, there's no, no, no place to get this information other than asking questions at this point. It's not, I couldn't find any description of how to, how to build or do things for this yet. And that's, that's fine. So, but unless I'm missing there, if there is a place where some of this is available. There, there's not really, like I've been talking about on my deep dive, but I know that's not a good resource. Oh, okay. So maybe the notes for the deep dives could be handy. The work, the CI workflow is kind of helpful to, I know. Okay. But my plan is to, my plan is to do the CircuitPython.org stuff this week, like today probably. So we'll have the downloads, pages, entries, and then, and then I'll put some notes there, probably not on the building stuff, but at least like what the two file, what the two files we ship with are. And some notes about like, this is really early still. And like, like for example, I don't actually have the heap as large as it could be. Right now the heap is only 32 megabytes, which is a whole lot more than what we have on any other CircuitPython board, but it's actually not anywhere near what we could make it, since there are gigabyte size devices usually. So there's a little work to have to do that. And I actually saw a thing that the L2 cache only does the first gigabyte of RAM, which I think is really interesting. So I'm kind of curious to measure memory access times between the first gig and the subsequent gigs. Cause like, if it's a Raspberry Pi 4 with eight gig is a RAM, but only the first gig is actually in L2 cache, like that should make a difference. And yeah, so when you build the Pi 4, you don't tell it how much RAM it has. It figures that out from the board itself. It doesn't, you don't need to specify. Right, so that'll be the goal. Right now it just always does the 32 megs. So basically ignores the extra RAM. Oh, okay. So it's not using any, right? It doesn't matter then if you have a one gig, two gig or eight gig board. Right, right. Okay. So that's why it's just 32 right now. I mean, it could even be 128 and it would still work, right? Cause that's small enough to fit on all the boards. Um, but we do get, we do get an identifier that tells us how much RAM is actually fitted. So my plan was that we would have one, one build that would automatically know how much RAM the device it's on has. And the SD card stuff already will read how big the SD card is so that that should work. The file system should be the right size. Oh, thanks. I'm looking forward to exploring a little bit. Yeah. Thanks for picking it up. And I'll be doing spy ice grid C and UART this week, hopefully. So that should, uh, yeah, hopefully they only have like two peripherals for spy and UART, two different types of peripherals for spy and UART. But yeah, thanks for giving it a shot. And if you can magically figure out how to fix the zero two to help you, please let me know. Sure. I've looked at that in GDB a number of times and it's not at all clear what the problem is. I think it might be stack corruption somewhere. All right. That's it for in the weeds. I don't see any other topics. So I will take a timecode and do the wrap up. So this has been the circuit Python weekly for November 29th, 2021. Thank you to everybody who participated. If you want to support Adafruit and circuit Python and those of us that work on circuit Python, consider purchasing from the Adafruit shop at Adafruit.com. And as a reminder, for those of you listening today, there is a discount code for circuit Python devices from the Adafruit shop at ADATY. Thank you, Katnie. The video of this meeting will be released on YouTube at youtube.com. The podcast will be available in major podcast services. It will also be featured in the Python for microcontrollers newsletter. Visit adafruitdaily.com to subscribe. The next meeting will be held next Monday, as usual at 2 p.m. Eastern 11 a.m. Pacific. I'm like 99% sure of that. Yes, that looks correct. This meeting is held on the Adafruit Discord, which you can join by going to the URL adafru.at slash discord. To be notified about the meeting and any changes to the time or day, you can ask to be added to the at circuit Python nieces role on Discord. Just jump in the text chat and ask for that. And with that, we hope to see you all next week. Thanks for taking the time this week. Thanks, everyone. Thanks all.