 Hello everyone, this is the CircuitPython Weekly for June 28th, 2021. This is the time of the week where we get to talk all things CircuitPython. My name is Scott and I'm sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny computers called microcontrollers, so it makes it really easy to program them to code them. CircuitPython development is primarily sponsored by Adafruit, so if you want to support them in CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to the URL adafru.it.discord. We hold the meeting in the CircuitPython DevTex channel and the CircuitPython Voice channel. This meeting typically happens on Mondays at 2pm Eastern, 11am Pacific, except when it coincides with the US holiday. If the meeting time is changed, we'll notify you via Discord. If you wish to be notified about changes to the meeting, we can add you to the CircuitPython ESA's Discord role. There's also a calendar available that we try to keep updated if you'd like to subscribe to that. And note, next week is on Tuesday, not on Monday. This meeting is recorded. We record the audio from the Voice channel and the video of the text channel. If you would rather not have your voice recorded, you are still welcome to participate. The video of this meeting will be posted to YouTube and the audio is released as a podcast. If you find this podcast is not available on your favorite podcast service, please let us know. There is 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 us in the document. We'll read them off during the meeting for you. 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 CircuitPython DevTex channel on the Adafruit Discord every week, checked 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 a preview of the 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 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 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 part is in the weeds. In the weeds is an opportunity for more long form discussions. These discussions can come out of status updates or be something you've identified ahead of time as too long for status updates. And that covers how the meeting will go. With that, I'll get started with community news. And just to note, sorry if there's a fan noise in the background on my speaking. It is quite hot here in Seattle today. So I've got a fan to keep me a little bit cooler. OK, so community news. First up, thanks to AskPatrickW for adding this. CirCup 0.9.9 is out, which includes support for the new .mpy format in CircuitPipeOn7, tab-based autocomplete for library names, and support for the community bundle. Pip installs CirCup today. I thank you to all the folks who put that together. Next up, Texas Instruments answers questions on their new TI-84 plus CE Python graphing calculator plus an update. The calculator uses an AtSandy21 chip as the CircuitPython co-processor. In May of 2021, Adafruit saw that there was a fork of CircuitPython reported to be running on the new TI-84 plus CE Python graphing calculator by Texas Instruments. And they had to get one and did. Adafruit then reached out to folks at TI Education slash TI Calculators and asked if they could send over some questions to their teams and they said yes. See the questions and responses on the Adafruit blog. Plus, the calculator is running a fork of CircuitPython on an Atmel AtSandy21E18, which is the same chip as Adafruit Gemma's M0 Trinket M0 and many Trinkies. Next up, Adabox 19 is shipping in July, joined now at Adabox.com. The next Adabox from CircuitPython ships in a few days curated Adafruit products, unique collectibles and exclusive discounts, delivered quarterly, subscribed now and give as a gift. And also we should note that the product in Adabox 19 and most Adaboxes do run CircuitPython. Not totally out of whack here. Next up, we've added a keypad module, thanks to Dan, which has support for vector and matrix key scanning in CircuitPython. Dan has completed initial work on a comprehensive keypad module for CircuitPython. There's a GitHub link and also Adafruit blog slash YouTube link. The keypad module provides three different ways to scan a set of keys provided by the class's keys, which is one key per pin, key matrix, which is a row column matrix and shift register keys, which uses an external shift register to read the values of the keys. Key scanning is done in the background and includes debouncing. Key transition events pressed or released are put in a queue and implemented by class's event and event queue. Next in news. Microcontroller shortages projected into 2022. Shortages of microcontrollers used to run millions of devices worldwide are acute and projected to last into next year. Chips from microchips slash Atmel, Nordic, ST, and others are affected. Due to timing, the new Raspberry Pi, RP2040, and the ESP chips from expressive systems do not seem as impacted at the moment. The shortages have led developers to scour the internet for dwindling supplies. For chips that are unobtainable, some products are being redesigned using more easily available microcontrollers, which can be a costly hardware and software process. There's links to CNBC, EENews, Europe, Seeking Alpha, and Bloomberg all in this article. Two more. Camera support coming to CircuitPython on the ESP32-S2. Testing the ESP32-S2 Kaluga DevKit version 1.3 with the latest PR from Jeff to add native camera support to CircuitPython. In only a few lines of code, it can initialize a display, read a buffer from the camera, and then blit it out to the onboard 2240 by 320 screen. There are now libraries for both the OV7670 and the nicer slash newer OV2640. Amazing work by the team to get this so smooth. Last up for news, we have an online editor for CircuitPython. Team User River Wong posts about a CircuitPython online IDE, which is web-based, requiring zero software setup. This would be ideal for any computer, but especially for machines where installing additional software is not possible, such as libraries, public spaces, and on-school Chromebooks. There's a different blog, GitHub, YouTube, and try it out here, links in the notes. And that's it. As a reminder, this is part of the CircuitPython Weekly Newsletter. It's a CircuitPython community-run newsletter emailed every Tuesday. The complete archives are available at www.aderfruitdaily.com slash category slash CircuitPython. It highlights the latest Python on hardware-related news from around the web, including CircuitPython, Python, and MicroPython developments. To contribute your own news or project, edit next week's draft on GitHub by going to github.com slashaderfruit slash CircuitPython dash weekly dash newsletter, check the drafts folder there to see the latest draft, and submit a pull request so you can just click the pencil icon when viewing the draft there to edit right in GitHub. If you don't have a GitHub account or you can't figure that out, you may also tag a tweet with hashtag CircuitPython on Twitter or email cpnews ataderfruit.com. That's it for community news. Lots of great stuff. Next up, the state of CircuitPython libraries in Blinka. This is a chance for us to take a statistical look at the health of the broad CircuitPython project, and we do it in a few parts. First we'd like to look overall. Overall, we had 39 pull requests merged from 27 different authors, which is amazing. New names that are in this list, CD, MUHLB, MULB maybe, TWA 127, D Griswold, and a lot of the other names look familiar, so thank you to everyone for creating all those pull requests and getting them merged in. Speaking of merging them in, we had 11 reviewers who take a look at those PRs and make sure that they match the expectations we have for our code, that they work, and they look well structured and well written. So thank you to all of our reviewers, we're always looking for more folks. We had 29 closed issues by 11 people, 18 open by 10 people, so we're net down 11, which is great. So thank you to everyone who's taking a look at all of the open issues. It's really important to take a look at those. Okay, for the core, we had 20 pull requests merged, which is a lot. Thank you to our 17 different authors. We do do translations, so I suspect that translations were a non-trivial part of those 20, so thank you to all of our translators for keeping up to date with the strings that we add as we've been adding new stuff. We had five reviewers, so thank you to all of our reviewers for the core. Pull requests wise, we have 19 open pull requests. The oldest is 224 days old, which is a while, but I believe that we've actually whittled it down a little bit, or we're about to. We have a couple that we're outstanding for a while that thanks to higher effect for getting through those. So 19 is really good. It's great to be under 20, and a lot of these, let's see, one, two, three, four, five, six, seven, eight, nine, eight are less than a week old, so that's pretty awesome. So thank you to everybody for pull requests for the core. Issues wise on the core, we had 13 closed issues by five people, 14 open by seven people, so we're net up one for a total of 465 open issues. But we're keeping real close to pace. To keep track of how we're doing in terms of issues, we use milestones to kind of categorize importance, and we have four issues not assigned to milestone, which means they need to take a look at and be triaged. That's kind of high, but typically over the weekend we get those coming in, and we knock those out at the start of the week. We have 66 open issues for 7.0, which is a lot, and I suspect that we'll kind of shuffle those around as we whittle down our priorities for the 7.0 launch. Overall, we're still adding a lot to the alphas, so that's been really great. And please try the alphas, maybe we'll try to get one out this week, so people can try it, but lots of good stuff coming, and once the alphas settle down, we'll try to really drive home to a stable 7.0 release, because it's been a little while, and we don't want too much happening in 7.0 that's not really stable, because then we end up just asking people to use what we call unstable releases anyway. Okay, and with that, let me kick it over to Katnif for the library stats. Thanks, Scott. So this applies to all of the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore, CircuitPython underscore, and a few extras such as CookieCutter and the Community Bundle. So across all of those, we had 16 pull requests merged by 11 authors and 10 reviewers, and that leaves us with 40 open pull requests. We had 14 issues closed by seven people and three open by three people, leaving us with 306 open issues. If you're interested in contributing to CircuitPython on the Python side of things, consider going to circuitpython.org slash contributing. You'll find all of this information and more, including a list of open pull requests and a list of open issues. Search through the pull request, see if there's anything you, if you're interested in reviewing, search through the pull request, see if there's anything that interests you, take a look at it for syntax, that sort of thing, if you've got the hardware, test it, and leave a comment letting us know that you did that. It's a great way to get started reviewing, and once you're comfortable with that, we can move you into our review team. As for contributing code, check out the open issues. If you're new to things, good first issue is a place to start. Otherwise, you can check out bug or enhancement as labels for slightly more involved things, and comment on the issue and let us know you're trying it out, and then go from there. There is a guide on contributing to CircuitPython using Git and GitHub, so if you're new to that, don't let that intimidate you. We are always available to help, so you can ask questions on Discord and so on. This week, we had three new libraries, DisplayIO SH1106, OV2640, and Neo-Key, and a list of updated libraries which I will not read off. Overall, we're still working through the current open PRs. We're down to 40 as of this report, and we're still looking to get through the rest. We're keeping up with new ones pretty well, which actually I looked at it, we're keeping up with new ones very well, but there are still many older ones that need to be dealt with. If you're waiting on a reply to a PR and it's been more than one to two business days, please feel free to ping us. We may end up closing some of the older PRs that haven't had any progress on them, but don't worry if it's something you can get to later, you can open a new PR or we can reopen current ones. As well, most of the repos have been moved to main. I say most, I'm pretty sure it's been all of them, but remember if you're contributing to libraries, you need to ensure that your setup is up to date. The contribute to CircuitPython with Git and GitHub guide has a page on starting over fresh, which as long as you copy any current work out of your repo is the easiest way to update. You just basically delete your fork, delete your local version of the repo and start fresh. There is also information in that guide on manually updating your local setup and your remote setup. If you'd rather go through all those steps, there is information on how to do that as well, but we do recommend if you are just getting started or you haven't contributed in a while, the delete and start fresh is an easier way to go. That's where we are with the libraries. Thank you, Gattie. All right, next up, let's hear from Melissa about the state of Blinka. Hello. Blinka is our CircuitPython compatibility layer for Raspberry Pi, MicroPython, and other Singapore computers. This week, we had three pull requests merged by two authors and two reviewers. There are five open pull requests still and there were two closed issues by two people and one open by one person leaving a net of 58 open issues. There were 11,745 Pi wheels downloads on last month and we currently are supporting 75 boards and that's it for Blinka. Awesome. Thank you, Melissa. All right. And that's it for state of CircuitPython. My brain is turning to mush. Okay, Hug Reports. Hug Reports is done as around Robin, so I will start and then we'll go through the folks who added themselves to the note stock. If you marked it in the note stock as for me to read or you're not listening, I'll read it off for you. So first up for myself, Hug Reports stand for having the patience with my reviewing of the Key Matrix API. Hug Reports to MicroDev for getting the ESP-IDF 4.3 change finished and anecdote for testing. And as I looked back through the Discord, I just wanted to say thank you to Mad Bodger for helping on the Discord. Not the only person on Discord by far, but somebody just thought could use a shout out. And with that, let's circle around and hear from Ann. Hi, everybody. I attend these meetings, but oftentimes I don't speak because I'm still trying to ensure the newsletter is ready to be published, but I feel confident that this one is. It's really full of great stuff. And Scott let you know how to contribute. I mean, I really appreciate those people who have sent in their projects or tips or anything. Just tagging it on Twitter or sending it in to cpnews at Adafruit.com. It really helps me in ensuring I get you all the latest information and the information that's pertinent to what you're doing. So I'm still doing that. I'm ensuring your guides are all top-notch quality. A lot of Adafruit people are just making great guides. But I'm hoping to get back to some projects now that I've kind of got things under control. That's about it for me. Awesome. Thank you, Ann. Happy to have you back and participating. All right. Next up, we have notes from AskPatrickW, who says her report to Nerodoc and Les Samurai Proprès for their awesome work on CERCUP. Next up is notes from Sea Grover, who says group hug, Christian Walters, who says absent teaching a MicroPython course, which is awesome, says a hug report to Hierophag for picking up my languishing pull requests about set next code file and get previous trace back. I apologize for going MIA on this. I needed to break at one point and then the break got longer and longer and I got distracted by other things. No problem, Christian. I'm happy to have all the contributions anyway. All right. Next up is Dan. Okay. Thanks, Scott, for reviewing the keypad module, which he did when he was on vacation. We had an extensive discussion about the API and we seem to have settled on a good compromise and good for everybody. Thanks, Scott, for doing the initial version of the BLE workflow, which is file transfer right now. We're looking forward to the next batch of things, which is REPL over BLE. That'll be fantastic. This whole idea of a BLE workflow opens up a whole bunch of new work cases, which are used cases, which are going to be extremely interesting. Thanks to Jeff for reviving the idea of providing some kind of wraparound millisecond ticks capability, which is especially useful for boards that don't have long integers. Thanks to Great BIM, also known as a cranky turtle, for finding a problem with USB HID, the serial device is there, which when they sent large amounts of data, it just dropped things. I found some bugs in the buffer management code, which are useful for somebody to test that. Thanks. Okay. Awesome. Thanks, Dan. Next up is FoamyGuy. All righty. Thanks, Scott. First out this week to play Samurai Porpei for some help on bundle building issues that I ran into over the weekend, as well as found some other problems and proposed fixes inside a Blinket Display IO. Big thanks there to Jeff for continuing to make improvements on the Stubbs building process, Dan H, for working on that key matrix scanning that has been mentioned a few times. I'm definitely looking forward to playing with that on the macro pad once I get mine. To C.Walter and Hierfect and anybody else if I missed any that worked on that set next code file functionality, I think that's really a super cool thing and I'm excited to find some usages for that. I think that's a really great functionality. And then a group hug. Thanks. Thanks, FoamyGuy. Next up is Hierfect. Hitting all the buttons except the one that I need just to say group hug. Oh my God. No worries. It minimized my window and then, all right, anyway, yes, group hug, group hug this week. We're happy to hear from you. Thank you. All right. Next up is Jeff. Hello. First, I want to thank Damian and Gemma. They were commenting on a PR that I found with CircuitPython that is of interest to MicroPython. So that's exciting. I'll talk a little bit more about that in my status update. Thanks to Dan for some code reviews on the weekend. He's always around and if I'm doing something interesting, he's interested too and that really feels nice. Thanks to Matt Bodger and Lady Aida for taking a look at a PCB design of mine, offering comments and also making me think about it again until I spotted more problems. And this ties into one of my 2021 New Year's resolutions, which is I want to design more PCBs. Thanks to Ketney for some private advice. She helped me create a code of conduct in another community where I hang out. And I didn't initially have the courage to do that, but I got the encouragement I needed and so far so good. Thanks to Dylan and to Ketney again for some Aida Bot sleuthing last week, over the weekend. And I think again this morning there were just a last few things are figuring out about that. So it's important to see that maintained, but I imagine it doesn't feel very glamorous. And I just added a hug for Christian Walther. I wanted to say thanks for the initial version of some very interesting additions and a reminder to take breaks without guilt when you need them. The community will be here whenever you're ready to come back and we're happy to see you if you're dipping your toes back in right now. That's what I got. Thanks Jeff. Next up is Jerry. Hey, group hug. Awesome. Thank you Jerry. Next up is Ketney. Alright, so I have a hug report for Dylan for moving a few more repos to me, the main default branch, and for working on tracking down some issues that came out of those moves. To Summersoft for submitting a fix for a dependency versioning issue on Aida Bot. To Justin for helping out with an Aida Bot issue and finding what appears to be the fix, even though it was a bit obscure. It was something that Github probably should have caught and or been prepared for with the move to main, but it wasn't and I totally understand if they just didn't take into account the possibility of the situation that we created with Aida Bot because I've missed stuff too. To Laysamai Pupre, Jose David, ask Patrick W. Fomigai and Deshipu for providing input and suggestions on the cookie cutter PR for the Circuit Python Community Code of Conduct and to John Park for designing the Chromakey ring bracket for camera lenses and webcams. It's a really neat design and it works really well. That's what I've got. Awesome. Thank you, Ketney. Last up, we have maker Melissa. Hello. I wanted to give a hug to Laysamai Pupre for the batch of PRs over the weekend and a group hug in general. Thanks, Melissa. All right. Next up is a new section called status updates. It's done as a run Robin as well, but this time we want to hear a little bit about what you're working on, what you did in the last week and what you're doing on the coming week. Some people are more structured about that than than I am. OK, so first up. Billy file transfer code is checked in. So if you're running an NRF 52 A40 board, you should be able to, it'll advertise and you should be able to bond to it and all that stuff. Billy serial code is next. It's almost ready for review. This allows you to get access to the serial connection to Circuit Python. So seeing what the code output is and also being able to do the REPL if you wanted to as well. The next step is to help push one or more apps forward so people can use it. What platform would be best? Let me just say what platform in the chat. And if you put, if you want iOS, put an I, if you want Android, put an A, and if you want web Bluetooth, put a W or something. I'm just kind of curious. I suspect I'll be taking a look at web Bluetooth because that will cover a lot of bases and is not something that we're actively working on, although we got three A's. We will do Android eventually. We will do all three of these eventually. We are working on iOS actively. So yeah, we'll get there. And then next week I'm out. So Monday through Wednesday sometime, we're going out to the ocean kind of at the end of, at the end of the fourth of July weekend. So I will not be in the meeting next week. And then what I forgot to put in the notes or fail to is I'm actually recording a podcast, recording a podcast starting around Wednesday, which is the TalkPython with me podcast. And we're doing it. I'm doing it joint with Damian, which should be really fun. So thanks to them in advance for that. And I don't know what the lag time is, so I don't know how long it'll take until it gets out, but doing that this week. And yeah, Jeff says live stream on Friday. Yeah, that's my plan. I know I think Adafruit proper has the day off, but since I'm taking two days off next week, I figure I'll work on Friday. I think that's, I think that matches up with my partner's days off as well. So that's the plan. So we'll live stream on Friday as planned. And hopefully it won't be as hot as it is today. Okay. And with that, let's kick it over to Ann for our status updates. Well, I'm looking at my window waiting for the UPS person because my Adafruit macro patch should be arriving. And I watched Scott's deep dive on Friday and really caught the bug for wanting to make a really nice keypad and play around with it. I have some ideas and the community's making some great ideas too. So that's in my immediate future. Awesome. Yeah, I need to finish mine. Yeah. And I got that little, what is it? Paw pad key too? Yeah. It feels really good. I hope you stay cool, Scott. I will. I should put my partner is texting me pictures of the cats staying cool. Maybe I'll. Good. Oh. Okay. Yeah, it's okay. I'll post this kitty picture in discord. Okay. Getting distracted by cat pictures. All right, let me read off some notes. So from C Grover, we have still on the path to upgrade old Arduino projects to circuit Python. I have a working version of fake TV for engineers running on the Neo Trinkie as well as on the original Metro M4 based project chassis. I'm trying to come up with a new more descriptive name for the oppressive Pacific Northwest Omega heat dome. Friendly family friendly suggestions are welcome. Oh yeah, like C Grover, how hot are you seeing over there? Cause you're on the further away from lots of water than we are. Okay, Dan's up next. You all mentioned the keypad module was merged. I don't really see it. I don't know about that in a minute. And I'm working on a guide to explain the three different ways of scanning keypads and some simple examples. Various new bugs cropped up on the past week and I fixed them or at least recorded them. So just sort of keeping up, but there are still a lot of bugs in 7.0 that we either need to fix or push off. So we're looking at those in the future. Right now I'm debugging a problem with RP2040 PWM audio which you play away from several times and it stops playing. And it's not clear what's wrong at all now but that's another major thing I'm working on. It would be really great to have another release soon which would incorporate both keypad and also Scott's initial BLE work so people could play with it. So I'd like to do that in the next few days. One of the things that I need to change before we go, before we lock down the API for seven is to change USB HID.device so that it can theoretically support more than one report ID and an HID report descriptor. So maybe I'll try to make a change for that very soon so that we can at least get the API stabilized. Okay. Awesome. And I think I might try to take a stab at the PWM out API change for seven as well which is accepting the pin instead of a PWM, or no, pulse out. Oh, okay, yeah, that what you mean, yeah. Yeah. That would be good to get in seven as well. Okay, next up is FOMI guy. All righty, let's see, it's not quite ready. There we go. For last week, I completed the guide for the Rotary Trinky Brightness Crank that I showed on Chantel. I started work on a bundle repo for the CircuitPython org. I got the repo set up and I got the first library added but there's still a little bit to do. So I'll be looking to finish that off this week. And then smaller one, I made a quick PR to add the SH-1106 library to the bundle. And then for this week, I'm gonna be working on that bundle library like I mentioned for the CircuitPython org to, and then also working on moving over the last few widgets, including, importantly, one of the ones with subfolders. So it's like a package instead of a single Python file. And it turns out those are treated slightly differently inside the bundling process. So that'll be good to test out a part of the work on that bundle repo. And then I'll be looking into some of the Blinka display IO issues and a fix that came up over the weekend to test those out. And then the last thing is somebody mentioned, I think during the deep dive, asking about drawing arcs with display IO. And I thought that sounded like a neat challenge. I'll have to brush up on a bit of geometry to make it happen, but I'll be looking into a way that we can maybe add that to display shapes or something like that to draw arcs. So that's what I got, thanks. Thanks, foamy guy. All right, next up is Hierophact. All right, found the button this time. This past week I worked on implementing the deep sleep support for the find next file feature or set next file feature rather, which is important because deep sleeping basically looks like a reset as far as the chip is concerned, so it needs all sorts of special stuff to remember what the next file name should be. I implemented sleep memory on the STM32 and tested some sleep memory controls on other chips, but ultimately didn't get as far as I'd hoped to, so I'm gonna be catching up this week. I also got started on the exception carryover, not that of storing exception information across runs, but I didn't get too far into that one. This week I'll just be continuing that work, implementing some menu examples, and then once that's wrapped up, I wanted to do a quick implementation of the STM32 RTC module, which has been kind of conspicuously missing module, and finish that exception storage PR, and that's it for me. Awesome, thanks, Hierophant. Next up is Jepbler. Oh, I clicked over and started researching circle drawing algorithms, so I don't have my notes. Squirrel. Because that's just the sort of thing that traps me. Yeah, so last week I started on the text for this guide on the OB2640 and OB7670 cameras. I designed a keypad PCB and set it away for manufacture. This will be used in an upcoming project guide, but that's a ways out. Revision A ended up with some pretty obvious problems. I had set it because I felt like I was in a hurry, and that is always a mistake, don't do that. It can probably be bodged into working, but revision B, which has also been sent away from fabrication, hopefully fixes the problems. I put in a couple of timekeeping PRs over the weekend, two different approaches to dealing with time spans on the tiny boards that doesn't require rebooting to keep time.monotonic values small. And for myself, I continued working on a Python library for a module called the ES100, which receives the North American time signal. The library is pretty solid now, and it can receive the time almost every minute in usual conditions. So this week my top work is on the camera guide. I completed the photos this morning. I made a really good dent in the text. And where I'm at is this fritzing diagram, which I may share into the channel. It is just a mess, and it will be daunting to try to get it into something that is even useful to anybody. Anyway, so soon this ES100 library, I should create a cookie cutter version of it and add it into the community bundle, because this is a module that you can buy. For ticks, I need to see if a built-in ticks module with a couple of functions, add a number of ticks to a time, subtract two times, and check if a time is before another time or not. If that would fit into the flash space we have available. And then I mentioned this PR, I'll talk about it in the weeds. We have an idea for splitting up these internal objects called type objects. And it looks like it will save over one kilobyte of flash storage on our smallest boards, like the Trinket M0. So we'd really like to do it. We just need to figure out some details about how to move forward. So we'll talk about that soon in the weeds. And as for fun stuff, this weekend, I visited Sioux Falls, South Dakota, which is a couple hours drive away. High point, that is the most exciting point, was called the Palisade State Park. It's a small park, but with some lovely stone formations and a river flowing through it, I'll share a picture of that in just a second. So that's what I've been up to. Thanks, Jeff. All right, next up is Jerry. Let's see, I'll explain that, my picture in a minute. So last week was all spent playing with grandchildren, and a great time doing that. And next week is gonna be mostly recovering from playing with grandchildren. And I do hope to spend some time to dig into an issue that came up a couple of weeks ago with SDIO on the STM32, getting some errors. And I haven't opened an issue yet because I'm still trying to create a good example of the issue itself. But, and Jeff confirmed it, I guess, that it may be a known issue as well. So we'll deal with that hopefully some this week. And yeah, and the picture opposed to there is the baby birds have hatched in the bird cam birdhouse. So I'd buy the box to them. Cute. I'd go as far as I was in there. Awesome, thank you, Jerry. Thanks for the bird pick. Next up is Catney. All right, thanks, Scott. So last week, published the QT Tranky Guide, which also includes the newest template, which is I squared C for Circuit Python. So that will go into other guides eventually as well. I updated the MCP 9808 guide for the STEM a QT version. That was the I squared C sensor that we used for the template and realized that the guide had never been updated. Finished up the PR to create the Circuit Python Community Code of Conduct and Cookie Cutter. This was brought up by someone who pointed out that the Adafruit Code of Conduct was going into all community libraries as well. And it definitely was far more appropriate to have a more community-based code of conduct. So I had a lot of feedback on that, as I said in my hug reports. And we put together a community code of conduct that is more general, refers to product or project maintainers and things like that. So it's far more applicable to the libraries that it's going into, which is excellent. I updated the Adafruit Community Code of Conduct with a few things based on that PR and a suggestion from the community moderators on Discord. I added the NeoKey library to the bundle and fixed up the docs and so on that goes with that. Published the NeoKey one by four guide. So that's an I squared C breakout. That's four keys in a row. And I filed an issue on Circuit Python about renaming underscore pixel buff and or Adafruit underscore pixel buff to make them drop in replacements for each other. Dan and I talked about this. It may be worth talking about in the weeds. I'd like to see it happen in seven because the sooner it happens, the less we have to, less code and fixes and other things we have to deal with right now. Searching for those things on learn returns less than one page. And that to me is a good time to do it. So I would like to see that done sooner rather than later. Today so far, help track down an issue with Adabot not running the reports after the reports, for example, the one that was used earlier in the meeting after the move to main went through all my guide feedback and I moved CERCUP to the main branch. I did not delete the master branch. I protected it so no one can push to it but I want to make sure that folks who are involved with CERCUP take a look at that and are absolutely certain that nothing is using master before I delete it. So I commented on the issue where I was requested to move it to main and said, please, here's a couple of suggestions of things to look at and make sure that nothing else is using that. And then this week it's macro pad time. So I'll be doing the macro pad guide and a macro pad circuit Python library and that should be most of my week. In quote unquote, fun stuff. I'm on day 19 of my 14 day mandatory quarantine as for actually fun stuff. I built the chroma key ring for a retro reflective green screen setup over the weekend. It's something JP designed and it's super nice. It's designed to go over camera lenses but it also fits over webcams, same exact setup. I'll be using it on a webcam, I think, when it's all said and done. But we tested it out and everything works great. It's a little rotary encoder on a STEMI QT board with a neopixel ring on it and it all fits into this 3D printed bracket thing. And then I will be out the 1st of July through the 5th of July. I put out in quotes because see the quarantine timing, I'm not going anywhere. I just won't be working. And that's what I've got. Awesome, thank you, Catney. I need to add that to my calendar so I know not to bug you. But not least, we had maker Melissa. Hello, let's sit here. Last week I worked on, I slipped the web serial ESP tool up so it's into two different files for the JavaScript code so that I could separate the UI code from the core code so that it can be applied with different user interfaces. I worked on a JavaScript port of an NBS partition generator for Whippersnapper and I'm making good progress on that. At this point, I'm just comparing the bytes and fixing the differences. And this week, I'm gonna finish and I will finish a demo UI that makes use of that. It shouldn't be too difficult. And I'll work on the web time I work on a guide I had on pause using Microsoft Lobe. For fun stuff, I got a new YouTube video published this past weekend and I started on my next one which is a multi-part build series. And that's it. Awesome, thank you, Melissa. And beware, I'm hoping to steal you away shortly. Oh yeah? For the web Bluetooth stuff, so. Ah, okay. I'll take a look at it, I'm kind of curious but you'll probably have to make it not so. Make it better than what I can do. Okay, no worries. Cool, all right. And that's it for status updates. Next, we have the last section which is in the weeds. In the weeds is a chance for us to just have any sort of longer form discussion stuff that we wanna do. Oh yeah, I have PC fans. So first off, we'll kick it over to Jeff for the first in the weeds topic. Hello again. Hello. So there is this flash saving PR that I was talking about. Well, you can find the link in the note stock. It's very low level stuff and Damian and Jimmo at MicroPython have expressed interest in the concept. So I think our ultimate goal is to upstream it. But in the context of some of these space problems like putting keypad instead of gamepad on the smallest boards, putting in a ticks library, it would also be kind of nice to have it right now in CircuitPython. So how do we want to approach that? If we want to merge it now or soon in CircuitPython, do we split the type object up in all builds which is easiest or just constrained builds which is harder? The reason we might wanna do it on only some boards is there's probably a slight performance impact. And of course, if we decide to go through MicroPython, it would be well after the 7.0 release window before we would be able to then merge it in from a released version of MicroPython. Yeah, so what do people wanna do? Don't wait, merge it now, do it in all builds. That's what I would say. I agree, because we don't know how long it will take to merge upstream and we can always, when upstream does various things with it, maybe under, we would do it under their direction then we can pull it back. All right, so the status of that PR then is that I feel like the core idea is pretty solid but I only did the structures for one particular build and so there's a bunch of stuff that doesn't build. So probably, well, maybe over the weekend if I feel like it, otherwise next week I'll work on getting all the boards to build. It's mostly a mechanical process of you'll get an error at each type structure that needs to be modified and you just modify it and it's reasonably straightforward. So I will work on getting that ready to merge and getting a green build on the PR and then we can talk about it again. Yeah, and don't feel like you have to do it on the weekend. You could count that as a different one. All right, there's just already too much stuff to do in a week, so. Yeah, that's because you're outside. That's where, yeah, I mean I do count these things that are not exactly, you know, not what Lamora's prioritized me to do. I generally count them as work but I do them outside of when I'm trying to get that stuff done and I hope I'm doing that right but nobody has asked me to do it differently yet so I'll keep doing that. Yeah, I think you're fine. All right, I just wanted to emphasize that. Okay, I appreciate that very much. That it is work. Okay, next up we have a question from Dan. So this is, I think I know the answer to this but I think maybe we should do a release suitor rather than later, like maybe I should even start one today or do it tomorrow and that won't have a few of the final API changes in it so it'll probably be an alpha release but it has a number of significant changes that and improvements and I'd rather not wait maybe for these other things because there'll still be a tiny amount of churn in a couple of APIs, I think. Specifically another thing that we're gonna discuss right after this, which is a bad pipe that's a lot. Maybe I won't wait for those, does that sound all right? That's totally fine with me. Okay, all right, then I will make an alpha as soon as possible, okay? Yeah, I mean there's been a lot of stuff that went in since the last alpha. It's really impressive, like when I even did, yeah, the last alpha it took hours to deliver there were so many progress. And we have like 50 or 60 since then I think so. Right, so I think it's fine. I think, I kind of hope that our beta process is gonna be pretty quick because I don't think we're that unstable we're just like, we're doing big things and still keeping our stability pretty good I think so. Yeah, yeah, there are a number of things that are broken but we can fix those later. It's no worse than what we have right now. Right, and also like the release candidate phase is also a chance for us to fix any egregious bugs or really bad bugs. Okay. Yeah, I kind of expect we'll have an alpha or two more and then do maybe a beta just to like do two weeks of bug hunting and then we'll do RCs after that. Okay. Something like that. Do we need to get together and triage those 70 bugs or is that not really a joint effort? Maybe I'll start doing that and then I'll consult with you if I feel like we should have a discussion. I think- There probably will be some that I feel like maybe we should really try to fix this question is when do we get the resources? How do we schedule by with that? I think. Yeah, I think the other question for me is like what new milestones do we wanna add to move them to? Like do we just wanna either keep in 7.0 or move to long term or do we wanna have a optimistic 7x bug fixing? Yeah. I think we probably wanna 7x or a 7xx. Yeah, generally 7x stuff doesn't get done though. No, we haven't been fixing those bugs. We've been writing new code. That's why we need to switch gears a little and stabilize. Yeah, I think it's fine if we were to spend a couple of weeks on it. I'm just doing bug hunting. There's always more bugs, that's the danger. But yeah, I was expecting Dan to just do it first pass. Yeah, I think I'm more worried about we have had some regression since five and it'd be nice to fix some of the regressions since five. Yeah, that's fine. Okay. All right, I'll make a pass at it after I get the next release out. Oh, good. See how I feel, yeah. Yeah. All right, do we wanna do this last topic? Yeah. We do. So I think, Caddy, you wanted to say your idea or? I'll explain what I want. Yeah. And I feel like you probably have a better way of doing it than I can even imagine. So what I want is Adafruit Pi pixel buff and underscore pixel buff to be drop in replacements for each other. And the reason for that is we put color wheel in them deliberately so that it could be used in code. And the problem is now to make it work on all boards to make an example work on all boards which with the templates and the circuit pipeline essentials pages and so on, this is a necessity. I'm doing try accept imports and it's just ridiculous. So my initial thought was rename one of them, but I think Dan's got a better idea of how to do it. Well, what I was thinking is that we could add Adafruit pixel buff as an alias for both of them or at least the very least the insight so that if the build doesn't have it, it would be imported properly. And you wouldn't have to say like, well, which one is it? So just like Adafruit bus device, I mean, this was really Catney's idea of like, well, why isn't this like Adafruit bus device where native version and there's a Python version and they have the same name and we should do the same thing and we should probably take this opportunity to rename pixel buff, Pi pixel buff to Adafruit pixel buff or maybe underscore pixel buff. But I don't know, something, something that's the same and we can make it upward compatible for a release, for this release by just, you can give things alternate names, both in Python and in natively. I think I follow as long as it does what I want. Yeah, yeah, it will do right. I think it'll do what you want. The main problem we have is dealing with multiple incompatible versions of libraries. That's the hardest part. Right, but if we are, if we're renaming the, if we rename the library, it's not, this Adafruit Pi pixel buff is not, first of all, it's not frozen into anything. That was the whole point of it. Second of all, there's guides that use it, but like I said, I searched for it, it's less than a page. Okay, good. So updating, and it's almost always in, it's never used in the code, because I think I'm the only person that's ever called ColorWheel. Like people don't really realize it's there and I haven't pushed it because it's kind of frustrating at the moment. Is it's in the listing of libraries that you need to copy to CircuitPi? Like that's pretty much all it is in most guides. Because if you use a Trinket or a Gemma, et cetera, those require Pi pixel buff. And so it says like, or Qt Pi, it says like, copy these two files, but then you use NeoPixel, you don't use Pi pixel buff. So renaming it is, I mean, it would be quick, it would be a relatively quick fix. Okay. So then we can, go ahead. I'm not against this, but I wanna throw out another option, which is move ColorWheel into its own module, instead of having it tacked on the pixel buff. What, I mean, what do you, so you're talking a whole other library that you install or that you copy? Or are you talking a native module? I'm talking it would be, you could do the exact same thing. You could have a native version that is the same name, but you could also provide a Python version as well. So you're talking about in CircuitPython. I'm just trying to make, make sure I'm clear on what you're suggesting. Yeah, like you could have a native CircuitPython module for it that you could also have a, like it feels weird to me that it's on pixel buff. That's why I'm throwing this up. Well, the idea was, yeah, I mean, the idea was that it was more applicable to NeoPixel and DotStar, but because the, because they moved to using pixel buff and Pi pixel buff, that's why we tossed it in there. I'm fine with it being a native module. Like that's totally, I would support that as well. Yeah. That would eliminate this problem because the only thing that is really importing the pixel buff or Pi pixel buff is color wheel. Right, otherwise, otherwise you're using it indirectly through DotStar and NeoPixel. Correct. Yeah. And your statement about like nobody really knows it's there is also assigned to me that it might be better to have a like pixel something, pixel swirl, pixel something, and like a module. You can just call it color wheel. Yeah, you could just. If you're being obtuse about it, then you're gonna run into the same issue I ran into when I first started with this, which is what is wheel? What does that even mean? So go ahead. Are there any other pieces of functionality that you might want to put in some library that has color wheel in it? Right. Probably not. And here's why. I don't wanna run into a situation where we've got, you know, I don't wanna run into this situation again, where I've got this color wheel library that does other things. And then we've got this native module that just does color wheel. And then we're like doing weird cross-import things or the naming is different, et cetera. I feel like it could be its own thing and just be that would be okay. And it's too slow to write in just Python. Is that right? I don't have an answer to that. I don't know. It's faster to write and see. I mean, you just gotta make that. If you're calling it all the time from your... If you generate them up front, it's fine, but sometimes you need to generate them as you go and then it is pretty slow. If you were like a pixel noodle, that's not necessarily the name I would choose, but it's sort of like, kind of like I made this simple math library that only has two or three things in it. It's not native, but as long as there's only a small amount of stuff in it, but it's sort of like a helper for pixel buff. I don't know. It's just like computations that take too much time in Python and you'd want to be native. Because otherwise, if it isn't too slow, if it isn't too slow as opposed to just being slower, then I would say, forget it, let's take it out of the native one and make it a separate library. So... Well, part of the reason I wanted it integrated into something was that we were copying and pasting the color wheel code into every single piece of code.py that had, that called it and that just seemed dumb. Like, there's so much an easier way to do this if we integrated it into, and in this case, having a native module would be my, would fit my definition of integrated into something. I think it's fine. I think having a native module is okay because it's so commonly like our blinky. Yeah. I agree, like for sure. Rainbows is like what we do. Yeah. That's our default everything. I actually just looked in the rain. There's already like a PyPI package called rainbow because I was like, oh, it would be cool to call it rainbow. We can make a plural. Then you would import rainbows, but rainbow I have. There you go. I'm okay. I'm okay having it just be a specific thing. Like Carter suggested in the chat to co-locate it with like HSV to RGB converters, but like Python already has color sys, and we also already have fancy LED. So like, I kind of like your proposal. Like this is like version two of Blink, right? And so like it's okay for us to just have import color wheel, color wheel dot color wheel or whatever. Color wheel dot compute, maybe. Like, I'm okay with having just a one off for it, but I don't know, does anybody disagree with me? It's not even an object, right? It's not even a class. Right. Yeah, it's just like a module with a function. Yeah. And I feel like we probably don't need a Python version. Like we could make one, but I don't think we need it because it seems like it's not going to take up that much space says me. I know, what do I know? I mean, part of the problem is that if we couple it to pixel buff, yeah, which I think is part of the reason it's in the pixel buff library to begin with, it might be better to have it separate as well. But again, I'm okay having a library that's just Adafruit, Circle Python, Color Wheel. Yeah, no, I understand. Yeah. So there would be, we would have to, like if we made it separate then, yeah, that's going to change the code in a lot of libraries. So there will be a lot of... Like I said, I don't know how much it's used. It's used in the examples, you mean, okay. Like I've used it. And Todd bought on Twitter, Todd Kurt, he found it. Which means that anybody who follows him and uses his code is using it, but that's kind of the extent of it because like I said, it's a little bit frustrating to use right now. So I'm really the only one doing it, which means there's only a certain set of examples and so on that needs to be updated. And we I think have like a lot of stuff in place to be able to find where it needs to be changed. And we can leave Pixelbuff the same then. We don't need to change Pixelbuff. Like it's still kind of annoying because you have to do the imports and stuff, but like we don't expect anybody to do that because we expect them to use .star or NeoPixel. But we can still fix that. I think that would be good to fix in the long run. I'm not gonna argue against it. Right. Suppose we call it like pixel colors or something like that. We can talk about a name. Yeah, yeah. Okay. Okay. Sounds good. I will reply to the issue with what we've discussed. And Dan, you and I can work through a name because like I said, I would like to see this done quickly. So I don't want it to just sit as something that we eventually get to quote unquote. Right. Simple I.O., but Simple I.O. is only. No. In Simple I.O., no. It's got a bunch of other stuff in it and you don't wanna make that native. Yeah, Simple I.O. exists actually. Simple I.O. is really just like appeasing people coming from Arduino and wanting what they want. But reality is not a lot of people actually picked it up. Naradoc says, I didn't know pixelbuff.colorwheel existed. Right. And that's exactly my point is that that is a little bit obtuse. Right. And I think putting it in. And underscore pixelbuff.colorwheel is a little bit obtuse. And so I haven't pushed our internal folks to use it yet. I haven't pushed guides to be using it yet. Like I do, like I said, but once we've got it in a better place and the imports make more sense, I will be pushing everybody to use it. Maybe I'll do a scrollman implementation of it and see how big it is. It's already in there. It's in pixelbuff. Well, that's right. Yeah, I could just take it out and see how many bytes I save if I take it out. Yeah. Yeah. Do you think we could change it from returning a tuple to returning an integer? What do you mean? It doesn't return a tuple. Okay, it's just the one in pypixelbuff that returns a tuple and the one in the core returns an integer. I thought it, wait, no, it takes an integer. Maybe it returns a tuple. I'm not sure. I'll look into it. A better version. Because that's likely to work the same with pixelbuff and pypixelbuff. You know, they take both kinds, but it's likely to be a little bit smaller as a, oh, good, it returns a sensible thing. It's just different than what the, I was looking at Adafruit pypixelbuff documentation. Oh. And assuming that underscore pixelbuff's color wheel did the same thing as this documentation said, which it doesn't. Okay. Well, I can fix that. Yeah, that's not good. We can fix it. Yeah, we'll fix it, yep. Thank you. Well, I mean, whatever it's doing right now works fine. And it's just, I was reading documentation for not this thing. Yeah. But the thing that I thought was maybe this thing. Anyway. Okay. That's all. I'll step out again. All right. Okay. The other one has a two. All right. Well, they will, a bit, let's concentrate on this for a while, yeah, good. Awesome. Thank you for bringing that up. That's a good idea. Okay. That's it. It is 95 degrees in here, so I am not gonna be here very much longer. This has been the Circuit Python Weekly for June 28th, 2021. Thank you to everyone who participated. If you wanna support Adafruit and Circuit Python and those of us that work on Circuit Python, who are paid by Adafruit, consider purchasing from the Adafruit shop at adafruit.com. The video this meeting will be released on YouTube at youtube.com slash adafruit, and the podcast will be available on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. Visit adafruitdaily.com to subscribe. Just check the Python for Microcontrollers newsletter box there. The next meeting will be held next Tuesday, big flashing lights Tuesday, not Monday, 24 hours later than normal, Tuesday at 2 p.m. Eastern, 11 a.m. Pacific. The meeting is held on the Adafruit Discord server, which you can join by going to the URL, adafru.it slash discord. To be notified about the meeting and any changes to the time or day, you can ask to be added to the Circuit Python NISAs role on Discord. And with that, we hope to see you all next week. Thanks, everyone. Thanks, everyone. Thank you.