 Hello everyone. This is the CircuitPython Weekly Meeting for January 23rd, 2023. My name is Tim, and I am sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python that's designed to run on tiny computers called microcontrollers. The CircuitPython development is primarily sponsored by Adafruit, so if you want to support Adafruit and CircuitPython, consider purchasing hardware from adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafru.it-discord. We hold the meeting in the CircuitPython DevText channel as well as the CircuitPython Voice channel. This meeting typically happens on Mondays at 2pm Eastern time, 11am Pacific time, except when that coincides with the US holiday. In the NoteStock, there's a link to a calendar that you can view online or add to your favorite calendar app. We also send notifications about the upcoming meetings via Discord, so if you'd like to receive those notifications, ask to be added to the CircuitPythonista's role on Discord. There's a notes document that accompanies the meeting and the recording. The notes document contains timestamps to go along with the video, so you can use that to view only the parts of the video that interest you most. The meeting tends to run 45 to 60 minutes, so that gives you a chance to skip around. After each meeting, we post a link to the next meeting's notes document in the CircuitPython Dev channel on the Adafruit Discord. You can always check the pinned messages throughout the week to find the latest notes document linked inside there. You can add your notes at any point throughout the week that you like. If you wish to participate, but you can't attend, you can leave hug reports and status updates in the document, and the host will read those for you when the time comes during the meeting. 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, the libraries in Blinka. That one 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 that folks are doing. Take the time to recognize awesome folks in our community and beyond. Hug reports will be the first of our two round robins. That's where we'll go down the list of folks as they appear in the notes document for that one. Same thing for status updates. That's our second round robin. Status updates is an opportunity to sync up on what you've been up to. Take a couple of minutes to talk about what you've been doing in the past week and what you expect to be doing in the next week until the next meeting. The fifth and final part of the meeting is called in the weeds. In the weeds is an opportunity for more long form discussions. These discussions could come out of status updates or they could be things identified ahead of time as too long for status updates. That covers how the meeting will go. Next up we will look at the community news for this week. Let me take the first time stamp here. First item in community news this week is we have hit a milestone of 400 circuit python libraries. This week's circuit python hit a huge milestone. There are now 400 libraries available for circuit python. That includes the Adafruit libraries as well as the community contributed libraries. The 400th library was contributed by Durbrotter71. It was a UUID4 library. I think that's the GitHub user name. It must be Durbrotter71. It looks like the name Trudor is here as well. Thank you to that person. They submitted their first pull request and contribution. Thank you to everyone who has contributed anything to any of the libraries. We would not be at 400 without the help from everyone. Thank you to everybody for working on that. The next item in the newsletter is a new video that was published this week called Troubleshooting Circuit Python and More. This is a video that covers troubleshooting the circuit python installation as well as board and Mew issues. It's a guide for new students. This is a video put out by Professor Gallagher, who some of you may know, a prominent community member. This walks you through several of the most likely reasons that your project or device may not be working how you're expecting and shows you how to solve those. That was a really great resource to see made available. Next up is a tiny micropython robot, MeetSmarz Mini. The smallest robot that maker Kevin McLeer has ever made has two motors and a laser time of flight sensor to detect objects. It uses a Pimeroni Tiny 240 or 2040, I should say, board that is programmed in micropython. There are links to learn more about that as well as a photo in the note stock if you're interested to Twitter as well as a link from Kev's robots. The last newsletter item for today that's in the notes for this meeting at least is a project called OpenMuscle. OpenMuscle is a project that's designed to provide biometric machine learning training data for use in prosthetic technologies. It uses an ESP32S2 with a Hall Effect sensor and micropython. There are links there to a Twitter thread as well as the GitHub project and a YouTube video that explains what's going on there. So that was a pretty intriguing project. So check that out if you're at all interested in prosthetics or even just using microcontrollers to assist in health and fitness and things like that. So that was all of the items in the notes here for the newsletter, but let me wrap up by telling you a bit more about that newsletter. The Circuit Python Weekly newsletter is a community-run newsletter that's emailed every Tuesday. The complete archives are available at AdafruitDaily.com. It highlights the latest Python on hardware-related news from around the web, including Circuit Python, Python and micropython developments. To contribute your own news or projects, you can edit next week's draft on GitHub. There's a link to that in the notes doc. You can submit a pull request there if you'd like. You can also tag a tweet with hashtag CircuitPython on Twitter or you can email to cpnews at Adafruit.com. Next up is the state of Circuit Python, the libraries, and Blinka. So I will read the overall section to start with here. I'm standing for that. So overall, this week we had 31 pull requests merged by 16 authors, a couple of names that are highlighted here as perhaps newer folks or folks that don't contribute as frequently. Mushroom, let's see, Mushroomrec, Mark McGookin, RealCoreBB, and Durbrotter71. Thank you to all of those folks as well as everyone else who is a more frequent or recent contributor. For those 31 pull requests from those 16 authors, we had five reviewers. So thank you to all of our reviewers. Looks like a relatively normal list of folks there. And rounding it out, we had 25 closed issues by nine people with 15 issues that were opened by 14 people. So that's it for the overall stats. Scott, are you available to tell us about the core this week? Totally. Can you hear me? Yes. Sweet. Okay, stats for the core. We had 10 pull requests merged from seven different authors. I'm going to butcher this. Matting Machik is new, but doing some bitmap tool stuff, that's great. Dave Putz is back to do some fixes, along with Jay Posada, 2020, and Retired Wizard are all relatively new folks. We had two reviewers, Dan and I. As always, we're looking for more reviewers. I saw some newer reviewers on the library side, so thank you for that as well. We have 22 open pull requests. A number of those are drafts. So as always, if you're involved in any of those that have been kind of stopped or not moving forwards, please take a look and see if now's the time. We have six closed issues by five people and four opened by four people. So we're net down two, which is great. And we have a number of people involved in that as well. We have 591 open issues. We have six of those that are open on the 8.0 milestone. A number of those I think we're waiting for responses. So if you're working on an 8.0 issue, please check on that as well. We do want to get to a release candidate hopefully this week so that we can get 8.0 out the door. We've started having discussions about new features for 8.1, which I just added to Milestone after these stats were taken for. And then we also have issues, bug fixes for 8.xx as well. And I think that's it for the core. All right. Thank you, Scott. Next up, I will send it over to Katnick. Can you tell us about the libraries for this week? Yes, I can. So this section applies to all of the Circuit Python libraries, which is everything in the community bundle, as well as everything that starts with Adafruit underscore circuit python underscore. This week we had 18 pull requests merged from eight different authors, including a couple of the new folks that were already identified. And of those merged pull requests, four of them were 21 days or older, all the way up to 87 days. So it's really excellent. We've had four this week, much older pull requests merged. So I'm glad to see we're still getting through a lot of that. And that leaves us with 43 open pull requests. We had 17 issues closed by five people and eight open by seven people, leaving us with 600 open issues. 84 of those are 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 a list of the open pull requests and a list of open issues. If you're interested in reviewing, check out the list of open pull requests. If you have the hardware tested, if you don't take a look at the code, let us know if you see anything, syntax, spelling, that sort of thing. Leave a comment on the pull request and let us know that you did that. That's always super helpful. And once you're comfortable with that, we can talk about leveling you up to the review team. If you're interested in contributing code or documentation, check out the open issues. Find something that speaks to you and leave a comment, let us know you're working on it, and we're always available to help. If you're new to everything, good first issues are a great place to start. We have a guide on contributing to Circuit Python using Git and GitHub, and we are always available on Discord to help you out. So don't let the process intimidate you. We want to make sure you can contribute in a way that works for you. In terms of PyPI weekly download stats, we had 100,554 PyPI downloads over 306 libraries, and below that is listed the top 10 libraries. Again, as usual, the top three or four are pretty typical, but it's always interesting to look at the bottom half of that top 10 because it seems to change out quite a bit. In terms of library updates in the last seven days, the new library we have is Circuit Python UUID4 by Dare Broader 71 and a number of updated libraries as well, which I will not list off. Overall, we reached 400 Circuit Python libraries. This number includes both Community Bundle libraries and Adafruit Circuit Python libraries. The 400th library was a community library, Circuit Python UUID4, authored and submitted by Tudor, who goes by Dare Broader 71 on GitHub and Discord. This is an exciting milestone for us, especially with the 400th library being a community library. We're continuing to evolve how we include community libraries in our ecosystem, including learn guides, the library reports, and more. For example, we just updated this report to include Adafruit and Community Library updates in the same list. And as the community continues to grow, we will as well. So thank you to everybody who contributed for that, and that's what I've got. Excellent. Thank you, Katnie. Always great to hear about the latest goings-on in the library world. Next up, I will pass it over to Melissa if you could tell us about Blinka. Yeah, Blinka is our Circuit Python compatibility layer for MicroPython, Raspberry Pi, and other single board computers. And this week, we had three pull requests merged by three authors and three reviewers. There are currently nine open pull requests, and there were two closed issues by two people and three open by three people leaving a net of 89 open issues. There were 23,290 Pi PI downloads in the last week, and there were 8,862 Pi Wheels downloads in the last month, and we are currently at 101 boards. Awesome. Thanks, Melissa. Yes. Next up is going to be the first of our two round robins. This will be the hug report section. Hug reports is a chance to highlight folks in the Circuit Python community and beyond for doing awesome things. I'll start, and then we'll go down the list alphabetically or however they appear in the note stock, which is hopefully pretty close, but we'll just follow the doc no matter what. That will give everyone a chance to participate. If you're text only or missing the meeting, but you have hug reports in the notes document, then I will read them off once it's your turn. So hug reports for me this week. Thank you to Bablok B, who worked on some fixes inside Blinka Display IO Pi Game Display, as well as some discussion with me in an issue comments back and forth about the API for that library. This person also made some sort of related fixes in Blinka and Blinka Display IO as well. So thank you to them for all of their work. Hug report to Mate Mecek for working on new functionality for the Bitmap Tools module in the core to be able to draw polygons inside Bitmaps. Hug report for Jose David for jumping back into the fray of Display IO widgets and things as well as typing issues for the libraries, and then a group hug for everybody as well. Curse me, I forgot to take a timestamp for myself, but I'll take one for the next one, which is CGrover, who's text only, and CGrover has a group hug for everybody. Next up then is Dan. Okay, thanks. So thanks to MicroDev, who's working on ESP Now support for the expressive boards. It's a draft right now and is in turn, but it looks like you could probably get it in for some 8xx release after 800. ESP Now is this proprietary, but it's an expressive protocol that lets expressive chips talk to each other directly without using a router. So kind of maybe like BLE advertising or something. I'm not really sure how it works, whether it's, I think it's UDP-ish, but it's interesting and a lot of people have asked for this because it's much easier to get going than setting up a Wi-Fi network. So we'll continue to look at that. And MicroDev's work is based on some previous work that other people have done, but he's like getting it into shape for a sake of Python, which we really appreciate. And then thanks to Anecdata, who has been doing a lot of testing of expressive Wi-Fi issues, and I really appreciate that because the testing is really thorough and we're making progress trying to track down what's actually wrong here. Okay. All right, thanks Dan. Next up is David Glada, who's not present, so I will read. They have a hug report for John Park for presenting and paint your dragon for adding support for more joysticks in the RP2040 NES emulator. Not strictly CircuitPython, but was related to David's 2023 CircuitPython post. Next up is DJ Devon. Thank you. I have a hug for FOMI Guy for hosting the meeting and for your weekly streams. Always learn something and a group hug. Excellent. Thanks, DJ Devon. Next up is Jeff. Hi. So I wanted to start off by thanking two friends of mine, Chris and Seb, for a week-long in-person hack fest on Chris's CNC lathe. They're not in the CircuitPython community, but I wanted to thank them here anyway and kind of use that as an explanation of why I was away. A hug for you, Melissa. I hope you're recovering well. And last of all, a group hug. All right. Thank you, Jeff. Next up is Jose David, who is text-only. Jose has a hug report for TechTrick for the improvements done in the DisplayIO Cartesian library that after Jose's deep sleep, he's just found out this week and also more recently taken the time to review the datasheet for the LIS 3DH sensor. And then a hug report to me. Thanks for all your hard work. So thank you to Jose for those. Next up is Catney. Hello. First up, I've got a hug report for TechTrick for updating the library report to combine the community libraries with the aid-proof specific libraries in the library update section to Dare Broader 71 for submitting the 400th CircuitPython library and for it being their first contribution to CircuitPython project and their first PR to the project as well. A group hug to everyone who has contributed to the CircuitPython libraries in any way, hitting this milestone couldn't have happened without all of your support with everything from authoring to reviewing to filing issues and finding bugs to documentation, et cetera. It's all super crucial. Welcome back to Melissa. Also welcome back to Jose David. Another hug report for TechTrick for blowing out my inbox with library updates. Also sending well wishes to TechTrick and his partner and a speedy recovery to his partner. Everything's good, but they had a medical situation this past weekend. And a group hug to the community. All right. Thank you, Catney. Next up is Micah Melissa. Hello. I wanted to give a group hug, or I mean, give a hug to Dan for taking care of reverting the code. TechTrickPython.org PR, which apparently broke it while it was gone to a family guy in TechTrick for responding to some blinking issues in PRs and a group hug to everyone else who took care of things was up for surgery last week. Excellent. Thank you, Melissa. Next up is Mark Gambler, who's lurking. So I'll read. Mark Gambler has a hug report to Tanute for gathering together the posts and then as well for everyone who posted a CircuitPython 2023 post. Mark enjoyed reading all of the varied responses and a group hug to all as well from Mark. Next up is Microdev. So would you like to read yours, Microdev, or I can? I'll read, I think. Microdev has a group hug to everyone. Next up is TC Franks. TC Franks, I think, is not in the channel here. Yeah, so I will read TC Franks. They have a hug report to Tetrick and FomeGuy for patiently coaching me through my first 100 PRs. Wow, that's amazing to hear. A hug to Tetrick for encouraging me to register and complete a successful Hacktoberfest and a hug report to the community for patience and excellence. That's all great stuff to hear. So thank you to TC Franks for leaving that. And next up is Scott. Hello. First, I have a hug to Retired Wizard for switching the IMX RT to the low power RTC interface, which means it should keep the time when using the low power input. A hug report to Dave Putz for improving the NRF Next Reset process. A hug report to Zodius Infuser from Pimeroni for the interesting native IO expander draft PR that they have for a board that they're working on. Thank you so much for checking in early about that. Glad we could give you some feedback. A hug report to FomeGuy for testing and reviewing all of the WizNet changes. There's been a ton, and it's been really helpful for you to do that. And then a new face here, G. Niverov. Thank you for the good async discussion last week. Excited to see the brainstorming on it and excited to see what comes of it. So that's it for me. All right. Thank you, Scott. And that rounds out our hug report section. So next up we'll move on to the second of our two round robins, the status updates section. Status updates is our time to sync up on what we're doing. I will start, and then we'll go through the list alphabetically. Or again, as they appear in the note stock, it will give everyone a chance to participate. When I call on you, you can take a couple of minutes. Tell us about what you've been doing since last week's meeting and what you will be doing until next week's meeting. It's an opportunity for you to provide tips and tricks relevant to what people are working on. If a discussion does become too much for status updates, then we can move it down to the in the weeds section. So I will start out the status updates. So for last week, I tried out hooking up the in iSpy display, I should say, and using display IO to draw on it. And that went all pretty well. Didn't have any issues with that. So it's great to see kind of another another option out there for hooking up displays to your projects. I started implementing bitmap tools for Blinka display IO. So that's a module that we have in the core that's capable of drawing and manipulating bitmaps in various ways. But we don't currently have Blinka implementation. So if you wrote code that uses it, then it won't necessarily be portable today. But I've started working on that so that hopefully one day in the future it will be. I tested some changes in Blinka display IO, Pi game display. There was specifically a really nice change that Bablok be submitted that allows that library to bring back to auto refresh functionality, which kind of got butchered with a recent update where I kind of got rid of it to resolve an issue that came up with threading. But there was actually a much better solution that allows it to keep its auto refresh functionality. So that was really awesome. I also figured out how to use the deep sleep and pin alarm wake up functionality in conjunction with the mag tag library. I wasn't quite sure exactly how to do that. I figured it would be possible. Somebody had asked about this in Discord over the weekend. So I took that and grabbed my mag tag, figured out a way to do that and then submitted a PR to document it and add an example. So folks hopefully can find that in the future. For next week and a couple of things that I've started today, I'll be brainstorming and starting to try out some ideas for a library that will provide a consistent game controls button API across different devices. So different devices could have different pins, different numbers of buttons, things like that, but ideally we want to have a way to write a game that would run on all of them and not have to care too much about the fact that they have different pins or anything like that for at least the most basic game controls like D-pad and AB start select, that sort of stuff. So that'll be something I look into. I will be trying out the remaining PR that's in the Ethernet library. There's one more sort of major one. I think there's a smaller one there as well that I'll look into also, but there's one sort of a meteor one there for this week that I will get to. And then another thing which I have started today but not made it through all of them yet is reading the CircuitPython 2023 posts. So I've seen lots of great stuff in all of those so far. And I will finish them up this week. So next up I will send it over to Dan. Okay, thanks. Okay. So since the last meeting, mostly I've been trying to work on 8.0 bugs. We have some several people who have network crashes, which happened after many hours of the network running. And I've been trying to reproduce those not really successfully. We talked about this in internal meaning just today. And we probably would like to make it easier for you not to fall and to recover from falling into safe mode in certain situations. So even if something goes horribly wrong, your program can restart. And we will try to do something like that, like post 8.0. So you'll have more robust stuff, even the presence of software errors that might send you into safe mode. And then another thing that I just started is that we are using the ESP IDF version 4.4, but we were behind on it because we have our own fork to fix some bugs that weren't fixed upstream. And I'd like to bring that forward to see if it fixes any of the existing Wi-Fi problems or the ESP32S3 I2C problems. So I'll test that out. And we should probably just move forward in general because there are a bunch of interesting bug fixes there which may be fixing bugs that we don't know we have. And I will continue to review a bunch of PRs that pass by way. We've got a bunch. I spent another small amount of time working on PRs, reviewing PRs which is great because it means we have a lot of contributors. Okay, thank you. Alright, thanks, Dan. Next up is David Glauda who's not present. I'll read. There are broken down into CircuitPython and non-CircuitPython. So on the CircuitPython side of things, convinced a co-worker to acquire one or two CPE. I think that's Circuit Playground Express, the 4H version of that device to build a mouse jiggler. And his girl could learn STEM with it. Connected my C64 keyboard to a Pico using Red Robotics Pico to Pi adapter and spent hours with the pen and key mapping to be continued this week to have something working and maybe a VICE slash PC mapping or VICE plus PC mapping it says there. For non-CircuitPython specific stuff, David writes, replicated the NES emulator with an RP2040 connected to HDMI and a PS4 joystick. Received my Olimax Aegon Lite 2, a Z80 8-bit computer. Tested the VGA output on that as well as tested eight different USB keyboards. Only three are PS2 compatible and out of those three only one is QWERTY, which is less than or equal to the number that it looks like David would like. So sounds like David's on to look out for some additional keyboards perhaps. Next up is DJ Devin 3. Thank you. There's been more progress on the TR cowbell enclosure. I'm printing in sections is starting to get tedious because there's four sections and because the bed is shorter than the entire board. I'm looking into bed extension parts for the Ender 3 S1 Pro. There's currently nothing available for it. The most popular sites don't have anything for it yet and it has to be specific for the S1 Pro because it's designed different. It's got this big shell and it's completely different than the S1 or the Ender 3 Pro. It's like this whole own thing. But the plan is to make the bed nine inches by two feet long and I've already sourced most of the parts for that. So it's just going to be getting over hurdles of calculating acceleration and inertia. I even found a bed heating element that's eight by nine by 18. So you can get heating elements in these ridiculous custom sizes. I finished printing section three of four and everything finally fit great. So that one is like completely done. Moving on to section number four and I finally got a Pi 4B, or Pi 4, one of the Pi's fours, at a fair price in order to run octa-print so that if a print does fail, I can monitor it and it might automatically catch it. I think that's how octa-print works. I'm still kind of new to the whole 3D printing stuff but I heard that that might help some failed prints. So that's the one I'm at with that. Nice. Thank you, DJ Devin. Next up is Jeff. Hello. I just marvel at how much you bite off, DJ Devin. You're an inspiration. So thanks for all that. Anyway, but I also need to find my notes. So as I covered, I was out last week. This week is starting with some catching up. I've got more email to get through. I have just one item of guide feedback that I need to look at. I need to pull a project out and check that the wiring is described accurately in the text and photos. Then after that, I'm going to finish the next computer's bus mouse guide. I need some text. I need some photos. I need some fritzing diagrams. And then after that, later in the week, I plan to move the SPI TFT emulator that I wrote a couple of weeks ago over to Arduino. And I'm just working on a PR to fix the product ID for the Feather S2 reverse TFT. I missed that there was already a PID allocated for it in this internal document that Adafruit maintains. And I allocated a fresh one and that was incorrect. And that only affected circuit Python because that's the only one I did. It didn't affect the Arduino environment because it was above fine. And that's what I'm up to. All righty, thanks, Jeff. Next up is Jose Davide, who is text only. So I'll read. Last week, Jose was working on some small stuff and reviewing changes in the libraries. They've done some updates in circuit Python personal libraries to be compatible with circuit Python 7 and 8. Worked on a small house project with an accelerometer connected to an Adafruit Feather ESP32S3 to detect when the sump pump is working and alert me in Home Assistant. This week, continue the updating of old circuit Python libraries. We'll watch developments in Bitmap Tools Core by Mate Macheck and DisplayIO by Tim, me, and take it from there to implement some add-ons to libraries. Circuit Python related slash personal work on Adafruit Titano to select a color for an LED strip in a color wheel picker in Circuit Python and send it via MQTT to a Home Assistant to change the color. That certainly sounds pretty cool. Next up is Katny. Hello. So last week we as a background, we have been updating a lot of our displays to have the iSpy connector which allows you to connect it to a microcontroller or a breakout using a flex cable instead of soldering. So we need to update the board guide or the display guides and the plan is to use one template page copy and paste a paragraph into the overview and then add to the pinouts page what pins are necessary for the iSpy connection. So the iSpy template is started it's probably 90% done. The overview text update is completed and approved and I blogged up a guide update. So this week finish the final section in the iSpy template get approval on that. Once approved update one guide that's the guide I'm going to update is the 1.5 inch 240 by 240 TFT which includes the 1.3 inch 240 by 240 TFT I'm going to be splitting up the rest of the updates with Liz and I'm still considering completing my Circuit Python 2023 post but it's very late. So unrelated I got three new plants this weekend they're air plants which means they don't need or want soil the two larger ones are Tilancia stricta they have little cup-like hairs on their leaves called trichomes which water them you soak many of the Tilancia plants in water for 30 minutes once per week there's also a super tiny one that I posted an image to the chat little tiny one on the right is a Tilancia tectorum which has significantly more trichomes it actually looks like fur on the leaves and you only soak that one for a few minutes my two stricta plants already have magenta bits on them they eventually bloom one of them is already starting to bloom there are little white flowers on it and I am inordinately excited about these new plants so we'll see how it goes they need a lot of light and the specific watering schedule and I'm limited on on both so we'll see how it goes fingers crossed anyway that's me alrighty thank you catney fascinating stuff next up is maker melissa hello so since I was out for Tuesday through Friday missed the circuit python meeting last week so this is for the last two weeks I was out for surgery still recovering though anyway I worked on the circuit python installer and it's in a pretty good place now although I'm running into some course issues with the firmware and bootloader at least for testing I believe that at least for the uf2 and bend files it should be easy to get around once the code is live because if the download circuit python.org domain doesn't work we can at least use the amazon s3 and I know that does the tiny uf2 bootloader will be a little trickier though because I think we'll need to add some GitHub action so it's up to the s3 get around the course issues apparently there is an issue with the code editor with a PR while it's gone and I'll take a closer look at that let's do one of my changes broke it so this week I'm doing lots of catching up including going over guide feedback and I need to chat with Brent and Lauren about the whipper installer not working for some folks and I need to try and get another PRN for the code editor I need to create a javascript library that is able to run the circuit python repo code and this will be needed for both the code editor and the circuit python installer and the code to do this was in the code editor PR I made it just needs to be decoupled in the package separately and I need to look at a way to get around the course issues with the installer and I need to try making the installer live and see what works and what doesn't and I just may end up make it so it doesn't show up by default unless you add some parameters so that people aren't running into broken links that's where I'm at thank you Melissa next up is Mark Gambler who's lurking Mark Gambler says he was thinking of looking at Anbee's request in the circuit python 2023 post about having native gif support in circuit python wanted to find out if there was interest in this before I get too far into looking at it my initial thought was to add support to display IO for it if there is interest I can take a run at starting it and have more detailed discussions in the weeds in a couple of weeks I will just pipe in and say I'm definitely 100% pro a gif implementation that sounds pretty awesome to me but next up in the list here I will send it over to Scott alright hello I need to do the wrap up post for circuit python 23 I know this will miss catney but catney can post to the blog directly if you choose to do that I fixed an issue with the belee workflow where if you type control C over the serial it doesn't interrupt things which I was able to test with a new version of bluefruit connect I fixed an rp2040 reset reason issue which was causing the pcow to not run the web workflow like the first time that you copy circuit python over and then if you added the settings it would still not do it this has to do with how they reset from the bootloader to the regular code they use a watchdog timer and we were classifying it as a watchdog problem even though it's really just a software reset so I fixed that the control C work diverted me into updating my bangle js2 PR branch that I have basically it's a watch that is an nrf52840 and it has no usb so it's all about the wireless belee workflow so I want to get that in because I have I just don't want to have to maintain it I think other people would like to try it and so I need to do some tests around how you get circuit python over it uses dfu so you'll need the nrf connect app to do it but I'll test that I have a from the store version of the watch that I'll be able to use as a tester as well thinking about that work got me it has an eight color memory display on it so there are going to be some display changes for it and that got me that and reading a book on my eink tablet got me working thinking about eink stuff again one of the pending items on that is working on the asep eink displays which are they turn out to be seven color displays which look pretty neat pimerone's got some of them and so I'm working on adding internal support to circuit python for those that's kind of the thing I'm working on now and then I'll like pop the stack off and get back to the bangle jazz stuff but yeah seven color eink support starting with the 5.65 inch display that I've got on my desk here I'm ordering the four inch and the seven inch as we speak and then once the bangle jazz support is checked in I'm going to pick back up on usb host and be off in a way hopefully but I should be more available this week as I will be doing less child care during the week all right thank you Scott and that is the last of our status updates so next up we will take it over to the fifth and final section of the meeting in the weeds in the weeds is an opportunity for more long form discussions these could either come out of status updates or they can be identified ahead of time you have any in the weeds topics please make sure they get added down at the bottom of the note stock there are a couple there so we'll start discussing those if anybody else knows of one you go ahead and add that now first in the weeds topic is from micro dev who's text only so I'll read the bullet points here micro dev says the IDF version 5 PR which is version 1 3 is kind of ready the PS RAM boards boot loop more importantly IDF v 5.0 adds a bunch of certs and firmware size is way past 14 0 8 K consider increasing it to 13 excuse me to 15 36 K before circuit python 8 to avoid a breaking change hoping we switch to IDF v 5 in version 8 dot X dot X if anyone has noticed the build arm matrix now builds 255 which in hex then is 0 X F F boards the limit is 256 will open up an issue for this so I will definitely say I don't know really too much about the IDF and that sort of stuff so I don't have any real response or thoughts on that personally well the build arm matrix thing is a catch thank you for looking at it and then for IDF 5 I I would like to still do it in 9 I think the other thing that we want to pull is a new version of micro python I'm just worried about stability and I would also like to take a closer look as to why it got bigger you know this is it shouldn't keep growing and so it would be interesting to see why the IDF keeps getting bigger and what we could do about it is my opinion if we need to increase it we can always increase it with 9 I'd rather not do it in 8 personally but I think what may happen is we'll do 8 1 and then we'll do a 9 Dan or Jeff have thoughts about that? I think that's true and I think also the thing to say is that once 8 is stable we'll make point releases on 8 but we can start doing 9 developments so we really will have 2 working streams then so we can go ahead and start doing the switch over and still have plenty of people who are willing to try it it doesn't have to be serialized I think the challenge that we have is we're limited to having one stable and one unstable release in a way that we've structured things we'll want to wrap up any 8.0 features that we would want to do as unstable before we start doing unstable lines well maybe we need to make it possible to have 8.1 8 is or something I don't know it's possible now but we couldn't also have a 9 alpha at the same time right no I mean to change circuitpython.org so that it would display 2 unstable releases? yeah I'm a little worried about fracturing where people who use unstable stuff is that's an interesting idea we already know we get a lot more people using the stable releases than unstable so I don't know I would like to be aggressive with 9 maybe we yeah maybe we make the decision to just not do an 8.1 and do do only bug fixes to 8.0 I don't know we should I need to talk with the micropython folks we should sync with them so that they get a release like 8.20 or 1.20 could be what we incorporate cause they're at 1.19.1 now I think I definitely think if you have something you need to be a beta and you have 9 as well that it makes a lot more sense to just put it all in 9 because exactly what you said like for me I wouldn't even know you know I'm deep into this and I wouldn't even know which one I should be testing for what right so I agree with your thoughts on adding it to 9 instead and just going ahead with 9 right cause we can do like IDF5 and the micropython update and call that 9 we don't need to wait to stabilize 9 for anything else so right so we were talking in text microdiv about ESPIDF and I moved, I'm not ESP now and I moved it to 8XX but we can move it back to 9 but just you know we can make it visible a lot sooner yeah and Jeff says in the chat that it would be nice if the 9 cycle was shorter than 8 totally agree with that I mean one of the things that I feel that we have some technical debt in terms of issue backlog and I want things to get fixed instead of moving on to new features all the time so I'm burned out on fixes though I'll tell you that but it's also nice to have a release to be able to say like oh sorry go back to 733 and I don't like to have to say that I think it's possible to focus on fixes and also still work on 9 I don't think those are mutually exclusive concepts yeah yeah and I think we've done a good job with like 732 and 3 like having those those bug fix bug fixes branched off it gets a little weird when we do something like SafeMode.py yeah we can do SafeMode.py and 9 we can do ESP now and 9 and 9 would be a moving target in terms of we might not go to 5 ESPIDF 5 we might not do the microprothen merge right away but that would all be alpha there'd be a lot of churn in alphas right and when the base is sort of more stable then we can start moving toward betas right and I suspect we'll probably want to do IMXRT kind of like proper support where we say call it stable 9 as well along with USB host yeah so 9 may have more features than 8 yeah I'd like yeah so I agree we should push to be more aggressive with 9 getting stable faster than 8 did I mean it got kind of hung up in the holidays um and just having me out a lot last year um yeah I the yeah we should we should I don't think we should change the flash size for 8 for ESP um in prep for IDF 5 we'll deal with that when we get there right maybe once the base things are changed maybe maybe 9 would be as long when we're long lived if most of what we're doing is adding functionality rather than churning the base so that is if 9.0 contains the upstream merge for micro python and it includes IDF ESPIDF 5 and well IDMX can be that's kind of that's true we can do that later that could be 9.0, 9.1 or something like that right because the thing that's forcing 9 is actually the micro python update because that'll include an MPY version right uh change okay does that make it clear yeah sounds like we got path forwards at least uh so the other in the weeds topic I will turn it over to Jeff to talk to us about that one all right this is an item that I saw Naradok bring up here on the discord and I just wanted to talk about it while we've got a couple of people who might have opinions um and also we were talking about an unrelated thing with Watchdog in our internal meetings so that may inform on to this so Naradok I think this the Genesis was a forum post that Naradok mentioned on discord so if on an rp2040 you enable the Watchdog and then you start writing to the circuit python drive uh I think this was from the host but it could apply either way uh that's a lengthy process and you could encounter a Watchdog reset during that time and now your circuit python drive is corrupt and obviously that's not good so I had two ideas I think there are probably other ideas um we could specifically during the flash write procedure make sure that while we're waiting for the flash to erase or write that we are regularly petting the Watchdog so that it doesn't count against um you know count against that time out and cause a reset um and the other would be to forbid enabling the Watchdog if the circuit python drive is not fully read only which would mean that neither circuit python code nor USB mass storage were allowed to write it um and I will create an issue about this after the meeting oh and Naradok if you have a link to that uh forum discussion um that would be cool if I was right about where that came from anyway and then I have a link in the notes doc back to that brief discord discussion it was last week or on the weekend I'm not sure what exactly that was so yeah thoughts about this um issue my thought is to manage the Watchdog during the flash write um and this is something I'm actually thinking about myself because the bootloader on the Bangaljs 2 I think sets up the Watchdog on the nrf and I don't think I could turn it off so one of the things I've got to figure out in my branch is that I just like added a Watchdog write in like that every time the background task runs like really aggressive um so that's another thing I've got to look at but it definitely makes me lean towards the first option which is like we need to figure out how to manage the Watchdog while we write to the flash um and that could be either user code or like the BLE workflow could be doing that as well yeah I mean there's a tension there between using the Watchdog to make sure that your Python code is working properly so if the background task were always calling it then the Watchdog would no longer serve as a check on your Python program as a whole but it could still be an improvement on the status quo so in the text chat, Naridoc clarifies the forum discussion was only tangentially about that thing Naridoc noticed these things when they were kind of testing in the vicinity of this user issue so I guess the original thread is probably not useful but yeah I, unless somebody wants to go a different direction, I will enter an issue asking for like the generic flash write code to pet the Watchdog using that that API I think maybe that will work um and I might look at implementing it but I've got a lot of stuff on my plate that is probably inline before that so if somebody else wants to pick it up that would be wonderful and probably the RP2040 is one of the most important ones to test although the other chips many of the other chips have Watchdog and a couple of you mentioned it's really aggravating that the Watchdog can't be disabled in the case of RP2040 that's definitely a deliberate hardware design decision that they made once you've turned on the Watchdog you can never turn it off except for when the Watchdog bites which is a little bit frustrating because yeah the other option would be to turn it off before you do these things but anyway um yeah so that's what I got and thank you alright thank you Jeff um and that was the last of our in the weeds topics so I will finish it up for us with a wrap up um so this has been the weekly circuit python meeting for January 23rd thank you to everyone who participated uh as a reminder if you want to help support Adafruit and CircuitPython and those of us that work on CircuitPython consider purchasing hardware from the Adafruit shop at adafruit.com the video of this meeting will be released on youtube at youtube.com slash Adafruit and the podcast will be made available on major podcast services uh it will also be featured in the python for microcontrollers newsletter you can visit adafruitdaily.com to subscribe to that the next meeting will occur at the normal time which is going to be next Monday January the 30th at 11am pacific or 2pm eastern time um the meeting is held on the Adafruit discord which you can join at adafru.it slash discord to be notified about the meeting and any changes to the date or time you can ask to be added to the CircuitPythonista's role over there on discord um and that's it for today we hope to see you all next week thank you everybody thanks everyone