 Okay, hello everyone. This is the Circuit Python Weekly for Monday, March 7th, 2022. This is the time of the week when we get together to talk about all things Circuit Python. I'm Dan, 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 and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.com. You hold the meeting in the Circuit Python Dev Text Channel and the Circuit Python Voice Channel in Discord. Typically, this meeting happens on Mondays at 2 p.m. Eastern Time, 11 a.m. Pacific Time in the United States, except when it coincides with the U.S. holiday. In the notes document, there's a link to a calendar you can view online or add to your favorite calendar app to get reminded. You also send notifications about upcoming meetings via Discord. If you'd like to receive these notifications, ask us to add you to the Circuit Python Easter Discord role. That's really all it's used for, is to remind people. There is a notes doc to accompany the meeting. The notes doc contains time stamps to go along with the video so you can use the doc to skip around in the video. Let me put up a link to the notes doc. After each meeting, we'll post a link for the next meeting's notes document to the Circuit Python Dev Channel. Check the PIN messages at the top of the channel to find the latest notes doc so you add your notes to the following meeting. If you wish to participate but cannot attend, you can leave hug reports and status updates in the notes document for us to read during the meeting. This meeting is held in five parts. The first is community news. The second is State of Circuit Python. The third is hug reports. The fourth is status updates. And the fifth is in the weeds. I'll explain those parts as we go along. I'll start off with community news. Community news, usually we take the headlines from the Weekly Python for Microcontrollers newsletter. You can visit AdafruitDaily.com to subscribe to the newsletter. Thanks to Ann for putting the newsletter together. If you have any Python or hardware projects to share or find content you'd like to see included, please consider contributing to the newsletter. You can open a PR on GitHub. You can DM or respond to Ann Engineer on Twitter with the hashtag CircuitPython or email cpnews at Adafruit.com with a link. Let's see, let's post some cpnews at adafruit.com where you can send mail to the newsletter. All right, let me add a timestamp for all this. Okay, so I'll just have a couple of headlines I took out of the newsletter. It's not as busy a news week as it has been in the past, but that's why it's nice to take a little break from so much news all the time. There was a developer meetup, the Dublin Linux Developer Group, had a video meetup with Adafruit on March 5th. Jeff Epler and Melissa Blanc-Williams from Adafruit attended that. And you can, there will be a recording of that meeting. I'm not sure it's been posted yet. Jeff, if you know whether it's been posted, but there's a link in the channel where you can find out about when it will be available or just keep checking back there. Jeff's presentation was on from Zero to CircuitPython, where he explained about CircuitPython. And Melissa explained about getting to Blinky with Blinka, and it's how to use Adafruit Blinka on Raspberry Pi to be able to use CircuitPython code and libraries. Okay, and then another thing I want to make note of is the CircuitPython show. It's a new independent podcast hosted by Paul Cutler, who can't be here today, unfortunately, focused on people doing awesome things with CircuitPython. Each episode features Paul in conversation with a guest for a 20 to 30 minute interview. Thank you, Fomy Guy, for posting a link. The first episode aired on March 1, featuring an interview with Catty. The second episode airs today, March 8, with Maker Les Pounder, who has been doing things with CircuitPython for a long time, and we've seen a couple of times at PyCon in Cleveland and had a great time talking with him. Okay, just a reminder about, I already told you about the CircuitPython newsletter, I won't repeat that here. You can, if you'd like to contribute news, as I said, you can send mail to CP News, or you can spit up PR to, oh, it says today, March 8. Thank you, Jeff. You can also, besides sending mail to CP News, you can also submit a pull request to the newsletter if you'd like to submit your own text, whatever you'd like. We'll take it in any form you like. Okay, let's move on to the heart of the meeting, the state of CircuitPython. First, we'll start with the state of CircuitPython libraries in Blinka, and I'll take another timestamp. We make, like, midnight, the previous midnight, we run a job that looks at all the pull requests and issues, outstanding issues for various components of CircuitPython and summarize them here. So, overall, in the past week, there were 25 pull requests merged. There were 20 authors. There are some people I haven't seen here before, like C.D. Calamini, Squash, S.Q.U.A.S.C.H.E., Falaam 84, FiveTie. Maybe they've been around, Fabaaf, but thank you very much for all your pull requests. There were nine reviewers, and there were 29 closed issues by 11 people and 19 opened by 16 people, which is nice where we got ahead. We reduced the number of issues by 10. Now, I'll go on to the core section to summarize what's going with the CircuitPython core. Scott, would you like to do that? Do you have time? Sure, be happy to do that. Okay, so the numbers for the core this week, we had 11 pull requests merged from 11 different authors, which is pretty awesome, one-to-one. So thank you to all of our authors there. We had four reviewers, so thank you to our reviewers. As always, if you'd like to level up from author to reviewer, please let us know. We're happy to help get more reviewers because the more reviewers we have, the more authors we can support. Open pull requests-wise, we have 17 open. Three of those are greater than 100 days old, although I think one of those just got pinked and I'll take a look at that. Besides that, as always, also, if you have an open pull request, please make sure that it's making some progress and it's clear kind of what the next steps are. If not, please close it because the open pull request number is a common thing that people look at for the health of a project. So we want to keep that number as low as we can. Issues-wise, which is a little bit different, is we had 10 closed issues by 4 people and 7 open by 7 people, so we're net down 3, which is good, for a total of 505 open issues. This number does tend to grow slowly over time, and one of the reasons is that we have a very big bucket that we kind of categorize issues into, called long-term. These are things that are interesting and we may want to do in the future, but Adafruit-funded folks haven't necessarily prioritized them. Doesn't mean you can't do it, just means that for those of us working for Adafruit, aren't doing it as a priority. So we have 448 open issues in that long-term category. And then we have one open issue in 7.2.x. This is kind of the top priority for something that may be in a follow-up stable release, like a 7.2.1. We have 4 open issues for 7.3.0, which will be the next kind of... It's not a major revision, but a feature revision, or whatever it's called, of circuit Python. 7.3 largely is kind of destabilized by the new version of MicroPython coming in, not saying that MicroPython is not stable, just that the merge can cause some stability issues. So 7.3 will include MicroPython 118, which will be cool, and we have 4 open issues there as well. And then we have 22 open issues on 7.x.x, which are kind of broader, like we should probably do these sooner rather than later. But yeah, that's all of the stats for the circuit Python core. I don't know, we always have negative one issue not assigned to Milestones, so I don't understand. We'll figure that out. Yeah, I've been meaning to look at that math, but I think it might have to do with, like, whether they have categories or don't have Milestones or something like that. Okay, all right, well, thank you very much, Scott. No problem. We'll go on to libraries. Katani usually does libraries. If you can, Katani, go ahead. Thanks, Dan. I think it's negative one because you just know what the next issue is going to be and you've already put it in a Milestone. All right, so this applies to all of the Adafruit Circuit Python libraries, which is everything that begins with Adafruit underscore circuit Python underscore as well as a few extras. So all of these repositories, we had 10 pull requests merged by eight different authors and six different reviewers. The oldest merged pull request was four days old, and it leaves us with 18 open pull requests across all the libraries, which is amazing. We had 16 closed issues by eight people and 11 open by eight people leaving us with 625 open issues. We have 209 labeled good first issue. If you're interested in contributing to Circuit Python on the Python side of things, check out circuitpython.org slash contributing. You'll find all of this information and more, including open pull requests and open issues. If you are new to everything, check out good first issues. If you're new to everything, we also have a guide on contributing to Circuit Python using Git and GitHub, as well as the fact that we're available on Discord every day or most days. And we can help you figure out a way to contribute that works for you. If you're interested in reviewing, check out the open pull requests, leave a comment, let us know you tested it, let us know that you took a look at the code and it looks good to you. Any of that sort of thing always helps. And if you get comfortable with that and you're interested in joining the review team, we can look at that at that time. In terms of library updates in the last seven days, there were no new libraries, but there is a short list of updated libraries that is available in the notes if you are interested. And that's what I've got. Okay, thank you, Katnick. Okay, we'll move on to the state of Blinka. Melissa, if you're available, we'll go ahead. Yeah, just a second now. Trying to find a place in the notes here. Okay, so for Blinka, which is our circuit Python compatibility layer for Michael Python, Raspberry Pi and other single board computers. This week, we had four pull requests merged by three authors and three reviewers. There are currently eight open pull requests. There were three closed issues by two people and one open by one person leaving a net of 71 open issues. There were 14,588 Pi wheels downloads in the last month and we are currently supporting 87 boards. So overall, it's been a little bit more activity for Blinka than we had been getting. So, cool. Thank you very much, Melissa. Okay, now we'll move on to hug reports. Hug reports is a chance to highlight folks in the circuit Python community and beyond for doing awesome things. We do this in kind of a round robin alphabetical order, except the host starts first as an example. And we'll just go down the list alphabetically. If you're text-only or missing the meeting, but have hug reports, I'll read them off as I get to you in the list. And I just want to say that the idea of hug reports is something that Adafruit has been doing internally in their weekly company meetings for years. And so we adopted that. It was a great idea. Okay. So, first I'd like to thank Rick Sorensen, who's a new contributor for their first PR, which was to fix some pin names and assignments for the Cedrino, Ziao, SamD21. There are a bunch of similar boards that have different things on them, but there were some errors, particularly with the LED pins. That was very helpful. Thanks to Dave Putz, who's continuing to contribute really useful fixes. And thanks for a discussion and discord between myself, PhomyGuy, Tectric, Naradok, and Jeff. And I think maybe some other people for some discussion about typing annotation, which is a continuing thing that is introducing more problems but more other good things into our code. It makes our code safer and makes it easier to use in an IDE, but we also have to keep introducing new features and new types to support it. Okay, Deshipu, you can go ahead. Okay, thanks to Mark, Dan and Scott for the PR reviews. Very helpful. And thanks to Jeff for the work on parallel display and the camera. I'm now trying to use those modules. It's a good piece of work. Okay, thank you. Okay, PhomyGuy, go ahead. All right, thanks, Dan. Harg reports this week. Thank you to Scott for having me on Deep Dive this past Friday and also generally just for starting up the Deep Dive. It's been a fascinating and inspirational go to watch. Thank you to Dexter Starbird, who reviewed a PR and gave some good suggestions for some work I did this week. And then lastly, thanks to you, Dan, for the great examples and explanations in the cooperative multitasking guide. It's to sit down and really dig into that over the weekend, and I found it quite helpful. So thanks. Thank you very much. Okay. Okay, Jeff, it's your turn now. All right, I wanted to start off by thanking Lamor for perfecting some camera code that I started way back last fall. Feels like a really long time ago. To PT for always doing things thoughtfully and revising your approach when it's necessary instead of doubling down, which is all too easy to do. Thank you to Scott. Thank you for all the deep dives. We expect you back at some point. And to make her Melissa, thanks for presenting with me to the Dublin Linux group on Saturday and as well to the organizer Neil for inviting us. Okay, thanks, Jeff. Okay, Jerry, go ahead. Hi, so group hug to the whole team. Thanks. Thank you very much. Okay, next up is Katnie. So I have a hug report for Nicholas Tolarby for the latest new release, the latest stable release, which might have been last week, but I don't think I got in a hug report for that so belated hug report for that. To Dan for all the help with a not exactly circuit Python bug that I found. To Carter for explaining pull ups and pull downs, as well as internal versus external. It started as a question about how do I figure out whether I need to pull up or pull down in code without trial and error. And turns out the particular pin I was dealing with was not clear which one you were supposed to use anyway so it wasn't entirely me but by the end of the conversation it cleared up a lot of just general not information that I had in my head. So that was super helpful. To Keith E for showing an excellent example of self care by taking time out for himself. And to Phil for beginning discussions about Python 2022. That's what I've got. Okay, thank you very much. Okay, came at you can go ahead now. Keep matches marked as text. Sorry. All right, I'm looking at three things at once. I will go ahead and read theirs. Thanks to Tandu for the live stream and the good conversation with phone we guy and thanks to lady a lady Ada for making all the available. Available all the helpful schematics and board layouts for me to learn from. Yes, you can learn a lot about Harvard design by just looking at how we designed boards how lady designed boards. Okay. Next up is maker Melissa. I wanted to give a hug to five tide for adding the USB HID to Blinka to Jebler for presenting with me at the Dublin Linux developers group on Saturday and to nearly organize who invited us to cat knee for organizing Picon and a group of everyone else. Okay, thank you. Okay, Tammy makes things. You can go ahead. I just had a group hug to everybody for being awesome today. Oh, thank you very much. All right, I'll read a tech trick. Who's not here. Who's who's lurking and can't it's not going to speak at the moment. Take a time. Okay. Thanks to Jerry, anecdote and cat knee for helping reviewing testing and fixing my SI 7201 PR. Thanks to foamy guy for always being a pleasure to work on with PRs and issues. Thanks to Paul Kettler and cat knee from an awesome circuit for an awesome circuit circuit python show podcast episode last week and group hug to all the contributors and retainers. My PR to grad school was recently merged and this community played a pivotal role in my decision to apply. That's fantastic. All right. Paul Cutler is not in the meeting. Revers group hugged everyone who listened and supported listen to and supported the circuit python shows first episode last week. And finally Scott. Hello. Okay, first a hug report to foamy guy for joining my stream for a chat and keeping the deep dive going while I'm on leave. Next. I have a hug for attack and second gone. For creating for one creating PIO USB host stuff open sourcing it and then being responsive to tack on a GitHub issue. So excited to see that moving forward. Thank you to both of those folks for pushing it forward. And lastly, thanks to attic data for helping with requests issues. It's really nice to have. You seem to me to be an expert in Wi-Fi stuff. So thank you for contributing and we really appreciate it. Okay, thank you. All right, now we'll move on to the next session section, which is status updates. This is our time to sync up on what each of us are doing. Again, I'll start with me as an example and then we'll go down the list alphabetically. You can either speak or I can just read what you've typed in. No problem. If there's if we end up discussing something, we can that in the discussion becomes a little involved. We can discuss it in the weeds. So don't feel bad about bringing up a discussion topic, which we can then continue on later. All right, I'll make a guess at the time code here and I'll go ahead. So I'm still working on this auto reload issue for 7021. The problem was that auto reload would not happen sometimes when you wrote a file. And I have it working much better, but it still isn't quite working. There's a logic for when you do auto reload and when you do a lot of other things is very hairy inside of main.c. And it looks like there might be some race conditions that are hard to figure out. And I may submit something that works better, but is not perfect right now and move on to some other things. And there are plenty of other issues still to work on that I'd like to do for 721 or 730. I'm still keeping an eye on async.io things. People are submitting PRs or support requests. And I'm still working on the async HTTP client. Though I haven't really done any work on that in about a week. And there's still some more outstanding things to do for CircuitPython typing library. We need to add some from future import annotations stuff, which I have a PR for, but it's having some self-referential problems and I have to get that working. And in the course of doing that I found a bug in Ubuntu 2204, the upcoming release in which the VN part of Python was not working. Somebody else found it ahead of me, but I was affected by it also. So I have to work around that bug in order just to test it. Okay, go ahead, Deshipu. Okay, so I made another attempt at the camera out on the ESP32S2. And this time, previously it at least went through the camera initialization. This time it's I2C that one is not found with the same hardware and the same code. So something is changing in the library for sure, but not sure what's going on there. Going to investigate further. I made up here for 9-bit mode for wire so that we can support 9-bit mode on the displays. And let me get the RH112 display, also known as the Nokia 1202 display, working with a very nice small TFT display. And that doesn't need backlight, so it's super low power. And I'm also working on getting the Maker Fabs ESP32S2 Parallel TFT board to work. I received one for free from them and I got the circuit panel working on it. Now I'm trying to get the display to work. It's fun because it's a 16-bit display. For now I switched it to 8-bit mode because 16-bit doesn't seem to be yet finished for Parallel display. But I still can't get the right initialization for the display to work pretty well. That needs some more work. I finally made the PR for the option for removing Blinka logo from the displays. That's useful for the smaller displays or when you don't want to burn in your OLED displays or things like that. Maybe also useful for saving some bytes on smaller builds. I made another handheld device, this time with a nice 3.2 screen. Sometimes it runs the same stage game library as the others. So not much new in there. And I also made an experimental keyboard with ESP32S3 using the unexpected maker's tiny S3 board on this. Right now it's only working in the wired mode because the BLE service is yet not supported on circuit Python on this platform. But I plan to eventually make it wireless and see how the power modes work on those boards and how I can make it not eat through the whole battery in a day, hopefully. And yeah, I also saw that Glowey is working on a port of circuit Python for some L22 port and I'm very interested in that as well. I asked him about where to look for his changes and I want to get involved with that. But I can really help a lot because this is a really low level stuff. So we will see. That's it. Thank you. Is there something really interesting about the SAML22 chip? Yes, it has a built-in LCD driver. So you can drive like bare LCDs, the ones that don't have the chip on glass on them with that chip basically for free because it has the same driver that normally is built in into the display. And those displays you can make custom ones and they are super cheap like 50 cents a piece and super low power because this is basically a capacitor. So it's really interesting to, you know, all kinds of devices. Yeah, that's very interesting. Okay, thank you. All right. Okay, from the guy, go ahead. All right. Last week, I updated the James Webb telescope project that's been a couple of weeks in the works fixing some certificate things and all of that stuff is merged in now. I went back to the actual project and rewired it up to show the current data that's coming from the new data source. I did some testing and work on a couple other smaller PRs in the core, one for documentation, one for an older issue relating to on-disk bitmap. I did some experimentation this week with the AsyncIO library, working on cooperative multitasking specifically with an eye towards display IO GUIs. So I created a new example and submitted a PR for that over the weekend. And then for the upcoming week, I'm actually, I have a couple of days of vacation scheduled so I have limited involvement for a few days, but I'll be back towards the latter half of this week. But I don't know exactly what I'll be getting into just yet when I do return. Okay. Thank you for me guy. Okay. Jeff, you can go ahead. Hello again. So last week, as I mentioned earlier, I presented to the Devil and Linux developers meetup. The attendance was small, but it was great practice for me as I'm not a confident presenter. Hopefully we'll be able to make the video available within the next week. So keep an eye on the newsletter for that. Floppy drive land continues over the past couple weeks. I've gained a deep understanding of how the Apple to floppy formats work. But I still haven't managed to write an image which reads reliably on my Apple to. I have also been working on a hardware interface from the RP 2040 feather to an Apple to floppy drive. And that is done to the extent that it's able to move the read write head back and forth. Within the disk and it's able to see the data coming out. This week, I learned about some software that allows disk images to be transmitted to the Apple over an audio cable. And then the Apple can write its own disk. So that's called EdT Pro. It's open source software in Java. I'll be giving that a try soon. I'm working on adapting Adafruit floppy so that it can use the Apple to floppy drive mechanism with the hardware interface that I've wired up. I mentioned a minute ago. I may have to modify the hardware to add an index sensor, which is a sensor that activates once per revolution of the floppy. I've got some ideas about how to do that reversibly. But also some ideas about how that might not be necessary as long as your goal is only to copy non copy protected floppies. So just generally I'm trying to complete this circle of being able to get data off of an Apple floppy and put it back on a floppy that an Apple can use. In other news, I made marshmallows from scratch on Saturday and it wasn't too bad. I'll probably try again and see if I can get them fluffier. Okay. Thank you, Jeff. I looked for a marshmallow emoji in Discord. I could not find one. I'm sorry. Jerry, go ahead. Hi. I look for one too. So I got sidetracked of some MicroPython stuff this week, but learned some interesting things. I'll share a few of them. One is I was using the LSM-6DSOX accelerometer on MicroPython and found that in their driver section, they have this really, really nice example of using some machine language. They call it Machine Learning Core. You can upload these pre-defined models to the LSM-6DSOX. And then it was a very simple code then you can have it detect certain types of motions. There's one for open, you put it on a door and it'll tell you if the door is opening or closing. If you put it on your head, it can distinguish a head nod from a head shake. There's one really simple, nice one where you can just tell what the orientation of the sensor is, is X up or Y up or X down or just gives you the sort of six axes, which one's facing up. They're all really pretty cool and they're very, very easy to use. So I thought I'd try and port that over to the CircuitPython library. I've got a little bit of learning to do about how to work within that library structure, but I think it should be fairly easy to port it over. You just load this file into it and the files are available on an ST microsite. And then while playing with MicroPython, I was playing with the new Feather ESP32 V2 board, the Version 2 board, and it's just a heads up for anyone else who's using it. I was trying to do something with this accelerometer. I wanted to use the I squared C and MicroPython won't allow you to assign pin 20. And looking at the pin definitions, pin 20 is not available, not defined. And so it looks like the way the pin depth has just set up is for previous boards or modules and not for the ESP32 Pico Mini 02, which is what's on this board. So I'm trying to work through that, understand it and how to get around it, or maybe you just have to wait until MicroPython adds another board definition. So yeah, so it's not a show. I moved just used another pin rather than pin 20 for SCL and it works great, but that pin doesn't exist in their build unless I'm using the wrong board but I can't find another board build that would apply. I'm using the SPI RAM build. Well, I think the boards, right, they're always pins. We always have fixes for pins, so they're not used from that either. So, okay, thank you very much, Jesse. Okay, Katny, go ahead. All right. So last week I got hung up on repeated bugs while trying to finish a guide. I usually love bug hunting, but this was getting old. After a lot of troubleshooting, sort it out that a microcontroller.CPU.temperature plus Wi-Fi bug is beyond CircuitPython, it's in the ESP IDF and updated a template to use a random number generator instead of the CPU temp along with Wi-Fi code. Filed an issue on the core for the CPU temp bug with a link to the ESP IDF issue for tracking purposes. Created a few new templates for CircuitPython, the LC709203 battery monitor data reading and Adafruit IO send and receive and Arduino for a built-in TFT example and the LC709203 battery monitor as well. Consolidated some ESP32-S2 CircuitPython template code to simplify the guide templates. Ran into a failed feather TFT board, another bug. It was a super weird failure and apparently I barely missed out on destroying the USB port that the board was plugged into. Belated hug report to Redamere for helping me troubleshoot that and teaching me not to bridge the ground in USB pins directly. Finally finished the feather TFT guide and started PyCon 2022 planning. This week, I'll be adding the new templates that I talked about earlier to the feather ESP32-S2 guide. Once that's done, I'll be doing the feather ESP32-V2 guide In between there's some various miscellaneous. There's four new product guides incoming, the MCP23017, there's two new TFTs and the VL53-VCD. The ADXL343 just had a STEMMA QT revision so that will be an updated guide as well. I may actually be walking Eva through how to do that so that she can help out with those STEMMA QT rev updates moving forward. I have the Essentials template for async.io which keeps getting bumped. It's not a super high priority but it's still on my list and then continue PyCon 2022 planning. In my off time, I didn't get any further last week than I was previously but I'm working on a Discord bot for the Adafruit Discord Survey. The first major feature is it will flag unformatted code and provide info on how to format it. But I'm looking forward to working on that again this week and that should be, I don't know, it seems like it's going to be fun. And that's what I've got. Okay, thank you, Kat. Okay, next up is Kmatch who's not here so I'll read their contributions. Last week, studying QI-CAD to make a board to simplify my display wiring and learning a lot from Lady Aida's schematics and layouts. Finalized pinout selection for ESP32S3 to touch display panel and minor progress on adding multiple lines to the Cartesian widget updates. Hope to pick this back up in several weeks. This week, add backlight driver and battery charger to my display driver schematic and finalize the board layout. Then experiment with ESP32S3 IDF demo code for RGB displays. Other is slower progress. Last week in the next few weeks, some home construction projects that have bubbled up to the top of my list. Okay, thanks Kmatch. Okay, maker Melissa, go ahead. Last week I added pre-commit support to Blinka which involved cleaning up a bunch of items that needed lending. I worked on preparing my talk for the Linux developers group and I worked on helping Lauren with some whippersnapper firmware, updater improvements, and fixed an issue with platform detect on the Beaglebone on recent firmware versions. And this week I'm going to finish and catch up on a few more GitHub issues and possibly work on adding ESP32C3 support to the Web Serial ESP tool. That's it. Great, thank you very much. Okay, next up, Tammy makes things. So last week I worked on refactoring the design for the display IO card deck library that I'm working on. I realized as I started thinking through what I was doing that I was making it much more complicated than it needed to be so I decided to go back and simplify before I started coding instead of afterwards. I fixed them issues with video hardware on my MacBook so that I could do Twitch streaming and I had two successful Twitch streams doing electronics and circuit Python stuff, making we did a little MIDI controller made out of a macro pad. So that was fun. My Twitch username is the same as my Discord username if people want to find me there. This week I'm going to keep working on my card deck library. I'm doing two more Twitch streams. So the first one is scheduled weekly Tuesdays at 7 p.m. Arizona time and then Sunday at 10 a.m. Arizona time and I specified both of those in Arizona time because I get confused by the whole time change thing since Arizona doesn't mostly change times but we change relative to the time zones that are around us. I also want to tackle some more of the open issues for adding type annotations to the libraries. I ran into a small issue yesterday with the PICU tool for helping with circuit Python code deployment. It wouldn't deploy to the macro pad because it said the board's memory was too large. So I figured out what's going on with that and I need to just figure out a clean way to fix it and then I'll submit a PR to the PICU tool for that. And in other news I got an offer over the weekend for an awesome, exciting new job doing data engineering with Python for a marketing company. I'm really excited and although I don't know if the work that I've done with Circuit Python made me a better candidate for that job, being able to talk about that work certainly made me a more interesting candidate. So I'm excited about that and hugs to the community for creating this amazing thing that I can be a part of. And that's what I got. Great. Congratulations, Tammy. That's terrific. Thank you very much. Okay, we'll go on to Tetrick, who isn't here. Maybe, yeah. All right, I'll go ahead and read Tetrick's because I did read their hub reports also. Last week, added suspend power functionality to the BNO-055, added heater control functionality to the SI-7021 and some miscellaneous documentation updates. This week, more typing PRs, picking back up my self-lighting menorah project now using the tiny S2. Looking for more issues across the libraries to start and starting to prepare and plan for grad school this fall. Congrats again on that. And now we'll go on to Scott. Hello. Last week, I made pretty good progress on USB host. On the IMX, I can now list connected devices and their VID, PID, product name, manufacturer name, and serial number. I plan on getting, testing that on the teensy 401 today and then getting this as a PR. You won't actually be able to talk to the device yet, but soon, let me keep down my list. I added USB specific exceptions to match Pi USB. I created two simple examples, one for mouse and one for reading a keyboard. And then on Friday, I did the last deep dive before I go and leave because the baby's due date is under three weeks away, which is pretty wild. Two weeks from Friday and from next Friday. So this week, I'm going to check in with TAC's tiny USB work. It looks like he's still working on it. He's adding a raw API for reading and writing endpoints directly that will need to do the Pi USB API. So I may start doing an example. This is a little old. I said I may start adding an example for IntelliQuies and I may also start experimenting with PIO DVI. But chatting with them more this morning, I think I'm actually going to take a brief look at the ESP32 S3 just to make sure that everything's in a pretty good space. In particular, there's a couple issues around deep sleep on the S3 that I'm going to take a look at. So, yeah, I'm going to be doing S3 stuff once I kind of wrap up and put this USB host work on pause. And that's my plan. Okay, thank you very much, Scott. Okay, we'll now move on to In the Weeds. In the Weeds is a chance for us to discuss some issues in more depth that people want to bounce off the community, get some ideas for or just make announcements about. So I'll start. We had a discussion in the internal meeting just before this one about the fact that we have a lot of support issues and general people needing help with ESP32, either ESP32 plain ESP32 SPI or ESP32 S2 Wi-Fi scripts that might mysteriously stop working at some point, often after several days. We're not really sure why this happens. And it would be helpful to figure out why the errors are happening. But the other thing that's true is that a lot of our example scripts don't necessarily do such great error recovery when something does go wrong. Wi-Fi and wireless stuff in general is, there are going to be errors. Everybody knows that things go wrong. There's interference, hosts go down, all kinds of things can go wrong. So it would be good if we had some more canonical examples of how to make our Wi-Fi scripts more robust. And we talked about some ideas for this. One idea is simply to catch, put a try accept around everything and the easiest way to do that, instead of putting try accept at the top level, we might encourage people to write a main function and then call main and surround the call to main with try accept. That's one thing to do. That makes it simple to see where the try accept is happening. Another thing that might be true is that I recently saw an issue or a PR about the fact that we throw different kinds of exceptions in the Wi-Fi code. Sometimes we throw a runtime error, sometimes we throw IO error, and it might be helpful to regularize those. Some of them we may want to change in the next major version because it would be incompatibility. But it would be nice to go through all those and even perhaps inventory them all so that we can list what things cause exceptions and which functions might actually cause exceptions to be thrown because it's not necessarily in the documentation. Another thing that was suggested. Can I interrupt you here? I just have a quick suggestion. If you are making different classes for those exceptions, it might be a good idea to have a class for recoverable errors in particular. So you can treat them differently than errors that are for sure programming error and so on. So things like tag nodes and things like that might be convenient to have them as a separate class because it doesn't make sense to restart your code on, I don't know, syntax error. But it may make sense on a timeout. That's a good idea. That's a very good point, yes. So with respect to that, the next two suggestions are about restarting the code automatically. You can do that two ways. You can use at exit, which was implemented and we haven't used too much. You can also use a kind of hidden feature of supervisor.setNextCode file, which said if you get an error, run this other file, but you could also just say reruncode.py. Both of these might work. So if other people have ideas about this, that would be great. Some of you have had more experience writing networking code than the rest of us, and you're more familiar with these kinds of errors, and if you can contribute, that'd be terrific. And eventually the idea would be to redo the learn examples and perhaps come up with a few canonical, simple examples that people can then copy. So are there any other suggestions that people would be interested in mentioning? I'll add one thing to the alternative as you talked about so far. I know one of the people who has been having these problems with Matrix Portal is my friend Wintaru, and he's talked to you, Dan. But his problems as far as I've been able to understand them are the VM locks up or something. So in that case, using the actual hardware watchdog to rescue the whole microcontroller in that case is another thing that you might want to do. And I think you may end up doing more than one of these things to get the fully robust program that you need in the end. And this is due probably to perhaps there are some errors in the ESP IDF, we might be using it wrong or we're running out of some resource, we're not really sure. Or it's some very uncommon interaction between the Matrix Portals, the RGB Matrix Display which gets pretty low level and something else. I know you've looked at it and it's not obvious what's going on, but you don't get back to the REPL. You don't control C out of it or any of those things. So it's some bug but what bug is it and we don't know. But using the hardware watchdog, which I've told him to do and he hasn't, seems like what would be the fix in his particular case. I'm sure it's true that in commercial products, having a hardware watchdog is really important so that people don't have to, because you want to reduce your support cost. So if the thing will restart automatically after it gets stuck, that's very helpful. This is just something that I will be starting to look at and I will ask some of you for help at some point. So thank you and you can think about it in your spare time. We also talked about a safe mode.py. That's another thing that we could use for a lot of things and these should be relatively easy to implement. Okay, and I see those comments in the chat. I'll take a look at those later. Very interesting, kept one of the, Keith says Wi-Fi manager class with the tri-accepts has kept one of their ESP32S2 feathers online since November. That's fantastic. Like I have a use for something, a long-term Wi-Fi monitoring thing but it would be at a remote location and I'm trying to figure out what's the best thing to do about that. Okay, Katnie, you had something that you wanted to bring up as well. I do, and actually I think you're the one who can answer it. Can you clarify where we're at with the type-hint PRs and so on? Because I know we discussed it last week, I think, or maybe the week before and folks are still working on new type-hint PRs and I'm vague on what our plan was with how we were going to deal with that in the interim between something you needed to do and something that hasn't happened or something to that effect. I'm fuzzy on it. Yeah, so there's a PR that I haven't finished about doing from underscore future import annotations and I will finish that and Tectric in particular, thank you for doing all these PRs but it might be the case that if we need to add more types or we need to fix an underlying infrastructure thing we might hold off on them and don't take it personally. We'll get to them just to make sure that we have the infrastructure in place. One interesting thing, for instance, is that if you look at the CPython infrastructure the annotation libraries and stuff a lot of them are PYI files and those are not directly importable but you use them to generate stubs and to use tools like MyPy and so maybe eventually we want to convert CircuitPython typing to be a library that is not really importable but is simply there for use by the type checkers. So there's a way to check whether or not you're doing typing. You can do from typing import all caps type checking and that's false when the program is running and true when the type checker is running and so that's a way to avoid actually importing these things at all but that also requires making from future import annotations work so there's kind of a pile up of things here and I've started to do some more research about understanding this but I haven't finished. So rest assured we're working on it but it has brought up a whole bunch of things like versions of Python and how we should be what's the right way to do the imports that we were doing in a pretty casual way before and we have to be more careful about it. Okay that's what I have to say about it. So should we then have folks stop working on the type NPRs for now or are they okay for now to continue working on them? I think it's fine to work on them some of them we might not merge right away okay we might put them on. That's what I... But I wouldn't say like stop I mean it's still great to have that work done it's just that we may have to go back for instance and edit some of them or something one reason to hold back on merging them is that if we eventually are going to have to change the imports that are atop of any library that has annotations then we want to minimize what we have to do. Okay. So is there a way for someone reviewing the PR to recognize if it's okay to go in or needs to be held or is there some kind of testing that they could do that will allow them to see if it's okay? No I mean I think not really I mean I just... I originally was talking about this holding business before I had made a previous change to the library which is now fixed it had to do with moving stuff out of Blinka and moving stuff out of the core and that PR got merged already so it's less on hold than it was. Okay. Part of what brings this up as well is that when for the PyCon sprints I like to be able to point folks to the good first issues and obviously if we're still changing things on how typents are to be done in CircuitPython we will probably need to go through and remove the good first issue label from those issues which is not a problem I just need to know you know like a week ahead of time what the status is and that's not until the end of April. Yeah maybe I'm... and I'm kind of thinking on the fly here I mean maybe this whole hold business that last week and maybe it's unnecessary now I haven't thought about it hard enough. Well this currently really only applies as far as I can tell to Tech Trick and Tammy makes things. I think those are the two folks who are most active on those type int PRs so I just wanted to... I didn't want them to be putting in work that we weren't going to do something with but it sounds like they're both fine to continue working on them for now and if the way we do them changes we'll let everybody know at that point. Yeah yeah. Does that sound good? We really appreciate it and the people who use IDEs love this because they really love the type annotations then they like you know this auto completion and stuff like that. I didn't even know what type annotations were before we started this and I use PyCharm and it is so nice. Yeah right and so it's even nicer when you give it hints. Yeah exactly. So okay excellent. I just wanted some clarification on what the deal was there and wanted to make sure that people weren't doing work that we weren't going to be able to use. Okay. So thanks Dan. Sure you're welcome. Okay so is there anything else in the weeds? If not we can wrap up. Let me take the timestamp for the wrap up. So thank you all for participating and next week's meeting is on Monday at 2 p.m. as usual. However, Daylight Savings Time starts in the U.S. next Sunday in the middle at 2 a.m. or whatever. So spring forward fall back. So if you live in a country where that is not synchronized with U.S. and I think none of them are in terms of Daylight Savings Time make sure that you check the local time with respect to 2 p.m. Eastern time in the United States. It'll be UTC plus four if someone has written in here. Thank you very much. You can use our online calendar with your favorite calendar app so you can see the meeting in your local time zone. Okay. Anything else? If not, thank you very much and thanks everybody for attending and I will stop recording.