 Hello everyone. This is the Circuit Python Weekly for March 4th, 2024. This is the time of the week where we get together to talk about all things Circuit Python. I'm Scott, and I'm sponsored by Adafruit to work on Circuit Python. Circuit Python is a version of Python designed on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit. So if you want to support Adafruit and Circuit Python, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to the URL adafru.it-discord. We hold the meeting in the Circuit Python DevText channel and the Circuit Python Voice channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with the U.S. holiday. In the Note Stock, 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'd like to receive these notifications, ask us to add you to this at Circuit Pythonista's Discord role. There's a notes document that accompanies the meeting and recording. You can contribute to this document beforehand. The final notes document includes timestamps to go along with the videos so you can use the doc to skip around and view parts of the video that interest you most. The meeting tends to run 30 to 60 minutes. After each meeting, we post a link to the next meeting's notes document to the Circuit Python DevChannel on the Aideford Discord. Check the pinned messages to find the latest notes doc so you can add your notes for the following meeting. If you wish to participate but cannot attend or don't wish to speak, you can leave hug reports and status updates in the documents for us to read during the meeting. The meeting is held in five parts. The first is community news. This is a look at all things Circuit Python and Python on hardware in the community. It's a chosen set of items from our Python on microcontrollers newsletter. The second part is the state of Circuit Python libraries in Blinka. This 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. Third is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. The fourth part is status updates. Status updates is an opportunity to report on what we've been up to. Take a couple of minutes and talk about what you've been doing in the last week since the last meeting and what you'll be up to over the next week. The fifth part is in the weeds. In the weeds is an opportunity for more long form discussions. These discussions can come out of status updates or be something you've identified ahead of time is too long for status updates. And that covers how the meeting will go. With that, we'll get started on community news after I take a time stamp here. I turned on the markdown. Markdown makes it go away. Google Docs has markdown support, which means it follows the formatting, but it doesn't leave the markdown marks in it, which is annoying. Okay. Anyway, community news is a chance for us to give a preview of the Python on microcontrollers newsletter. I picked two Python things related out here. First is that the Raspberry Pi celebrates 12 years. Happy birthday to Raspberry Pi on February 29th. Their leap year baby technically it's their third birthday. They've sold 61 million units as of their anniversary. They celebrated by having their in-house maker Toby whip up projects with Raspberry Pi Pico W, Neopixel LEDs, and MicroPython. Check a link there to Raspberry Pi news and also to Tom's hardware and the Adafruit blog. Next up, the PyCon US 2024 talks schedule has been released. Several talks and tutorials involve Python on hardware. Three highlighted here are is one is open source robotics with Python, learn robotics with no robot required by Kat Scott. Our own Jeff Epler has a connecting old to new with circuit Python retro computer input devices on modern PCs. And then lastly, we have introduction to MicroPython getting started with the BBC Microbit by Juliana Caroline de Souza. At PyCon in Pittsburgh in June? May? May June? I think May. All right. It's in May. Thanks Jeff. Newsletter details, the Python on microcontrollers weekly newsletter is a circuit Python community run newsletter emailed every Monday. The complete archives are at www.adafruitdaily.com slash category slash circuit Python. 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 project, edit next week's draft on GitHub and submit a poll request with the changes. You may also email cpnews at adafruit.com or tag a post with hashtag circuitpython on mastodon, blueskye, or x formerly known as Twitter. All right. And that's it for community news. Thanks to Ann for putting all that good stuff together. Next up, we have the state of circuit Python libraries in Blinka. This is a chance for us to take a hopefully objective, more statistical look at the health of the larger circuit Python project. I'll go over the overall and core and then we'll hand it off to some folks for the other pieces. So overall, we had 60 poll request merge from 15 different authors, which is awesome. So new names to me are Mark Camp, Stan C. Analogic is new to me. Sean Chain W is new to me. Mario Swila, Mario Peche are all new to me as well. Overall, we had seven reviewers. So thank you to all of our reviewers. And we had 17 closed issues by eight people and 13 opened by 12 people. So we're net down four. And, you know, we're getting a high single digits, low double digits for folks being involved. So that's great as well. Next, we have the core. Taking in another timecode. So in the core, we had six poll requests merged from five different authors, which is awesome as well. And the same new names that I said, we had two reviewers. 21 open poll requests, which is well under our 25 single page goal. So that's good. Many of these are drafts as well. We have five closed issues by three people and seven opened by six people. So we're net up two for a total of 673 open issues. We use milestones to track prioritization for eight of fruit funded folks. And eight to X is our current stable branch. And there are no open issues there. I don't know if we plan on doing one more release there or not. We have 12 open issues for 9.0. This is where we're putting a lot of our focus right now to get 9.0 stable. We have 20 open issues for 9XX. And those are the ones that we want to do soon after or as part of like the post 9.0 launch. We also have one issue not to send a milestone as of when these stats were taken. So we'll just need this really common for over the weekend. We just need to make sure we triage things. I'd be worried if that was more than 10. And with that, let's go to FOMI guy for an update on the libraries. All right. Thanks Scott. This section covers all of the circuit Python libraries, which are Python level code that helps you either interact with certain bits of hardware like driver libraries or the other main class that we have our helper libraries that just allow you to create your project at a higher level without having to worry as much about some of the intricate details involved. All these libraries can be found on GitHub under names like fruit underscore, circuit Python underscore, and then the name of whatever library it is. Across all those libraries this week, we had loads of pull requests, 50 pull requests merged this week from eight authors, a couple of the names that are newer or less familiar to me. So these folks might be newer contributors or less frequent contributors. Thanks to Mark Camp, Danzie and Analogic this week. The rest of the names were more familiar to me. We had seven reviewers. So thank you to all of our reviewers, including Tectric Scott, Brent, myself, Dan, Liz and maker Melissa. Of our pull requests this week, we did have quite a few of the older ones. We had one over 300 days, one at 200 days and two at 100 days and then a small handful, less than 100 days and a few dozen that were just open for a single day all as part of the connection manager updates, which I'm sure we will hear a little bit more about throughout the meeting. That leaves us with 54 pull requests open. The oldest one I believe is a draft and it's 564 days. The newest one is just one day. In regards to issues for the last week, we had nine issues closed by six people with four new issues opened up by four people. That leaves us with 737 open issues and there are 19 of them that are labeled good first issue. You can find those 19 and more over at circuitpython.org slash contributing, which is the place that you should head if you are interested in contributing on the Python side of things to Circuit Python. On that page you'll find a list of open PRs as well as open issues. If you're looking to contribute, that's a good place to start. You can get started with reviewing. If you look at the list of open PRs, you can take a look at those PRs. Look at the code. If you have hardware, you can test it out. Leave a comment on the issue, letting us know that you tried it out or took a look at it and what you found. Once you get the hang of that, we can get you leveled up to be on the official review team. If you'd like to actually start getting your hands dirty contributing code and things as well, you can bounce over to the issues tab. Take a look at the open issues. Find one that you've got some hardware for and start working on that and submit a PR in order to solve it if you can. We do have guides for contributing to Circuit Python using Git and GitHub. We also have lots of folks who are available on the Discord who are willing to help you get started. We want everyone to be able to contribute no matter what skill set or background or anything like that. We're always going to be willing to help you get started if that's what you want to do. Rounding out the library stats for the week, we've got the PyPI stats. So there were 129,726 PyPI downloads across the 325 libraries. The top 10 list is here, and the libraries that were updated this week look like PyCamera, Connection Manager, ESP32, SPI, and Requests. These are the ones listed here, but I think there probably are a number of others that were related to Connection Manager. Anything that deals with the network likely was updated this week. So that's what we've got for libraries. Thanks. Thanks, funny guy. All right. Next up, let's go to Maker Melissa for an update on Blinka. Hello. Hello. So Blinka is our Circuit Python compatibility layer for MicroPython, Raspberry Pi, and other single board computers. This week, we had four pull requests merged by three authors and two reviewers. There are currently a total of nine open pull requests amongst other repositories. There were three closed issues by one person to open by two people, leaving a net of 85 open issues. There were 15,106. We are at 129 boards. And that is it. Thanks, Melissa. All right. Let's go on to Hug Reports. Hug Reports is kind of the opposite of this objective view. This is a subjective view of the health of the project. A chance to thanks folks for what they're doing within Circuit Python land or even abroad. This is great for just recognizing the folks that are doing awesome work and also reinforcing the things that we value as a community. So I will start and then we'll go through the list in the note stock. I will read folks off if they're marked as text only. So first for myself, Hug Reports a scur for testing I2S on 9.0 builds. Hug to Justin for following up with all of the connection manager changes and also a hug to TAC for fixing tiny USB for me. And next up is Dan. Okay. Thanks to Scott for several technical conversations over the past week. We had one just a few minutes ago. Thanks to Justin. In addition to all the connection manager stuff that he was working on over the weekend, he was trying to use SIRCUP and noticed there were some problems with it and there was a problem with the PI, the library bundle that was source code. It did include version information. And that actually broke some time a couple of months ago. So we fixed that and then also fixed another issue having to do a SIRCUP update that I need to merge in. Thanks to Marias Vickler who added a pull request to SIRCUP Python that was approved to set the USB HID interface name because it was fixed at SIRCUP Python space HID but a lot of people wanted it to be something different for their own keyboards or whatever. And this is a feature that has long been asked for and it's great that we have that now. Thanks to Foamy Guy who over the past week or so I've had a whole bunch of interactions with about infrastructure and debugging and all kinds of things. I really appreciate your help. Okay. Thanks Dan. Next up I have notes from DJ Devin 3. After I take the timecode. DJ Devin says, Hug report to Justin and all the developers that worked on getting connection manager merged. I'm excited to start a project and look into it soon. Hug report to Hairbrain and Lady Aida for answering some questions about chip select lines needing pull-up resistors. Lastly, hug to SCUR for making me aware that the Raspberry Pi CM4 modules and their add-on boards are no longer hard to come by. And next up is Foamy Guy. All right. Thank you. Hug reports for me this week echoing what a couple of folks have said. Thanks to Justin for continued effort on the connection manager as well as follow-up changes surrounding that. Thanks to Dan for reviewing and merging many of those changes across the libraries. Thanks to Liz for testing out an issue that popped up on the Feather DVI and submitting a fix for that. Thanks to user Bear over on Discord for patiently offering help and suggestions during a live stream when I was struggling to understand. Thanks to Tyeth for testing out the web workflow support proposed for CIRCUP. Thanks to James J. Nadow. I don't know if I pronounced that improperly or not. I apologize if so. But thanks to them on GitHub for adding the M5 card pewter support to the CIRCUP Python repo, as well as posting some steps elsewhere online for how to flash the boot loader so that you can get that loaded. And then lastly, thanks to Jeff for reviewing some of my PRs in the Pi Camera library. Thanks. Thanks Foamy Guy. Next up is Jeff. Hello. Today I just have a group hug. Thanks Jeff and Jerry. And another group hug, hi everybody. Thanks Jerry. Alright, next up I have notes from Justin who says, Hug Report to Brent, Dan and Tanute for reviewing and merging all my PRs. And now it's time to hear from Liz. Hello. Hug Report to Dan, H, and Tanute for continuing the fight against CIRCUP Python 9 bugs. Foamy Guy for assisting with a Feather DVI issue that popped up. Jepler for having done a few CIRCUP Python open AI projects on Learn that made my most recent guide a little easier to get started with, and a group hug. Thanks Liz, and now for Maker Melissa. I just had a group hug for everyone. Thanks Melissa. And Mark, are you around? I'll read Mark's off. Not voice. Okay, no problem. Hug Report to Jepler for a birthday project idea he gave me last year that just popped up as a phone reminder. And now from Todd Bot, we have a group hug. That's it for hug reports. Thank you everyone. Next up is status updates. I don't know if I said it, but we do this as a round robin, so give everybody a chance to speak up. I will start as an example and we'll go through the list of folks in the note stock. Just like last time, but this time we want to hear about what you've been working on in the past week and what you plan on working on in the coming week. Okay, let me take a time code and I'll go. So for me, I was mostly out last week with a sick Ari, my son. He's doing better and at daycare today. I did fix the read the docs build that I think Antic Data discovered that was wrong and then Dan was looking at it too. It was accidentally building the micro lab docs instead of the circuit Python ones. I disabled a warning printing during tab complete. So that fixes an issue that bill 88 t filed I think there's a PR out that I think just got merged to make file system writes work when not connected to USB. And I actually I take that back. I don't think it was filed. We got to figure that out. That may be it in the weeds topic. I started debugging an RGB matrix crashed you to the interrupt watchdog not having but haven't found the issue yet. Dan's working on this as well. And then the start of the week week at least will be working on squashing all of the remaining 9.0 bugs or punting on them if we don't want to do it. So that's where I'm at. Next up is Dan. Okay. In the course of debugging some nrf bugs I fixed the storage leak in the Adafruit BLE library that'll be merged in soon after review. I assume I added a finalizer for ESP camera to fix some issues with playing tones on the Memento camera board. And I'm looking at all the remaining 9.0 bugs and figuring out what to do with the ones that I have the most expertise on. Okay. Thanks, Dan. Next up I have notes from DJ Devon 3 who says finish the 3D model of the 64 by 32 5 millimeter pitch matrix panel. The model is now available on principles and Adafruit CAD parts. For those who want to design your own bracket having the model available makes it much easier. Revamped my Fitbit API project to be more stable during Wi-Fi and power outages updated the code from 822 to 8 210 without issue. Designed in order to new PCB with 8 slim switches for mounting and enclosures will take about 2 weeks to arrive. This week I'm redesigning my 3D printed 3.5 inch TFT feathering enclosure and adding more shelving and cabinets for storage in my workshop. For some reason my workbench is always littered with microcontrollers. Having more horizontal surfaces to store things is always a good idea. I feel that for sure. Next up we have notes from ADCC who says continue USB debug with argon blue implementing a new wrap trace buffer for debug. Useful for low level debugging with minimal interference and continue BLEIO for RP2 development. And next up is FOMI guy. Alright, last week I submitted a PR that adds support to Pie Camera Library for being able to scale the overlays which I worked on the week prior. This allows you to either use frames or borders that are a different size from the actual photo that you're taking the picture for but scale it up or down. Or if you use like sticker images you can scale those up or down to fit your photos. If you want an amusing example of that I pasted one in the note stock of a little Lego robot with some nice glasses on that I used that feature for. I did last week a bunch of reviewing of older library PRs and moved forward the ones that I could. I fixed circuit instructions across a bunch of libraries. There was a period of time where cookie cutter I think had a bug in the libraries that got created during that time. The circuit instructions in the readme was slightly wrong so I went through and fixed a bunch of those last week. I over the weekend started on this, circled back to the web workflow support for circuit, made changes based on the last feedback that was there. As well as found a couple other issues and fixed them and a few other improvements that were submitted as part of that as well. I got a M5, I don't know if it's M5 stack or just M5, the M5 card pewter device last week. I figured out how to flash circuit Python on it as well as how to flash it back to the demo code that it came preloaded with. And what I want to look into on that device which is my last item as well for this week is trying to write some Python level mock-up code of how the keypad API could work in order to kind of have it add support for using either rows or columns that are, I don't know if multiplexed is the right term, but it actually only uses three pins but there's a shift register so that there's eight total outputs and then those represent the rows and then it has column pins like normal. So it's not quite set up to handle it but it's not actually that hard to do. So I'm looking into the Python code for that and that's what I have got. Thanks. Thanks for having the guy. All right, next up is Jepler. Hi again. I was out last week but I did do a little circuit Python work. In a branch I made it possible to use the cores SSL implementation on WizNet Ethernet which is a SPI connected Ethernet device that implements the TCP and UDP protocols. So that's kind of cool. The downside is it uses up most of the remaining firmware space. For instance on the Feather RP2040 that makes the firmware area about 95% full overall. So I think we're not likely to enable this. Generally this is a pretty niche feature to spend about 200K of flash space on but I would still like to see it merged and enabled on one particular board. WizNet makes a Pico form factor board that also has an Ethernet port on it. So that will come at some point I hope. But this week it is more centered around Adafruit products that we're working on. So I will be in Adafruit LAN working on support for MFM floppy writing. The status of that when I put it down Friday before last is that I could write data that I generated the MFM encoding for and read it back with my code but it doesn't read on a USB floppy reader. So I just need to sort out what are the differences and fix them until it reads on my USB floppy drive. The hope is eventually that this code can be pulled into CircuitPython although we'll have to see how that goes. Again it probably adds a lot of code that's a fairly niche usage. It also needs a lot of RAM so it is really not a super practical appliance. But anyway in CircuitPython world my plans for this week when I need downtime from the floppy project I will look at getting the SSL code closer to being pull requestable. And also I have a couple of issues to work on for version 9 and incidentally I did just reproduce some problems accessing slash SD. So Melissa thank you for reporting that problem, hug report and more on that as it comes. Thanks Jeff. Alright next let's next let's go to Jerry. Okay so I spent a lot of time this week working on the combined radio module library to combine the MFM69 and 9x libraries. So now I pretty much got all the functionality that both of the libraries had combined now into one and it all works the way it did before. Just like to do to run the examples is to make a really minor change to the to the actual you know calls to set it up. But um. And then so now I'm trying to add some stuff and my big breakthrough the week was to be able to add FSK support to the RFM 9x. Because right up now it only it only is set up for Laura. And what that enables me to do is have an RFM 9x actually talk to an RFM69. Even though the product guide says they can't do that they do just fine as long as they both do a FSK. So that that's kind of fun and that means that you know people have both of those modules now can actually communicate between them. And my next part of the whole thing is to now take the radio head. Support or compatibility and make that an option make it the default still they probably leave it that way, but enable the someone to turn that off so that it just writes raw packets out. And then on the FSK mode, the both the RFM69 and the 9x support have built in addressing note addressing filtering for packet. So you can use that if you send raw packets. So my goal is to get that up and running and that will then allow these units to be used with the other Arduino libraries that are out there radio live or low power labs that don't have any particular header. Making progress and having fun with it. Awesome. Nice update. Thanks Jerry. Next up is Justin. Yeah, just some stats if people are curious. So, almost everything on connection managers merged at this point. In the end I touched 25 repose there was 46 PRs and about 3000 lines added 2000 removed. So just kind of interesting to see where all something like that touched. Over the weekend I put together a playground note, which was both fun to play with playground and whatnot and everything and just kind of put it out there. I know a couple people have looked at it already. After I did that I started digging into a circuit because I hadn't actually used it before. I found the issue that Dan mentioned earlier and things like that so I opened up a couple PRs into there. And at this point I'm going to get back into some of my own libraries around time and config and probably continue to watch the help with channel and see what might be my next kind of fun thing to really kind of dig into as I watch the connection manager stuff kind of settle. Sounds good. Thanks Justin. Next up is Liz. Alright. Last week I worked on a circuit Python project using open AI with the Memento camera board. Memento takes a photo, converts it to base 64, uploads to open AI and open AI returns a response based on the prompt provided. It was really baffling in a good way how accurate the responses were especially for things like translating text to English. I know there are a lot of opinions about AI but this feels like a helpful use case. I wouldn't think about accessibility, how it could go out to there. And the guide is live now. And this week I'll be working on a product guide for the new Stema analog switch that just went into the shop. I also have a couple of projects on deck that will be code in circuit Python. One is a feather battery monitor charger and another is controlling an Elgato light over Wi-Fi. Awesome. Thanks Liz. And last up is maker Melissa. Hello. It was a short week because I was visiting family but I worked on fixing some of the Raspberry Pi installer scripts backwards compatibility bugs. I fixed a bug in Blink-a-Display.io that was causing it to fail as a number that was expected to be an integer was converted to a float under certain conditions. And I continue working on the PiEyes project and I'm working on desktop buffer scaling at the moment and that's where I'm at. Thanks Melissa. And thank you everybody for your status updates. The last section that we have here is in the weeds. This is a chance to have any longer form discussions that we want to have. I just added a topic. If anybody else has topics as well feel free to add them below me. But I wanted to just check in with Dan. Do we need to have a discussion about how this should work? The background for folks listening is that I have a PR out that changes the way file system writability works. So previously you had the storage remount something in order for Python to read and write it. But the changes I made actually allow if you're not on USB or USB hasn't come up yet it allows you to write files and potentially block USB from being writable. So Dan do you want to just give me an update on what you found there and do we need to make some decisions around that? So I did a test where I wrote a program that just opened a file immediately and wrote it and it beats USB to the punch. So that means that it can write the file and then circuit pi is read only USB which is not the semantics that we've had before at all. So I said well maybe we need to go back to the regular semantics on this. I mean I think the underlying locking code is it's cleaned up considerably. But for the case of competing with USB I don't think that it should be the case that depending on the timing of your program USB is or is not read only seems not the greatest. I'm just curious what issue this addresses. The changes were done because on Web workflow it wasn't writable even if you were on USB. Okay I noticed that. So I fixed that but the problem is I went a little too aggressive and I made the writing from Python code work the same way. So I think I think we want the workflows to be like a bit more dynamic like this but we don't want user code to be. And so I just I got a little little little aggressive like I said. But yeah so this yeah so this this this fix was done because somebody noticed that like if you have you know your Wi-Fi device plugged in and you still wouldn't be able to edit it without the storage. Or the or the disabled stuff. I mean I think the reason that it works for Web workflow and internally in Python is that those things make atomic transactions to the file system. Whereas when it's USB it's not those the blocks that are being written from USB are not part of some transaction mechanism. So that's why you have to lock out USB completely. I mean that's the explanation for this. Right. Yeah there's no way to enable USB rights and do that safely because you can never tell when USB is done. Right. Unfortunately. But you could have the same race condition between using the Web workflow. If you're if you're writing a file or creating a file from Web workflow and USB is enumerating you could have the same thing happen. But I think that it's a lot less likely than this weird code case. Okay I'll undo that. File maybe or something. Yeah. It's just a matter of like whether anything is grabbed the block device lock while USB is defined deciding whether to be read only or not. So yeah I think I'll change it back. Everyone that the reason for all of this is because Maco because Apple refused to implement something called media transfer protocol. Because it competed with iPods. We could live in a better world where USB drives worked at a file system above the system not below it. Yeah. So that is the first item and I see FOMI guy added another one and I'm curious for an update about this. So let's go to FOMI guy next. Yeah I had a just a quick question we saw this issue pop up on the feather DVI basically somebody noticed that the old demo code was having an out of memory exception and what it boiled down to is that device it initializes the display automatically inside the board in it. It comes up as board.display just like you know PyPort or anything else with a built in display. But the demo code I think might have been written before that was actually the case back when it maybe did not initialize it automatically in the core and so the demo code had released displays and it initialized the display you know quote unquote manually. The kind of crux of my question is in a scenario where a device initializes a display automatically and board in it and then code pie turns around and immediately releases the display and then attempts to re initialize it. Would that be expected to work always I guess because it seems to me like it should release the memory that was used when it was automatically initialized so then it should have enough memory to initialize it again. So it makes me think maybe it's not actually releasing everything when it gets released but I also don't know if that simplistic view of it is really how it works or not. I think it's tricky and it's definitely trickier in nine because it depends on where you're allocating and nine is going to be more susceptible to fragmentation and I don't remember if like so you're allocating a big buffer. I don't remember whether we allocate that back into the outer heap or not so like when you're when you do board in it the VMs not up so you're going to allocate it outside of the VM heap and I think if you run it during the VM you're probably still not allocating to the heap but if anything else has gone and gotten into that spot that you freed in that time being you risk like the big spot where you hope to allocate again being smaller and then failing your allocation the second time. Okay. So it sounds like that could like it may not always be the exact same on every device but it could that may not really be a bug necessarily indication. Yeah I mean it's good to check like your intuition or like maybe something's not being freed I think it's fair like it's all it's all manual memory management so it's totally possible that something's not being freed. But like I could imagine oh like yeah I yeah I don't know it would take some there's a debug print that could help you. But yeah just it would take more analysis of like okay this this chunk was allocated for this big frame buffer and then like this one other random small thing got allocated in that chunk before we had a chance. I gotcha. But the outer heap should be pretty smart in terms of matching sizes so I would hope it do it do a better job. I will do a kind of quick like sanity check because I have not actually looked at the numbers I just know that it was raising the error when you went to initialize it so I'll do an actual check and look at the numbers and see if it's kind of different enough that it looks suspicious or for maybe just having like one of the input. Reports or something occupying some of the space where it was or something like that. Yeah I guess what I would say is do release displays as close as possible to initializing it like minimize the amount of other stuff that's going to happen between the two things. Oh between those two okay I'll take a look at the code I think they were I believe they were one after another. I think they usually are yeah. Yeah they were it was there was there's like an if statement in the original code because it was it's written to handle the feather DVI or just a Pico that has I guess like a breakout DVI breakout or something it must be. Yeah so the only thing between release and initialize was the kind of beginning of the if statement so they were pretty close together but I will I will see I'll check the actual numbers and see what's getting reported and see if it seems like there's an obvious trunk missing or not and can go from there. Yeah I mean it's all it's all really tricky especially when you're allocating really large chunks because fragmentation can kill you pretty quick. If you need something big to fit. If you or Dan happen to have a moment sometime if one of you can take a look at that learn guide PR just to see if that kind of cause and effect hypothesis actually makes sense for what we saw there. Yeah I have it open I'll look at it later today. Cool. I saw it go by and I was curious about it so. Look at there. That covers it thank you. Thanks for the guy and thanks Liz as well for looking at that now too. Okay and that is it for the circuit by the weekly meeting for March 4th. 2024 I'm stalling as I get back to my notes. Thank you everybody who's participated if you want to support Adafruit and Circuit Python and those of us that work on circuit by then consider purchasing from the Adafruit shop at Adafruit.com. It looks like next week is also on schedule. The next meeting will be next Monday as usual at 2 p.m. Eastern 11 a.m. Pacific on Discord. The meeting I'm going out of order. The video this meeting will be released on YouTube at youtube.com. Adafruit and the podcast will be available on major podcast services. It will also be featured in the Python for Microcontrollers newsletter next week. Visit adafruitdaily.com to subscribe to that. Oh and Jeff has a note that note that the U.S. changes to summer time next weekend. So if you're not in an area that follows the same DST role a.k.a. If you're not in the U.S. it's likely that the time will change for you next week. So thanks Jeff for that note. This meeting is held on the Adafruit Discord server which you can join anytime by going to the URL adafru.it.discord To be notified about the meeting and any changes to the time or day you can ask to be added to the at-circuit-by-the-neesters role on Discord. With that the time will be 2 p.m. in UTC-4 which is a confusing way to talk about it. Anyway, hope to see you all next week. Thanks everybody have a great week.