 Okay, hello everyone. This is the CircuitPython Weekly Meeting for March 13, 2023. This is the time of the week where we get together to talk about all things CircuitPython. I'm Dan and I'm sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to support Adafruit and CircuitPython, you're purchasing hardware from Adafruit.com. We host this meeting on the Adafruit Discord server. You can join anytime by going to adafruit.com. We hold the meeting in the CircuitPython Dev Text Channel and the CircuitPython Voice Channel. This meeting typically happens on Mondays at 2 p.m. Eastern Time, U.S. Time, or 11 a.m. Pacific U.S. Time, except when it coincides with U.S. Holiday. In the Notes Dock, there's a link to a calendar you can view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you would like to receive these notifications in Discord, ask us to add you to the CircuitPython East as Discord role. As I mentioned, there's a Notes Dock accompanying the meeting. It contains timestamps to go along with the video, so if you view the video on YouTube, you can then use the Dock and skip around to find the parts of the video that interest you most. The meeting tends to run 45 to 60 minutes. After each meeting, we'll post the link for next week's meeting notes to the channel on the Discord, and you can check the pinned messages in the CircuitPython Dev Channel to find the latest Notes Dock. We hold the meeting in five parts. The first is Community News. The second is the State of CircuitPython Libraries in Blinka. The third is Hug Reports. The fourth is Status Updates, and the fifth is in the weeds. I'll explain each of those as we get to them. Alright, so now I'll set a timestamp for Community News. Let me press the right button. There we go. Okay, so there's a bunch of interesting things going on this week in Community News. Set these headlines heading so I can read them more clearly. Pi Day is March 14th, 314. That was the first three digits of Pi. As everybody knows what Pi is, if you took geometry, Pi Day is an annual opportunity for math enthusiasts to recite the infinite digits of Pi, not all of them. Talk to their friends about math and eat Pi, P-I-E, and you go to PiDay.org to find out about that. Pi Day is also a celebration of celebrating Raspberry Pi. You can pull out your favorite Pi and have some fun and consider donating to the Raspberry Pi Foundation. There are links that I will update the links that are in the note stock. I pasted this quickly from the newsletter and it lost the links for the moment. Okay, now another interesting thing that's coming up is that Github will start requiring two-factor authentication. Now I hope you all use two-factor authentication on things as vital as Github, but if you don't, by the end of 23, you're going to be required to do that. They'll start rolling this out today is what it says. Next up, Make Magazine interviews Devere and Cell, known as Geekmang projects. Frequent Python is the Devere and Cell. Geekmang projects on Twitter talks to Make colon about the creative process making blinking projects and much more. You can find there's a link to Magazine there. And finally another very interesting thing in this week's newsletter is that about using certain Python in neuroscience. Embedded.fm podcast talks to Peter Griffin in episode 444 about operant boxes, projects, embedded systems and more. At the 29 minute 30 second mark, Peter talks about using circuit Python operant box programming. And there will be links to that if you'd like to find out more about it. So where did all this news come from? It comes from the CircuitPython Weekly newsletter, which is a CircuitPython community run newsletter emailed every Tuesday edited by The Great and Barela. The complete archives are available at a link in the notes doc. This newsletter highlights the latest Python and hardware related news from around the web, including CircuitPython, Python and MicroPython developments. We'd love to have you contribute things to this newsletter. You can make our to the newsletter repo. There's a link to that. You can also tag a tweet with hashtag CircuitPython on Twitter or Mastodon or email cpnews at Adafruit.com. Any of those are fine. Thank you. Alright. Next up is the state of CircuitPython libraries in Blinka. This is a quantitative view of the entire project. It gives us a chance to help the project separate from the qualitative stuff that we talk about in status reports. We'll talk about the project overall and then separately discuss the CircuitPython core, the libraries and Blinka. Okay. Overall in the past week 34 poll requests were merged by 24 authors. There's a lot of people I don't recognize, Matamaciek, let's see, Xenomorphius, Edenidzera, Mathjusnl and maybe some others I've also mispronounced. There were eight reviewers and there were 14 closed issues by eight people and 16 opened by 13 people. So that's interesting. So we're not quite keeping up but that's okay. People are finding things to fix. Okay, Scott, would you be able to read the core? Yeah, totally happy to. Thanks, Xen. So for the core, we had 18 poll requests merged from 13 different authors. So thank you to all of our authors. We have four reviewers. So thank you to our reviewers. We have 32 open poll requests which is again a little bit above where my threshold is. I'd like them to fit on the same page. A bunch of those are graphs and unfortunately do get counted towards the number that shows up on the top of the page. So if folks have any boards that they'd like to help out with, please take a look at those. I think a lot of those are board editions. Issues-wise in the core we had nine closed issues by four people and five opened by five people. So we're net down four which is not always the case. So good work in the core folks. We have 634 total open issues and we have eight active milestones. We have no open issues for 8.0.x which is great. We have nine open for 8.1. So those are the kind of two most urgent things. And then we have an even 500 open issues on the long-term category. We have two issues not assigned to milestones. So we'll have to take a look at getting those triaged and assigned to the appropriate bucket. And I should note that these milestones are generally used for us who are funded by Adafruit to prioritize circuit Python work. If other folks want to work on something that may be marked long-term, that's still welcome and we're happy to support you doing that. So don't be afraid to pick up other work even if it's not in those higher priority milestones for Adafruit folks. That's it for the core. Okay. Thank you, Scott. Okay. Jeff has volunteered to read about libraries. Catney's out this week. So thank you, Jeff. Hello. So in the libraries, we had 12 pull requests merged overall by 10 authors and reviews by six reviewers. So thanks to all of those folks, there is a list of the merged pull requests in the notes document. I'm not going to read that out. That leaves 39 open pull requests across all of the libraries. Issues-wise, there were four closed by four people and 10 open by nine people. So in the libraries, we saw the number tick up a little bit, leaving us 605 open issues. 76 of those are marked good first issues. And that brings me to talk about contributing to circuit Python. And the place to start, if you're interested in helping us out, is circuitpython.org slash contributing or just go to our front page and click the link in the banner. So if you're interested, that's where you can find all the open PRs, open issues, and a list of library infrastructure issues. This is a great place to start if you're looking to contribute to circuitpython for the first time. You can start the issues by label. So search for good first issue if you're just getting started, or for bug or enhancement if you're looking for something a little bit more complicated. We have a guide on contributing to get and get hub, and we're always available to help you get started with that. So let us know if you need any assistance. All right. And then I've got just a little bit more data before I hand it back to Dan. We track our PyPI weekly download stats, and last week across 308 libraries, there were 140,419 PyPI downloads. At the top of the list are such popular libraries as Adafruit Bus Device, Adafruit Request, NeoPixel. And as far as library updates in the last seven days, there are no new libraries, but we updated two libraries, MiniMQTT, and within the community bundle, a library called Uplot, and that wraps it up for the libraries. Okay, thank you, Jeff. One thing I'll note is that because of a mistake I made, there were no bundle updates for a week, and so that's being fixed and that new bundle was just published an hour ago or so. Okay, next up is Blinka, and Melissa, could you read that section? Yeah, Blinka is our Circuit Python compatibility layer for MicroPython Raspberry Pi and other single board computers. And this week we had, sorry, four pull requests merged by three authors and one reviewer. There are four open pull requests at the moment. There was one closed issue by one person, one open by one person, leaving a net of 96 open issues. There were 13,037 PyPI downloads in the last week, and 9,591 PyWheels downloads in the last month, and we are at 101 boards. And that's it. Okay, thank you, Melissa. Okay, next section is Hug Reports. 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 to give everyone a chance to participate. If you're text only or missing the meeting but you have Hug Reports in the notes document, I'll read them off as I get to you in the list. So I'll start. Thanks to TAC for helping updating TinyUSB, which is something I'm doing at the moment. And he answered some questions of mine, fixed a bug, and also I had some problems with the RP2040 update and he knew immediately what to do this morning. And so I should be finishing that soon. And thanks to Greg Nevorov, who's, we had some extensive, more extensive discussions about asyncio, and he's doing rework of the asyncio library and the internals, and has some PRs that we now have to study in detail. Okay, next up is Foamy Guy. All right, thanks, Dan. Hug Reports this week, thank you to NeerDoc and Jose David, who both put in some fixes in the display text library, echoing what you said about Gnevorov for jumping into all of these asyncio improvements. And then Hug Report for Brent Yee, who is, I think, a first time contributor or perhaps infrequent contributor, who submitted some typing fixes in one of the libraries this week. Thanks. Okay, thank you. And now we've got Jeff. Hello. So I first wanted to thank Micodev for working on the RP2040 Watchdog pull request. I was absolutely sure that the hardware wouldn't do what that PR adds, and I'm happy I was wrong, and that I checked on my fax before I commented on the pull request. Thanks to Mark for continuing to work on the on-disk GIF memory problems, even if there's not a full resolution yet. Dan, I know there's something I wanted to thank you for, but I couldn't figure out what it was. So consider yourself thanked anyway. And finally to NeerDoc for fixing a problem that I ran into with a multi-line label that had blank lines. Okay, thank you, Jeff, and you're welcome for whatever it is. Okay, Jerry is next up in Hug Report. Hi. Thanks to Maker Melissa for the CircuitPython installer. I didn't even know it was the thing and just stumbled across it this, I guess, last night when I was trying to update a ESP32V2 and it worked great, and what a nice tool. So thanks for getting that out there. All right, thanks. Yes, it's on CircuitPython.org, so everybody take a look there. It's brand new, really. Next up is Jose David, and I'll read their contribution. Thanks to Edan Zerda for adding the parameters for 2200 mAh cylindrical batteries in the LC709203F driver and for keeping the good vibes along the way, counting pixels in the graph. Yes, the data for this was done by reading a printed graph and looking at the screenshot. So we figured out maybe what the number should be. Thanks to Xenomorphius for updating an example in the BNO08x library. Thanks to Chris Wilk for adding real-time playback feature to the DRV2605. And thanks to Narodoc for working in fixing the directional option on the label and bitmap label. And next up for hug reports is DjDevon3, who is not here. Looks like, okay, so I'll read it. Thanks to Todd Bot for an excellent helper function to replace the missing Python find all regular expression that doesn't exist in circuit Python. I don't know if that one is in your tips and tricks, but it definitely should be and I'll make sure to check there first next time. Thanks to Narodoc and Deshipoo for teaching me how to add list integers using some with for loops and for teaching me far more efficient JSON parsing techniques. You're both wizards. Thanks to Dan H for helping me troubleshoot a Metro M7 issue which ultimately ended up being a bad magnetic data cable and user error. Yes, these magnetic cables are very nice but you might need to clean the contacts occasionally. Thanks to Jepler for the great guide on the IMX series bootloader. I'm sure it would have worked if I had had a good cable. Thankfully ended up not needing the guide. The Metro M7 bootloader process is a completely different experience than any other circuit Python board I've used so far. I'm glad the guide was there just in case. And thanks to Lady Aida for an excellent episode of Desk of Lady Aida going over the difference between RPSMA and SMA antennas. I made the exact mistakes she warned about and I'll be correcting my RFM95 antenna connection this week. Alright, and next up is Keith the EE text only. Thanks to Katni and Tami Makes Things and Janine over the Python Discord for all helping me during a build a text scrolling at this workshop. Katni gave me a lot of advice leading up to it and with Tami Makes Things the two helped answer questions in the chat. Many of which I did not have the answers for myself. Helping me focus on keeping the build moving. Okay, and now maker Melissa is up next in our reports. Hello, I wanted to give a hug to Jepler for sharing your chat gpt code to Jerry for testing out the circuit Python installer and a group like everyone else. Okay, thank you. Next up I'll read Mark Gamblers who's out this week. Thanks to Dan H, Tanute and Genevra for comments and information to get my JTAG debugging going and thoughts on an issue where memory isn't being freed by the garbage collector when I think it should be. And Scott is next up. Thanks Dan. First a hug report to Robert HH kind of within the MicroPython sphere for running the Perf Bench programs on the IMXRT with MicroPython for me using that as a comparison. A hug report to Dan H for chatting with me while I'm in the performance weeds at the end of last week. It's a lot of random stuff and it was helpful to talk it through and decide on the direction to go from there. And lastly not related to circuit Python but Adam from the Albums app. Everybody listens to albums more than songs. Should check it out. It works on top of Apple Music which is really neat. And they let me nerd snipe them about importing Spotify song playback history. They do Last.fm imports already but I didn't always have it working with my Spotify. So thanks to them for entertaining me and humoring me on that. Okay, thanks Scott. And finally for this week Tech Trick who's not present but has a group hug. All right. Next up is status updates. Status updates is our time to sync up on what we are doing. I'll start and we'll go through the list alphabetically. When I call on you you can take a couple of minutes to talk about what you've been doing since the last meeting and what you'll be doing until the next meeting. This is also an opportunity to provide tips and tricks relevant to what people are working on. And if we get into a discussion in status updates we can move that to in the weeds for more extended discussion. All right. So I will start. So in the past week or so I've been working on updating various pieces of software that we depend, that CircuitPython depends on. I'm doing this for 8.10 because these are mostly upward compatible changes are in all cases really. And so at least to the outside users. So that's all right. So I updated the Pico SDK to the latest version and the CYW43 driver. The CYW43 is the module that's on the PicoW that does Wi-Fi and Bluetooth but we don't have Bluetooth support yet. So I updated them to the latest version. They seem to work okay and I'm nearly done updating TinyUSB which we were about a year behind on. As I mentioned TAC has been helping me on that particularly on the RP2040. So that should be in soon as well. I'm still planning to head to 804 and 810 beta 1 releases soon like maybe this week. There's a lot of reviewing just to keep up with everything that might go over those releases and helping others make issues to get fixes into those releases. And as Scott mentioned I talked with him about IMX performance late last week. Okay next is DJ Devon 3 and I'll read his. Added some Neopixels to my Mail Boombox project and now blinks and plays a sound on the 20 watt speakers when receiving a Lora test message for mailbox activity. It is so bright and loud you can't ignore it. It could easily be adapted as a great accessibility project for deaf or blind. Created a Steam API example for the 804 request library. Unlike most popular websites Steam does not use OAuth. I like the way Steam does it. It's the easiest API I've used so far. Creating an API key is a one-click process. The data you can return is minimal. They put their users privacy first which I find highly respectable. The API example pulls every game you've played into a list. It then adds all of the time played into a sum total in hours or days spent playing video games. If you've played a lot of Steam games over your lifetime you might not want to see that number. It's another popular API added to the library. Okay and then receive the Metro M7 this week after realizing I don't have a large dot clock display. I ordered a 7 inch display from Adafruit. I plan to dive into the graphical project when that arrives. And FOMI guy is next up for status updates. Alright thanks Dan. I had a bit of a lighter week last week. I was on vacation for the second half of the week all the way through the weekend. The stuff that I did get into though is I started working on a fix inside boundary fill which is inside the bitmap tools module in the core. It was not handling background tasks or respecting the control C interrupts so those things are now in there. But there is a bit of a hiccup on the actions for the Unix port that I'll need so point in the right direction on if I can get. The other thing I did last week more on a for fun type of a note is I saw this viral video of a person playing a MIDI piano in order to draw a picture inside of the like DAV software that was recording the notes. So they played a song in order to have it draw that picture. And I can't really play the piano but I do know a circuit python and I made a script that will import a bitmap image, a small one bit image and then output MIDI notes over the USB that correspond to that drawing if you're recording it inside of the software. So you can kind of make your own pictures in there. It's been interesting to listen to different images. Albeit not necessarily practical and sometimes more chaotic than musical but a lot of fun to play with. This week a couple of things that I know so far I've been reviewing some PRs this morning. Tested a couple fixes for bitmap label and checked into some typing fixes in the BLE library. The only other thing I know for sure I want to work on this week is attempting to add an endpoint to the web workflow API to return the information about the storage like how much space there is and how much space there is. There's an issue or maybe yeah I guess probably issue 7637 where that's discussed. But I haven't really gotten fully dove back in yet so I'm sure some other stuff will pop up throughout the week. That's what I got. Thanks. Okay thank you. I just want the MIDI piano picture thing. There's another video which I may have posted about which is somebody having fractals which they then translated into which actually makes for some interesting pleasing music. Which is kind of interesting. Okay next up is Jeff. Hello. So last week I wrote a guide called Infinite Text Adventure or Infinite Zork. It runs on a pipe portal of any of the three sizes and uses chat GPT to create an infinite if sometimes nonsensical text adventure. You can customize it by writing in plain English or even French rather than computer code. Which is really neat. I started working on the I2S out for the IMX series of microcontrollers. It is at the point where it doesn't build yet. I will keep working on that this week. And for myself while playing with chat GPT I created a text-based front-end to run on your computer and talk to the chat GPT API and put that up on GitHub and had a lot of fun learning a new library called Textual. Yeah and that's about it. So what's up next is working on I2S out on the IMX microcontrollers. Okay thanks Jeff. Next I'll read Jose Davides contribution. Some PR reviews. PR to fix the padding and label after the work done by Naradoc and Bitmap label. And not sort of Python. Help translate game messages for the open source tabletop game. And there's a link to the GitHub repo for that. Okay and maker Melissa is up next. Hi. So yeah I'm reading for the last two weeks because I was out sick for a part of last week. Not quite better yet. But anyway I finished up getting the Circuitpython installer live and working. I added a bunch of new boards to circuitpython.org. I wrote a JavaScript merge bin library to incorporate most of the functionality of ESP tools merge bin function. But it works online. I updated the whipper snapper firmware uploader to be able to create a downloadable file for flashing later which used the merge bin library. But I worked with Brent to fix an issue where whipper snapper sometimes wasn't working on the ESP 8266. I wrote a voice assistant by the script that interfaces with chat GPT. And I tested out the ESP tool JS on different boards. It worked on most but wasn't working on the ESP32S2 that I had tested. This week I'm working on some changes to allow the Circuitpython installer to be used on the Adafruit Learn system. And also going to work on some additional improvements to the Circuitpython installer. Alright, thank you Melissa. Next I'll read Mark Gambler's contribution. PR7712 adds dnit support to onDiskGIF. This ended up not fully fixing the memory-feeing issue but it can be treated on its own if it passes review. So, thanks Mark. Okay, and next up is Scott. Hello, I'm in the weeds still. I'm running a lot of performance benchmarks. MicroPython has them. I'm running them. I got them working. There was some fixes I had to do to get them running. So, I'll have a PR at some point here soon, hopefully. I mentioned Robert H.H. Posted the MicroPython on the IMX tests and at that point Circuitpython was running about half the speed that MicroPython was on the IMX which was quite surprising to me. I've been digging into what they're doing in MicroPython. I'm much more in the ballpark as it was before. It's mostly a function of putting things in ITCM which is the instruction tightly coupled memory. They're pretty aggressive about that. They're also aggressive in using the DTCM which is kind of interesting to me too, but I thought I have to look more about how DMA interacts with that. And then also they use SoftFP as the floating point ABI rather than hard and it looks like that also made a big difference too. I'm going to take a look at that again. I have a couple more things I want to try. Kind of big things that I hope we get big wins from. One is we use object representation C by default in Circuitpython and A is what the default uses in MicroPython. I'm curious to see just how big of an impact that has on performance. So I'm going to take a look at that. That should be pretty quick to switch. That has to do with how small pieces of data are stored in the pointer itself rather than allocating out to the heap. Speaking of the heap, the heap generally lives in what's known as OC RAM. I don't remember what it stands for. But it's basically RAM that other peripherals can access as well which is really handy for DMA. It runs at a quarter of the speed of the core so I'm curious as to turning on the cache in front of that and seeing how fast things run if it's cached. The tricky bit with that is that anything, any pieces of memory in that range, if you have the cache on you have to be very deliberate to say write it out completely or ignore what you have cached based on when the other things might be changing or reading that memory because if you have the cache the changes may only live visible to the CPU rather than visible to everything. So that adds complexity but also could mean that accesses to that is a whole cycle rather than four or more. So I'm going to take a look at that. And then lastly I found that Clang is a separate compiler from GCC. It's really, really commonly used in desktop applications because it's first claim to fame was that it had better error messages than GCC but it's also licensed not under GPL. You see a lot more corporate compiler work happening from Google in particular, or Google is one of them, it started at Apple but because it's liberally licensed you see more corporate contributions to LLVM in Clang is the C compiler version of that. I wanted to move to that for a long time but it's not been as good as the ARM GCC version. I found that the API has modified Clang to work better on embedded in particular respecting linker scripts better. And so I want to just see if I could use that in particular for the IMX so that we could do link time optimization. In GCC link time optimization may move code from one memory region to another even though the challenge is that sometimes memory regions are not accessible so if you're like erasing flash you can't run code from flash because it's busy. And so you have to be careful in putting all of the code that can run when you're doing flash stuff in RAM and that's true for RP2040 and also ESP. So if we could have a version of Clang that did that and did LTO that'd be pretty awesome because link time optimization can do more, it's smarter because it knows more stuff. Anyway, so I want to take a peek at that because this is the first time I've seen an alternate thing that could do LTO and linker sections. So I'm going to take a look at that. And last up, it's not secret but they're related but I'm excited about it. I ended up ordering a Steam Deck which is kind of a handheld gaming computer. I think Nintendo Switch but running Linux. It's pretty open and they have a bunch of repair stuff through iFix which is cool too. So I ordered one of those and I'm excited to try it when it gets here. Okay, thank you Scott. Finally, I'll read the tech tricks. I've been out the last couple of weeks between being sick classes and my birthday registered for PyCon. Excited to be going this year and eager to see everyone there. I also plan to attend the first day of Deb's Prince before heading home. Planning to catch up on PR reviews and keep working on the CI tools using RP2040JS. I'll have more information and topics for discussion in the weeds next week about how the CI tools should analyze and report the information as well as how it should be configurable. I think that we can use PyProject.tomwell to do so. I'll have an example when I present it. Okay, so expect more larger in the weeds next week. And speaking of in the weeds this brings us to the in the weeds section which is an opportunity for more long form discussions that either come out of status updates or that folks have identified ahead of time. If you have any in the weeds topics please make sure they get added while we're discussing other things. So we're not waiting around to see if anyone has topics. Okay, so Jeff has, I'd like to talk about Watchdog. Yeah, and it may be better to talk about this on issues or pull requests since MicroDev is one of the people involved and they're not in this meeting. But I'll go ahead and talk about this anyway. So MicroDev filed a pull request to add the ability to disable the Watchdog on RP2040 after it was already enabled. And in looking at this further I feel like there is some inconsistency and I think that it would be great to resolve that. So the first item is the inconsistent behavior across ports. And specifically does the Watchdog get reset from the interpreter exits? Naradoc says that it does on expressive and I believe that it should remain active if it's not explicitly turned off even when your program exits such as through an exception. And the reason that I want this is I have an existing project, it's a keyboard and when you are trying to communicate with the host computer and the USB connection isn't active you get an exception. And to fix this crashing my keyboard I just put in the use of the Watchdog so that the program will kind of continuously restart until the host computer is ready. Works great. But if the Watchdog is turned off by the standard platform reset when the interpreter exits then that would not occur and my keyboard would break. And because expressive right now is doing this advice that I've given people like on the CirclePython, Help with CirclePython channel to enable the Watchdog so that after any problem the device would restart as though from power on that was wrong advice that I had generalized from these other platforms where there was no way to turn off the Watchdog. So that's part A I think we need to create a consistent behavior across the ports where if the Watchdog is not explicitly disabled it remains enabled when your program exits. Except maybe if you control C or if there's a reload I think there's some wiggle room in those cases but not generally speaking. Second the Watchdog code I think was written when the SAMD was the only microcontroller or maybe the only microcontroller and it has no way to ever disable the Watchdog until there is a reset of the whole system. So in the shared bindings there's actually a check for setting the mode back to none and that is rejected. What expressive and now RP2040 do is they use a call to the DNIT method of the Watchdog object to disable the Watchdog and that's kind of inconsistent because normally after you call DNIT on an object that means the object can no longer be used and that is not how it is. So I think we need to allow assigning of none or allow the common hell layer to be the one that throws the exception if it's not supported by the hardware and then because it doesn't make sense to DNIT the Watchdog we would remove that API from 9 or from some future version of CircuitPython. That's my brain dump. Any comments? I think that's good. I think the readers can see if you can get consistent behavior across all the platforms or just say okay this is not supported ideally the API is this but blah blah blah it's not supported. So I think that makes sense. Yeah, I think you're on the right track as well because we just didn't have enough experience of the differences in all the platforms I did see somewhere that the ship who pitched the idea of a CircuitPython Watchdog An all software kind of thing An all software sort of thing yeah which I think could also be interesting and you should think about when redoing this because then what's the problem if the actual hardware can't be disabled if we had a software Watchdog kind of like as a first like as a Python Watchdog then that could be interesting like that could be a way to have one that you could actually disable which I think could be interesting so I'm not saying we have to add it but I think it's something you're right that we need to think holistically about it and evolve it and I think that's something to consider when thinking about how to evolve it is whether we want a pure Python sort of Watchdog because that would be way easier to make consistent across ports. Yeah. The hardware Watchdog is good too for hangups. Yeah but maybe we use that internally just to make sure that our checking code is like we could use the hardware Watchdog to ensure that our software Watchdog isn't still working. If we can't turn it off that's a problem too. Yeah I think once we start looking at Watchdog we'll discover there are more things that we want so for instance I think I may have closed based on incorrect information an issue which said on the RP2040 please disable the Watchdog during a flash right. You know a user was running into problems that during the flash right the Watchdog would fire and then your circuit pi is in a really bad state and because I thought that the RP2040 Watchdog could not be disabled like at the hardware level I think I may have closed that issue saying it would be great but actually it's not possible so I should go look for that. The other thing I will do as an action item out of this is go open an issue which says basically restates what I said here and then ask for it to be worked on and I think it would be nice if we could put that in 8.1 but I also wouldn't hold 8.1 for this. It feels like a 9.0 like API changed to me. Changing it so that you can assign none to the Watchdog mode property depending on the whether it's hardware supported doesn't seem that big a change but there's more. I think as we think about it you're right that there's more like kind of a full rethink of Watchdog. Yeah and the other case I just ran into was that the single js2 the bootloader enables the Watchdog and the nrf can't turn it off so I actually needed to add code in CircuitPython to feed the Watchdog which would be similar to if we use the hardware Watchdog internally and then had a software Watchdog for user code on top of that. Alright so we just need to bring that code up to a more generic level. Do you want background tick or something else? Yeah I added this like it runs every background pass call. It's really aggressive. Even though I know the period of the hardware Watchdog is like 5 seconds or something but I didn't want to add complexity to figure out when I actually needed to feed it. So just feed it every time. Alright thanks all. Thank you for thinking about that. Alright so we'll finish up. This has been the CircuitPython Weekly for March 13th 2023. Thanks to everybody who participated. Reminder that if you want to support Adafruit and CircuitPython and those of us that work on CircuitPython consider purchasing from the AdafruitShop adafruit.com. We'll release this video, this meeting on YouTube at youtube.com slash Adafruit and the podcast will be available on major podcast services. There'll also be a link in tomorrow's Python for Microcontrollers newsletter. You can visit adafruitdaily.com to subscribe to the Python for Microcontrollers newsletter. The next meeting will be held next Monday as usual at 2pm eastern 11am pacific. In US that's daylight time. In other northern hemisphere countries maybe you will or will not have switched to daylight time by then. I think not. I think it's a little later. So a reminder that Ad yourself has to be added to the Ad at Science CircuitPython East as a role in Discord if you want notifications of that. So thank you everyone and we'll see you next week. I will stop recording.