 Hello everyone! This is the CircuitPython Weekly Meeting for August 1st, 2022. This is the time of week that we get together to talk about all things CircuitPython. My name is Tim, and I am sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python that's designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to support them and CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted in the Adafruit Discord server. You can join anytime by going to adafruit.it.discord. We hold the meeting in the CircuitPython Dev Tax Channel and the CircuitPython Voice Channel. This meeting typically happens on Mondays at 2 p.m. Eastern Time, 11 a.m. Pacific Time, except when that coincides with a U.S. holiday. In the note stock, there's a link to a calendar that you can view online or add to your favorite calendar app. This calendar will contain the dates of all the meetings, especially the ones that do end up changing. We'll send out notifications of the upcoming meetings via Discord. If you'd like to receive those notifications, ask us to be added to the CircuitPython Easter's roll on Discord. There's a note stock that accompanies the meeting and recording. The notes document contains timestamps to go along with the video, so you can use the doc to view only the parts that interest you the most. The meeting tends to run about 30 to 90 minutes, depending on how many people we have, so this gives you the opportunity to skip around. After each meeting, we post a link to the next meeting's notes document on the CircuitPython Dev Channel on the Adafruit Discord. Check the pin messages to find the latest note stock, and you can add your notes for the following meeting. You can do that throughout the week as well. Those go up typically within a day or so after the meeting occurs, so you can actually put those in throughout the week if you like. If you wish to participate but you cannot attend, you can leave hard reports and status updates in the document for us to read aloud for you during the meeting. The meeting is going to be held in five parts. The first part is community news. This is a look at all things CircuitPython and Python on hardware in the community. It's a preview of the Python on hardware, excuse me, the Python on microcontrollers newsletter. The second part is the state of CircuitPython, the libraries in Blinka. This is a statistical overview of the entire project. It's a chance to look at how the project is going by the numbers separate from what we're all up to. The third part is the hug reports section. This is an opportunity to highlight the good things that folks are doing. Take time to recognize the awesome folks in our community and beyond. The fourth part is status updates. Status updates is an opportunity to sync up on what you've been working on. Take a couple of minutes to talk about what you've been doing since the last week and what you'll be doing in the next week until the next meeting. Then the fifth and final part is in the weeds. This is an opportunity for more long-form discussions. These can come out of status updates or be identified ahead of time as too long. That covers how the meeting will go. I did not catch maybe Scott. I think maybe you're unmuted. I didn't catch who it was that coughed. Let me see here. That's how the meeting will go. With that, we will do community news next. Let me start taking time stamps and get to our community news here. First item in community news is a new milestone for the Circuit Python project. We reached 300 AidaFruit Circuit Python libraries recently. This is a major milestone. AidaFruit has now written 300 AidaFruit libraries. These cover drivers, helper functions and more. Just a reminder to everyone. AidaFruit invests time and money into providing free open-source code to help you use the AidaFruit products and much more in the hope that you will buy some project gear from AidaFruit. You can support the efforts of developing libraries and more by purchasing hardware from AidaFruit.com. There is a link here to the AidaFruit blog which does contain a couple of additional details if you want to check it out. Next up is from the GitHub blog. This was a notice that the GitHub sponsors program is expanding, bringing the total number of regions covered to 68. They are continually branching out, adding more and more regions to this program, which is great. For those that don't know, GitHub sponsors is a way for open-source projects and developers to receive funding and support through GitHub. Even like the MicroPython project and many of the Circuit Python developers are available to be sponsored through Discord, so it's great to see that coming to more and more regions all the time. Next up is the PyOhio talks, including a talk by our very own Katni. PyOhio 2022 had some great talks last week. Katni's was called Simplicity and Fun, Learning with Circuit Python. You can find the video of Katni's talk on the YouTube link here. There's also a Twitter link as well. And one additional YouTube link which contains the entire playlist of all of the PyOhio talks if anyone is interested in watching those. Next up, we have a couple of interesting projects for the week. The first one is from GeekMom projects. This one is documented with a link on Twitter, and this was a very neat, colorful LED headband with some nice LED animations running on that, so that was super cool. And the other one which I've grabbed here that I thought was really neat was a project using the Adafruit Matrix Portal as sort of a display to show live blood sugar data from a Bluetooth-enabled blood sugar monitoring system. So it would pull the data from this little patch on the user's arm, send it to the phone, the phone would send it to the server, and then the Matrix Portal was able to pull that data out of the server using some API and show it on the display. An honorable mention for this one I saw in the video for this project, this person also hooked up their terminal prompt to show their blood sugar, which I thought was a really neat idea for a developer trying to get some information to stay in front of their face and on the tip of their brain. So really neat stuff there. Check out the links for both Twitter and TikTok for that project. So that wraps up the community news, so with that I will finish up by mentioning that this all of these items and many more come from the Circuit Python Weekly newsletter, which is a Circuit Python community-run newsletter that is emailed every Tuesday. The complete archives are available at AdafruitDaily.com. It highlights the latest Python on hardware-related news from around the web, including Circuit Python, Python, and MicroPython developments. To contribute your own news or projects, you can edit next week's draft on GitHub and submit a pull request with those changes. Or if you are not as familiar with GitHub, you can also just tag a tweet with hashtag Circuit Python on Twitter or email to cpnews at Adafruit.com in order to submit those newsletter ideas. So next up, we will have the state of Circuit Python, the libraries, and Blinka. I will read the overall section here. Let's get some timestamps in. So overall this week, across the entire project, we had 42 pull requests merged by 20 authors, which is really nice to see. A couple of names which I do not recognize, and these might be newer folks or less frequent contributors, or perhaps even just people that I do not recognize, but these were some folks I wanted to highlight. And those are, let's see, Anne Muov, Carl FJ, BW Shockley, RU Dine, Victor Wiz, GWN Dan, Andy Warburton. And again, those are names that I do not recognize, so perhaps newer or less frequent contributors. Thank you to all of them, as well as everybody else listed here who made contributions to Circuit Python, or the libraries, or Blinka this week. We had 10 reviewers this week. Looks like the usual suspects there. We had 37 closed issues by 12 people, with 23 issues opened by 14 people. So that covers the overall stats. Next up, I will pass it over to Scott if you are available to tell us about the core. Totally. All right, so numbers for the core. We had 22 pull requests merged from 14 different authors. So thank you to all of our authors. I won't double thank the new folks, but thank you. You know who you are. We had three reviewers, myself, Dan and Jeff. So thank you to all our reviewers. We're also always looking for reviewers, both for the core and more broadly. So if you want to jump into reviewing, go ahead and raise your hand and we'd love to level you up. Because the more reviewers we have, the more authors we can support. Pull requests wise for the core, we have 18 open pull requests. Six of those look like they're more than 100 days old, so we should take a look at those. And kind of linear from there. As always, please take a look at any pull requests you're involved in and close the ones that are stale or don't have anything actionable, that sort of stuff. I think a number of these are also board specific. So if you do have a collection of dev boards, take a look at the PRs and see if you have any of the boards that are there. That can be super helpful too. Issues wise for the core, we had 12 closed issues by five people and 13 opened by seven. So we're net up one. For a total of 555 open issues, I feel like there's a 555 timer joke in there somewhere. We're slowly gaining. Generally, it's okay though. The way that we keep track of kind of triaging our issues is through the milestone system. We currently have 54 open issues for the 8.0 milestone, which is a lot, especially since we have gone through that. So that'll be our next thing. But there, Mr. certainly says there's always time for a 555 joke. Good one. And then we have 477 open long term issues, which are the things that aren't super priority for us who are paid by Adafruit Torpon. That's it for the core. All right, thanks Scott. Next up, I will pass it over to Catney to tell us about the libraries. Tim, this section applies to all of the Adafruit circuit Python libraries, which is everything that begins with Adafruit underscore circuit Python underscore, plus a few extras like our cookie cutter. We had 18 pull requests merged from seven different authors and nine different reviewers. The oldest pull request we merged was eight days old. Everything else was keeping up with the latest PR is coming in and leaves us with 22 open pull requests. In terms of issues, we have 25 closed issues by eight people and 10 opened by nine people, which is remarkable, both because we are down quite a bit, but also because it was nine people that open 10 issues. I'm really happy to see that many people involved, leaving us with 658 open issues. 176 of those are good first issues. If you're interested in contributing to circuit Python on the Python side of things, check out circuitpython.org slash contributing. You'll find all of this information and more, including a list of the open pull requests and a list of all the open issues. If you're interested in contributing by reviewing, check out the open PRs, see if any of them interest you, see if you have the hardware for any of them, test them. If you don't, just take a look at the code, see if it looks right to you, and leave us a comment. Once you're comfortable with that, we'll consider upgrading you to the review team. If you want to contribute code or documentation, check out the open issues. If you're new to everything, good first issue is a great place to start. We have a guide on contributing to circuit Python using Git and GitHub, and we're also available on Discord to help you out. We want to make sure you can contribute in a way that works for you. In terms of library updates in the last seven days, we have two new libraries, Adafruit Circuit Python SI 1145 and Adafruit Circuit Python AGS02MA in a list of updated libraries which I will not read off. In library news, we hit 300 Adafruit Circuit Python libraries which the newsletter scooped me, I was hoping to scoop myself, but we have worked hard to reach this point. The overall number of libraries that's typically listed in the newsletter includes the community bundle. This is an Adafruit specific milestone. So make sure that if you ever buy hardware, check out and see if it's supported by Circuit Python, you'll find libraries, both drivers and helpers, for most of what we sell and what we support, and that's where we are with the libraries. Alrighty, thank you, Katnig. And next up is the section on Blinka, and it looks like Maker Melissa is out today, so I will read the Blinka section. Blinka is our Circuit Python compatibility layer for Raspberry Pi and other single board computers, as well as MicroPython devices. This week in Blinka stats, we had two pull requests merged by one author and one reviewer. So thank you to, I'll say author again, Anne Humov and then Melissa for the review. There are four remaining open pull requests. There are 79 open issues. There were, let's see, 8,563 Pi Wheels downloads in the last month, and currently Blinka is supporting 89 different devices. So that is fantastic. Next up, we will start up our first of the two round robin sections. This will be the hug reports section. So hug reports, just a reminder, this is a chance to highlight folks in the community and awesome things they've done. I will 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 have hug reports in the notes document, then I'll read them as we get to your turn in the list. And so with that, I will get started. So my hug reports this week, thank you to NeerDoc for making and sharing a deep dive octopus game graphic the other day during one of my streams. Definitely thought that was really cool. So thank you for that. To DeShipu, who I noticed is working on P&G support for Display.io. And I think that's definitely going to be a really, really nice thing to have. So thank you DeShipu. And lastly for me this week, thank you to Cgrover, who shared some great seven segment font files that will be helpful in a project that I'm working on. So thank you to Cgrover. Next up indeed is Cgrover as well. So Cgrover is text only. I will read theirs. They have a hug report for me. Thank you FOMI guy for diagnosing some potential font issues with bitmap label that was this morning in the help with channel. So next up I will pass it over to Dan for your hug reports. Thank you. I also like to plus one on DeShipu's working on P&G support. That's really great. It sort of makes it all real because P&G is so universal. And thanks to Scott for working on tuning up the web workflow before he goes on leave again. Okay. Thank you Dan. Next up is DJ Devin3 who is text only. So I will read theirs. They have hug report for Todd Bot and Deirdoc for helping to figure figure out my project was being limited by the spy bus speeds and that I needed to hack the featherwing TFT for parallel mode. And then another hug report. Thank you to Katny for adding an Oshpark Discord emoji into the available emojis on Discord. So thank you for that and thank you to DJ Devin3. Next up I will pass it over to DeShipu. So thanks to Jeff and Scott for the reviews. Last week. And a group hug. Thank you. Excellent. Thank you DeShipu. Next up is Hellweaver666 who is text only. So I will read a big hug to everyone who helped me get up and running with my dev environment so I could make my first contribution to Circuit Python. That's awesome. Congratulations on your first contribution and thank you for leaving your notes in the meeting here. And then let's see. Next up I will pass it over to Jeff. Hello. Give me just a second here. So yeah, first I wanted to give a hug to the QMK community for some discussions on their Discord this weekend. I went and hung out with them and said, you know, I wrote this guide and I'd love your feedback because we love making guides better. And yeah, just fun hanging out in that community. If you're interested in mechanical keyboards, custom keyboards, definitely check that out. It's not Circuit Python. That's KMK. But they're still a good group. Anyway, on to actual Circuit Python stuff. Thank you, Dan, for taking back the ESP32 bug with no PS RAM and making some interesting findings, particularly that the single core Unicor fixes it or conceals whatever the real problem is. And anyway, last up a group hug for y'all because I haven't left one of those in a while. Excellent. Thank you, Jeff. And let's see. Next up, I will pass it over to Katny. Tim. First of all, I have a hug for the community and Adafruit for hitting 300 Adafruit Circuit Python libraries. Second, I have a hug for Tectric for jumping into changes to the libraries, finding bugs and getting them fixed up. A hug for Lady Aida for writing the 300th Adafruit Circuit Python library and a group hug. Excellent. Thanks, Katny. Next up is Kmatch. Thanks, Tim. My hug goes to Jebler. Jeff, thanks for a PR to reserve PS RAM on the ESP32 builds. It will likely simplify some code for the RGB dot clock displays. Thanks, Jeff. And thanks for everybody else. Thank you, Kmatch. Next up is Mark Gambler, who's lurking. So I'll read. Special hug for my new niece, Rory, as well as Mark Gambler's brother and his wife as well, and a group hug for all of us. Next up is Tammy makes things. So I just have a group hug today for everybody for being awesome. Excellent. Thank you, Tammy. Next up is Scott. Hello. Hugs for me to retired wizard, Nerodoc, PR Cutler, and Todd Bot for testing the web workflow. Hugs to Andy Warburton, aka Hellweaver666 for the CSS improvements to the web workflow as well. And a hug report to FOMI Guy for the edit page, which I still have not tried, but is merged in and I need to try it. But thank you all. Yeah. Thank you, Scott. Next up, and rounding out the hug report section is Tectric, who's not present. So I'll read his hug report this week from Tectric for Carter for feedback on the SI 1145 library. It's probably not 11 but 1145, I suppose. Hug report for Lady Aida for tagging Tectric on new libraries. It's nice to see the cool stuff in the pipeline. Hug report for Katny for constantly helping with whatever tasks I'm working on. Hug report for FOMI Guy and me for doing a game jam with Circuit Python. It's something, looks like Tectric finished or stopped writing mid-thought. So it just says it's something. So we'll have to hear from Tectric maybe next week what the remainder of that thought was. And then lastly, Tectric did leave a group hug for everyone. So thanks to Tectric. And thank you to everyone who participated in the hug report section. So next up, we will move on to status updates. Status updates is our time to sync up on what we're doing. I will start, and then we'll go through the list alphabetically to give everyone a chance to participate. When I call on you, 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 to folks that are relevant to things that they're working on. If a discussion becomes too long for status updates, then we can move it to the, in the weeds section to occur afterwards. So I will get us going first. My status updates for this week, let's see, or I should say last week, I paired down the embedded web workflow editing page to the most basic version with no dependencies so it can work by itself without internet connection or any other libraries. This past week, we had the official kickoff, both the post and the video for the hack tablet giveaway. The first couple of winners will be selected this week. So if you're interested in winning one of those hack tablets, there is still a couple of days to get in for the first drawing. And then I also had this week, I was working on, or last week, I should say, working on the octopus game. Specifically, I put in some high score functionality using both the SD card and or I should say, you know, either SD card or the NVM storage. So if you enable one of those two, the game will keep track of the highest four scores over the time that you play it and show them back to you. Also did a couple more of the guide pages for that last week in him, hoping to wrap that one up this week, the guide for the octopus game. This week, a couple other things that I'd like to get going are starting the library for the hack tablet. And then just a heads up to people who watch the deep dives on Friday evenings. I'll be on vacation this upcoming weekend, including Friday. So I will not be doing a deep dive stream this week. So I will mention if anyone else is interested, I think, you know, back early on, I started filling in for deep dives when Scott was taking days off. So if anyone else is interested in streaming on Friday, I'm sure we could you know, put a link in the discord and all of that. I might actually be able to do it. I'll double check. Okay. Yeah, sounds good. Yep. Next up in the status updates, we've got a Sea Grover who's text only. Sea Grover commenced work on the Clue Coffee Scale, which is a NAU 7802 ADC learn guide. They wrapped up four project enclosures this week, sawing, routing, thread tapping and painting quite a lot of work, it sounds like. The fingers are hoping for less than three band-aid experience. And lastly, going back into the studio to track some new songs next week. So excellent. Thank you, Sea Grover. Next up, we will hear from Dan. Okay, a lighter thing. You found that the builds were failing because GitHub was deprecating macOS 10 builds. So I updated that to 11. And then what they do is they do these brown-eyed periods where when they're about to discontinue something, they turn it off temporarily so that your jobs will break temporarily. And then you'll do something about it. And they do that several times to like make you pay attention. Then most of the time I've spent has been debugging ESP32 builds with PSRAM disabled. So then we have an ESP32 build with PSRAM. If we disable PSRAM, we get boot loops. Jeff found that if you pretend that you have PSRAM but you have a dual auto detect, that works but it sort of reserves the pin. I was trying to do it a different way so it wouldn't reserve the pin. And I found that I found out exactly where the problem is, but it doesn't mean I know why it's happening. And only when both cores are unused, which is another clue. So we have various clues and I'll spend a tiny bit more time on this, but I'll probably throw it back to Espressif soon and see if they can give me some hints about that. That's pretty much it. I guess I was also, I did some work on ESP32, ESPI, like cleaning up some problems that people had and seeing whether it was our problem or their problem. So I'll add that bullet list in a minute. Okay, that's it. Nice. Thank you, Dan. Next up, we will send it over to Dishapu. Okay, let me... So I've made a lot of progress with my robots. I'm working on it for, like, walking robot. It's supposed to be super affordable and super easy to build. So I have it working properly now. I have made a shield for it that you put as a mask, basically, in front of it with a display where you can display a face for it, so it can have emotions and, you know, fun stuff. And I also made a version of the same robot that uses OpenMV board, which is MicroPython, not CircuitPython, but it has a lot of the vision algorithms implemented in it directly. It has a camera built-in, so you can do even more fun stuff with the robots this way. As people mentioned, I added PNG support to the state library. Unfortunately, I had to replace the GIF support because it wasn't fitting on some of the boards anymore with both. But I don't know about any code that was using GIFs, so hopefully that won't break anything. And going forward, I want to use PNG everywhere. I'm also adding the support to the FruitImage load for PNG. I have a pull request app with the initial support, which should support indexed images, but I still need to figure out how to undo the filters in PNG to support other kinds of images. Indexed images don't use filters, so that was easy. Other kinds of images do use them, so that will be some extra code. And I also finished with this sensor I mentioned last week, but I still have to read the tutorial on how to start a new library for CircuitPython. I haven't done it since a while and learned to use CookieCutter and so on. So that's all. Thank you. Yeah, thank you, DeShipu. Yep, and definitely check out the CookieCutter guide, luckily. That process makes it nice and easy to spin up a new one. Next up, we will hear from Jeff. Hello again. So, both last week and this week, I'm doing stuff with the ESP32 family of microcontrollers and cameras. So, we are going to change it up, and rather than be based on the code that I primarily wrote myself, we're going to base it on Expressive's official library for cameras called ESP32 camera. And as of this morning, my one camera module that I have been testing works on the ESP32 S2. I can take a picture in RGB565 or JPEG format. However, it needs to cooperate better with CircuitPython. One item that I'm aware of right now is it needs to cooperate with the rest of CircuitPython when it allocates a PWM instance. It uses PWM to provide a clock to the camera module. And it also needs to have kind of the Pythonic API that we would expect. There's a lot of getters and setters like contrast. And then we need to add things like a free choice of pins. Right now, it's just hard-coded to my one board that I'm testing on. And I do have to make some changes within ESP32 camera, and I hope that at least some of them Expressive would consider accepting upstream. One of them has to do with cooperating with other devices on an I2C bus, which even their own dev kit requires, but they don't have it in the library. And then last, this is kind of a cross out. I will be chatting later today with Dan and Katny to discuss our CircuitPython day stream. So yeah, that's on the books now that's planned, and it'll happen. So that's what I've got. Excellent. Thank you, Jeff. And next up, we will hear from Katny. Hello. So last week, I finished up my list of Whippersnapper guide updates, created a power management template for the feather guides, filled one out, and then handed the rest over to Eva. Subsequently verified all the templates before they were deployed, few miscellaneous things, and set up new libraries on Read the Docs. Last Saturday, my PyOhio talk went live on Saturday morning, and that's now available on YouTube. This week, I'll be doing the PCF 9574 product guide, verifying the current list of new power management templates that Eva finished since the last time I checked, set up some new libraries on Read the Docs, and it is a short week again for me. In basement news, patched the drywall modding where needed, sanded all of it, found one more patch. Needed, redid a section of the plumbing where the well line enters the basement with pecs and installed a new iron filter. Started priming when Coat found out how much junk was in the water previously when we had to clean the aerators out of all the faucets. The basement faucet had one built in that has clearly never been touched. It was nasty. Next up, sanded the final patch, primed the rest of it with two coats, cleaned as much as possible, and then it's ready for the rest of August, where we have other things going on that needed this room. And then we will be continuing with finishing things up, painting, putting up trim, all that in September. And that's where I'm at. Excellent. Thank you for the update, Catney. Next up, we will hear from Kmatch. This week, I spent time visiting family, so not much circuit Python activity. But this week, I hope to get back to my bowling training aid by using an infrared time of flight sensor and figure out how to separate the pulse from the background noise and make some sense out of that. I hope to get that done this week. Awesome. Thank you, Kmatch. Next up, let's hear from Tammy Makes things. Thanks. So last week, I worked on debugging my Matrix Portal display status board that I'm trying to build to display the status from our CI CD system at work. This week, I'm hoping to finish that up and get it tested and release the code. I hope to have some time to do some PR reviews, and I'm thinking about what I want to do for Circuit Python Day. That's what I got. Excellent. Thank you, Tammy. Next up, we will hear from Scott. Hello. Okay, I have a laundry list of stuff. I made improvements to the C3 serial. It no longer drops transmitted characters. It also enters REPL quickly, which is awesome. Turning on the Wi-Fi leaves USB active, which is a bug that we saw on the S3 as well. So I had to fix the IDF for that. I fixed web socket handling of frames that are over 125 bytes. Retired wizard found this bug, and it was easy to fix. I merged in Web workflow responsiveness, fix, and changes to the title bar to limit how often it was sent. Basically, to improve responsiveness, as I had had it, I was sending the title bar a bunch, so now it should send it less. I also merged in changing the Web workflow port and dynamic reload of settings. If you save the .env, it should be able to go in and change the port kind of as you do it. You don't have to hit reset. Working to enable the Web workflow on the ESP32, and I'm adding a couple more boards, including the Odroid Go, which is pretty fun. It's like a Game Boy-esque sort of thing, which is neat. This week, I'm fixing more bugs, including the fact that the title bar doesn't update enough, which is unfortunate. And then I'm working with Antonio on adding FileGlider Web support, which is on Android Distart, which is really neat and interesting. Being able to talk to CircuitPython devices and discover them from an Android app, which is really neat. And then also working with Melissa on the code.circupython.org stuff. So that's it for me. And let me know if you have any bugs and stuff, because I think I have three weeks left before I'm on leave. It's like great, great stuff as usual. Thank you, Scott. Lastly, for the status updates, I will read Tectric's status updates. So last week, Tectric did some final touch-ups and test run of the pyproject.toml generation and switchover scripts. Everything looks ready to go for next week. Next item, Tectric added the AGS02MA gas sensor to the Adafruit bundle, as well as touched up the SI1145 library and submitted a PR for additional functionality to that library. This week, Tectric's item says on vacation all over the northeast United States, so we'll resume next week. And that is the final status updates. So with that, we will move on to our fifth and final section in the weeds. In the weeds, just as a reminder, is an opportunity for more long form discussions. These can either come out of status updates or be identified ahead of time. If you do have in the weeds topics and you haven't put them in the document already down at the bottom, please go ahead and do that while we read through the first couple. So with that, our first item in the weeds is from DJ Devin3, who is text only. And it says, let's see, custom USO N8 to SOIC8 PCBs. USO NuvaChip arrived, which is a 15 millimeter adapter board for the Bluefruit Sense. To use this board, I need to add a PR for the Bluefruit Sense to allow 16 megabytes Cypress flash chip in port's board and NVM Tommel. This tiny NVM adapter PCB allows the ordinarily 2 megabyte Bluefruit Sense to have 16 megabytes of flash instead. This will be DJ Devin's first build contribution, and they're taking baby steps for that. So yeah, that sounds really cool. So I guess I'm not sure if there is a question. If so, maybe it's just like how to go about making that PR, it sounds like, to add it as what I would assume is a separate device. Kind of like the Tinsys are the device, or no, not Tinsy. Trinket? Is it Trinket? I think the one that has the Xpress version, this is kind of a bit of a similar idea to that, I think. Ah, status update, I see. I see that was a status update item. Yeah, no worries at all. But that does sound really cool, and super neat to be able to use that much space. That will certainly make it amongst the largest devices that I'm aware of, at least. So let's see. Next up, we have a weeds topic from Tectric, who is not present for now, but this says the design guide recommends using Adafruit bus device where possible. But what about Adafruit register? It may make it harder for smaller boards to use, but it handles the abstraction of bit shifting and whatnot for code safety. How should relatively simple sensor libraries approach using or not using the Adafruit register library? And there are a couple of links here to some PR or APR, which was the context for this discussion, as well as the actual docs, the design guide docs, which I assume are where it mentions what Tectric said, which was about using bus device. So it sounds like the idea is basically when to use register versus when to use bus device when you are riding a driver. I mean, I'm biased. I'm biased in that I really like register the way that it objects stuff. There is definitely a tipping point where it will save memory. So imagine you have like two drivers that both use it. You can actually share code then in memory, but it does have a bit more of a impact at the start. It's a little bit more code to import. Generally, I would use it if you could. I can look at this thread and apply there too. I agree entirely. So when you say use it if you could, what does that mean? Don't use it because there are boards out there that get memory errors when you try to import it. So how do you define use it if you can? Well, it doesn't support SPI yet. So that's one. I think that's the references more like what it doesn't do, not what it doesn't fit on. I guess what I'm saying, for example, yeah, another issue. Go ahead. I was just saying in terms of CAN is just like if the model of the registers in the device matched the model that the register library does. So is there literally an Adafruit Circuit Python device where writing import Adafruit register runs out of memory? It sounds like that's what you're saying, Carter. Yep, see the link. This has come up multiple times and that one is typical. It's always a library that's like this and it's on a non-express board, et cetera. And I could look at the TMP 117 data sheet. It's a very simple device. It looks to me like something that could easily be written without having to use the register library and then it would work on that QDPy. Yeah, I mean, I think there's other things to think about, right? Like how maintainable is it to have bus device code scattered everywhere or I don't know. I think it's easy to, yeah, the TMP177, Carter, is the library's overdone, in my opinion. Like you're saying it's a simple device but this driver is not simple. It's not, it's not register's fault. It's the fact that the driver itself is complicated. That's the question and that's kind of if we can find something we can put into the design guide, then we have an answer and we can always just kind of like a bus device is an easy thing. There's a no-brainer that should be used. Register is a little more of a sliding scale. It's like it exists. It has benefits. There's pluses and minuses and I don't think we have good guidance out there that kind of discusses the plus and minuses in a way where one had to decide when it should be employed or not employed. I think that's the wrong question. I think you should always use register but you should not use it for every register of the device. Like you still for an individual device you have to use your discretion on what you implement and what you don't implement and looking at the TMP example is just like and do I, did I write this up at one point? It's the idea of like are you reading the datasheet and wanting to expose everything or are you taking examples and wanting to implement those examples? The TMP example at least is not a problem of the register library. It's that this library was written to be very complete. There's a lot of code in here that's not a different register related that is in here that arguably doesn't need to be in here. Well I think it's register related at least to me. It's like for example... It's not the register library itself. There's 150 lines of other stuff or 100 lines of other stuff like convert to integer this these all these enum style things like that that's not a different register problem. It sounds like in some cases though that before the library does anything if you just import register on some devices that you're already out of RAM but I don't know it sounds to me like in that case there's just not enough RAM to really be able to interact with the thing. I'm not sure is there actually a case of that? I think that's what I understood from one of these threads it was mentioned the QDPI. There's a QDPI one. Well they're using the TMP 117. I think I think this is a huge problem but I don't think the answer is is hating on Adafruit register. I think really what we need is we need tooling that tells us how big our driver libraries are. Like how how much RAM do you use at the end of this because there's no feedback loop between driver writing and how much memory something takes. At least there's no automated way that we do that. So like we're going to continue having memory allocation errors until we have a way of telling when we've bloated a library too much or or when like people always come to us and say like add this functionality and like we can say yes thank you but that does impact how much memory it takes and and we had no way to measure that now. And we did over time we have like Lamar saying in this thread we have lost some heap space on the on the samd21's over time too. It's not much it's like three or four k but that can make the difference between running out of memory and not. So yeah I'm happy to I'm happy to give specific guidance for individual drivers but I would not blame Adafruit register. Okay so let's talk about the SI 1145 pull request discussion. So I wrote the first pass at that library and I would consider it to be a fairly simple sensor in terms of like its register layout it's not a ton of registers and they aren't really complex so I lean toward kind of my thinking with register libraries I will bring it in when things get kind of complex which is it's subjective it's like I can't really there's no definitive line of like oh when do things become complex but if it's if the registers are just like all being accessed and written to eight you know full eight bits like a bike goes out a bike comes back and you're just punching back and forth like that I see register didn't really help out too much might as well just go ahead and just use bus device and call it good knowing that bringing in registers gonna potentially bite you for the for the small boards like cutie pie. Well I'm arguing that it won't like it so I think one way to think about it is there are different ways of deduplicating code right like if you have four registers that you're reading and writing like either you can have a function where you pass in which of the four registers you're reading and writing or you can have four copies of a class that is for from the register thing right like they're they're both serving the same function they're both deduplicating the reading and writing code there's a little bit more overhead with a different register but it also changes the model of how you're programming it right where with register you can declare that these registers exist and then treat them as separate variables. It's my belief that that is a clearer way to to program and and define these devices than by using a function to do it that is certainly not the way that Arduino does it because Arduino can't do data descriptors which is what registers is using. So would you be willing to put that into the design guide because it sounds like you're saying register libraries should be used? Yeah I'm happy to write something up. Do you think that it would help any it is a question for both of you like for the real value of register is when you have bit fields all right that makes it much easier to deal with those. If there was a kind of a byte only version of register for the simple the simple devices and maybe there aren't any maybe all of them have bit fields I don't know but it's like so so that if you imported some fraction of register that you didn't have to import all of register at there because there's a lot of I looked at register once to see if I could make it smaller and I couldn't really see any way to do that like it's like I was saying like is there like is it is it is there something about the bitmilivision code that could be refactored or something I couldn't really find anything you know I didn't look for that long but if there's for simpler things if there's some simpler way of doing register and maybe I should have started at the top level to say like is there's some way of writing a descriptor that ends up with less code or something so that if there's some refactoring of register that could be done for these simple devices where all I'm reading is like two eight bit values or something like that and I still like to declare it maybe maybe register could be split into like byte and bit parts or something I don't know I thought we did it already isn't it already like that maybe it is okay because I don't write these drivers so I don't know I haven't in a while either but if you look at the TMP 117 lines I link you can see where it's setting up the all of the registers using register library I think the ones like temperature at high limit and low limit and temperature offset right are just like bytes yeah well h is probably I mean I also think you can save space just there's a lot of a lot of devices where they're really long names are used unnecessarily long and they're not underscored and that kind of thing they're not constant and yeah both the s is an example of that yeah like there's this si 1145 command like that's a string that's stored in ram like I think this is a tooling problem it's a tooling problem around explaining why what takes space up in a particular driver and how code changes impact that uh like there's a lot of this constant stuff it makes it more confusing but like yeah you're I don't think register is a problem I think there are other problems not register which is why I would argue for using register where you can okay I mean that's that's fine but I guess puts when you write the um the design guide stuff it might be nice to have also some garbage about how we're going to handle the low memory um the memory error issues for like QDPI things like the vissue for the TMP 117 and it's just it could be as simple as like you need a bigger board well I know that's it so be it I mean this is the problem like we don't need a bigger board we need a smaller library right so somebody needs to go into this and do the like GC mem free tracking for like okay I imported it here's how much memory I lost and go in and figure out how to make it smaller like the TMP library certainly is too big like larger than it needs to be and same with this si one but like it we don't have good tooling around explaining why that is um until we do I don't feel like I can give guidance because we don't have the tools to to guide that that work um it's really just kind of a manual thing in following that train of thought is it um is it does it give us meaningful information to import that library in CPython and gauge how much memory is used or is that information not really analogous like if we had an action or something that did that on each you know on each PR or something just outputted a graph or a number somewhere yeah that's the type of tooling I'm talking about um CPython I think is too different to use for that but that doesn't mean we couldn't do I don't know can we is the Unix build I think the Unix build is 64 bit um yeah and also like you couldn't import bus IO in it so if the if the code does that then it wouldn't work you know just get an import error uh well blink uh we isn't well maybe maybe we could figure out how to get around that um and you can do a 32 bit Unix build it is possible it's just not the default on modern 64 bit systems right I guess I'm just worried that measuring memory is going to be different if we're pointers are all twice that is big like we probably want to use the same object representation so I've thought about this also is like we could actually use like do a QMU build uh where it's using QMU to emulate an arm cortex M um and then importing a library and measuring like we could we could capture the whole heap and we could actually like do some cool visualizations around that too um to explain how big things are um that's the type of tooling I wish for I'd love I'd love to be able to say like this this library on import is 8k or 10k or 14k or it was 12k and now it's 14k would it be expected that that number would be wildly different from device to device like different ports essentially or if we made that measurement on an rp2040 is it pretty reasonable to assume it's basically going to be the same number on a esp32 s2 or does that need to be I think it's it's it's going to be the same basically right like for scripts and stuff where you have fragmentation like that's going to be impacted by how big the heap is so how many times like you've run a garbage collect and they yeah like like import imports will cause fragmentation too um but then the size of objects that you're left with is still going to be similar and mpy file size could be a reasonable proxy to start with as well like it does similar uh similar conversion stuff before writing out the mpy file it's just not quite true to what is in memory but it's an it's an approximation in terms of like I think like strings that get dropped because of the current stuff gets dropped before mpy is written out um but yeah this is this is something I'd love to do and this is kind of I know it's frustrating that that the samd21 boards are not large enough and it's just it's really hard anybody who writes drivers should just use it as sandy 21 we could say that it's not an easy problem but strings strings are everywhere like like Dan was I think Dan pointed out like in this si example like all of these variables that are prefixed with si1145 like that string is like it's being stored for every variable like all the variable names are stored um and it could take a lot of space it's a rabbit hole okay so it sounds like we have guidance then is kind of to try to use register if possible and a new blurb in the design guide maybe will yeah I'll take a look at it it's been a long time since I added anything to the design guide so I could just do a read over that I think that'll be the only thing that helps up in the design guide because then we could just simply like like you could right now if someone was using bus i o directly in a driver it's very easy to say please use bus device link to design guide whereas right now with register all we have are kind of discussions and opinions right I mean this is a discussion please update the design guide I think that'll that's great thank you that'll help a lot yeah I mean this is a discussion that Tony and I had like early early early on Carter is like when I first did register we had this debate it's like if you have if you have three drivers that you're importing and they all do their own reading and writing of bytes like that's duplicate code whereas if you had shared register stuff then you could actually share it but you have to get more than one driver in memory first for that to pay off yeah I think ultimately we we need to have better tooling around library size especially as we develop drivers in like CPython like CPython code is totally oblivious to how much code how much memory it takes it sounds like we have at least idea of a path forward on updating the design guide and then yes some of these cases the driver can be made smaller either with variable names or different different things so there's some chance that could help it be able to fit on some of those smaller devices okay um if if nobody has anything else on that one I'll read off our last uh in the weeds topic okay or uh I'll pass it over to Katnien I suppose actually Katnien if you want to read off yours yeah no problem so uh just to follow up for circuit python day um if you are interested in uh contributing participating have any suggestions or ideas uh please email circuit python day at adafruit.com it's the best way for me to keep track of things um a lot of the events are coming together I don't have a schedule sorted out yet that's a plan for this week um but we're still uh open to ideas and and so on um so I just wanted to uh plug that one more time awesome thanks Katnien and that is our last in the weeds topic we find the wrap up here well it's all for just a moment there we are okay um so uh this has been the circuit python weekly meeting again this is for august the first 2022 thank you everyone who participated if you do want to support adafruit and circuit python and those of us that work on the project please consider purchasing hardware from the adafruit shop at adafruit.com the video of this meeting will be released on youtube at youtube.com slash adafruit and the podcast will be made available on major podcast services um the this meeting will also be featured in the python for microcontrollers newsletter visit adafruitdaily.com to subscribe to that the next meeting I did not look at the calendar I believe is us scheduled regularly for the 8th of august at 2 p.m eastern yeah thank you for the confirmation on that appreciate it so 2 p.m eastern 11 a.m pacific next monday the 8th of august is the next meeting the meeting is of course held on the adafruit discord which you can join by going to adafruit.it slash discord if you would like to get notified about the meeting and any changes to the day or time please ask to be added to the circuit python east is role on discord and that is all for today so thank you again to everyone for participating and we will see you all next week thanks everyone