 Hello, everyone. This is the Circuit Python Weekly Meeting for February 20, 2024. This is the time of the week where we get together to talk about all things Circuit Python. My name is Tim and I am sponsored by Adafruit to work on Circuit Python. Circuit Python is a version of Python that's designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit. So if you want to help support Adafruit and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting gets hosted on the Adafruit Discord server each week. You can join anytime by going to adafru.it-discord. We hold the meeting in the Circuit Python Dev Text Channel as well as the Circuit Python Voice Channel. This meeting typically occurs on Mondays at 2 p.m. U.S. Eastern Time, 11 a.m. Pacific Time, except when that coincides with the U.S. holiday like it did this week, in which case we usually bump it to Tuesday like we are today. In the note stock, there is a link to a calendar which you can view online or add to your favorite calendar app. We'll also send out notifications via Discord to the Circuit Pythonistas role when we are going to be making changes to the schedule of the meeting. So feel free to ask yourself to be added to that role if you want additional pings to pop up when we do change the meeting over to a different day. There is a note stock that accompanies the meeting and recording. You can contribute to the document beforehand. The final notes include timestamps to go along with the video so you can skip around and view the parts of the video that interest you most. The meeting tends to run 60 to 60 minutes. After each meeting, we post a link to the next meeting's notes document in the Circuit Python Dev Channel on the Adafruit Discord. You can always check the pinned messages there throughout the week to find the upcoming document for the upcoming meeting and you can add your notes to that throughout the week or whenever you'd like. The meeting is held in five parts. The first part will be community news. That's a look at all things Circuit Python and Python on hardware in the community. It's a chosen set of items from the Python and Microcontrollers newsletter. The second part is the state of Circuit Python, the libraries and Blinka. That is a quantitative overview of the entire project. It's a chance to look at the project by the numbers separate from our status updates. The third part and the first of our two round robins is hug reports. The hug reports section is an opportunity to highlight the good things folks are doing. It can take some time to recognize the awesome folks in our community and beyond. The fourth part is status update. That is the second one of our two round robins. Status updates is an opportunity to report on what you've been up to. You can take a couple of moments to talk about what you've been doing in the last week since the past meeting or what you plan to be getting up to for the next week until the next meeting. The fifth and final part is in the weeds. In the weeds is an opportunity for more long-form discussion. Those discussions can come out of status updates or they can be topics identified ahead of time as too long for status updates. So that covers how the meeting will go. So I will give my scroll in the document correct. Get a first time stamp and get the community news going. So first up in community news this week, CircuitPython 8.2.10 was released. CircuitPython 8.2.10 is the latest bug fix revision of CircuitPython and it's a new stable release. There are links in the document here that go to the Adafruit blog as well as the GitHub release notes. And there is a short list of notable changes since 8.2.9 which include a fix to ePaperDisplay garbage collection, a proto argument to socketpool.socketconstructor for allowing the specification of protocols, allowing the RGB matrix frame buffer size to be more than 65,535 bytes, allowing, allow creating a mount point on an existing directory and then some individual board fixes. Next up from the newsletter this week was CircuitPython 9.0.0, beta.1 and beta.2 were released. These items aren't in the newsletter. Thanks to Dan for adding this here. These were, came out I think after the newsletter so they didn't make it in but they may be noted in the next one. But yeah, for everybody here in the meeting it's a good thing to know CircuitPython 9.0.0, beta.1 was released on Saturday and then beta.2 was released yesterday. Beta.1 contains a number of significant fixes since the previous beta which is beta.0 and then beta.2 contains an important fix for the memento camera board. You should upgrade your memento to beta.2 and reformat the file system as described in the release notes or the memento learn guide and as always be sure to back up your important files before you do that. Next up in the news this week I don't know the proper way to pronounce this company's name so my apologies if I get it wrong but Renaissance is going to be buying the PCB design firm Altium for 5.9 billion US dollars. The Japanese chip company Renaissance Electronics Corp has set up plans to acquire PCB design software firm Altium Limited for Australian 9.1 billion which is about 5.9 billion US. The move is an extension of Renaissance's mainstream business which is predominantly the supply of digital and mixed signal chips for automotive and industrial applications. There are links here, I don't know where that is to actually it says E.E. Euro news it looks like so if you'd like to read more on that you can follow the link in the notes doc or this week's newsletter. Next up is hands-on with the Bus Pirate 5 debugging tool. The Bus Pirate is a hardware protocol analyzer used by thousands of designers since its introduction in 2008. It's been a number of years since the last iteration but now the Bus Pirate 5 is available. It's based on the Raspberry Pi RP2040 chip. There is a link here to Hackaday and the Adafruit blog and it says Hackaday provides a hands-on look at the latest incarnation if you want to learn more about that. A couple more this week, we had lots of news items because lots of neat stuff caught my eye this week. So next one up is CircuitPythonista Helen Lay was featured on the Embedded.fm podcast. CircuitPythonista Helen Lay joined Embedded.fm to talk about putting together conferences including Teardown 2024, Indie hardware producers including crowd supply and building communities. There's a link here to Embedded.fm if you want to listen to that podcast. In the project of the week, we had a Pico and MicroPython meets Vintage Radio Shack kit. I couldn't resist putting this one in. Don Wilter uses Raspberry Pi Pico to build an adjustable clock with an LED display and then integrate the clock with a vintage Radio Shack science fair microcomputer trainer programmed to function as a 7-bit binary counter. Don adds a Raspberry Pi Pico programmed in MicroPython making an adjustable digital clock. These little Radio Shack kits with their bendable springs were one of my first introductions to electronics so those things will always have a special place in my heart which is what caught my eye on that project. The last two are both a couple of notes from the Adafruit Playground which both caught my eye. As a reminder for anybody that may not know the Adafruit Playground is a new place in the community to post their projects and other making tips, tricks and techniques. It's ad-free and it's an easy way to publish your work in a safe space for free. The two items this week that are in the newsletter that caught my eye, the first one was a new Playground post that talks about using the Web workflow with CERCUP which is still in beta. There's a PR out to do that which this is a good reminder to myself to finish up on some refactoring in that PR. This is really, really cool. Thanks, I believe it was to Tyeth for writing that up and showing folks how to get the version of CERCUP from that PR and use it to load libraries onto your device via the Web workflow instead of USB. The other one which I thought was really, really cool is a custom A&O fidget firmware. This is a custom CERCUP Python firmware that uses the NeoPixel Rotary. It's a custom CERCUP Python firmware for the NeoPixel Rotary fidget project. So head over to Adafruit Playground if you would like to see that. If you follow the link I suggest taking a look. There's a GIF in the newsletter as well which is really cool to show what this little fidget device is all about. So really, really cool stuff. Lots of stuff this week that was really awesome in the newsletter. Let me take the next time stamp and tell you more about the newsletter itself. The Python on Microcontrollers Weekly newsletter is a CERCUP Python community run newsletter that's emailed every Monday. The complete archives are available on AdafruitDaily.com. It highlights the latest in Python on hardware related news from around the Web including CERCUP Python, Python and MicroPython developments to contribute your own news or project edit next week's draft on GitHub or submit a pull request in order to add your changes. You can also email to cpnewsatadafruit.com or tag a post with hashtag CERCUP Python on Macedon Blue Sky or X formerly known as Twitter and thanks as always to Ann for doing all of the wonderful work to bring that newsletter to us each week. Next up is the state of CERCUP Python libraries and Blanca. This section is a quantitative overview of the entire project. It gives us a chance to look at the health of the project separate from our status updates. We'll talk about the project overall and then separately discuss the core, the libraries and Blanca. So first up I will read you the overall section and also as noted here in the document, especially since we are doing our meeting on a Tuesday this week, our reports here cover stats for like a rolling seven day window. So unfortunately when we do the meetings on a Tuesday there is one day that gets left out of the stats. So there were some stats from last Monday that did not make it into this. We do appreciate all the folks that worked on anything in that time frame nonetheless though. So for overall stats this week we had 38 pull requests merged by 14 authors. The names here that are newer to me are KB Sererim, EZR Schwartz and let's see, Radiak Knockman, NOQ Man and let's see, C Darius Those are the names of folks that are either newer or less familiar to me at least so those might be newer contributors or less frequent contributors. Thank you to those folks as well as all of our other more regular contributors or folks who have names that are more familiar looking to me. For those 38 pull requests from the 14 authors we got reviewers, excuse me we got reviews by five people, mostly the usual suspects for reviewers so thank you to all of our reviewers as usual the more reviewers we have the more contributors we can support so thanks to everyone who does reviews for us we had 40 issues closed by eight people and 16 new issues opened up by 16 people so we're net down quite a bit on issues for the week. Next up I will pass it over to Scott if you're available to tell us about the core. Yeah, happy to thanks Tim. Okay so for the core in the last seven days missing Monday as Tim said we had 31 pull request merge which is awesome we had 10 different authors which is more than we normally do as well so just thanks to 88T, NoQMan, KB Sriram Retired Wizard Seed Areas those are all kind of newer folks in terms of authors so thanks to them. We had three reviewers myself Dan and Jeff we have 18 open pull requests which is quite good for us which is awesome. We tend to want to be under the 25 pull PRs per page limit so we're well great. Issue-wise we have 32 closed issues by four people and eight opened by eight people so we're net down a bunch which is awesome. We have 662 total open issues we track 80 fruit funded folks' prioritization on issues via milestones. The milestone that got a lot of attention over the week was 9.0 because we're trying to get 9.0 stabilized and out the door. We have 13 open issues there which is great. I think the last number I remember is like 38 so 13 is awesome. We have zero open issues on 8.2X I don't expect to see any more there because we're basically like pushing to get 9.0 stable. We have two open issues on 10.0 those are things we want to not forget to do in the next major version we have nine open issues on 9.0XX so things we want to do once we have 9.0 stabilized. Lastly we have seven issues not assigned to milestones so we'll want to go through and triage those as well and that's where we are with the core. All righty, thank you Scott. Next up is the libraries. The section covers all of the libraries which you can find on GitHub under names like Adafruit underscore, and then the name of whatever library it is. These things tend to provide either like drivers for specific pieces of hardware or higher level helper libraries that allow you to create projects without worrying about as many of the low level details. Across all those libraries this week we had seven poor requests merged by six authors. I'll repeat a couple of those names. I think they were the same ones and I want to make sure to call them out. The folks that have names that are less familiar to me so these might be newer or less frequent contributors thanks to KB Sriram, EZR Swartz, and Radiac. Thank you to our other more regular contributors too and we had three reviewers this week for those seven poor requests so thanks to myself Brent and Dan for reviewing in libraries this week. Of the merged poor requests the oldest one merged is only nine days and the newest handful were just one day so we were focused mostly on newer poor requests this week. After that it leaves us with 49 open poor requests. The oldest one is 551 days and the newest is one day. In the last seven days there were seven closed issues by four people and six new issues opened up by six people. That leaves us with 742 open issues and there are 19 that are labeled good first issue which you can find over on circuitpython.org slash contributing which is the place that you should head if you are interested in contributing to circuitpython on the Python side of things. Check out circuitpython.org slash contributing you'll find a list of open PRs and a list of open issues. If you're looking to contribute it's a great place to start. To get started with reviewing you can look at the list of open PRs you can look at any open PR you can look at the code for spelling and syntax. If you have the hardware you can test it out. Leave a comment on the PR letting us know that you looked at it and what you found. Once you're comfortable with that we can get you leveled up to the review team so that you can leave official reviews on GitHub. However comments leaving reviews are perfectly fine too. If you would like to get started actually publishing your own code you can look into the list of issues including those 19 good first issues that I mentioned before those are going to be issues that are waiting for a person to come along and actually contribute some code in order to resolve whatever that issue is. Those are listed out again on that circuitpython.org slash contributing. If you want to find those you'll click over to the issues tab and then use the drop down at the top in order to filter by the type or the tag that I should say to find those good first issues or any of the other tags. We do have a guide for contributing to circuitpython using get and github we're always available over on Discord to help folks get started so let us know if you need assistance. Don't let the process intimidate you we want to let everyone be able to contribute in whatever way works best for them and we're willing to help work with you to make that happen. So for library IPI download stats this week we had 92,730 PI downloads across the 324 published libraries the top ten list is here in the note stock if you'd like to take a look at those and for library updates in the last seven days there is a new library in the community bundle that's titled BLE Cycling Power Service there are updates to HTTP server and macro pad as well C-Rubber's WaveViz library over in the community bundle so take a look at those if you're interested in any of that stuff and next up I will send it over to maker Melissa to tell us about Blinka Hello, so Blinka is our circuitpython compatibility layer for MicroPython Raspberry Pi and other single board computers and this week we had zero pull requests merged by zero authors and zero viewers of course there are currently six open pull requests amongst all the Blinka repositories there was one closed issue by one person and two open by two people leaving a net of 85 open issues and there were 12,300 PI PI downloads in the last week and we are at 129 ports and that's it awesome, thank you Melissa next up is the hug reports section as a reminder for folks, hug reports is a chance to highlight the folks in our community and beyond for doing awesome things I'll start and then we'll go down the list alphabetically or as names appear in the note stock if they happen to be out of order that's okay too if your text only are missing the meeting then I'll read your notes for you and then we'll get to your turn in the list so I will get us started after I take the first time stamp I have a number of hug reports this week so thank you first of all to squid.jpg and Justin who both helped me out with some color space conversion functions and math on discord last week thank you to retired wizard for testing out different scenarios on the memento device to check if an issue that I noticed was reproducible thank you to Dan and Jeff for figuring out the root causes of that issue and working on fixes for it thank you to Kmatch and Jeff as well as anybody else who has contributed to bitmap tools I'm always finding new stuff in there that I didn't know about that is making my life easier so really really neat stuff in there thanks to everyone who's made it what it is another hug thanks to Dan for making new beta releases the one that contains the new board specific stubs feature and another for the memento storage fix and lastly thanks again to Jeff for pointing me towards a way to convert between RGB565 swapped and non swapped color spaces using ULAB so that is what I have got for hug reports next up is Anikdata who's text only so I'll read Anikdata says hug report for Jeff for the embed TLSPRs to extend the HTTPS server from a Raspberry Pi only slow to the expressive ESP32S3 which is faster and for exploring making TLS available to non-native sockets Anikdata has another hug report for Romkey for the PR to expose the details of stations connected to a wifi access point next up is C Grover who's also text only so I'll read and then after that I will pass it over to Dan so C Grover says thanks to Dan for Dan and the team for the release of 9.0.0 betas one and two significant updates that represent some impressive problem solving group hug to our inspiring community next up is Dan followed by DJ Devin thank you so thanks to Jeff and Scott for what we all work together to reduce the number of 9.0.0 issues significantly huge number of poll requests last week as you saw thanks to FOMI-I DJ Devin 3 Jeff retired wizard in ADCC and maybe some other people even I'm not sure for help with debugging the memento storage problem over the weekend and thanks to Jeff for co-working with me on a fix for the memento problem he found a couple of serious problems our fixes made it very quick to publish a fix and thanks to mccallapakusa for updating the HTTP server there's a poll request to handle a new incompatible change to sockets that kind of out in beta.1 this makes sockets more like they are in CPython and you have to use SO reuse adder when you're reusing a socket with the same risk ok alrighty thanks Dan next up is DJ Devin 3 and then Jeff will come after that thank you I have a hug for Lady Aida and Quiriad for the Arduino TSC 2046 TouchDriver I was able to pull a formula from the embedded code comments in the driver for calculating analog resistive touch pressure even though it was for Arduino it helped immensely a hug to FOMI-I for running into a hard fall issue on the memento and it derailed his fancy border project temporarily during the stream as he dove into investigating the hard fall it was nice to see multiple people in the dev channel jump right into beta testing the issue with him a hug to Dan H. and Jepler for the quick low level investigative work to discover and fix a fatal bug in the memento build and a hug to syndrome for a private collaboration on our next matrix panel projects we've had some excellent conversations behind the scenes comparing notes with large matrix arrays and we would like to present our findings in a playground note eventually after more experimentation. All right thanks DJ Devin and next up is Jeff and then I'll read Justin's notes after that. Hi there on this first item I keep growing the list and I'm worried I'm going to leave somebody out but for everybody who was working on finding diagnosing and working through the whole circuit Python drive on memento thing I've got FOMI guy, Retired Wizard, ADCC, DJ Devin 3 Dan and Lady Aida on my list, Lady Aida we talked to her internally and she reminded us why we made the decisions we did about partitioning that device and why it's different than the others and that has to do with Arduino anyway next this morning thanks to DeShippu for a hint about Wysom code I was working on wasn't working one for anecdote for prompting the idea to further generalize the core SSL implementation with the idea that maybe it could be used with WysNet and add some wired Ethernet with SSL support for circuit Python On the circuit on the socket rather theme thank you to Justin for moving sockets forward another one thank you to IDE on GitHub for circuit Python HTTPS server which I was using as my test bed when I worked on some of the recent SSL changes and I'll probably use it again thank you to Michael Pokusa for quickly finding and reporting a apparently new problem with binding SSL sockets that may apply to all sockets it's not clear yet and finally thank you to Dan H for releasing circuit Python and probably more releases in the near future and that's what I've got for hug reports alrighty thanks Jeff next up I will read notes for Justin and then after that is maker Melissa Justin says hug report for Scott, Dan and Jeff for all of their help with moving the connection manager along so I will send it over to maker Melissa next let's see I want to give a hug to Micael Pokusa for improving the circuitpython.org search performance and group hug everyone else alright thanks Melissa and I forgot to mention that he was on deck but next up is going to be Scott hello hug for me for Bill88T who had a originally looked like a very complicated bug but he retested and posted test code that didn't involve any other external libraries there was a couple bugs in the test code but it was like still very nice and concrete and had clear instructions so thanks to Bill for giving that easier to reproduce code for that bug alright that is it for the hug reports so next up I will take the time stamp and tell you about the next section status updates is our time to tell folks what we are up to individually I'll start and then 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 an opportunity to provide folks tips and tricks relevant to what people are working on if a discussion becomes too long for status updates we can move it down to end the weeds so I will kick us off I had a little bit less time than usual for circuit python on towards the middle and end of last week dealing with some stuff in real life so I did not do as much as I would have liked the things that I did get into over the past week were testing a change to the macro pad which added the ability to rotate the display and the buttons after it was initialized we always had the ability to do it when it was initialized but this made it so you could do it after the fact which is kind of cool lots of the rest of what I worked on was all related to this one project the memento camera project with overlays trying to put frames and other neat graphics on top of or combined with the photos that you take on the memento camera so before I actually got the hardware in hand I built a proof of concept using an older TTL serial camera and a esp32 s3 feather I did get it working to combine those images it took a bit of work but it was nice to do that even before I had the hardware because it allowed me to work through some of the color space conversions that I ended up having to do anyway during that I went down a bit of a small rabbit hole trying to make some modifications in the core before Jeff very kindly pointed me towards some helpful code that uses uLab instead that uses uLab to do the conversion that I was trying to add new code for so that was much easier to do didn't require any changes in the core I got that functionality moved over to the memento device once I actually got it in hand in the process of that discovered a wider unrelated problem with the storage configuration on that device once I started pasting some of the larger image files on there I started getting weird stuff and then the rest is history I figured out how to do the overlay in the preview using bitmaptools.rotozoom in order to scale that down to 75% so that it matches the preview that's on the display which is really cool I'm actually quite surprised at how well it's able to keep the preview moving live even though it's kind of allocating an extra bitmap and doing that copying each time so that's actually was really cool to see I refactored everything into a cleaner interface and submitted PR in the pie camera library with an overlay property that allows that to be done a little bit more easily and without the random hard-coded bits and extra print statements that I was using before so if anybody wants to take a look at that that PR is in now and then my last item which is not directly related to CircuitPython but I do intend to eventually use it with CircuitPython and the HTTP server library is a library that I published on GitHub over the weekend called sql.json which is a very basic SQL engine that stores its data and reads it from .json files instead of a SQLite 3 or anything else that's up on GitHub and it supports only a very limited subset of SQL syntax I'm hoping that this can be maybe like a helpful introduction to the concepts of SQL and SQL injection to people who don't have any prior knowledge of either but who may have some experience with CircuitPython or JSON data and with that I will go next up is Cgrover who's text only so I'll read and after that will be Dan Cgrover says upgraded WaveViz to automatically adjust to synth.io waveform or envelope input object when plotting an image rather than having to set an initialization QUARG and there's a link here if anybody like to follow that and read up more use the new version on the faderware WaveBuilder testbed to graphically show the dynamically adjusted wavetable and ADSR envelope settings and there is a link here to YouTube if anybody would like to take a look at that next up Cgrover says made significant headway saving and retrieving synth.io waveform and envelope files using an SD card the in progress WaveStore class is designed to read and write synth.io objects such as waveforms, envelopes and filters as well as storing and retrieving WaveViz windows and screens the object is to create manage and share a collection of synth.io assets of course when completed WaveStore and the initial asset library will be placed into the community bundle and the last one that Cgrover's got says next on the list is to design a basement expansion PCB for faderwave that incorporates an I2S speaker a stereo I2S stack output and an SD card for storage thanks to Cgrover for those and next up I will pass it over to Dan okay so as already mentioned I released circuit python A210 last Tuesday that has some mostly minor bug fixes but it had been a while since we had updated so there were various things including the ability to support a larger number of panels for RGB matrix as was mentioned then on Saturday I caught up on 900 betas by releasing 900 beta 1 which includes a slew of changes some incompatible changes and you should look at the release notes carefully about those I've tried to make it looking about capabilities really called out clearly in the release notes as suggested by Scott then over the weekend we also encountered this memento circuit py drive problem it wasn't a regression it's just that it came up right after beta 1 so thanks to everybody who helped fix it it's now fixed and I released beta.2 last night so as mentioned update your memento camera board first backup circuit py update to beta 2 then reformat circuit py erase and reformat circuit py and that will fix the problem so over the weekend I did spend a lot of time debugging this issue it was extremely confusing because there were really two bugs and fixing one then revealed another bug it was also the case when we thought that the file system was being reformatted it wasn't so that was also confusing I updated the master root certificate list the one that's shared by everybody to include a new root for flightaware.com there's an 8 root certificates as the repo for that and I fixed something that I had been trying to get to work for a while but finally finished which is that now the build file names that are on AWS S3 include more information instead of just having the commit in them may now include the branch name like either main or 8 2x and the PR number is like PR NNNN so you can look at a particular build in the listing or lying around on your disk and decide that oh that's what this is for okay and that may help people who are doing manual bisecting or trying older versions and that's it alrighty thanks Dan and thanks for adding extra information to those that sounds quite helpful as someone who has clicked through that list before I definitely think that will help out next up is DJ Devin 3 thank you this week I've been working on the XPT 2046 resistive touch controller and I found it is just a clone of the Texas Instruments TSC 2046 discovered Adafruit has an Arduino driver for that chip the TSC 2046 Liz's learn guide on that chip and Lady Aida's Arduino driver are excellently documented unfortunately there is no circuit python driver for that learn guide so that's kind of what I'm working on is using an existing circuit python driver and trying to merge though that incomplete subset with the completed one from that Adafruit has from Arduino I released a 3D model for the Adafruit 2.5mm pitch matrix panel I intend on submitting the model to Adafruit CAD parts and I am currently designing 3D printed support brackets for the set panels that's it awesome thanks DJ Devin next up I will read notes for FETA 2 and then ADCC is after that so FETA 2 says I built a Zabix library for circuit python I have an unofficial RISC 5 lab which uses Zabix as monitoring so now I have a RISC 5 board QTE SP32 C3 monitoring my RISC 5 lab the demo uses a NeoPixel strip to light an LED for each host green for available blue for load and red for down FETA 2 also says configuring HID remappers on Adafruit's USB Feather to distribute them to linguists and indigenous language teachers to test the new keyboard layout for Costa Rica before submitting it to Unicode which sounds super cool next up is ADCC alright thank you Tim alright so this week traded in a Sonoma Delayed metadata writes for a new stat file system write performance and directed wrote it up and wrote new feedback for Apple and this new regression affects the Sonoma 14.4 beta and continued work on BLEIO for Pygo W wrote some PRs for minor upstream issues in BT stack and tiny USB and rebased my work in progress onto the beta 1 of 9.0.0 alright thanks ADCC and next up is Jeff hello I mostly been working on 9.0.0 bugs I filed a bunch of PRs late last week I think most of them have been merged at this point I helped out with the Memento storage bug a little bit and this morning I got sidetracked with anecdote is musings about Wisnet SSL as to whether we could generalize my work a little bit and make it work with that in progress there's a draft pull request out but I think there are some things that don't work yet just on even boards that work before so don't go try it right now so for the rest of the week I really need to switch gears back to what is important for Adafruit and that is working on this flopsie board I've got an early revision need to test that the functionality we want working in circuit python works I suspect it doesn't and I have to update the library that does the floppy interfacing the floppy IO module and then probably some time in Arduino land and just another note I am out or mostly out all next week so probably it'll be two weeks before I'm hanging out in a meeting with y'all and that's what I've got it going on right now. Alrighty we will see you then thanks Jeff next up is Justin who's text only Justin says I got a chance excuse me got a change into mini MQTT that allowed me to move forward with connection manager which is now updated and ready for a full review thanks to Justin for that next up is maker Melissa hello so I worked on updating the Raspberry Pi Pi Ice project it's in C code that will basically I'm trying to get it to capture the new Wayland desktop and now it's successfully getting an image and at least saving it as a PNG file. I'm taking a break from that right now to update the Web workflow editor to reflect new API changes and I'm working writing a learn guide regarding that and that's it awesome thanks Melissa next up I'll read notes for McCall-Pucusa and then we'll round it out with Scott after that he says improved performance of search bar in circuitpython.org downloads section preparing Adafruit HTTP server library for circuitpython 9.0.0 and working on HTTPS support for Adafruit HTTP server library there are still some problems on ESP boards but at one point using a specific version of circuitpython 9.0.0 I was able to implement SSL with HTTP server so exciting stuff on the HTTP server front thanks to McCall-Pucusa for those updates and I will send it over to Scott for his updates hello okay so I had a Neopixel day last week where I tuned Neopixel transmission on the ESP boards and S2 in particular is a lot better ESP32 is better as well but basically we try to greedily grab as much buffer we can on the peripheral side temporarily while we do Neopixel transmission and that's made it a lot better. I also moved circuitpython to core 1 on ESP32 so ESP32 will hopefully work better when because the core 1 is the second core and the original core core 0 should be used for networking stuff so hopefully it will actually work better we had already done that on S3 but we hadn't set the setting on ESP32 the S2 is single core so it doesn't matter I fixed some IMX UART receive issues and also updated its SDK while I was working on it I debugged and impossible to control C on IMX and realized that if we set the CDC receive buffer to exactly as much as the endpoint can have so 512 for high speed USB is that the moment you get a single character you no longer go back to the computer and ask for more characters because you can't guarantee that you have enough room for a full packet's worth so I added a check there that we always give ourselves at least 64 characters of buffer so that if you accidentally type a thing or two into the serial connection you can still control C basically the control C needs to be sent to the device so they can see it even if there's other stuff backed up as it's kind of come up has come up I changed the behavior of socket.bind it previously implicitly set a flag to allow reuse that is not what C Python does and the bug I was running down I think was leaking or not closing sockets as it should have because this behavior masked that so now in CircuitPython 9 you have to explicitly request that reuse is allowed and this matches C Python behavior but does change the way that CircuitPython has been working and folks are making that work even better which is great I started working on fixing a crash on SanD for pulse-in that it turns out it's caused by conflicting reset mechanics but basically I have an item in the weeds to go into more detail there and then last up I want to just continue bug fixing until we get to release candidate phase which will hopefully be soon so we can get 9.0 stable and that'll be awesome so that's my update alright thank you Scott next up and the last section for the meeting is in the weeds in the weeds is an opportunity for more long form discussions these can either come out of status updates or be topics that are identified ahead of time you've got any in the weeds topics please make sure they get added to the in the weeds section in the note stock we do have a couple topics there so if anybody knows of another one please go ahead and put it while we're discussing this one so first in the weeds topic is for Justin Justin are you able to read or should I read for you I can go ahead and read on this one so sorry I just have a bit of a sore throat so let me be my talking so as you read I've made some great process progress on connection manager feels close to potentially getting at least the B1 kind of merged in and then basically trying to figure out what next steps are going to be just to try to figure out kind of plan of attack I know when we talked about it a while ago we didn't know if we wanted to just update requests first or request in Minium QTT what help docs we want to update and things like that I'm obviously at the point that requests uses it then you'll need to be added to the frozen modules for whatever has requests frozen in and so just trying to figure out where we want to go on that and so I can start working or at least prep aid or figure it out kind of next pieces so okay yeah I'll let Scott or Dan or Jeff or if anybody has ideas around that I would mention for myself I'm probably in favor of doing the requests and Minium QTT at the same time instead of trying to do them separately would be my thought and as far as documentation to the best of my knowledge there's not a whole load of a lot of documentation I don't think because a lot of the projects and learn guides and things are not actually typically using Minium QTT or requests directly but a lot of them use the higher level libraries like PyPortal library or Adafruit IO library so I would say one step during testing will be making sure that those higher level libraries are either unaffected or if there is like an API change that's needed from the user code then that's I think where the documentation would be around is more on that like higher level the PyPortal and the Adafruit IO type libraries and stuff but they should need any changes other than the fact that potentially if you're using someone that's not frozen you would now have to make sure to add that library as well so okay yeah and then yeah I would say in my mind it also makes the most sense to go ahead and just update the frozen ones at the same time for both of them again still like request a Minium QTT at the same time would be my thought but Scott or Dan or Jeff or anybody else have thoughts on connection manager next steps I think get it in the bundle right so that when we update Minium QTT and requests we already have like the new dependency plumbed all the way through and then I would probably still do a major version release just to make it clear that like a lot is changing and and you may need to install the dependency even though it's not doesn't require any code changes and I think I would kind of I might buy us to actually doing one and then the other like maybe request first actually just in case you find something just in case you find something in the like initial use of it that so that you don't have to go back and fix it in Minium QTT as well and I've been playing with them both pretty extensively like I've got draft branches for both of them obviously they point to it get repo for the requirements so I think you know separate number one is getting that first PR approved and merged at that point I can open up the other two PRs and I'm happy to do one at a time doesn't really matter too much to me and then we don't need to be that cautious I guess yeah let's just let's just get it in and released and do it so we really get that first PR merged in release the version that way I can update the other ones and then just going to start moving that way and then add connection manager to the bundle which is basically just opening PR on the bundle repo with some changes okay is it pretty straightforward I've been looked at it yet it's pretty easy there's a learn guide for it in linky 2 afterwards if you want it's okay awesome alright yep thanks Justin next topic yeah looking forward to that review and then we'll kind of go from there yeah I haven't even gone through my email today today hopefully next topic is for Scott so thanks so this is also primarily for Jeff and Dan but I was running down this pulsing crash on Sandy and I'm pulling a string that is longer than I thought it was but basically there's a now I discovered a class of bug where the Sandy code was originally written in that D and it didn't fully well D and it did fully de-initialized stuff but it wasn't called by a called by a finalizer and then along came some changes that enabled finalizers for pulsing which makes total sense to me but the problem is that now on reset we call this blanket reset function and then we then then the finalizers run so in specifically in this case the blanket reset sets a ref count to zero and then the de-init comes along and decrements it and wraps around because it's unsigned which causes problems so the general thing is like the general question I have for you is should we move away from bulk resets and only do finalizer based resets that's kind of the tendency I think for the newer APIs anyway um yeah that's kind of my gut because then you know that finalizers are more reliable versus remembering to add a reset I think we have bugs where we forget to add this reset or that reset and it just we know the same thing is going to happen either way when the heap gets cleaned up and I think that's really a good thing right I mean go ahead Dan uh what so when so the finalizer runs when the VM shuts down like it's going to run then it is but right now we shut down the heap after we do the bulk resets so that the memory is still valid in the bulk resets so that's why the bulk reset gets run before the heap is completely de-init and the finalizers are run and are there cases in which we have some severe error um like suppose there was a some safe mode thing or some internal state inconsistency then is it possible that you like exit the VM and and not run it and not run it yeah I don't I don't I don't think safe mode well because safe mode really like you call the safe mode function it's hard it's it's it's a value and then it does the hard reset like okay I think in that case that's true I guess not safe mode I'm just thinking about any other any other cases I guess it's it's a controlled restart in all of the cases so right and we have most we have most of this code already because we've we've been pretty good about writing de-init so that they actually de-initialize stuff yeah um the problem is that when we take something that was not finalizers but how to de-init and then change them but we don't remove or make sure that the full preset is um is like compatible with the de-inits like this is where we're running into this issue where we're like crashing yeah yeah yeah um one thing that's also interesting to think about in terms of the and I think maybe this is like I should file an issue for the larger like redo but the other thing is if we move away from bulk resets we can move away from never reset um or at least to a model where the objects need to know that the finalizer should be ignored or something like that um rather than having these separate um like resource lists that are never reset um you know so in the case of like the main display you create the main display and then the finalizer won't actually be run for that at all right like it will live as long as possible and now you don't need never reset because you don't have to worry about a bulk reset coming along and undoing its state right um mm-hmm which is you know we've always had problems with never reset as well so like the work to do here is actually to look at all of our APIs and make sure that they're all finalizer based um that's the major that's the major work which I think I don't want to do right now for 9.0 because we're trying to get it out the door yeah um I think I have I have to so another thing I ran into with this is like I was I fixed pulse in and then I looked at pulse out and it had a problem and then I realized that pulse out internally uses a PWM out on the on the CMD and because it because the kind of the using class is finalizer run then dnit for PWM out is also called after the bulk reset of PWM out so it's like it's also a bit viral so I think I can at least grab a hole and I did this all on the screen last week if you want to see me do it but I think if I have to do PWM out now um but I don't think I have to do absolutely everything for 9.0 okay um because if I change PWM out to do finalizers not only do I have to fix it for CMD I have to make sure that it works in all of the ports like switching to a finalizer is a cross port endeavor yeah I agree not 9.0 and these bugs will just linger or we won't implement right so I think maybe I'll file in an issue a new issue so this shouldn't change any public API so it's something we could probably do before 10 but like the audit every API and make sure it's finalizers and then remove all the bulk resets and never resets is like a bigger task we could do between 9.0 and 10.0 yeah for now I'll just do the the stuff required to fix this crash which is pulse in pulse out and PWM out hopefully in MicroPython they just added another macro or call to create objects with finalizer or something like that there was something something new they added to bundle that up together oh great because I did notice that there's an easy new such and such thing that's a one call that sets the base type but for finalizer that doesn't exist so that's right I think somebody just did that I don't know who either Angus or Jim alright I'll take a look at that too because it would be good to just like maybe we do the MicroPython update and then we do the switch to finalizers get rid of all the nonsense which is a big internal change but okay well that sounds like a good short-term and long-term plan alright thank you Scott and Dan with that that was the last of our in the weeds topic so I will move us on to the wrap up and get us on the road here this has been the circuit python weekly meeting for February 20th, 2024 thank you to everyone who participated as a reminder if you want to support Adafruit and circuit python and those of us that work on circuit python consider purchasing hardware from the Adafruit shop at adafruit.com this video and excuse me 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 it will also be featured in the python for microcontrollers newsletter which you can find at adafruitdaily.com to subscribe to that the next meeting is I believe going to be at its normal day and time on Monday that's going to be the 26th of February at the standard 2pm eastern 11am pacific that meeting as all of them will occur here on discord you can always join the discord by going to adafruit.it slash discord and as always if you want to be notified about the meeting on the day of or any changes to the schedule you can ask to be added to the circuit python roll over on discord so that's it for this one thank you to everyone and we'll see you all next week