 Hello and welcome to the Circuit Python Weekly Meeting for May 24th. My name is Scott, and I work for Adafruit on Circuit Python. This is Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. Adafruit is an open-source hardware and software company based out of New York City who funds a number of us who work on Circuit Python. So if you want to support Adafruit and Circuit Python development through Adafruit, please go to adafruit.com and consider purchasing some hardware there. This meeting is hosted on the Adafruit Discord server. You can join any time by going to adafru.it Discord. We hold the meeting in the Circuit Python Dev Circuit Python Dev Text Channel and the Circuit Python Voice Channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with the US holiday, speaking of which next week there is a US holiday on Mondays. So next week will be 24 hours later on Tuesday, not on Monday. So big flashy lights next week is not on Monday. We'll notify you via Discord. If you wish to be notified about changes of the meeting, we could add you to the Circuit Python East's Discord role. There's also a calendar available that we try to keep updated if you'd like to subscribe to that. I checked it. The meeting next week is also shifted there. This meeting is recorded. We record the audio from the voice channel and the video of the text channel. If you'd rather not have your voice recorded, you're still welcome to participate. I wanted to make sure I had the right tab being recorded. The video of this meeting is posted to YouTube and the audio is released as a podcast. If you find this podcast is not available on your favorite podcast service, let us know. There is a note stock to accompany the meeting and recording. If you wish to participate but can't make it to the meeting, you can leave hug reports and status updates for us in the document and we'll read them off during the meeting. The note stock also 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 60 to 90 minutes, so this gives you the option to skip around. A link to the notes document is posted on the Circuit Python Dev channel on the Avery Discord every week. Check the pinned messages to find the latest note stock. This meeting is held in five parts. The first part is community news. This is a look at all the things Circuit Python and Python on hardware in the community. This preview for our Python on microcontrollers newsletter. The second part is the state of Circuit Python libraries in Blinka. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers separate from what we're all up to. The third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in our community. The fourth part is status updates. Status updates is an opportunity to sync up on what we've been up to. Take a couple of minutes and talk about what you've been doing in the last week since the last meeting and what you'll be up to over the next week until the next meeting. The fifth and final part is in the weeds. In the weeds is an opportunity for more long form discussions. These discussions can come out as status updates or be something you've identified ahead of time as too long for status updates. If you have topics for in the weeds, please put them in the note stock under that section along with your username. And that covers how the meeting will go. With that, I will switch note stocks, take time code and do community news. So first up in community news. Python snakes its way to the new Texas Instruments TI-84 plus CE Python graphing calculator running circuit Python or a circuit Python, a version of circuit Python, not official circuit Python. The new TI-84 plus CE Python graphing calculator by Texas Instruments runs a circuit Python fork. We should make that clear. This link here goes to the USA site. And it says you can sign up for alerts but not purchase yet. And this link goes to the UK site. And it's available for purchase in the UK. Read it more and follow developments as they're known from the Adafruit blog. Haxter IO News discusses the TI-84 plus CE Python calculator circuit Python and available modules there as well. And I just I'll have to remember to say that it's a fork. OK, and as far as we know, we haven't seen the source of it either. So it's a private fork at this point, which is totally OK by our license, although they shouldn't actually be calling it circuit Python. They should say it's circuit Python, but not. Yeah, got to figure that out. OK, next up, more coverage of using circuit Python drivers on MicroPython on the Raspberry Pi Pico. This is a headline from last week. So more coverage on the headline in the last newsletter on using circuit Python drivers on MicroPython on the Raspberry Pi Pico. Tom's Hardware had a write up. It said circuit Python libraries slither into MicroPython on the Raspberry Pi Pico. Mix both MicroPython and circuit Python code in the same file on a Raspberry Pi Pico with Blinka. That's from Gurgle Apps on YouTube, I think. And then lastly, Pimaroni has baked the circuit Python Blinka layer and platform detect libraries into their MicroPython helper library, which I think is actually their build of MicroPython as well. Next, we had some info around disabling the circuit Python USB devices in Boot.py. With the upcoming circuit Python 7x, you'll be able to selectively disable the many USB devices it creates, the circuit drive and the USB serial. Read more in the new guide, customizing USB devices in circuit Python. And there's a link to the Learn Guide and the blog. There's also example code from Todd Kurt on Twitter and on GitHub. Next, Adafruit squeezes the power of the RP2040 into a USB key. On the desk of Lady Aida, LaMora discusses development of the Adafruit Trinky RP2040 with QT Connector. There's a link to the YouTube there. And thank you, I think it's probably Fomey Guy posting all these links in the chat. Thank you, Fomey Guy. Quote, we've wanted to have something that plugs into a USB-A port and provides QT port for a while. But since we wanted to support any and all QT boards, we need more RAM and storage than the SAMD21 can provide. We probably cannot buy any SAMD51s for like a year, but RP2040 is a good option. Lots of RAM and we stuck an 8 megabyte flash on there. The idea is you can attach a QT sensor or whatever on top with some nylon stand-ups. Maybe it will even auto-detect which sensors are plugged in. We made the boot button, the user button too, thanks to a little diode friend. And Tom's Harbor reviews the Adafruit QT2040 Trinky as well. Next up, lots of news. Arduino Nano RP2040 Connect now runs CircuitPython. Liz, BlitzCityDIY submitted a PR to add support for the Arduino Nano RP2040 to CircuitPython. So far, so good. The digital pins all toggle right and see the built-in LSM6DSOX chip on the I2C port. There's a driver for this IMU, so the video has a quick demo and external OLED wired up on the same I2C bus, reading accelerometer and gyro data and displaying it on YouTube. Next. The Python Software Foundation has a second quarter 2021 fundraiser. PyLadies Brazil co-founder Debra Azevedo can capture her feelings about our Python community in one word, belonging. There's a link to a mail post about it. Debra has stumbled upon her love for programming accidentally, quote, I pursued a computer networking course because I didn't want to code, she said. But when I learned Python, I had this empowering feeling that I could really build something. Thanks to community support, the PSF has provided more than 651 PyCon scholarships and travel grants to community members like Debra and $2.8 million in grants to Python projects across 91 countries over the past 20 years. You made this possible. You built this incredible community and sustained it for more than 20 years. You helped us come this far. To continue this growth, the Python Software Foundation needs your help, raising $80,000 by June 12th. To give to the Python Software Foundation, there's a psfmember.org link there. And almost near the end here, we have the 2021 Python Language Summit, Lightning Talks round one recovered. The first day of the 2021 Python Language Summit finished with a series of Lightning Talks from Petter, Victorine, Lorena Mesa, myself and Jeff Allen. CircuitPython is a much smaller version of Python that runs on microcontrollers. Scott Schacharoff compared what's included in CircuitPython and CPython to give a sense of what is central to a user's experience of Python. Read more at the PSF blog. And that's it. As always, this has been a preview of the Python for Microcontrollers newsletter. The CircuitPython Weekly newsletter is a CircuitPython community run newsletter emailed every Tuesday. The complete archives are available at AdafruitDaily.com slash Category slash CircuitPython. It highlights the latest Python on hardware related news from around the web, including CircuitPython, Python and MicroPython developments. To contribute your own news or project, edit next week's draft on GitHub by going to github.com slash Adafruit slash CircuitPython Weekly newsletter and look for the drafts folder with a draft in there and submit a poll request with your changes. You may also tag a tweet with hashtag CircuitPython on Twitter or email cpnewsatadafruit.com and we'll add it for you. What a loaded newsletter. I can't imagine how the newsletter is gonna be. Thank you to Ann for putting that all together. Next up, we have the state of CircuitPython libraries in Blanca. This is a statistical overview of the health of the broader CircuitPython project. And we'll go over some numbers to ground us in the stats we like to check out. So first, we'll do overall. Overall, we had 43 poll requests merged from 23 different authors, which is becoming more and more the norm, which is amazing. So thank you to all of our authors. We had 11 reviewers as well. So thank you to all of our reviewers. As always, reviewers empower our authors. So the more reviewers we have, the better. So if you're interested in reviewing, please reach out to us. We'd love to help you get to that point. Issues-wise, we had 20 closed issues by 10 people and 23 opened by 20 people. So we're net up three, which is not too shabby. And lots of people involved, so that's good too. With that, let me talk about the core. And I forgot to write my overview, but that's okay. 23 poll requests merged into the core from 16 different authors. A lot of folks I recognize, but some new folks, Edrick, I think is new, Bullet City DIY is new, Gabe Willen is new. So thank you to those new authors. We had eight reviewers. Thank you to those reviewers. We have 24 open poll requests, where one of them is over 200 days old. The rest are less than that. Many of them are just a few days old, less than a week, so that's great. That's poll requests. Issues-wise, we had 11 closed issues by six people and 11 opened by nine people. So we're net zero, which is awesome, for a total of 452 open issues. We keep track of how we're keeping up with issues by using milestones to triage the issues. We have five active milestones, where we have 60 open issues for 7.0. We're gonna have to take a look at those again. And we have two issues not assigned to milestones. So those are the ones that we need to take a look at. Not uncommon to have a couple that we haven't looked at because of the weekend. Overall, things are going really good. Dan's been running down the flash issue with the QDPIs. And once that's sorted out, we'll get a 6.3 RC zero at the door. And then once that's, once 6.3 is stable, we'll start doing 7.0 pre-releases as well. So lots of exciting stuff. And with that, let me kick it over to Katni for the library update. Thanks, Scott. So this is all about the CircuitPython libraries. It applies to every library that starts with Adafruit underscore, CircuitPython underscore, as well as the CircuitPython community bundle and our cookie cutter that takes care of generating the initial library files. So we had 16 pull requests merged by eight authors and six reviewers. In terms of merged pull requests, we have one that was 113 days old, which is excellent. I will talk a little bit about the fact that those are getting taken care of later. And we're keeping up with some recent ones, which is also great. We had seven, and that leaves us with 50 open pull requests. So we had seven closed issues by five people and eight opened by eight people, leaving us with 307 open issues. Six of those were labeled good first issue. Although I went through that list and either they're already being taken care of or they're not really that great. So we need to curate that a little better, I think. If you're interested in contributing to CircuitPython, go to circuitpython.org slash contributing. If you're interested in contributing on the Python side of things, you'll find a list of open pull requests, a list of open issues, and a list of library infrastructure issues. You can search the open issues by label or you can search them. You could search for a particular piece of hardware in the page. And if you go through that and you find something that interests you, let us know and feel free to start working on it. We have a guide on contributing to Git and GitHub, or contributing to CircuitPython using Git and GitHub. If you are new to those things, don't let that intimidate you. And we are always available on Discord, et cetera, to answer questions. We want you to contribute. So whatever it is that you want to do, we want to help you do that. And in terms of library updates in the last week, we have had no new libraries, but several updated libraries that I won't read off. Overall, we are seeing a lot of action on older PRs, which is excellent thanks to Jose Davide, who has been going through all of them and tagging folks and getting some of them merged, testing them, that kind of thing. Something that we talk about every week that needs to be done, Jose Davide is taking care of it. So if you submitted a PR, expect to see some action on that at some point. If you are waiting on us, please feel free to ping us at any time. Give us obviously 24 business hours to reply, but if it's been longer than that, you can always tag us again. And that's where we are with libraries. Awesome, thank you, Katnie. Next, let's kick it over to Melissa for an update on Blinka. Hello, so for Blinka, we had four poll requests merged. I see dollar star Nova as somebody I don't recognize. And we had three reviewers. There are six open poll requests amongst all the Blinka-related repositories at this point. There were two closed issues by two people and four opened by three people, leaving a net of 56 open issues. There were 7,322 PIPI downloads in last week and we are currently supporting 74 boards. Overall, it's great to see more contributions to Blinka and I think having it expanded to work with MicroPython once again has helped a lot. And that's it. Awesome, thank you, Melissa. All right, next up we're done with the state of CircuitPython libraries in Blinka. We're going to go to Hug Reports. Hug Reports is done as around Robin, so I will start and we'll go through the folks in the notes and in the voice channel. If you're unable to make the meeting, you can always drop notes in the note stock and I'll read them off, otherwise. Or if you're in the meeting and don't wanna speak, go ahead and just say that you're a text only and I'll read them off for you as well. Okay, so I have two, three Hug Reports. First, Hug Report to Blitz City DIY for adding board support for the RP2040 Arduino. I missed, my brain's too fast for my mouth. And Le Samurai pour pe for the idea of adding a web hook from GitHub status to the channel on Discord for that and thanks to Dan who set that up. And those are my Hug Reports. Let's go back up to the top and go to C Grover. Yeah, I've got a Hug Report for David G for the help and inspiration, the discussions and ideas that he's provided while I've been going through some thermal camera host board selection performance comparisons. And then I wanted to thank Lady Aida and the team of people that are working on the RP2040 SPI improvements and I hope to see those spread to a couple of other boards too. Awesome, thank you C Grover. Next up, it looks like we have notes from Blitz City. Blitz City says, thanks to Naradok, Mark Gambler, Dan H, Catney and Tanute for their help on Discord. Excellent learn guys and help on GitHub with the PR for the Arduino, Nano, RP2040 Connect. It was my first time doing something like that and all of your assistance and documentation made it a smooth experience. And of course, thanks to Lady Aida for the cleanup, testing and merge. Next up is Charles. I want to give a Hug Report to Lady Aida and all the people, all the circuit Python people who worked on creating the drivers for the rotary trinky because that has turned out to be a very handy device for my music projects and a group hug for everybody else. Thank you. Thanks Charles. All right, next up is Dan. Okay, I'd like to thank ADCC on GitHub who's been helping me debug. We have it, well, to state the problem, we have some QDPy RP2040 boards that when you plug them in, circuit Python doesn't start up or you have to press reset a bunch of times or something. And it turns out this seems to be due to a slow startup of the crystal oscillator that's on the board. And ADCC was also investigating some issues possibly having to do with the flash memory but that's probably a red herring. So they were extremely helpful on this and they've looked at traces and I've looked at traces and we've come to a conclusion I think, which is great. I'd like to thank Cam Tom Fiori who very quickly tried out Dynamic USB on this presence. They support this presence and submitted some fixes because I hadn't had a chance to test its presence at all with Dynamic USB. Thanks for Dave Putz for doing Pulse Out on the RP2040 which was highly necessary. And also repeating thanks to BlitzCity for the Arduino Nano RP2040 board definition. Okay. Thanks Dan. All right, next up is, I have notes from David Cloud. Who says, Huggraport to Kevin J. Walters for finding a bug presence since 5.0 with the iSquared Z is not unlocked with Soft Reset. Huggraport to C Grover for performance analysis of many boards with a thermal camera. Huggraport to BlitzCity DIY for the Nano RP2040 Connect PR and Lady Aida for the faster spy screen update. And next up is Deharada. Hey, so first our report is to whoever wrote the AidaBot patch software because that has probably saved me about 50 hours in the last few days. And then a group hug. Awesome, thanks Deharada. Next up is Foamy Guy. Alrighty, thanks. First hug goes out to near doc. Pointed me in the direction of the 7.0 bundle. I was grabbing individual libraries one at a time. I didn't realize there was a bundle there, so that helped me out a lot. To Leis Amarai-Pourpay pointed me towards in the community bundle, there's a base 64 library that can encode and decode. So thank you for that. To Brent and JW Cooper, both helped me with some questions I had about Adafruit IO. And last one for me is to Kmatch, Mark Gambler and KJW and possibly some others as well who all looked into and did testing and testing and worked up a fix for an issue on funhouses with the display drawing some weird extra pixels. And possibly I think it is on other ESP32 S2 devices as well, but Funhouse was the first one reported. So thanks to all those folks. Thanks. Thanks, Foamy Guy. And Catney points out in the chat that Summersoft is the author for the Adafatch software stuff, we believe. So hug report to Summersoft specifically. All right, next up we have notes from Hier Effect who is missing the meeting today. Thank you to Phil B for fixing the Big Sur Drive-Eject alert problem and Dr. On Discord for pointing me to the fix. Thank you to Tanute for a discussion. Thanks to Armstrong Sabero for work on the H7 analog support and Tanute again for the LED revamps and Dan H for the review or reviews. And now we have notes from Jeff E. I keep deleting the wrong things. Jeff says hug reports to Tanute and Catney for running the meetings and a group hug. Next is Jerry. Jerry. Hi there. Excuse me. Yeah, thanks to Maker Melissa for the getting Blinka on going on the MicroPython and the new guide and for the guide for using the Home Assistant and Funhouse, having fun with both things. And a group hug. Group hug. Thanks, Jerry. Thanks, Jerry. Cat. All right, next up we have notes from jose.veed who says hug report to the Summeray Prepe for the work in the community bundle and their attention to details. Hug reports to Jerry and for helping me test the PR for the TCA 9548A. Hug reports to Tanute for all the week long discussion over library's memory allocation for the M0 restricted memory board. And a hug report to Maker Melissa for quickly solving issues with Blinka for MicroPython and all the work there. Next up is Catney. All right, my first hug report is to you, Scott, for hosting today so I could get settled in my office without worrying about fighting with OBS and recording the meeting. To Keith the EE for joining the PyCon 2021 Circuit Python sprints this year. They were super excited to join. They had made a goal of contributing to Circuit Python sometime this year and didn't expect to get to it until much later so they were very excited to have the opportunity. And it was, they chose to work on an issue that applied to a project that they're also working on so they had some personal connection to the thing that they decided to do. And so that was really excellent to help them out and see how that goes. And they're also really looking forward to contributing to the project in a bunch of different ways, including reviewing, which I'm looking forward to the time when we can add them to the review team when they're comfortable with that. I also have a hug report for Jose David for going through all the open PRs and making headway towards getting caught up. And a group hug to the community keep being amazing. Awesome, thank you, Catney. Next up is K-Match. Hey, thanks, Scott. First off, thanks to Gambler, AniData, and KJDebbia for the discussion on the ESP32 spy display issue. So I'm learning a lot, tagging along with that issue. And then second one is for Lady Aida for the cool I-squared-C UART debugging tool. Looks like it'll be really helpful. Thanks a lot. Ah, thank you, K-Match. And next up, we have notes from Keith EE who says, hugger print to Catney for being fantastic through the sprint and having a great set of demos ready that help talk about her experience with Circa Python as a whole. Hugger print to NeuroDoc for all of their help in the Python Discord to answer questions in the microcontrollers channel and the community at large as a whole for being welcoming and encouraging and helpful when issues arise. Next up is Maker Melissa. I think I'm already unmuted. Let's see, I want to give a hug report to Jerry for testing out my MicroPython guide. Another one to Jerry for general guide improvement suggestions. A hug to, let's see, I'm not sure you pronounce this. Leza Mora Papua for fixing the FunHouse slider code. Ash from Tom's Hardware for writing a great article on the Blink of MicroPython functionality. Gurglabs for a great YouTube video version of my MicroPython guide and a group hugged everyone else. Awesome. Thanks, Melissa. And next up we have notes from Mark Gambler who says, hugger print to KMatch98, Kevin J. Walters, and many others who are helping on the ESP32-S2 display get glitched problem. Last up we have notes from NeuroDoc who says, Leza Mora Papua helping out with the PR to support the new MPY format in circuit. And a hug report to Entol and Carlos Peratt for following up on the fixes in the MewEditors Circuit Python mode detection. Awesome, thank you everyone. So that was hug reports. First of two round robins. The next round robin we're going to do is status updates which is a chance for us to talk about what we've been working on and what we plan on working on in the coming week. It's a really good way to kind of collaborate with folks and give tips or tricks about what people are working on. And also just have an idea of everything that's going on as our community gets bigger and bigger. So for me, my goal is to be heads down on the BLE workflow stuff. I started it last week. I also finished the status LED stuff. So if you're using the latest on main you'll see that. I fixed Safe Mode on the RP2040 for both 6, 3 and 7. So you should be able to enter Safe Mode by pressing reset multiple times. Of course, that doesn't really work on the Pico because there's no reset button but if you manage to just do it there you could. I'm ticking Friday and Monday off for the Long Memorial Day weekend here in the US. So I'm excited for that. And as a result, deep dive will be on Thursday. One thing I'm going to do today is I'm going to start a deep dive role so that I can ping people about that if they want to know when I switch things up. So that's on my to-do list as well. And with that, let me scroll back up to the top and kick it over to C Grover for status updates. Well, let's see. I've been spending a little bit of time with the thermal camera obsessed with trying to get it to work properly and using some of David G's interpolation code I was able to increase the resolution from eight by eight to 15 by 15. I got a picture coming up here. But I also wanted to pick a platform for it. So I tried it on seven different development boards, pipe portals, RP2040, the Feather S2 and so forth. And some of them have integral displays, some without. And because of the mix of the I2C and SPI connections, the ULAB methods that we're using inside of that, and it has the really memory hungry implementation of display IO that has over 240 different elements, one for each of the temperature sense displays. It was difficult to find just the right kind of host development board for it. So I found that the Pi badge, the Pi Gamer performed the best for that camera application of the mix of the I2C and SPI and display IO requirements. But I was surprised to find that the RP2040 and the ESP32 S2 Feather S2 were a lot slower and were unable to achieve my target rate of two frames per second. So I've got a comparison graph I'll show in the in the weeds section just for the information. I know that the thermal application, the thermal camera application is fairly unique in its need for, like I said, I2C for the thermal sensor and SPI for the display. So I don't think it's a good board comparison benchmark for general purpose applications, but it is kind of interesting to see how some of these development boards work with that. Anyway, for next week, I'm going to look at updating the existing thermal camera learning guide with some new code, particularly the pseudo color spectrum helper that I developed for that, that uses the iron spectrum. It makes the images a lot easier to spot and some of the edges of the objects easier to spot. Then I'm going to try some of David G's three X and four X interpolation techniques. He's done some really great work with the larger sensors and see if I can get rid of the display IO rectangle memory usage issues that I've been facing. And then I'm going to find some high quality and affordable servos that may be difficult to do, but for the robotic cuckoo clock after about six months, the internal bird got a case of laryngitis and we need to fix that. Oh, and finally, the book that I provided some illustrations for is going to the printer this week, so that's kind of exciting. Awesome. Well, thanks so much, Seagrubber. Next up is Dan. OK. So as I mentioned, you have this problem on a small number of QDPI RP2040 boards and maybe some other boards. Some people have found that the board doesn't start up properly on power-up. And so I spent a while looking at this and took some traces with my salier. And this person, ADCC, also worked on this. And it seems like the crystal oscillator is not starting up properly. ADCC saw that. They looked at the waveform and it's kind of a mess. It's like not, it's too fast for a while until it's stabilized, for instance, which causes bad data to be read from the spy flash or not any data read, and that's why it hangs. So if we just slow down the startup, it works. We have to figure out how the best way to do that in a general way, but we can do it easily for 630 right away. I'm starting to work on some kind of keyboard matrix library, which you could use for simple things like telephone keypads, but also for keyboards. And I'd be happy if you have any input on that to hear what your requirements are. It'll probably be something simple to begin with, maybe kind of like gamepad, but more general. But I'll talk to Deshi Poo about it when he comes on. Now that we have the fix for the startup problem I talked about, I will try to get a 630 RC0 out right away. And the only other thing I'm going to add is the Arduino RB2040 Connect board. So we'll have a release candidate out. And soon after that, if it seems OK, then we'll have a 630 final. And then as soon as that's out, I'll work on the 7.00 alpha release, because 7.00 is in good enough shape that we should have an alpha release for now. But I can't have two alpha releases. I can't have two non-stable releases at the same time, unfortunately. CircuitPython.org doesn't show that, which maybe is something we should fix. But right before we do that, barring that, I'll use this timetable. OK. Thanks, Dan. All right, next up, we have notes from David Cloud, who says, no project done this week, although it sounds like he was involved with the thermal cam stuff. All right, next up is Diharata. So last week, up until today, I was running three Itabot patches and finishing up the FunHouse IoT Hub guide, just waiting on some issues with the learn repo. And this week, writing code for three guides and actually writing one guide. I'm going to try to start moving the CircuitPython library from master to main. Hopefully, that'll be this week, but it might be next week. And then I'm also going to be making my own USB cables. Awesome. Thanks, Diharata. All right, next up is Fomegay. All right, last week, I made a PR in the cookie cutter to handle library names with spaces in them better. So it will go through and replace with underscores and dashes and all the spots that need it. And then after that, I spent probably the majority of the rest of my time last week learning about Adafruit I.O. and MQTT. And I only done very basic stuff with Adafruit I.O. before, and I had never used MQTT before. So I got figured out how to post data into Adafruit I.O. and make dashboards to see it and how to subscribe to feeds with CircuitPython code so that you can get a callback whenever there is new data. So that stuff was all really fun, super impressed with how easy it is to make dynamic IoT projects that can store anything you want up there and notify you when there's new data. It's a really powerful platform. I put most of what I learned to use in order to integrate design I.O. into Adafruit I.O.'s web hooks so that when a user saves their design, if they have it set up, then it will automatically upload that image to Adafruit I.O. And then if they have the receiver code running on a FunHouse, it will get notified of the new version and it will download it and show it on the screen. So it's kind of an automatic update loop whenever you save design. For this week, I'm going to get that design I.O. deployed out to a public-facing server. Right now, it's just on my test device. So I'll get that out there this week for other folks to use and then dive back into the CircuitPython org repos, all the renaming and moving of the display I.O. stuff into there. So that's what I'll be working on this week. Thanks. Thanks for me, guy. All right, next up we have notes from Hire Effect. Who says, last week, reviews and alarm merges and debugging pin alarm on the RP2040. This week, wrap up RP2040 alarm, clean up the NRF alarm, and work on the next file PR. And now we have notes from Jeff Epler, who says, last week, vacation. This week, back on Tuesday, debugging crashes with the Wi-Fi or RGB matrix on ESP32S2 probably. And next up is Jerry. See, last week, I spent a little time playing with the TCA9548, just trying to help with testing out a PR. That was kind of fun. I looked and thought I'd recognize the names. Turned out I had bought one in 2017. It's been sitting in a drawer since then. So it was nice to actually pull it out, put some headers on it, and put it to use. And I made some soil monitors. I'll put a picture here. And put it in the garden. And they just have helped keep track of the soil. And they're using ESP32S2 to connect back to my home assistant and eventually set it up so that it can ping us when the thing needs to be watered. But it's kind of fun to play with. And then I just tested out Blink on the Pico MicroPython. And got the I2C example working OK. I tried it on ESP8266, but it ran out of memory right away. And I'm not sure it's worth spending a lot of time and effort on that, but I really wanted to use it on ESP32, but it's not supported yet. So be looking into that at some point. But following up on that, one of the things I want to be able to do, be nice to be able to use some of their RFM radio boards with ESP32s. And I totally forgot that sometimes last year in August, it helped somebody port over the libraries so they actually run on the MicroPython. And I don't remember how far it went when they work. I actually did a quick test and they actually function. So I need to go back and do some more looking at that. There's links to the guides, to the person who was actually setting up the MicroPython library. So that might actually be fun to do. And I'll spend a little more time looking at the rotary encoders seem to have an issue where it can lose some counts if you tweak it just the right way. And I think this was reported by Jeff last week. And I did confirm that it happens on both Arduino and Circuit Python. It's clearly something in the seesaw itself. And that makes sense since the libraries do is read the data from the seesaw. Next week, yeah. So I want to dig back out all that stuff about MicroPython and the RFM boards and see if I can get those working with my ESP32s. Awesome. Thanks, Jerry. All right, next up is Jose David, who says, last week, open PRs and reviews, some library documentation and library features improvements, did some sensor library PRs, and did some testing on the Pico with MicroPython. This week, PRs, PR reviews, and work in the BME280 memory analysis. I think it's E, might be P. Next up is Ketney. Yeah, I can never remember which one of the BME or P's are what they are. Right. So last week, started with finishing up the sprints. That was a lot of fun. It was great helping Keith, the EE, work on the stuff that they wanted to work on, and it gave me some time to work on starting the refactor of the LED animation library. Still don't know what that's going to look like. Trying to preserve backwards compatibility to the greatest extent possible. It still will involve, obviously, changing the imports, which means importing another library. Which, once the library screenshot generator is in place, is a much less huge fix to make across 28 guides. So I'll be waiting on that before we actually move forward with this. But at the same time, it's not really a priority. So it may actually just be waiting until I have time, which is an indefinite amount of time. I worked on the Neo Trinkie guide. I don't recall if that went live or not, but the core of it is mostly done, or the core of it is done. We ran into some issues on the repository that we host all of the learn code on. So I have to fix how the code is embedded in the guides. That's seamless to the user, though. Anybody reading the guide is not going to know the difference between how... Actually, that's not necessarily true. The project bundle download works a little bit different when the code's embedded versus when it's embedded from GitHub. However, all the libraries necessary are built into Circuit Python for the Neo Key Trinkie, rather. And so it doesn't matter. I did some pretty pins diagrams for a couple of the Trinkies. The Neo Trinkie and the Neo Key Trinkie. So those are both now available. And the Circuit Python and Python page for the I2C Rotary QT already existed, but was not made live until last week. So this week, the last thing for the Neo Key Trinkie guide is adding applicable templates. That won't be too bad because there's not a lot to the Neo Key Trinkie, so not all of the templates apply. And then next, I'll be working on the Rotary Trinkie guide, which will involve creating a new template for Rotary encoders. And then after that, it'll be the Slide Trinkie. And so I'll be doing a template there, too, for analog input and potentiometers. And then finally, if I have more time working on more pretty pins for SAMD21 boards, the way Pretty Pins works, it requires having a CSV in place with all of the pins available for a particular chip. And the SAMD21 has been put together. So that's the next set of them that we're working on. And there's many, many, many. So we'll be working through those. And that's where I'm at. Awesome. Thank you, Kenny. All right, next up is Keymatch. Thanks, Scott. So this week, mainly I've been doing some testing on some of the fixes that Mark Gambler had proposed on the SPI display fixes for the ESP32S2. It's an issue that cropped up with some display glitches, particularly observed on the Funhouse board. And that'll be a discussion more in the weeds of how to proceed with that. Also, I was able to build some code to use the RP2040 as a logic analyzer. That's a project called PicoLogic. The most recent code I'm running is from a user called Mark. A BE139, I think, is the name on GitHub, who extended some of Gambler's code. It's basically a logic analyzer using the 2040, which is pretty good. And I'm trying to make it so my tiny logic friend driver for SigRoc and PulseView can also utilize that board as well. So just got a brief update for you. I haven't gotten any response on my PR for that tiny logic friend driver into SigRoc. So I'm hoping maybe I can test this one out. And if I can get that all into one, maybe we'll have a package of a couple of things so I can make sure it can accommodate that when it goes in. So hope to get that done this week. Awesome. OK, thanks. Thanks, Keymatch. Great. Next up is Maker Melissa. Hello. So last week, I figured out some ways to get Blinka minimally installed on MicroPython. And I wrote a CircuitPython library as a MicroPython guide for the Pico. I worked on getting the Beaglebone Star 5 up and running, but didn't get much further than that. I updated the Dynamic Bundler to 7.x and PY files. I went through circuitpython.org board, all the boards on there, and did updates like updating images and adding a couple of blimp boards. And I did some general GitHub issue maintenance. This week, I am working with finding developers to make MicroPython Blinka install smoother. I'm looking into a new issue that's or I want to look into a new issue that's causing Learn Guide peers to fill in some boards and some more issue maintenance. And that's it so far. Awesome. Thanks, Melissa. Next up, we have notes from Mark Gambler, who says last week the ESP32-S2 display glitch related to SpyDMA. And this week, we'll continue looking at the display error. And last up, we have notes from Naradok, who says last week, I filed a PR to circuit to fix reading the module version strings in the new MPY format. Ooh, thank you. Bug fixes and issues to the core mostly discovered thanks to the help channel. And this week, working on adding the community bundle to circuit in a generic way as a stepping stone to add support for third party bundles. And also, open a couple of rep related issues I have filed in the I'll look into it later bin. Perfect. That's exactly what issues are for. The I'll look into it later bin. All right. Thank you so much for everyone's status updates. We're going to go to our final section here in the meeting, which is in the weeds. There are a number of topics in here already. So you've got some time if you want to add some more things here. If you have more things to talk about, please just put your name in the brief summary of what you would like to talk about. And we'll go down the list. So starting with a topic from Jose DeVee, who said, we'll need some help understanding why we have problems with the RP2040 and not other boards regarding a pull request on the TCA 9548A. Is anybody aware of this and wants to summarize it? To summarize it? Yeah, I was working on that with them. That's just somebody else who wants to jump in. I think it's all you, Jerry. OK, yeah. So I wasn't really clear what the initial problem was. But when you run the code, there was an issue with a try lock that was missing from the scan program. So I think that's what the PRs were trying to fix. But and the fix that was put in works fine on the NR5040 board and on the Feather M4. But when you run it on the RP2040, it just doesn't. It gives really bizarre results. Sometimes it works, actually. The scan doesn't work. It never reports the right information. But sometimes the actual ITC devices work. And sometimes they don't. It doesn't recognize them. It doesn't find them and says they're not there. So it's just clearly something very odd about the RP2040. But the RP2040 works fine if I just plug the devices into ITC and run them normally without the MUX, the PCA board. So it's some interaction between the two. It's not at all clear what or why. Interesting. I feel like, I think Carter has a lot of background with that chip, too. Yeah, he does. He was, in fact, I think he wrote the driver. OK. I have no insights right now, but I'll take a look at it. Yeah, I took a look. I mean, the drivers really, there's not much there. Because it does read some of the board. But there is some funky stuff going on with switching channels and with, yeah, maybe something's getting lost. It communicates to it. It seems it just doesn't tell. Yeah, the iSquared C issue we have in the 2040 before was having to do with the data line delay setting or something. But I thought we fixed that. It doesn't also surprise me that there's more issues. Yeah. Yeah, I was working with two sensors on the MUX. And it wouldn't see them or it would see them in the wrong channels and it also plugged them directly in. There were stem is that plugged them right into the board and they were fine. The both of them recognize both very well. Oh, you're saying it had to do with the wiring. No, no, no. I mean, if you if you if you connect the TCA board and then connect the two iSquared C devices to the TCA board, it won't work or it's very unreliable. But if you hook them directly to the to the semiconductor and just run them normally without the MUX, it works fine. For the expander, it should say MUX. Oh, OK, right. So it's not that there's no there's no general I2C problem with iSquared C with accessing two devices. What if you connect them through the multiplexer or the TCA, whatever you call it, board and it just doesn't recognize things correctly passing through that board. You could just try it with BitBang IO just to see whether it'll work. Yeah, we thought we fixed all the i2C issues. For now, there's one more thing that is not fixed that is kind of we're waiting for something in upstream, but it's much more obscure. Yeah, like I said, I can't blame it on i2C from the testing that I did that since you're working on it, there seems to be some interaction with using the TCA 9548 board or driver, but only on the RP2040. Yeah, weird. I got nothing. All right, let's move on. Thanks, Jerry, for chiming in on it. Sure. So let's go to Cgrover. Talked a little earlier about trying to find a host development board for this thermal camera project and some of the trade-offs that are required to make that work, memory trade-offs and i2C and SPI performance trade-offs. So I went to my inventory and pulled out whatever boards I had and started playing with those. And I've got a comparison graph coming up here that I'm going to walk through just a little bit. What I found was that when I tested the Pi Badger, which is at the bottom of this chart, you can see that the date acquisition time, the time it takes to interpolate, which is just about invisible on there. It's just a millisecond or two. And the display in gray and the display update time in orange is pretty reasonable. And it beats my two frames per second target, which is that green line in the center of the graph. And so I started checking other boards that had most of them had integral displays like the Pi portals. And they work pretty well as well. But when I moved up to the clue, the, I don't know if I can read my own graph here. Oh, the titano. Of course, the titano has a big display. So it's going to have decent date acquisition time for the sensor. But it has a huge data or a display update time. But then when I moved to the Feather S2 and the RP2040, I noticed that the acquisition time, which is predominantly I2C, and the display update times in gray and orange were just huge by comparison. And these are chips with a lot of memory and with a high clock speed. So I was pretty surprised to see that for this particular application, running circuit Python, that they were just dramatically slower than the M4 that we were using with the Pi Badger. Now, the code for acquisition, the code for display updates is, well, acquisition is identical. The code for interpolation is identical. The display code was a little bit modified, depending on whether I could use a touchscreen interface on the Pi portals, which actually added some display IO elements. Or if I had to use digital in-out for the buttons that I needed for hold and focus. So if you're asking why do you think that is, I have a couple guesses for you. Well, I would love to hear why. I'm mostly just saying, look at what I found here. And is this an indication of something we need to take a look at? I generally think no. I think what I would expect to see is it would scale with display size generally. But I think one thing that people don't give enough credit to, at least on the S2s, is that the RAM is on a separate chip. So RAM, you have a lot of RAM, but it's not fast RAM. It's slow RAM. You're doing essentially spy to another chip for every RAM transaction. And we put the whole circuit Python heap on S2 there. So even though the CPU is fast, the RAM is not necessarily fast enough to keep up. So if you're doing RAM intensive computation, you're going to be slowed down by that. The RP2040 surprises me a little bit. But then again, if you're doing any sort of floating point, you're going to hit that. And then on top of that, the RP2040, all of its code is also stored externally. There is a cache in front of it, but if you're doing lots of different things of code or you're running enough code that the cache is full, you could be slowing down due to that as well. Yeah. But I'm surprised that the I2C speed is quite a bit slower than the M4 on both of those, because that code is really compact in that area. And it's largely just the time that it takes to pull 64 temperature measurements through the STEMI interface. So I'm surprised at those. Yeah, I think the best way to compare those would actually be just logic analyzer traces, because that would tell you. Yeah, I'd plan on scoping it later today. Like that'll tell you what is the clock rate when you're actually acquiring data. Things that can happen is that if we're doing DMA, but the DMA can't keep up, you'll see pauses between each byte. And then you'll also see between the reads, you'll see like transaction time. So like how long all the code around an I2C transaction takes, and potentially like, I guess I'm thinking a spy. But like in spy, like you might see like the CS line is like changed quite significantly differently than when the actual like bytes gets transferred and things like that. So I think logic analyzer traces will give you more insight into that piece of the puzzle. Ah, excellent, okay. If you want to dig further, but again, like I tend to not, oh, David says, is there any benefit in disabling display auto update? There could be. Oh, I tried that, I didn't try that. You did? I tried that during acquisition. I didn't try that. Actually, I tried it during acquisition and I tried it during calculations and I updated it just at the end of after all the calculations were done. And it made almost no measurable distance difference. Yeah, so I would say that if you're changing the elements on the screen and you're changing them in a way that they might overlap, then you're probably transmitting more than you need to if you're doing auto updates. Because if it's on auto update and you're starting to change the objects on the screen, like it'll start transmitting those. And that's okay if the bounding boxes for each of those individual things are like separate and not overlapping. But the moment that you overlap, you're going to end up doing like multiple transitions of the same pixel potentially. So I turned this, but I turned it off and didn't really notice any difference and nothing measurable anyway. So it looked to me like for this application, this application is unique and I recognize that. But for this application, turning that off really didn't make any big difference. Well, I think that's good then. That tells me there's not a bug in like the dirty area tracking or anything. Yeah. Yeah, I think display IO auto update really works well. You know, I remember it before that got fixed a few iterations ago. And this is just wonderful by comparison. Awesome. Well, yeah, I think that's interesting. I think you could also scope the, or logic analyze the display transmits as well to get an idea of how that's doing it. You know, bigger areas will be faster to update as well. Yeah, that's obviously true because when you look at things like the Titano, that has exactly the same architecture as the other PyPortals, it's a lot slower because it has to do, it's a lot slower in the display IO section of this, the orange section. That's pretty obvious. Yeah, I mean, some of it just comes out. I'll scope the, well, David, and David G says scope the I2C and then the SPI that's in the plans. Plus, I've been getting some encouragement to try vector IO and that could help with some of the screen update stuff. But I'll tell you, going through this process has been kind of interesting, but I was really just trying to pick a host platform for the application so I could move on to my next project. And it looks like the PyBadger might be the winner, but I do like the touch interface on the PyPortal. So that's kind of cool. Well, this is the danger of performance work, is that it never is done. Oh, yeah, I don't wanna go down that particular rabbit hole, but we'll see who can control that, me or my calendar. Awesome. Well, thanks for doing the analysis. All right, well, thanks. I appreciate you guys letting me bend your ear on this stuff and any other advice you have for me, just keep it coming. No, I think generally the story of clock rate is not everything is important. Yeah, that's why I was surprised by it because I'm kind of a neophyte when it comes to throwing these applications at these advanced, so-called advanced architecture boards and it's always a trade-off. Yeah, yeah, like the M4s, M4s have the built-in floating point and that can really help when you're doing math that involves floating point. It's pretty amazing. When I plug an M4 into the TFT feather wing versus the RP2040, you can see just an instant difference and it's running exactly the same code. Yeah, it would be kind of curious to see if we could de, like if there's any floating point math in display IO that we could find and make integer math instead, that could be kind of interesting as well. Those are the performance weeds. That could be your rabbit hole to go down. No, thank you. No, thank you. All right. Well, thank you. Thank you, Grover. All right, next up is Mark Gambler. Hello. Hello. So an update on what I found on the FunHouse and ESP32 displays. So I did all the, what was sort of suggested of switching the command and data rates and that did not make a difference. So I didn't want to proceed changing the API until it was sort of further down. And then it was just on a hunch. I disabled DMA transfers and then it started working. So at this point, I'm just kind of bringing this up because I've kind of hit a limit. I've gone through all the ESP32S2 examples and there, the IDF for it and can't see what's different in CircuitPython from what they're doing as to why this might be causing an issue when it is DMA versus non-DMA. The IDF is DMAing as well? Yeah, well, and the calls to it check if you set a DMA flag. And there's basically two lines different. If you call the DMA, it just sets it up versus just tells the low level call to copy it byte by byte otherwise. Right. Yeah, so it's one of these things that I'm not sure if it's better just to lower the frequency to avoid the glitches in the short term and just keep this issue open. Yeah, that's probably the best place to start. Yeah, I'm kind of at a loss. I'm gonna keep poking it a bit but short of trying to recreate it in a standalone application outside of CircuitPython, I'm not quite sure where else I could try to use Raspberry Pi. The Pico is a logic analyzer to see if I can get anything but I'm not really familiar with that sort of work. So. Yeah, I think this might be the sort of thing that maybe Jeff would be a good person to pick it up. Cause I think my intuition is to put a salient on it and compare it between the two, like figure out which byte's being corrupted. Yeah, and that's where I was kind of thinking yesterday and then I just lacked the equipment to go further. Yeah, cause DMA can have problems where like your code continued because the DMA said it was finished but the peripheral hadn't actually finished transmitting. Like that sort of stuff can happen. Whereas it, like the timing might be different for the like push each byte by itself. I wonder if that's actually the case cause like if you look at the push byte by byte code it's gonna have a thing that's saying like while it's not busy or if it's not busy transmitting then push a new byte, something like that. And it's possible that you want that check at the end of the DMA transmit as well. Yeah, it copies it into the hardware buffer byte by byte and the DMA just sets up the linked list descriptor for the DMA. Right. And then most of the rest is just checking like when you start it's just setting a hardware register to go. Right, but you're gonna block on the DMA finishing, right? Well, and it does block in the circuit in SPI.C. Right, but I wonder if it's blocking on, if it's blocking on the DMA finishing it may not be waiting long enough to let the peripheral finish transmitting the byte. The DMA is finished but the peripheral is not. Right, so maybe we actually need to wait for the DMA and then wait for the peripheral and then return. Like that might be a hunch. Like I had a similar problem on the RP2040 with the NeoPixels because like, oh, I buffered the next four bytes and the DMA's finished but I've got to wait for the PIO to chew through those four bytes before it's actually finished. Otherwise I like shut the peripheral off too early. Yeah, that makes sense. I can poke at it or again if Jeff's back when he wants to get the background just. Yeah, if you want to, but like you're totally in the weeds. Thank you for trying what I suggested and feel free to hand that off to Jeff. He'll be back tomorrow, so. Okay, sounds good. Yeah, thank you for doing that. No problem, it's interesting. I learned something new, so. Awesome. A lot of new things, but okay, thanks. Cool, all right, last up we have Dan. So I just, if anybody has some ideas about keyboards scanning and we're talking about different kinds of keys, anything with push buttons, not just typing or using keyboard or something. Right, key matrices. Key matrices, yeah. So let me know. I will ask Radimir also who's not on today, but we already, something already came up in the chat. Dan? Yeah. I'd be very interested in either observing or trying to help with this, cause I'm trying to put together a like a 61 keyboard for my multiple 61 key keyboards for my computerized organ. Okay, so if you have some ideas about other... I do have a couple ideas on how to scan eight by eight matrices. Yeah, so if you have some idea of what you'd like API to be then drop it in the chat is what I'm saying or... Sure, well, I'll drop it in and see what happens. I'll see what I come up with first. Okay. Thank you very much. Okay, thanks. I'll come up with something good whether I'm part of it or not. Okay. All right. Bye. Thanks. All right. Well, that's it. Let me take a time code for a wrap up. Thank you to everyone for joining us for this CircuitPython Weekly meeting. Reminder before I forget. Next week is not on Monday. Next week is on Tuesday. Big flashing red lights. Next week is not on Monday. Next week is not on Monday. Memorial Day. Yeah, Memorial Day here in the US. So we will be pushing it a day later. And I'm trying to find my notes. So this has been the CircuitPython Weekly meeting. Thank you to everyone who participated. Charles, can you mute please? If you wanna support Adafruit and CircuitPython and those of us that work on CircuitPython who are paid by Adafruit, consider purchasing 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 available on major podcast services. It will also be featured in the Python for Microcontrollers newsletter. Visit AdafruitDaily.com to subscribe. The next meeting will be held next Monday, or well, sorry, I'm auto reading this. That is not true. It's lies. The next meeting will be held next Tuesday at 2 p.m. Eastern 11 a.m. Pacific here on the Adafruit Discord server. You can join the Discord server by going to adafruit.id slash Discord. To be notified about the meeting and any changes to the time or day, you can ask to be added to the CircuitPython and Nisa's role on Discord. And with that, thank you everybody for hanging out. It's wonderful to hear all the cool stuff you're doing. And we'll see you next week on Tuesday. Tuesday, Tuesday, Tuesday. Thank you all and have a great weekend and week on the Discords. And for those of you in the U.S., I hope you have a good long holiday weekend as well. Thank you all. Thanks, everyone. Thanks.