 Hello, and welcome to the Circuit Python Weekly Meeting for March 15, 2021. This is the time of the week where we get to talk together about all things Circuit Python. My name is Scott, and I work for Adafruit on Circuit Python. Circuit Python is a version of Python designed to run on tiny inexpensive 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. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to the URL adafru.it.discord. We hold the meeting in the Circuit Python Text Channel and the Circuit Python Voice Channel. This meeting typically happens at Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with the U.S. Holiday. The meeting time is changed. We'll notify via Discord. If you wish to be notified about changes to the meeting, you can add you to the Circuit Pythonese's Discord role. There's also a calendar available that we try to keep updated if you'd like to subscribe to that. This meeting is recorded. We recorded the audio from the Voice Channel and video from the Text Channel. If you'd rather not have your voice recorded, you're still welcome to participate. The video of this meeting will be posted to YouTube and the audio is released as a podcast. If you find this podcast is not available on your favorite podcast service, please let us know. There's 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 notes document and we'll read them off during the meeting. The notes document also contains timestamps to go along with the video so you can use the doc to view only 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 note stock is posted in the Circuit Python Channel on the Adafruit Discord every week. Check the pin messages to find the latest note stock. The meeting is held in five parts. The first part is community news. This is a look at all things Circuit Python and Python on hardware in the community. It's a preview of our Python on microcontrollers newsletter. The second is the state of Circuit Python libraries in Blanca. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers and separate from what we're all up to and ground us in reality away from the way that we're feeling about things. 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 we were doing in the last week since the last meeting and what we'll be up to over the next week. The fifth part is in the weeds and final part. 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. That covers how the meeting will go. With that, I'll get started with community news after I take a timestamp. First up on community news, this is a preview of the Python for microcontrollers newsletter is Piper. I can't type and talk at the same time. Piper Make brings block programming to CircuitPython. Piper Learning is releasing a new product, Piper Make, which is a browser-based coding platform for the Raspberry Pi Pico. It has a block programming interface based on Google Blockly and the underlying code is CircuitPython. You can access the interface, which is similar to Make code at make.playpiper.com. Under the hood, there is a CircuitPython helper library. Piper has created a link there from GitHub. For more details, check out the Make article and YouTube. Next up in community news, the Adafruit Discord server surpasses 28,000 members. The Adafruit Discord community where we do all of our CircuitPython development in the open reached over 28,000 humans. Thank you. Adafruit believes Discord offers a unique way for CircuitPython folks to connect during the get today at the URL ADAFRU.IT slash Discord. This is where the meeting is happening and just a huge hug report to all the new folks and all the mods who help keep it the wonderful place that it is. Next up, we had a number of soft releases that we're highlighting in community news. First up, there's a new version of the CircuitPython bundle manager released including dependency detection on GitHub that is github.com slash unsigned Arduino slash CircuitPython dash bundle dash manager. Next up, the Raspberry Pi team is posting examples of using PIO to make common interfaces on the Raspberry Pi Pico. And that is happening in the Pico examples directory or repository under the PIO folder. And last up, the new editor team is testing version 1.10 beta 2 which is the first public beta. So check that out for me and thank you. I think foamy guy for posting all of those links. And just as a reminder, the CircuitPython weekly newsletter is a 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 under the github.com slash adafruit slash CircuitPython dash weekly dash newsletter repository. There's a you'll see a drafts folder there and submit a poll request. There's a link here to editing files in a repository with changes. You may also tag a tweet with CircuitPython on Twitter or email cpnews at adafruit.com and I just like to reiterate this is how we get content for the newsletter. So if you are seeing people doing cool things with Python, please, please, you know, email cpnews at adafruit.com with those links. We'd love to highlight them in the newsletter. Okay, and with that, let's continue on to the state of CircuitPython libraries in Blinka. This is an objective kind of statistics base view. Jeff points out self-promotion is totally legitimate to your project or your friend's projects. As long as they're related to Python, we'd love to see those in the newsletter too. So the state of CircuitPython libraries in Blinka is an objective view of the health of the project and these major sub-components of CircuitPython broadly. And it's geared towards giving us some like concrete things to base our feelings on how things are going with. So these numbers are kind of numbers we track week to week. But if folks do have ideas on new numbers that we should be tracking, please let us know. We'd love to evolve this or we're certainly open to evolving it. So overall, we had 73 pull requests merged from 22 different authors, which is really great. I'll just go through here for the folks that I don't recognize. So there's no code. Tom Aray, Cognitive Gears, Flavio Fernandez are all TWA 127, Alex Colello, Tesla K2 K20 are all names that I don't think we've seen before. So thanks to all the new folks and thanks to the total 22 authors. Nine reviewers. So thank you to all our reviewers. As always, we couldn't have this many authors without these many reviewers. So always we're looking for new reviewers. It's a great way to help us grow the community. Issues-wise, we had 36 closed issues by 12 people and 27 opens by 21 people. So we're net down nine, which is amazing. Thank you to everybody who's been helping knock out issues. And with that, let me go to the core statistics before we hand it over to other folks for the other two parts. On the core side, we had 11 pull requests merged from eight different authors. So thank you to those eight authors. We had four reviewers, so thank you to reviewers as well. We have 21 open pull requests where a number of them are growing in age. So again, as always, as I say every week, if you're involved in any of these pull requests or not and want to help us get through this backlog, we'd really appreciate it. We really do want to keep the number of open pull requests down. Either they could get picked up and finished or they can just be closed if people have lost interest in them. Issues-wise, in the core, we have three closed issues by two people and seven opens by six people. So we are net up four. For a total of 419 open issues, you can see all of the issues at github.com. The way that we keep track of how we're doing on issues, this number does tend to grow slowly, but we do want to prioritize how we take a look at those issues and what we worry about. We have a long-term category, by category I mean milestone, which is all the stuff that we would like to do at some point, but we have no priority to do urgently. And then we have three milestones related to six and we have a 7.0 milestone as well. We have four issues, not a milestone, so those will need to be triaged. And that's kind of the breakdown for where we are with issues. And with that, let's kick it over to Katnie for the stats on the libraries. Thanks, Scott. So this is across all of the Adafruit Circuit Python libraries and a few extras. So everything that starts with Adafruit underscore, CircuitPython underscore, and also the community bundle and our cookie cutter is covered here as well. We had 58 pull requests merged from 15 different authors and seven reviewers. Most of those were less than a week old, two of them were older. It's good to see that we are keeping up with both older ones, but also that we are keeping up with them as they come in as well, leaving us with 57 open pull requests. There were 31 issues closed by 12 people and 17 open by 13 people, which is excellent to see. And so that leaves us with 292 open issues. If you are interested in contributing to CircuitPython on the Python side of things, consider going to circuitpython.org slash contributing. You'll find all this information, open pull requests and open issues, as well as library infrastructure issues and how to translate or how to contribute translating to core CircuitPython. You can search the issues for a good first issue if that's where you're at and you're new to everything. Or if you're looking for something a little more complicated, bug or enhancement is also excellent. And if you're looking to start reviewing, you can go through the open pull requests and comment on them. Take a look at the code. If you have the hardware, test it. If you don't, let us know that you looked at the code. It looks good to you that you didn't test it. But any kind of review helps us. And that is an excellent way to start reviewing is to just leave a comment on an open PR. And that can build you up to actually joining our review team, which we're always looking for more folks to join the review team. Because as Scott may or may not have said, the more reviewers we have, the more authors we can support. So we had one new library. It looks like in the last week, the SSD 1680 and a number of updated libraries as well that I will not read off individually. But I will note that the community bundle saw an update. And that's been really great to see the community bundle in the list pretty regularly either for new libraries joining it or updates to current libraries that folks are developing. And that's where we are at the libraries. Awesome. Thank you, Catney. And next up, we're going to check in with maker Melissa about Blinka. Hello. Oh, hold on. Okay. I lost my tab for a second here. For Blinka, which is our circuit Python compatibility layer for Raspberry Pi and other single board computers this week, we had four pull requests merged by three authors and one reviewer. We had we have four open pull requests still, and there were two closed issues by one person and three open by three people leaving a net of 57 open issues that were 3,324 Pi PI downloads in last week and we are currently supporting 70 boards. Awesome. Thank you, Melissa. Yeah. Next up, we have hug reports. This is a chance for us to say thank you to folks for the work that they've been doing within the community and the wider world. It is done as around Robin's I will start and we'll go through the list. We did cover it. And if you want to if you are in the meeting and want to follow the along in the note stock, that's the easiest way to follow along. Anybody who's in the note stock or marked this and not in the meeting, not in the voice channel or marked as text only, I will read off. And as always, if you're unable to make the meeting but want to participate, you can also leave notes in the note stock as well. So let me take a time code. So for myself, I have to thank you to micro dev for setting up the issue templates. It's been awesome to see folks actually picking up and using those. Thank you to Luke W from Raspberry Pi for helping with some flash stuff on the RP 2040. Those are my two hug reports for this week. And now we've got to from v 923 Z who's not in the meeting so I'll read off a hug report to David cloud for a very interesting discussion on his thermal camera stuff and a group hug. We'll scroll up. And I've got notes from Brent. So Brent says group hug. And a hug report to J. Pasada 2020 20 and quirk timer for PRs into the circuit Python Jupyter kernel. One hug for the RP 2040 and one for inline magics that allows see Python code to be executed in the same notebook as circuit Python code. Really powerful stuff can already think about the applications of this. And with that, I've got another couple to read off. First from see Grover, we have a group hug to the team and the community. And from Charles. We have a group hug and happy Pi day. And with that we'll go to Dan. I'm eating it having a snack so hold on a second. Okay. Snacks are important. Yeah. I'd like to thank Gadgetoid who's working at Pimeroni. And we've had some back and forth about RP 2040. I to see which is the hardware peripheral on the chip was slightly peculiar and it works with some chips and not others and he is testing some things and I have contributed and we have some synergy going on here which is good. And then also in the I to see land I'd like to thank as Patrick W micro devins key East. Who tested my fix for ESP 32 s to I to see interaction bad interaction with Wi-Fi. And I think kind of together we're continuing to look at this to kind of understand like what the heck is going on here because the fix doesn't make that much sense from a coding point of view but it. It really does something at it. It's probably some code as I'll talk later that we can't see that's going bad. Okay. Thanks Dan. All right next up a couple more notes. So notes from day piece as a hug report to Tanute for his careful and patient reviews of my RP 2040 pulse I OPR. You're welcome. I thank you for doing that Dave. Next up from David. We have a hug report to maker Melissa for fast response times on further is 31 FL 3731 improvements. A hug report to be 923 Z for helping me with micro lab for thermal camera usage. A hug report to gadgetoid for discussion on circuit Python support for the breakout garden. A hug report to Jeff Epler for the feather RP 2040 RGB matrix guide just in time. And a hug report to just you for breaking the group limit in display IO. This is so last week hug report. Good to reiterate. And next up we have foamy guy. All right. Thanks Scott. This week I got hugs for K match 98 and David for helping out with the documentation for the display text library. Both of those folks did a bunch of great work to compile lots of the information that went into the new learn guide. So I really appreciate that. Also to K match 98 for working on a really nice dial gauge widget and as well for enhancing a new icon widget with an animation so you can click on it and get a little animated action. To Jay Posada 2020 Jose David for some great additions in display text, namely the ability to use the base alignment with anchored position. Also directional labels are really cool so we can have labels in different orientations now. And then the last one there for Jose David in this is for the new font added a new example font you can use in the examples. So thank you for all of those. Jeff E. Jeff Hepler last night. I think it was last night or the night before created a really cool enhancement in the core in bitmap tools and also inside of the bitmap font library that makes it quicker to load fonts again so another really nice speed up there. Thank you to Jeff and be and catney both for all their work on the newsletter and delivering you know a steady stream of really interesting Python news and projects every week. We got a taste earlier in the meeting but I also had a peek yesterday and saw that the newsletter is loaded up with all kinds of good stuff this week. And lastly to get a user Flavio Fernandez. They fixed a bug that I had actually introduced in display text when I was doing refactoring so thank you for that fix PR there. That's all for me. Awesome. Thank you for the guy. And next up is her effect. This past week. Thank you to Teo Mitch for their work on an implementation of audio PWM IO the STM 32 port. They did a great job of fitting that in nicely with the existing timer system. So I'm going to be trying that out today. Thanks for all the hard work on that. Thanks to micro dev and ask Patrick W for their continued work on trying to update the ESP IDF ESP 32 IDF, which seems like it's got some some annoying problems. So thanks for sticking with it. Thanks to Dan for finally tracking down that ESP 32 S2 bug, which sounds like I know that there were other people who were involved with that fix. And just hearing it described was like, right, yeah, that's it seemed like a team effort job to finally nail that thing. Thanks to Jason Mecham, who's tag is a lot of letters and numbers that are hard to pronounce for reporting a issue with the UR DNA on the STM 32, which has been hanging on for a long time. And thanks to you, Scott for reviews and approvals of my bug fixes this past week. And that's it for me. Thanks higher effect. Next up is Hugo. Should I read it off for you? Did I? Hugo says a hug reports Dan for the info on good places to check for computer purchases and for a hug report to cat me for a pleasant chat. And next up we have Jeff. Hello. First I want to give you a hug report for figuring out that flash reliability problem on the RP 2040 to cat me for helping me find the right page on learn when I can find the info I needed I assume she just has a list of every page in her head. To Jerry for testing some PRs. And we discussed some confusing aspects of how the RTC module works and to microdiver work on that code formatting PR which I was seeing in the chat we may be able to merge soon so that will be nice to have done. Yeah, it looks like there's two checks in progress on that. Next up is Jerry. Hello. Thanks to Jeff for fixing that RTC issue and explain to me how it's supposed to work. And group bug everybody. Thanks. Thanks Jerry. Thanks Jerry. All right. Next up we have Jose Debbie. Jose says hug reports for me guy for the excellent work in the display text guide. Hug report to quarter timer for working on executing Python native code in the Jupiter notebook circuit Python kernel this will allow users to use both in the same notebook. Hug reports Jerry and for helping me debug my RFM X feather. Hug reports Scott that always is always open to answer questions and other discord channels about circuit Python. Hug report to K match 98 for all the help and reviews and lastly hug reports Hugo for helping me understand GitHub and cherry picking. Next up is cat knee. So I have a hug report for Dylan for all of the work on adabot. We've been running patches and also adding features and updating current features and Dylan's been putting all the work in there. A hug report to summer soft for popping into help with some of the adabot updates to she in from the learn dev team. It's our internal team that works on the learn system for dealing with all the bugs I found in the new learn feature. For me guy for all the work on all the things to say K 9 1 7 on GitHub for picking up some older issues and beginning with good first issues. And to Hugo for adding another pre commit hook to cookie cutter to cover tests. Awesome. Thank you cat knee next up is K match 98. Thanks Scott. So first off filming guy for the new display text learn guide and also the addition of the new icon widget for the touch deck. Thanks to Jose David for a whole bunch of additions to display text. So thanks for sticking to it and working through the refactor as well. Thanks to warrior of wire for the vector IO library seems like an underutilized or at least I wasn't as aware of that library so it's got a huge capability for drawing polygons. Particularly if you want to move around a lot. It's a good, good addition. Next to maker Melissa for adding rotation to the matrix portal is something a user asked for in the in the discord chat. Thanks to jet blur for the new bitmap loading tool and for some warnings of how to use and what to watch out for on that. Thanks for that. And then finally, it's just been a wealth of discord members that are showing their matrix portal and mag tag projects are really cool. So thanks to everybody for sharing those. Thanks. Thanks K match. And next up is maker Melissa. Just want to give a group hug. Thank you, Melissa. And last up we have notes from micro dev. Who says a group hug. Hard reports Dan H for looking into the ESP 32 s to I squared C issue and to jet blur for solving my code formatting PR issues. With that, that's hug reports. Thank you all. Next up we have another round Robin, but this time it's status updates. Status updates is a chance for us to talk about what we've been working on in the past week and what we plan on working on in the coming week. It's a great way for us to have a feeling for what all is going on and also to collaborate across projects of folks have related info between folks or between what they've been doing what somebody's doing now. And I'm scrolling down so I will start. So for myself. Last week I did further flash work, including I need to check this in but there is a tabulate. I added a tabulate function to cascade Tom all which will allows me to have a spreadsheet of all the flash settings for everything. So it's really great for seeing like understanding commonalities amongst flashes. And then the the end of the week was debugging that the unreliability of flash on the feather RP 2040 turned out we were just running it too fast, but it took some. It's it's not obvious that that's the problem. This week I'll focus on the sea version of the Q spy knit and should be able to make a pretty versatile version that we'll use for hopefully a lot of the upcoming eight of reports and also allow us to switch chips. Which will be cool and then I also have to check that in the Pico SDK to make sure that we're we're working well in Pico SDK as well. Next up I have notes from v923z who says added functions to micro lab to interface with peripheral devices producing 32 bit integers. Which sounds very interesting and intriguing. And then circling back we've got notes from Brent. So Brent says got to work with the Pico of it and the Pico feather wrote a quick start guide for adding Wi-Fi to the circuit Python RP 2040 projects. Briefly gets you started with sending RP 2040 data with HTTP and MQTT and mostly working on non circuit Python projects with some circuit Python sprinkled here and there. Next up are notes from see Grover who says last week submitted the PR to include a setable brushed DC motor recirculation current mode parameter for the Adafruit circuit Python motor dot motor library. Learn a bit more about pilot in the process start starting work on the learning learning guide rewrite in anticipation of the PR merge. This week will address converting raw measurements to Lux and UVI for the LTR 390 true UV sensor plans are to update the sporting library spot of the stem a DRV 8830 voltage regular motor controller in the wild on Lady it is desk excited to get my hands on one for testing unrelated after months of downsizing the commercial side of the reporting studio is now officially closed. Not sure how the space will be reconfigured just yet but it will certainly involve multiple strings of neopixels and the underutilized eCorns recliner. Probably really butchered the name of the recliner but that's okay. And next up we have Dan. Okay. In beta three we introduced a second USB serial channel which is very useful but it also means that all the boards now show up with like two comports or two dev TTY ports, which is confusing and some people had scripts that shows one of those. To determine which was the rebel port and they weren't necessarily in the same order all the time and so we've turned that feature off. Now, it's still there if you want to build it but it's not on by default. And in seven, and as we get new and other things up to speed and will probably may turn it back on, or we may make it be able to turn it back on at runtime in boot dot pie, which would be kind of the right thing to do. Because of this problem, I started working on a simple library, which uses pie serial to be able to identify which port is which you can because they actually, they're, they're tagged with descriptor names, though they're not so easy to get to sometimes. And I'm going to submit a PR to mu to be able to use will use this library to be able to identify which channel is the rebel channel. And then finally, another big thing was, and another big thing but a big thing was that after a lot of Harry like divide and conquer work I like narrow down ESP I to see Wi Fi interaction problem. To a particular place in ESP IDF in the I to see driver, and I changed way it does something when it deallocate some storage, and now it works. It's not really clear why this change works. Because the old way isn't obviously wrong, but there's something really peculiar and I tried to debug further down and I ended up getting stuck at a brick wall because part of the though a lot of the ESP IDF is open source. There are some critical parts, like the Wi Fi stack that are closed source. And so it's a binary blob and I, I looked at the disassembled source but it didn't get anywhere with that. So we'll probably report this bug up the chain and say here's what the fix is, and then see whether we can get ESP folks to work on it. Okay. Awesome. Thanks, Dan. All right, next up we have notes from David cloud who says text scrolling demo for Michael Horn on his 11 by seven matrix breakout plus fix the why access mirror after he tested my code on the hardware. Driver and simple test for the five by five RGB matrix untested because they don't have the hardware linked to the Twitter status there. MagTag plus SCD 30 to display CO2. I did not wait find a way to power off the sensor during sleep on the fat on Pico with the zero form factor. Googly eyes on scroll fat HD thermal camera MLX plus my pie mini TFT. These are there's all Twitter links here. I folks want to check the notes talk for that zero segment which is a max seven to one nine plus eight seven segments plus two buttons Accelerated thermal camera with micro lab seat in the weeds got my feather RP 2040 funny slash sad non circuit by the news got a vaccine shot. Unfortunately, only tetanus because I walked on two nails. Well, I hope I hope that's okay. Hope your foot's okay after doing that, David. And next up is foamy guy. Alrighty, thanks Scott. For last week I finished up the display text guide and that got published on think Monday or Tuesday last week. The I began work on a touch deck project in collaboration with JP, and I finished up the refactoring in display text and that got merged and then I got through a bunch of the reviews of PRs that were waiting on that refactoring. And this week I will be tonight I got my got my three and a half inch feather wing in the mail today so I'll be converting the touch that code tonight to work with feather RP 2040 in the feather wing. I am going to try to make a configuration layer for pie charm with helpful get commands inside that a little macro screen, a little macro touch screen there and then also this week I want to print one of the enclosures for it once that is created and available. Other stuff this week I'll be finishing up a last couple few reviews on display text and display layout. I will be I have an idea for a game that I think I'm going to work on an Easter themed game so you're going to play a bunny and you'll wander around and you have to try to find eggs and you have to eat carrots to get energy and then when you run out of energy. That will be the end of the level it will count up your eggs and you go to the high score and stuff so I'll work on that maybe starting out this week and then the last thing is, I noticed there was no library. I don't think I took only a quick glance so maybe I just missed it but I didn't see a helper library for the three and a half inch feather wing. If that's the case that there actually is not one that I might make that this week and add it to the feather wing helper library. That's all I got. Thanks. Awesome. Thanks for me guy. Next up is Hierophact. Cardi. Chrome please. Scroll down. Last week I've had a couple of weeks so I'm a little bit behind on my STM32 power stuff but that has been my continuing focus. It's mostly done. I've just got some deep sleep interrupt stuff that has been really kind of slowing things down so I'm going to keep cracking at today but I'm also trying to just make myself available on other stuff. I fixed some minor bugs like a DNA problem with UART on the STM32 and an update to the STM32F4 discovery board which can do everything the STM32F405 feather can since they have the same silicon but just need some copy pasting to bring it back up to speed. And I also do a little bit of research. We've been having a discussion on one of the issues about overclocking and clock options in circuit Python and whether those should be able to be dynamically changed either actually during runtime or at least during soft reboots so that you can get better power performance or lower noise or do overclocking for just higher speeds. So I did a little bit of looking into how that might work for the chips in our various ports. This week I'm going to be testing the new audio PWM IO PR that has come in. I'm going to try and nail this deep sleep stuff finally. I got some notes on low power consumption so that you can compare chips from different ports on how their power consumption during deep sleep and light sleep looks like. I'm going to try and at least bundle RTC in with any of the deep sleep stuff that comes in since it's like two functions and it's basically done already so virtually no effort. And then I'm generally available for other stuff that's coming in. I've had some stuff added to my to-do list so we'll see what happens with that and that's it for me. Awesome. Thanks, higher effect. Next up is Hugo. All right, I hope I can be heard. Yep, sounds good. So last week I got some progress bar code refactored to piece the pilot duplicate code rule that basically singled me out for the work I did previously and started looking to be actually she really did maps on the line guy. This week, I'm fishing the refactor and looking into the crash issues some more and eventually learn how to deal with this score. Awesome. Thanks Hugo. Next up is Jeff. Hello, I went over and started reviewing that PR. But so I'll get back to my notes here. So last week I wrote a new guide on circuit sculpture, which is live on the 80 fruit line system. I enabled MP3 playback on the RP 2040 but only extremely low bit rate files work. The MP3 library that we use assumes that there are some efficient instructions for particularly multiplying 232 bit numbers to get a 64 bit number. And that turns into a sequence of about 25 instructions on the Cortex M0 of RP 2040. And that's not good enough. So, fix the bug with the RTC on the RP 2040 reverted a space saving commit. But we may need to reevaluate it now that we better understand the flash problems we were having on RP 2040. There's a flag for whether multi partition flash devices are supported and we don't use it. I put in a pull request to save I forget it was 160 bytes or something by disabling it in the midst of that I had it fail. I had it make storage be lost on one of my RP 2040 boards or storage database file system didn't work or something so we reverted it but maybe we should put that back in. Last week I ran the meeting I had put in a bug for certain PCF font. It didn't read write with our font reader library that was merged and I updated the RGB matrix guide with a new page for the RP 2040, including a new scroller which says RP 2040 feather on top of the Raspberry Pi logo. What's nice about the feather is you can use the feather wing that's designed for the Sandy 51 the feather and four and that works just fine and dandy. So if you have that combo of hardware check it out it's an easy way to do the Pico and the matrix together and there's plenty of RAM so that's always good when you're doing matrix stuff anyway this week. I haven't written down to see if audio mixer can be enabled on RP 2040 but I think we're going to punt that for myself. I want to add to the RP to PIO module the ability to choose the pin that is used by the jump pin instruction. I'm going to test I2S out for the Pico slash RP 2040 and it looks like the next after that is starting on some IMX stuff in particular starting with just getting a handle on how the built in USB bootloader works on the IMX 1011 microcontroller which I have a And as for fun stuff I've continued working on my WWVB clock it was daylight saving time change this weekend so of course there is a daylight saving time bug. I tried to fix it but I can test it next year and I'll also be moving that from a matrix portal to a feather RP 2040 feather a feather RP 2040 and the reason that will be better than the matrix portal is the feather has a crystal. And so when the time when when the locally tracked time stays closer to the true time its ability to read the WWVB signal is improved so that will kind of help make it work better. That's what I'm up to. All right next up is Jerry. Hello. Let's see. So mostly I can't remember what I did last week but I had fun playing with all my toys. One thing I did come across and I've been just trying it periodically whenever new kernel updates come out for the pie. So I know there's been an ongoing problem with the ITFT kernel and the brain craft hat. And finally this week when I just tried it it all worked. So maybe you're maybe it's all better now. At least it worked for me and the same load I can I can run my EMG 8833 thermal camera or play with the brain craft hat using the TensorFlow stuff without breaking the display. So that's the big improvement. And next week I'll probably do the same stuff. I do want to hope to add that I was playing with Dan's library for the oh why WS deal 3 MCC the media little thermometer and marveling at how simple his library is to read the temperature humidity data out of it. So I thought well gee I wonder if I can get the battery monitor out of that. And add that maybe I'll find out why why it isn't there. But it's been fun to delve into and all it's taught me is just how much I how little I understand about how all the BLista works anyway so good to play with. And then there's some stuff going on with the fingerprint library there was some additions put in week or two ago for a new sensor to add some stuff that doesn't work with some of the old sensors so I don't hope trying to straighten that out again. Awesome. Thank you Jerry. Next up we have notes from Jose David, who says last week PR adding a solution for K three walls for the ice grid sea peripheral Sandy 51 corrections in the control sea bit draft PR for the feather RP 2040 ice grid sea peripheral corrections for the PRs for display text PR for directional label, exploring how to port encoding polylines to circuit python PR for label styles and some PR for core documentation. This week work on on the comments from Scott on ice grid sea peripheral review and corrections of core documentation read the docs related issue three to one, which is a really old issue corrections on feedback for directional label and if decided path to take work in the style library. And next up is catney. Alright, so last week had Hugo update the cookie cutter to include a new pre commit to run pilot on the test directory similarly to how examples is run. So that we can avoid the duplicate code issue on the tests directory as well. And I also I guess I didn't put this in there but had Dylan add that to. At least I think he did anyway I asked I told him to find out what other libraries had test directories I don't know if he followed through with adding the hook or not. But we looked into that as well. Random note I updated the fritzing app to the latest version and so far haven't run into any issues. Noting because I think the last release was three or four years ago. So it's kind of a big deal that they did another release. I added a reverse look up quote unquote pinouts list to the feather RP 2040 pinouts page so the pins are now listed both by pin name equals functionality and then also pin function equals pin names. So if you are looking to see what pin five does, you know what D five does you can look for D five and find out what it does but if you're looking to find out what pin support SPI, you can look at what what pin support what SPI and then find out the pin names that way. Updated the AMG 8833 guide for the Stem and QT revision. Worked with and further on interim taking over the newsletter. Wrote the first template in the learn system with the new templating feature. The first template is blank using the D 13 LED found a ton of bugs with the new templating feature and learn, which is what led to my hug report for learned dev dealing with everything I found. And the other miscellaneous stuff I'm sure I'm forgetting so this week. I already had this chat with Brent about getting date time passing pilot. This was from a previous discussion in this meeting. The tests are failing miserably but they're based on CPython and so we're not going to redo them all. So I talked to Brent about adding the global pilot disables to those files to get that passing and that is now on Brent's radar. Continue on the template creation mission. The eventual plan is to ostensibly recreate the circuit Python essentials guide with templates. So instead of mirroring the essentials guide into every board guide, every board guide will have its own tailored pages. So we're not dealing with, you know, but my board looks different or there's no LED or whatever other feedback is constantly coming up because the essentials guide was written to be generally applicable, not specifically applicable. So that's kind of what the point of this template engine is, is to be able to create as much content as possible so that the least amount of effort has to go into putting it into a guide. But for example, blinking an external LED might have a template and there will be space for you to put a wiring diagram for that particular board and maybe the code based on what pin you use. And then the rest of it would be done, something like that. So that's going to take a lot of time, at least initially we're working backwards on the boards in terms of when they were released. But that's going to happen over time, but hopefully all future board guides will have this to begin with. We had a very polite request to add information to the clue guide about information on the debug pins. So I'll be doing that sometime this week. Eventually going to be doing the new products process for the new cyber deck, which was recently released. Just need to put together files and put out the PCB files and that sort of thing for it. And need to finish up the MIDI feather wing guide. However, it turns out I already did it a while ago. So that was convenient. So I need to review it and get it to a little more for her to look at. But it turns out I actually already did that. So passed me. Thanks. Hug report passed me. Yes. And that's what I'm up to. It's good when it works out that way rather than the reverse. Pretty much. Awesome. Thank you, Kenny. Next up is K match. Thanks. So this week I added a couple of basic features to the bitmap tools to allow painting, either rectangular regions or lines into existing bitmaps. I helped with filming guys icon widget added a little animation. So it gets some feedback when you press press the widget. And then I updated my dial widget so it's it's maybe suitable for others to use and give it more flexibility than my original and did. And I submitted that this week. I hope to wrap up the widgets I had had in mind and get those submitted. One is an annotation where you can draw lines and arrows and text on a widget or on the screen. And then another input where you can flip through different inputs and hope to get those submitted. Once that's done, I hope to get an example with all the cool new widgets that are that are in there now to highlight what their capabilities are. Thanks. Awesome. Thank you, K match. Next up is maker Melissa. Hello. So last week I wrote a circuit Python driver for the SSD 1680. I updated the circuit Python EPD library to add the SSD 1680 as well. I wrote a 2.13 inch EPD or e paper display guide. I created a pull request for the RP lidar to add additional functionality, but I need to update it some more because it's not working on the very latest firmware. I need to look into an issue where a user or I looked into an issue where users have in trouble updating the Wi-Fi coprocessor firmware and help them with that. I fixed an issue with the 2.7 inch e paper display in Arduino where the red and black were swapped. This week I am just working on some miscellaneous have issues, possibly starting a 2.9 inch eating guide. I need to be gathering pages from existing guides, making them look more uniform. And probably work on the RP lidar library a bit more. That's it. Awesome. Thank you, Melissa. And last up we have notes from microdav who says, did some ESP 32 s to I squared C work and IDF update work added code formatting and translation checks to pre-commit. And just a heads up for anybody who's working in the core, the PR for the code formatting and the translation checks was just merged. So it's likely that if you have any pending code for the core that you're going to have to rerun the formatting on it, although it was added to pre-commit so maybe it will do it automatically. But just be aware that that's happening. And the reason that we're doing it is because MicroPython adopted a standard C formatting after we had previously merged. So this is a kind of precursor to getting us updated to newer MicroPython. So it's a great thing. Code formatting is the way to go. And a huge hub report to microdav for taking that work on. And yeah, microdav says having pre-commit is highly recommended. So if you haven't done that yet, now is a great time to do it. And lastly, last up we have in the weeds here. Thank you everybody for status updates. In the weeds is a chance for us to just have any sort of longer form discussion as we need it. And if you have any topics, there are a few here already. So if you do have some more, go ahead and add them down along with your name. But for now, we will hear from you guys already getting ready. So we'll kick it over to FOMI guy for the first topic here. So this came out of a discussion on a PR for display text is kind of where we started. But the core idea was kind of adding themes or styles. So kind of a bunch of presets of different colors that look good together. And then creating a way to make it easy for folks to kind of apply those themes or styles onto their labels. So I was thinking about it a little bit and I talked with Jose a little bit over my stream, we were talking about it. And my idea was maybe it might be good to create a new library, like a new color helper library, which could contain things like helper functions for converting between numeric hex, tuples and string hex. Also, maybe helper functions for manipulating colors like lighten and darken by a certain amount. And then this library would also hold all of those theme definitions that I talked about. So kind of like sets of colors that look good together and names given to them as well so that you can easily import those themes and then apply them onto display objects. We'd need some work done to update those objects in order to support it. But the core question is like, do we want a color helper library like that as its own repo? Or would we want to include stuff like that in with the existing libraries kind of scattered out through all the display IO stuff? I think given that it would apply to multiple libraries, it should be its own. Otherwise, you're going to have folks who want to use it in one place importing, for example, display text. Simply to apply the colors to their something else. So I think it would work best as a separate library. Plus, it sounds like something that could end up kind of big. And I feel like trying to shoehorn it into another library while it might work right now, it's not scalable. I agree with Katnie on having it as a separate library. The thing I would also add is there's kind of this already with fancy LED. It at least does HSV and RGB conversion. And then at some point, I think somebody added a color sys module library, if I remember right, which is the C Python version that does a lot of this. So I agree with Katnie that having a separate library for all this stuff is good, but I would take a look at those two things, color sys and fancy LED, as a make sure that you don't overlap with those things. So if things that color sys does, it would be better to just do color sys, and then C Python, it applies to C Python as well. And then there's also the fancy LED side as well. So just take, like, yes, you're on the right track, but take a look at those two things as well. Okay, yeah, I'm not familiar with those, so I'll definitely check them out. As an unrelated but related thing, that C Python library needs to be refactored because it already has two .py files in root, which doesn't work, and we don't have this in the bundle right now because of the fact that it's kind of ad hoc and we didn't really do a whole lot with it. So if it's something that you think you might be using, I would greatly appreciate a possible refactor in just getting that sort of maybe bundle ready so that way you've got it available. Yes, I had not seen this C Python library before, so if you're seeing this, but yeah, I can refactor that. I think it looks like it just needs to have a module or whatever, a folder. Package, yeah. Excellent. I wonder if that's the best way to do it or whether we should just have two libraries because I think there's only two things in there, right? Yeah. I plan to add more. Yeah, but people haven't. So I guess what I'm thinking instead is... I understand, but... So the reason that... If you add a package, it means that it will be imported differently than the native C Python one is. And that's why it's weird that it's at the top level right now is that it's meant so that you can just use about them the same. I guess my suggestion would be don't refactor it, but fix the workflow in this one. It'll mean we can't patch this library, but it's one library out of many. I think we could just put it into two libraries as well. We could just have an Adafruit, CircuitPython, C Python, Colorsys library and whatever the other thing in there is. It looks like there is not... The other file that's there is the one with the Adafruit name, but it has pretty much just the basic template. There's no actual code in it, it looks like. Okay. Yeah. So why don't we... We could just rename this to be Colorsys specific. It's actually... Didn't you find something a few weeks ago where you can import inside the init to basically expose the original class name? I did, yeah, that was on... That was in... Well, it was for the progress bar, actually. I think that you were working on... I think that's where we found that, but I don't know if it would help us on this one because we're trying to match the C Python import, which is just import Colorsys. I guess though... Well, okay. It would work if this was made into the Colorsys library and not C Python library. I guess that could work, because then it would change the name there. But if this is going to get renamed, then if it's only going to have the one thing, I think we might not run into that issue. I mean, if it could work the same way as in C Python, this means all of the working code from Pimaroni for the Raspberry Pi, MCU, or single board computer would work directly in circuit Python. Yeah, that would be great. Yeah, that'd be awesome. Yeah, David, it sounds like you have ideas of example code. So I would suggest linking, considering that as well, because it probably uses a subset of the full API, so it would be good to know what that subset was. Yeah. So my suggestion then would be, because I'm looking, there's no examples in this. The example is empty. So we still need to do some stuff to get this bundle ready. Yeah. But I think if, like I said, if it's something you're going to be referring to or using elsewhere, it probably should be part of the bundle. So I'll file a quick issue, just stating we need to do some extras to get this bundle ready and I will tag you on it if that's okay. Yeah, definitely. All right, excellent. And then I guess a little bit further down the line, so we can move kind of the helper stuff into color sys. Would we also want this to contain like the themes and styles, those things to import? No, the color sys should only be whatever C Python has. Yeah. So do whatever you want to do that color sys can already do for you and just expand this for the circuit Python case. But it's still totally okay to have like a theme library, a separate theme library would be totally fine. Okay, cool. All right. I think that covers it for this first one here. Awesome. Thank you, FOMI guy and also Jose David who's listed here as well. Next up we have info from David Glaude and V923Z. Maybe I can start with easy stuff and then you can do the math. Okay. So I did the thermal camera stuff and in there I need to find the min and max and do a little bit of math on 768 real number, I guess. And I figured out that I could go much faster with ULA, which is obvious, but okay, when you never try, you don't know. Right. But one thing is that I need to take the data from the MLX library and that provide me an array and then I need to convert that to ULAB and then I do my processing and then I need to convert it back to display IO bitmap to be able to display. And we figured out that if there was a faster way to copy into bitmap that would be great. And that's the end of my story. Yeah, I agree with you. I'm totally okay if we added something to bitmap or just micro lab handling to bitmap. Is V923Z present? Yeah. They were on earlier, but I don't know if they are voice. He was touched by the time chain. So what I figure out... Looks like Discord's having problems for him. So then I did try to find out where it was slow and I figured out that in MLX90, blah, blah, blah library, there is a lot of math and maybe this library could use ULAB to be super fast. Right. That's very specific issue to that library which is less interesting. But those copy and paste from one buffer to another buffer, this is likely taking some time. And there is a piece of code where I show you the fastest way I could copy from a ULAB array of int into the bitmap which is palette bitmap or whatever it is. If you have a faster way, I can take it. But this is not where I'm losing time. Yeah. The only thing I can think of is if bitmap allows for a slice assignment. But I don't remember off the top of my head. I don't think that it does. So kind of my first impulse would be can we add it to the new bitmap tools because adding code on M0 boards and some M0 boards have display IO is a bit icy these days. Especially if the bitmap tools read into is going to be something that we accept, I think that would be the place to put this. I have anything that conforms to the array protocol and I have a bitmap and I want to put a sub rectangle. Right. Yeah, I think it's essentially blitting, right? Yeah, it is. But right now the only kind of source we support is a bitmap. So it's basically adding a source as an array to the existing blit. Yeah, maybe that's a better way to put it. Yeah. Yep. The only question is who would like to try doing that? And is it a U-lap stuff or is it a bitmap stuff? This code would go in the core of CircuitPython in the bitmap tools module. And it would work with anything that in terms of C that you can call an MP getBuffer so that you can treat it as just an array of memory in the C code. Yeah. So folks who are just listening, v923z says in the chat, which other objects could benefit from adding the buffer protocol? I can help with that. And we also have microlab.array.2bytes, which is a buffer. Yeah. So I think you would want a U-lab array that was a U16 type so that value 0 or maybe a U8 type where value 0 represents pallet index 0 and value 1 represents pallet index 1 and so forth. Right. And whether you call 2 bytes or whether you just rely on the fact that microlab arrays do act like arrays now in terms of this function that we're talking about, that's the thing where we made sure that they could be used with memory view recently, if you remember that, Zoltan. So yeah, the complexity of doing it in the core, I don't want to say, you know, if you're new at C, you can pick it up, but I think it's not so hard that you shouldn't think of giving it a try, whoever you are. If you're listening, think of giving it a try. Yeah. So David, I think for you, filing an issue would be really good. And then that's where we can drop all these hints about how to do it that I've just talked about. OK, that's my level. Yeah. Well, I mean, that's a good place to start. So it's totally good to say, like, oh, it would go in bitmap tools, it would be part of Blit, and Blit would be able to just handle inputs from microlab. Or more broadly, just the underlying buffer stuff from Microbython, or from Microbython generally. OK. Yeah. And v923c also says, I'm also open to adding tools on my side, but I don't think in this case you need to. I think it's a matter of Circuitbython being better about sharing memory or copying memory quickly from one place to another. We should also add letting a bitmap be at least a read-only memory viewable object, which would ease getting information in the other direction into microlab from a bitmap. Yeah. Yeah, I mean, the challenge with just interfacing with bitmap is that it does subbit packing or a subbyte packing. Yeah, if it's not an 8-bit bitmap or 16-bit bitmap, then you'll have some work to do. But at least we could make it memory viewable. And then you would select, if you need to go back and forth like this, you would select an 8-bit or a 16-bit format in memory. Right. And as we get chips that have more RAM, it's more doble. Yeah, bitmap stuff is so great on the RP2040. It's luxurious. Yep. OK. So I think we have a plan on how to get this going forwards, which is David will create an issue with this super helpful and then we'll also add some tips about where and how things should be done to that issue. And hopefully somebody will pick it up. OK. We have one more small thing in the weeds from V923Z, which should be super quick to address. So V923Z asks in the note stock, the MicroPython repository is not searchable. Can anything be done about that? And this is largely a function of being a fork from MicroPython, which is a GitHub thing for some reason. And I don't know why it's a constraint on their end. Has anybody looked into this to understand it more? It's just something that they don't do. And I don't understand their technical reasons for it. I suppose that they have to have one index for each project. And by eliminating all the forks, they have less indexing to do. If you don't, if you aren't conversant with using GitGrep, I really recommend it. I mean, it can search through the whole code base of CircuitPython before you blink. It's local. So it has different tradeoffs compared to searching online. And that's only directed at searching the source, not like commit messages and issues. Those have their own different searches on GitHub. And they work on GitHub. I'm not sure about searching, like searching for a commit, which has a particular word in the commit message. I'm not sure if GitHub does that. But for searching within the code, GitGrep is a really, really great tool. And I'm sure that there is like a graphical front end on it. That's what I would try since we're not going to change GitHub, unfortunately. Yeah. I mean, personally, I just searched locally. There is another option we could consider. And Notro actually set this up a while back, which was having a separate site that does search and cross-linking. So that's an option as well. There are open source projects, I believe, for doing just code search. And that's something that we could look at if we really wanted to. But yeah, I generally just do it in my local clone. So GitGrep is a sub of Git. So that's just a... Oh, and I guess that, Jeff, that includes commit messages then. That's what you're saying. No, GitGrep only searches the content of files. There's a way to run local searches on commit history. There's a flag to Git log. And then that's used by the GUI visualizers such as GitK, which can be really handy as well. So you can also use it to search for commits, which changed a string and a file versus in a commit message, which is much slower. There are a lot of really awesome local Git search things you can do. And skilling up on them is definitely going to pay off. Recommend, recommend, recommend. So what is your argument for doing that versus what I'm doing, which is just searching the currently checked out source? You mean of using GitGrep? Yeah. What command do you use to search? Just Silver Searcher, AG. I mean, I think AG has some knowledge of Git built in. What is nice about GitGrep for me is compared to regular Grep. I've never used Silver Searcher compared to regular Grep. Regular Grep goes into sub modules, which can be good or bad. It also goes into the .git folders. And sometimes it'll say, oh, your match is in this binary file. Right. And GitGrep doesn't do any of those things. On the other hand, sometimes you do want to find something and you don't know which sub module it's in. GitGrep does not help you. There's not a GitGrep and do all the sub modules. And that can be frustrating. Right. So the Silver Searcher is Git aware. So it knows not to do the Git directory. And then it also will ignore stuff and Git ignore. That's super handy then. Does it look in sub modules? It does, yeah. Oh, okay. I'm going to install that right now. And the other reason it's better than Grep is that it's multi-core. So it's real quick. Yeah. I think once you are looking at all those sub modules, that may become relevant. When you're looking just in circuit Python, but I noticed how long it takes. But yeah, for those situations, it's going to make a difference. Yeah. So v923z says, searching locally hinders over the web collaboration. I can't just send a link to someone else. Yeah. Yes, that's the one. Yeah. I understand that. I mean, I'm kind of old school in the sense of like, I'm totally okay to like search it locally and then pull it up on the web. I need to find a particular spot. But I'm also known for not using the best tools for the job sometime. So yeah, I would say like if you really do want like a way to send people a link to search results in circuit Python, I think the way that we would have to go is, well, for one, people, this is a known issue with GitHub. And at some point they're going to do it hopefully. But then also like there are other options. Like I said, like no true had sent set something up that did searching and like automatically updated the indexes when pushes were done and stuff. So like there's probably solutions out there that we could do as a separate place to do all the code search stuff. But really, honestly, it's not high on my priority. So we would have to figure that out. So yeah, no good, not really, no great answers. Sorry. Bug, bug GitHub as well. Okay. And with that, let's wrap up. This has been the circuit by the weekly meeting for March 15, 2021. Thank you everyone for taking the time to hang out with us. I'm going to scroll down to the bottom and make sure I don't forget to say anything. If you want to support Adafruit and circuit Python and those of us who work on circuit Python who are sponsored by Adafruit, considered purchasing from the Adafruit shop at Adafruit.com. The video this meeting will be released on YouTube at YouTube.com slash Adafruit and the podcast will be available on major podcast services after that. It will also be featured in the Python for microcontrollers newsletter. Visit AdafruitDaily.com to subscribe. Check the Python for microcontrollers newsletter there. The next meeting, let's see, I'm just double checking that it's on Monday. Yep. So the next meeting will be next Monday as usual at 2 p.m. Eastern 11 a.m. Pacific. And just like today, if you're outside the U.S., be aware that I believe the rest of the world will not have done Daylight Savings yet. So just double check the time again to make sure that you understand what it will be. If you would like to be notified about the meeting or speak during the meeting, you can be asked to be added to the Circuit Pythonistas role on Discord. That's where we mentioned when the schedule and stuff is. There's also a calendar that should be able to do this as well. This meeting was held on the Adafruit Discord server, which anybody can join by going to adafruit.ru.id slash Discord. And we hope to see you all next week. Thanks, everyone, and keep making Circuit Python and the community great. See you next week. Thanks, everyone. Thank you, Scott, for running the meeting. Thanks a lot.