 Hello, everyone. This is the Circuit Python weekly meeting for Monday, July 25th, 2022. This is the time of week when we get together to talk about all things Circuit Python. I'm Dan and I'm sponsored by Adafruit to work on Circuit Python. What is Circuit Python? Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support them and Circuit Python, consider purchasing hardware from Adafruit.com. We host this meeting on the Adafruit Discord server. You can join anytime by going to adafru.it-discord. You hold the meeting in the hashtag Circuit Python Dev Text Channel and the Circuit Python Voice Channel. Typically, this meeting happens at Mondays at 2 p.m. U.S. Eastern Time, 11 a.m. Pacific Time, except when it coincides with the U.S. holiday, then we usually move it to Tuesday. In the notes doc, there's a link to a calendar you can view online and add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you would like to receive these notifications, ask us to add you to the AdSign Circuit Pythonistas Discord role. There is a notes doc to accompany the meeting and recording. The notes doc contains timestamps to go along with the video, so you can use the doc to view only the parts of the video that interest you most. The meeting tends to run 45 to 60 minutes, so this gives you the option to skip around. After each meeting, we'll post a link for the next meeting notes to the document to the Circuit Python Dev Channel. Check the PIN messages to find the latest notes docs. You can add your notes for the following meetings. If you go up to the top of the Circuit Python Dev Channel, you can see a push pin. If you click on that, you can find a link to the notes document. The meeting is held in five parts. The first is community news. The second is the State of Circuit Python Libraries and the third is hug reports. The fourth is status updates and the fifth part is in the weeds if we have any in the weeds discussions, which is kind of for extended things that don't fit elsewhere. So with that, we'll start with community news and I'll take a timestamp and my timestamp thing is working and is on time. Great. Okay. This community news comes from the Circuit Python newsletter. It's called from the most prominent items in it each week, thanks to Ann who works on the Circuit Python newsletter each week. So to start, the first item is a new version of Circuit Python 7 was released. Circuit Python 7.3.2 is the latest bug fix revision of Circuit Python and is a new stable release. Notable changes to 7.3.2 since 7.3.1 include Adafruit Matrix Portal. For that board, we restored the Traceback module, which allows async IO use. That was just an error. Sorry about that. Another bug that was fixed was to always release displays during deep sleep that lets them go blank and the last thing was to update frozen libraries. In particular, we needed to update some of the network-related libraries such as ESP32-SBI and Adafruit Request's uncertain airlift boards, which freeze them to save RAM space. The older versions of libraries were causing problems there. Okay. Next item is about Discord. Discord, we now have 35,000 members of the Adafruit Discord. That's like an incomprehensible number of people, as far as I can say. But that's fantastic. To read the news item, the Adafruit Discord community where we do all our Circuit Python development in the open reached over 35,000 humans. Thank you. Adafruit believes Discord offers a unique way for Python and hardware folks to connect. You can join today at hdtbs slash slash adafruit.it slash Discord. That points to an invite for that every Discord. Next item is to note that this year, Circuit Python Day 2022 is August 19th. We just designate this as the snakiest day of the year. This day highlights all things Circuit Python and Python and hardware. Usually we have this day in August or September, depending on timing of various other things. If you're working with Circuit Python and you'd like to note something about it for Circuit Python Day, tag your projects with hashtag Circuit Python Day 2022 on social media and Adafruit will look to highlight them. Do you have events that you'd like folks to attend or projects in the works on that day? Email your thoughts to CircuitPythonDay at adafruit.com. We have a couple of events I'm going to mention. First of all, there will be a panel discussion with Catney, Jeff, Dan and Tim, which will be hosted by Paul Cutler. More details on that are coming soon. Then we'll have a more freeform video chat with Jeff, Dan and Catney. This will be the third year in a row that Jeff, Dan and Catney will sit down and chat about their involvement and latest favorite contribution to Circuit Python. There will be a special Circuit Python themed edition of Show and Tell hosted by Liz Clark. Details are still being solidified, but start prepping your Circuit Python related projects you're interested in participating. This Show and Tell is not the regular Wednesday Show and Tell. This is a special Show and Tell for Circuit Python Day. Next item is that FOMI Guy, Circuit Python Day game jam stream. On Circuit Python Day, FOMI Guy says, I'll be combining two of my favorite things, Circuit Python and games. I will stream the making of a Circuit Python game jam game. My goal will be to make a basic but playable and fun game within the time constraints of a few hours and I'll be streaming the process. After the stream, I will publish the code to the game so folks can play it on their own Circuit Python devices. Okay, and then another item that's scheduled is that at 11 a.m., the time for this event is already set, at 11 a.m., Eastern time, 5 p.m., I guess the Central European time, reimagining IoT deployments with Circuit Python. Ediford Circuit Python has helped to open up the IoT space and place it within the reach of developers of all types. Join us on Circuit Python Day as we look at getting started with Circuit Python and wireless IoT, walking through a real-world Circuit Python based IoT project and remotely updating Circuit Python firmware with cellular IoT. This is unusual because we don't have specific cellular support, so this is very interesting. You can register for this event at the link that's in the note stock and I'm not sure who's sponsoring this, but it's great. Thank you. Okay, so I mentioned that the news that I just discussed comes from the Circuit Python newsletter, which is emailed every Tuesday. There's a link to the complete archives in the notes document. The newsletter highlights the latest Python and hard-related news from around the web, including Circuit Python, Python and MicroPython developments. You can contribute things to the newsletter by doing a poll request to GitHub repo, that link is in the newsletter. You can also tag a tweet on Twitter with hash mark Circuit Python or you can email cpnews at Adafruit.com. Any of those are gratefully accepted for news for the newsletter. Thank you very much. Okay, next up is the state of Circuit Python, the Circuit Python libraries and Blinka. This is a look at Circuit Python by the numbers. It gives us a chance to look at the health of the project separate from what we're up to. We'll talk about the project overall and then discuss the core libraries of Blinka. So first, the overall statistics. Over the past week, we had 44 polling requests merged with 16 authors. A couple of new authors I don't recognize are Wind, Stormer, GER and DJ Hedges, maybe also Carl FL and maybe Tim Waj. I'm not sure if those people are completely new or not. There were six reviewers of these 44 poll requests and there were 16 issues closed by 8 people and 15 opened by 12 people. So as is typical, we have about the same number of issues open each week. Okay, next up is about the Circuit Python core and Scott, if you're available, feel free to read that. Yes, let me scroll up. Okay, so the numbers for the core. We had 7 poll requests merged from 8 different authors. So thank you to all of our authors. We had 2 reviewers, Jeff and Dan, so thanks to them as well. We have 23 open poll requests, so we have a lot to take a look at. The oldest is 312 days old, so we should take a look at that. And the number of the old ones are board-specific, so take a look at those if you have boards and give those a test if you can help us out. Issues-wise for the core, we had 6 closed issues by 3 people, 8 opened by 8 people, so we're up 2. We're a total of 551 open issues. We have 5 active milestones. This is kind of how we triage the issues that we have. We have 6 issues that are not assigned to milestones, so those are the ones that we need to triage. We have 0 open for 73x, which is awesome, and we have 50 open for 8.0. So we've got lots of work to do for 8.0, and I believe that that number previously was not quite accurate, but now we've done a pass over that, so I think that is kind of where we're at in terms of 8.0. That doesn't mean we can't do beta and alpha releases before then, so that will be what we're working on. And that's it for the core. Okay, thank you, Scott. Okay, now, Catney will go over the state of libraries. Thanks, Dan. So this applies to all of the Adafruit Circuit Python libraries, which is everything that begins with Adafruit underscore, CircuitPython underscore, as well as a few extras. This week, we had 35 pull requests merged from 7 different authors and 6 different reviewers. I see one of the pull requests was 38 days, so it's good to see that we're still getting older PRs done. And that leaves us with 23 open pull requests, which with all these 35, it means we're keeping up with the recent ones quite well as well because that number hasn't changed in a bit. We had 10 issues closed by 6 people and 7 opened by 5 people, leaving us with 668 open issues. 175 of those are good first issues. If you're interested in contributing on the Python side of CircuitPython, check out circuitpython.org slash contributing. You'll find all of this information and more, including open pull requests and open issues. If you are interested in contributing by reviewing, check out the open pull requests. If you're interested in contributing code or documentation, check out the open issues. If you're new to everything, good first issue is a great place to start. And if you are entirely new to Git or GitHub, we have a guide on contributing to CircuitPython using Git and GitHub, and that covers all of that. And we're always available on Discord to help out. In terms of library updates in the last 7 days, there were no new libraries, but a pretty significant list of updated libraries, which are in the notes if you are interested. And I will not read them off here. And that's where we are at the libraries. All right. Thank you, Katnie. Okay. Next up is Blinka. Maker Melissa couldn't be here today, so I'll go ahead and read that section. Blinka, let me find the description of Blinka. Blinka is our compatibility layer for CircuitPython on single board computers like Raspberry Pi. You can also use Blinka on top of MicroPython to use CircuitPython libraries. So it runs either... Mostly, we use Blinka to run CPython and then can run CircuitPython code underneath that. So in the last week, there were two pull requests merged, one author and one reviewer. There are still four open pull requests. Some of them have been open for more than a year. So we should probably take a look at those. There are 79 open issues on Blinka, and there were 7427 PiWheels downloads in the last month. There are now 89 boards supported by Blinka, which is fantastic. Okay. Now we'll move on. Whoops. We'll move on to Hug Reports. Hold on just a second. Put a timestamp in the how to run the meeting document. So anyway, Hug Reports is a chance to highlight folks in the CircuitPython community and beyond for doing awesome things. As mentioned, this section is held as a round robin. 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, I'll just read them off as I get to them in the list. So as I mentioned, I will start. I'd like to thank Brent for some discussions on ESP32 SPI and related topics. He knows a lot about that from doing all the Whippersnapper work and from working on the NIDA firmware. Thanks to Katny for managing the addition of Discord's moderation bot over the past several weeks and handling some new issues that came up with DinoBot, the previous moderation bot that we were using and are still using to some extent. Thanks to Jeff for continuing to brainstorm and for discussions on the plain ESP32 port. And thanks to Paul Kotler, who I had and other people who had a brief preparation meeting with about the Circuit Python Day panel that he's going to run. Okay, next up is Ask Patrick W. I don't see them in the chat, so I'll go ahead and read theirs. Thanks to Collins Lab for this excellent YouTube short on pull-up resistors. It was helpful to me for getting the beetle into firmware download mode with no buttons on the board and a group hug. Okay? Next is David Glaude, who also isn't present or is text only. He's here but is text only. Thanks to K-Match and FOMIGuy for the work on the hack tablet. Thanks to Nerodoc for Discord Tool and for joining Calme, the Discord de la Tentation from the French-speaking streamer, Titi Mobi. I think this is under... This is Discord about some interesting technology that people would like to buy. Thanks to Paul Kotler and all the participants to the Cirque Python Show podcast. I think that I recognized his voice while listening to the recording of last week's meeting. Next up is Deshipu. Okay. I'd like to thank K-Match for the work on the hack tablet. Dreyfeebler, again, I started using the display 1816-bit displays and the camera on the ESP2, so thank you for implementing that. It's really fun. Well, the 16-bit is not implemented yet, still it's interesting. FOMIGuy for pushing for more games and MacGyver for T-I-O. Okay. Thank you, Deshipu. Okay. Next up is FOMIGuy. All right. Thanks, Dan. Hargis reports this week first. Thank you to Katni for getting started and getting in preparations for Cirque Python Day. Similarly, thank you to Paul Kotler for getting preparations in motion for the panel discussion on Cirque Python Day. Thank you to K-Match for all of his ongoing work on the hack tablet and providing those devices. And then lastly, thank you to MacGyver, the creator of T-I-O for that useful tool and also for stopping by the Discord to introduce themselves today. Okay. Thank you, FOMIGuy. Next up is Jeff. Hello. So I want to thank you, Katni, for apparently dropping everything to work on a fritzing diagram for me. Dan, thanks for your helpful discussion with me. You got me over a roadblock on the ESP32 stuff. There are more roadblocks, but we'll get to them. And like several others of us, I need to thank Paul Kotler for a quick getting-to-know-you chat. I'm looking forward to being on the panel discussion. And last, to Eva for uploading all the Circuit Python libraries to PyPI. And I'll talk about that just a little bit more when we get down to status updates in a bit to clear that up for folks who may be wondering. Okay. Thanks, Jeff. Okay. Next up is Katni. Thanks, Dan. So I have a hard report for my dad for giving up half his week last week to take the lead on redoing a storeroom and adding another room to our basement to my housemate Brian for helping out with the project and to my partner Rose for doing all of the drywall mudding. I'll go a couple of others with a hug report for Matt Guiver for authoring and maintaining TO. To Paul Kotler for hosting and more importantly preparing the panel discussion for Circuit Python Day. To Makra Melissa for confirming a project build live stream for Circuit Python Day and to Tectric for a huge list of things. Probably stuff I wouldn't have remembered anyway, so I just put a huge list of things. And a group hug. All right. Thank you, Katni. All right. Next up, Keymatch. Thanks, Dan. First, hug goes to folks on the Discord chat for some suggestions on separating single signals from noise and how to do some initial signal analysis. Thank you all for that. Second, Fome Guy, thanks for a collaboration on the HackTablet, especially including your live streams and organizing the giveaway for Circuit Python Day. And a particular thanks. I was so overjoyed to see you playing around with the tablet and having fun in the process. So thanks for that. And finally, thanks to Paul Cutler for inviting me to participate in this week's Circuit Python Show podcast. And thanks, Phil. All right. Thank you. All right. Next up is Makra Melissa, who I mentioned is out. So I'll read her contributions. Thanks to everybody involved with Circuit. I hadn't tried it in a while, and I just tried it and it worked very well. And then a group hug. Okay. Next is Neridoc, who's text only. So I'll read a group hug to everyone helping in the help with Circuit Python channels and others. Thanks to Katny and the Mods fighting the uprising of the Discord bot. Thanks to Matt Geiver for the great TIO program. I use it every day and tell everyone to use it. And thanks to Tetrick R. Hooper, Dan H. Jepler for PR and issues feedback. All right. Terrific. Okay. Next up is Paul Cutler, if you're available. I am. Thanks, Dan. As has been mentioned, thanks to Katny, Tim, Jeff and Dan for making some time last week. It was great having a quick chat and getting to know all of you, and I look forward to the panel. All right. Thanks, Paul. All right. Next up is Scott. Hello. First, a hug to Neridoc for the course tweaks for the Web workflow. We'll look at that today. And then also a hug report to ask Patrick W, who's been adding a bunch of ESP boards and those need creation ideas. So they've been super helpful getting creation ideas really fleshed out. Basically, they're USB IDs for boards that don't have USB. So thanks to Patrick for that. Okay. Thank you, Scott. Okay. Next up is Tetrick, who says not present, but has a group hug. I see him in the chat, but perhaps he's occupied. Okay. And then finally, G3 Holiday, who's also lurking, gives a group hug. So thank you very much. Okay. Next is status updates. This is our time to sync up on what we're doing. This section is also held where I start, then we 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. And you can discuss CircuitPython stuff or if there's something else that's of interest, feel free to talk about that too. If you end up having a discussion about something or you'd like to bring up something to discuss in more detail, we can discuss it in the discussion. So I will start. I released CircuitPython 7.3.2 to fix a missing module on Matrix Portal and to update frozen libraries with important network-related fixes, as I mentioned. And I had an extended discussion with Jeff on ESP32 troubleshooting, which we both learned a lot from. And right now, I'm testing why ESP32 SPI is failing with various test cases offered by users. Like right now, I'm trying to figure out it looks like when you make an MQTT connection that it can time out after about a minute or so, unknown to the people who are trying to use it. And it's breaking one of our projects, the pipeline of projects, specifically. And finally, to understand all this, I'm making more of an effort to actually understand how to use sockets because I've used them in a casual way before, but I have to keep reading the socket how to every few years to remind myself of things like when you receive an empty thing, it means the socket is closed and stuff like that. Next is Aspect with W, who's not here, so I'll read their contribution. Two weeks ago, I made a board definition for the DF robot beetle ESP32-C3. This board is a bit odd as it has no mode or reset button. In the cpoorg.board page, I include a drawing and steps on how to get it into firmware flashing mode. So that is interesting. Okay, this beetle also comes with an add-on prototyping and display cable board, which sits on HatStyle which connects to all the pins on the board. I need to look at how other boards have handled this. It is unclear if it should be in the board definition or if it should be handled in the library. And I'm tracking it in circuit python issue 6616 or maybe that's a PR. This week, I'm planning to do a board definition for the M5 stamp C3. No specific reason for these boards, just wanted to know how to practice making board divisions and C3 boards are very affordable. And I would remind you, we have C3 support, but it's very early. There are things that are broken. So don't buy C3 board as your only board right now is what I would just say. Next is David Glaude who's text-only, circuit python. I'm testing and promoting disco tool from Neridoc. I have no progress on my web workflow test and usage. Non-circuit python, I have work in progress changing the brain of my NABAS tag with tag tag tag and adaptation board that uses a Pi 0W. I don't know what any of these things are, but it makes you want to Google them. So thank you. Okay. Next up is Deshipu. So I have been playing with this Gassure sensor that EAJ7620 and I think I got it working with circuit python which is nice. I hope to get a library done for it. It's nice because it detects motion in front of it like up, down, left, right, forward, backward, clockwise, counterclockwise and also waving. And it can also it also has a cursor mode so you can by moving your hand in front of it you can move a virtual cursor that can then be displayed on something. So I think it's a very interesting device. And the reason I'm working on that is because I went back to my fluffback robots for like walking robots and obviously this sensor would be nice for controlling your robot with gestures. Yeah, that's it. All right. Thank you. That sounds like a very interesting gesture sensor. It sounds like it does more than the one that we sell as a breakout. Next is Dexter Starboard who's not present so I'll read theirs. Looking forward to circuit python day 2022 I posted a related video on show and tell and it's in the show and tell channel and you can look for Dexter Starward's post there text testing web workflow on fun house and unexpected maker pro s3. All right. Next up is foamy guy. All right. Thanks, Dan. This last week I continued working on the octopus game guide. I kind of dove more into the hack tablet branch inside the core. It was a different branch of the core code. I made some tweaks inside there to frame buffer display in order to force it to refresh even when there aren't any dirty regions. Because it turns out the display we have kind of like fades away if you stop sending it data. You have to keep sending it the current picture if you want it to keep showing. So I figured that out inside that branch. A couple other tweaks inside there was around the refresh rate to make it a little bit slower which got rid of some visual artifacts that we were seeing on the screen and I have a little bit more about that in the weeds. I made a multi-touch example for that tablet this week and just from there started planning out trying to build like a portal-based style helper for that tablet. So for easy IoT projects to fetch things similar to PyPortal. I'll be publishing the announcement and the instructions later on today for the hack tablet giveaway and then my last thing was just planning stuff around CircuitPython day so the panel and then my Game Jam stream will be going on that day so I've been doing some planning around those. Thanks. OK, thanks for me guy. OK, next up is Jeff. Hi, so I wanted to lead off by talking about why we updated or why we uploaded all of our libraries to PyPI and why we will do it going forward. So before now we did it only for libraries that we thought were useful with Blinka so that you could use them on a standard computer. But the way that Thani likes to install libraries on a CircuitPython device is by getting them from PyPI and I talked to Thani developer Ivar on GitHub for a little bit and we decided that the best approach was to not add something like CircuitPython to Thani but to let it use PyPI and therefore that we would publish all of the CircuitPython libraries to PyPI even if they don't run on standard desktop Python. We could have made different decisions but this is the decision we made and that reminds me I need to go file an issue saying to change around the prompts within cookie cutter so this option isn't offered anymore to not publish. Anyway, so getting on to my actual work. Last week I got the ESP32 Feather version 1 to a state where it can find CircuitPython but there are caveats. There is a draft pull request open so you can take a look at that. The main awareness that I know about is that when I disable PSRAM entirely it can't finish booting or boots to safe mode saying you can't find CircuitPython. So PSRAM is in a state where it's turned on but the early initialization of the ESP IDF is allowed to continue if PSRAM is not detected. The downside to this is there's some growth in code size but also there is I think at least two GPIOs that are now not usable because they would have been used for PSRAM. In on CircuitPython stuff I learned about how QMK supports OLED displays. I've certainly seen some YouTube videos where people put OLED displays on their keyboards and now I know a little bit about how that works so that's cool. And then today just this morning I got the KB2040 and the ESP128 by 32 OLED display working together in QMK and that'll be a part of the upcoming guide. And this week I hope to wrap up that guide. I will write one of these new learn system profile pages that have been recently added by the development team of learn. Thank you very much for that. And the main thing then that I will spend my time on after that is getting image capture module support on the ESP32S3. There are some the details of the peripherals are different between the S2 and the S3 so it's not just a matter of enabling it and checking that it works. And the first thing is to dig in and figure out how much work is it to support. Coming up I'm going to have lower activities on some days. A friend is staying with us for the week from Tuesday through Sunday or Monday and I will be doing circuit-by-thon day planning as needed but I think Katnie is really creating a straight road for me on that and I don't have much to explicitly do. And I'm also planning to be out August 11 to 18 again with the same friend who's visiting. So that's what I've got going on if I'm around a little less than usual. That's why I've got a friend visiting. Okay, thank you Jeff. Okay, next up is Katnie. Dan, so last week I finished adding whippersnapper setup and usage pages to three guides. Started on the whippersnapper usage page for a fourth guide. Continued circuit-by-thon day planning and had a short week. Over the long weekend, tore down two walls in quotes because it was really badly built with super janky wooden paneling and shelving and learned a hundred times over how not to build things as we tried to tear this apart and it was awful. But then we framed in four walls into two rooms, dry-walled the entire thing, got through two coats of drywall mud, and we're pretty sure we have everything we need to finish it. So this week finishing up the whippersnapper usage page for PyPortal this is actually wrong because my assignment set changed before this meeting I'm going to be making a template for feather boards for power management they all have one but apparently it was all created before we had templates and so it's something like 25 pages all of which are almost identical and we want to replace it with a single template. So I'll be working on that once I'm done with the PyPortal page and this is a short week again tomorrow I will be installing two doors evenings during this week finished mudding the drywall and then the upcoming long weekend is cleaning up and priming or attempting to clean up because drywall dust stays forever and then maybe painting the outside walls and maybe installing our iron filter but basically it's a jam-packed week. For me that long weekend is not really a weekend off and that's what I've got all right thank you Katnie. Okay next up Kmatch Thanks Dan. So past week some minor debugging on the ESP32 S3 dot clock display module that goes along with the hack tablet and there are other RGB devices you might want to connect to that also related to the giveaway I built up five more of those hack tablets and as Naomi got mentioned contact him for more details and it sounds like more information is coming also another project I'm working on is trying to measure a passing sphere basically a bowling ball and I tested a time of flight sensor and it looks promising measured down about five or six points during the pulse and I hope I can be able to fit that and so that's my work this week see if I can understand enough about basic signal processing to comprehend that measurement pulse and make some sense out of it and then on non-circuit python taking a few days off to visit family Thanks. Thank you Kmatch. Okay maker Melissa is now in the chat so go ahead Hello So last week I worked on edge impulse to figure out how to train a machine learning model and then I created an example in Arduino to get the machine learning model running on the KB2040 and I started taking a look at code.circuitpython.org to see what needed to be updated to start adding web workflow into it this week I'm going to start working on refactoring code.circuitpython.org so we can have the web workflow added and then once it's refactored I'll add that in and I'll possibly be working on writing up a guide on the edge impulse stuff I worked on and also I'll be probably working on some preparations for a circuit python to a live stream and that's it Okay, thank you Okay, next up is naradox contribution which I'll read Last week continuing to work on webcircuit for the web workflow and PR it fixes to access control This week more web workflow Okay Next is Paul Cutler go ahead Thanks Dan There's a new episode of the podcast out today with Kmatch talking about the hack tablet so some great timing on that with all the work that Tim's doing and then if you haven't heard there'll be a panel on circuit python day that I'll be hosting and lots of work is going on around that this week and I met with all the panelists last week, thanks Okay, thank you Okay, next is Scott Thanks Dan I'm booting up back up because I took last week off which was awesome I know that I have to finish the port environment variable PR and I've got a bunch of tabs open to go through as well I'm excited to work with Melissa on code.circuitpipethan.org this week we're going to chat later about that too and then I also do want to refine the title bar status because right now we only use it for web but I'd like to use the title bar status bar for other status as well like the state of code.py and we could do usb status and stuff there too so that's what I'll get to if I work through all the web workflow stuff Okay, thank you, Scott Okay, and finally Tectric who's not in the chat so I'll read Varis Last week updated the I2C address learn guide with instructions on how to add new addresses we now have a mechanism for doing that so people can do that without by submitting a PR add an ability for the cookie cutter template to verify the user's cookie cutter is at a minimum version which for reference is now version 2.1 added underscore underscore version underscore underscore fix for libraries that have pyproject.toml so it's submitted a PR with type annotations for Adafruit BLE, Adabruit BLE, let's fix that This week update the remaining learn guide examples using the gamepad shift module, final touch-ups on my generation scripts for the pyproject.toml switch over and follow up on changes to Adabut and fix anything that breaks during the daily schedule build of circuitpython.org and I'll just reference here that pyproject.toml is kind of a more moderate way of doing stuff than setup.py it's a more declarative way of describing how to install and build a python library following week the last thing vacation taking a road trip with my girlfriend down to DC so taking the week to relax ok thanks tetric our last section is in the weeds which is where we have long-form discussions about things that we probably like to have a back and forth on and we're not maybe sure who to discuss it with so it's open to everyone if you have any in the weeds topics that you'd like to bring up please make sure they get added to the note stock we're all discussing other things ok so with that I'll turn it over to foamy guy for their in the weeds question yeah thanks Dan I have a question around frame buffer display I was doing some digging around inside of there to work on the hack tablet and I was noticing a couple of things that might be helpful to add arguments for but before I too far down the road of doing it I wanted to get feedback to see if it made sense to add arguments for these things or if there's some other way that I might not be knowing about or considering so the main two things are the refresh rate there's a default as far as I could tell there was just a default inside the core of 60 for the kind of target refresh rate that it will use when it has auto refresh on and we found that a slower rate was better for this particular screen so I wondered if we make sense to add an argument for that so that it can be initialized and then set to the lower rate and then the other one was the basically the ability to skip the dirty region check so display I O internally has checks to make sure that things have actually changed and if they haven't then generally it won't draw a new update to the screen but on this particular screen we actually need it to still send the data to the screen otherwise it kind of like fades out kind of like back to the future picture style if you imagine the image fading away so I figured out where or K match actually figured out where in the core we can change that to basically skip the check but I wondered if it made sense to add that as an argument so people could turn it on and off and if it's you know we'll default to off and so the today's behavior will be the same it won't refresh when it doesn't need to you could turn it on and then it will copy the memory every time that it every time that refreshes the display okay thanks does anybody have comments so I guess there's two things there's there's the refresh rate and there's the dirty bit as optional arguments they sound both sound reasonable to me Scott you have something to say I think Jeff does I was just going to start with saying for a dot clock display I think just by you know you've got a certain number of clocks that are going to occur per frame so the time of one frame is a computable value I was looking in this data sheet that came out linked to and if you multiply it all out it ends up being 60 Hertz is the nominal frequency of a frame so it would be an item that you could compute but maybe you're computing it in Python rather than in C and in that case you would need to send it in the other thing I would say is I think there's an important distinction between when you have a dirty region that means you need to recompute some of the pixels and you need to send the bits out to the display to keep the display refreshing and maybe those need to be disentangled and I'm relatively confident you don't want to recompute all the pixels on the screen but you do need to do this other step so however it is you need to do that but I think that would be a characteristic of any of these dot clock displays that you need to continuously or near continuously renew the pixels to them but that's different than making a choice about whether to recompute the pixels of the display I think that's what I mean to say I think I probably have those two conflated in my mind the dirty regions versus needing to send it out to the display right and I think that the difference is well I'm looking at RGB matrix but it's not actually RGB matrix but like the frame buffer display class but then there's also the frame buffer itself and for the refresh rate the default of 60 should be fine from the frame buffer display side but I think you want the refresh rate to come from the frame buffer itself so that the default doesn't get used if that makes sense okay I can yeah I think we are initializing both so I can look closer the fb getter thing is doing a function call into is it dot clock display what is the module dot clock display is the module where the new code is oh okay and that's in the PR or in a branch I don't think we have even a PR for it yet okay but yeah so I feel like maybe in both cases we need the dot clock display to tell to manage the like if you need to pass keyword arguments in pass it there and then the frame buffer display will do the fb getter call into it gotcha yeah this is the RGB matrix one okay so we would get it from inside of there and that's where it can be declared yeah let's see let's pull it up I think I'll look through RGB matrix as well it sounds like that's a good example of I guess probably the most recently added kind of display type I saw the issue go by do we have a link to the branch for this yeah yeah so RGB matrix ends up having the actual refreshing of the display happen by timer interrupt which is separate from background tasks which is separate from display IO which doesn't care whether you're have a long running python thing or if the garbage collector is running so it kind of keeps running despite almost everything at a fixed pace and that may be the kind of thing that you need for these displays but that's the kind of thing that needs microcontroller specific support so you know you'll know you're working on the S2 or S3 or whatever it is and you could create some specific timer code that made it happen 60 times a second regardless of what display IO the display IO part is doing regardless of whether display IO is dirty or not I'm not sure exactly how that will fit into the organization of your code because I haven't looked at it but that would kind of be my god idea so I think this is a bit similar to how pure module works using interrupts to display things on the matrix on the LED matrix it also has to run in the background all the time but I didn't actually connect it to display IO so this is a bit more I think you would want to basically display IO was designed for those displays with internal memory that has the SPI bus and you write the memory to them and maybe you could make this frame buffer display like simulate that in the structure not have actual SPI bus but you can pass custom buses to the display IO and you would basically have a new bus type that is simulating them external memory by using internal memory I don't know if that makes sense I see, yeah kind of like replacing almost the like four wire sort of layer as a different kind of option that you pass to the display when you create it would be interesting I mean this is this is where you already have a cut basically in the current architecture so that's where you can plug in easily not sure how that would be performance wise okay definitely give it a try let's see at that clock native frames per second okay okay get native frames per second so we implement that and then it will basically ask the subclass for it when it gets used okay right this is like a protocol thing so in the bottom of dot clock oh and I lost my tap yeah at the bottom of dot clock you can you're like connecting like struct members to functions to call mm-hmm and so you would add a dot get native dot get native frames per second and then you'd be able to tell it what value to actually go on okay and then I can it makes sense to pass that into the constructor to dot matrix display and then basically it will return whatever the user said yeah you could have you could pass it in the clock display frame buffer construct but I think just right generally like you want to manage you for frame buffer stuff you kind of can manage when the refreshes happen because you're managing the frame buffer itself which is different than how display works for non frame buffer things and then one last comment this isn't shared module but it has ESP specific stuff in it so I would move it to common how under ports express it the dot clock display oh yeah the dot clock display module yeah just because shared modules for something that would work across ports okay although I I've skirted that role for the web workflow stuff temporarily to you said to ports expressive common how correct yeah to do that as well thank you I definitely appreciate everybody's comments and ideas I think that gives me a lot of direction to go on this came as if I could be labor just another moment on the same related topic in these displays there's two sort of frames per second one is this native frames per second but yet there's another in the refresh I think it's in a refresh structure about requesting a target frames per second I couldn't separate those out in the code or understand the differences between those two could maybe Scott or Jeff could you guys comment on when each of those take an effect or where are you looking yeah I think in a normal display you can set it I think it's in the refresh function you can request the target frames per second in a minimum frames per second right so target is we will refresh faster than that so if you if your codes running faster than that will actually delay so this is like if you want a while loop that's going to run every 60 frames per second like it can hold you to that and then the minimum is the if your loop runs so slow that you don't hit your minimum it will raise an exception okay I'm not sure I observed that or not it seems like when we were having issues that foamy guy fixed it with this native frames per second but target frames didn't have an effect so I wasn't sure it seems like each of them are behaving error somehow being checked differently and I wasn't sure on the logic I couldn't follow it immediately yeah I haven't looked at it in a while okay all right no worries yeah so the difference between target and minimum is target is if you're running faster than it it will slow you down so that your loop runs at that speed and then minimum will raise an exception if your loop was too slow to hit that then there's native frames per second also that's where I got lost it seemed to in this cable so native is for auto refresh I think whereas the refresh call here is if you're managing it yourself okay that was my misunderstanding okay I thought I misunderstood thinking target frames was actually setting the auto refresh rate but okay that makes more sense I think the refresh call is explicitly like you're managing it yourself got it okay oh so okay that makes more sense of why changing that target frames had no effect then yeah it does say when auto refresh is off and target frames per second is none this waits for the target frame rate and then refresh the display running returning true got it okay should read the docs okay if the call has taken too long since the last refresh call for the given target frame rate then the refresh returns false immediately without updating the screen to hopefully get caught up got it okay that makes a lot more sense now if you yeah yeah yep okay is it anything else shall we wrap up I'll go ahead and I think everything is good for mine okay thanks everyone okay thank you thanks for that discussion okay so finally this is a wrap up time this has been the circuit python weekly for July 25th 2022 thank you to everyone who participated if you want to support Adafruit and circuit python and those of us that work on circuit python consider purchasing from the Adafruit shop at Adafruit.com we will release the video of this meeting on youtube at youtube.com and the podcast will be available on major podcast services uh meeting will also be featured in the python for microcontrollers newsletter visit adafruitdaily.com to subscribe next meeting will be held next Monday August 1st as usual at 2pm US eastern time 11am specific time and um remember you can go to adafru.it slash discord to get an invite to the Adafruit discord and join the meeting and to be notified about the meeting and any changes to the time or day you can ask to be added to the AdSign circuit python easter role on discord so we hope to see you all next week thank you everyone and with that I will stop recording