 Hello everyone! This is the CircuitPython Weekly for February 14th, 2022. This is the time of the week where we get together to talk all things CircuitPython. I'm Scott, and I'm sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to support them and CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join any time by going to the URL adafru.it.discord. We hold the meeting in the CircuitPython Dev Text Channel and the CircuitPython Voice Channel. This meeting typically happens on Mondays at 2pm Eastern, 11am Pacific, except when it coincides with the US holiday. In the Note Stock, there's a link to a calendar you can view online or add to your favorite calendar app. We also send notifications about upcoming meetings via Discord. If you'd like to receive these notifications, ask us to add you to the CircuitPythonDista's Discord role. I should note that next week is on Tuesday. Next week is 24 hours later than normal because it is President's Day here in the US. So just double checking that that's true. So next week, the meeting will be on the 22nd, not on the 21st. So I will try to make that clear and all the stuff that we're doing as well. But just adds up the meetings a day, 24 hours later than normal next week. Okay, there is a Note Stock to accompany the meeting and the recording. The Notes document contains timestamps to go along with the video, so it 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. After each meeting, we post a link for the next meeting's notes in the CircuitPythonDev channel on the Adafruit Discord. Check the pinned messages to find the latest Note Stock so you can add your notes for the following meeting. If you wish to participate but cannot attend, you can leave hug reports and status updates in the document for us to read during the meeting. This meeting is held in five parts. The first is community news. This is a look at all things CircuitPython and Python on hardware in the community. It's a preview of our Python on microcontrollers newsletter. The second part is the state of CircuitPython 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. It takes a couple of minutes. So 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 of status updates or be something you've identified ahead of time is too long for status updates. And that covers how the meeting will go. And I'll move on to the first section and take a time code and get this show on the road. So first up, this is community news. This is a chance for us to talk about all things CircuitPython. Oh, CircuitPython, MicroPython, and Python on hardware. Thank you to Ann for putting these together and whoever accidentally deleted stuff and undid it. Thank you for that as well. Okay. So the first thing we have here is 500 Adafruit projects have been certified products have been certified by the open source at certified as open source by the open source hardware association, Oshawa. Adafruit is an open source hardware and software company. To that end, Adafruit has been working to submit many of their boards for certification by the open source hardware association. According to Oshawa, the certification program exists to make it easy for creators and users to identify hardware that follows the community definition of open source hardware maintained by Oshawa. Hardware projects that display the certification logo are licensed and documented in a way that makes it easy for users to use and build upon them. So on February 7th, Adafruit hit the milestone of 500 certified projects and was the first to reach this number. By registering their boards with Oshawa, Adafruit aims to ensure that users ensure users that products they sell are open source and easy to learn about. Adafruit extends a special thank you to everyone who made this possible but especially the wonderful folks over at Oshawa who set this all up and were incredibly helpful throughout this process. Additionally, they thank the community that keeps this all going and encourages them to publish, share, and more. And thanks to FOMI-I for putting a link in. Next up, CircuitPython. Let me take a timecode. This is my first set of timecodes I've taken where I don't have the number keys labels. I'm working on that. Okay, so CircuitPython 7.2.0, Alpha2 was released. It was released this past week. It's the second published Alpha release for 7.2. It is relatively stable but there will be further additions and fixes before final release. Notable additions to 7.2 since 7.1 are continued work on the Raspberry Pi Broadcom board support, support for the ESP32-S3 and C3 including some Bailey, RP2040-PIO optional side set support, the addition of the Stema I2C board singleton constructor which is available on every board that has Stema connectors. Bineski CRC32 is added and VectorIO has a dot contains now as well. So those are some highlights. Next we have the Raspberry Pi Beta Test Network Install of Raspberry Pi OS. Until recently you've always needed to use another computer to run Raspberry Pi Imager or to run something similar to let you flash your operating system onto an SD card when you get a new Raspberry Pi. But how do you get the operating system onto an SD card if you don't have another computer in the first place? There's a new beta version of the Raspberry Pi bootloader that implements network installation and we'd like your help to test it. The new network install feature can be used to start the Raspberry Pi Imager application directly on the Raspberry Pi 4 or a Raspberry Pi 400 by downloading it from the Internet using an Ethernet cable. The Raspberry Pi Imager application which runs in memory on the Raspberry Pi can then be used to flash the operating system onto a blank SD card or USB disk. That's very interesting. Next up, the Raspberry Pi OS 32 versus 64-bit benchmarks have been published. Raspberry Pi 32-bit benchmarks have been compiled. Most operations benefit from the 64-bit software use. The best speedup is performing the Sysbench CPU test a 1,380% speedup. Overall, using the 64-bit operating system gave a 48% faster response overall. And next, the PiCast celebrates 10 years of Raspberry Pi. New episodes with Lady Aida, Ebon Upton, and more. The PiCast celebrates 10 years of Raspberry Pi. LaMours will be livecast tomorrow, February 15th at 2.30pm US Eastern. That's 7.30pm UTC. So heads up, that's coming tomorrow. It's marked in here as today because this will go out tomorrow morning in the newsletter, which I'll talk about in just a second. But we have one more thing to talk about before we get to wrapping up this section. The sensor watch on CrowdSupply is a circuit Python compatible. The sensor watch is a microchip SAM L22-based board driving a watch LCD. It's designed to fit into a vintage Casio watch body. It has connections for sensors to make it versatile. And a designed goal is ultra-long battery life without time between charges. There's a thread on Twitter where developer Joey Castillo discusses getting circuit Python working. And I gave a tip to Joey on that and he made progress as a result too, so that's great. Okay, so that is the Community News. The Community News comes from the Circuit Python newsletter, which is a Circuit Python community-run newsletter emailed every Tuesday morning. The complete archives are available at AdafruitDaily.com slash Category slash CircuitPython. It highlights the latest Python on hardware-related news around the web, including Circuit Python, Python, and MicroPython developments. To contribute your own news or project, edit next week's draft on GitHub at GitHub.com slash Adafruit slash CircuitPython dash weekly dash newsletter, and submit a poll request so you can just click the little pencil icon in the top right and edit it there. With those changes, you may also just tag a tweet with hashtag CircuitPython on Twitter or email cpnews at Adafruit.com and we'll happily add the latest news for you as well. Okay, let's move on to the next section, which is the state of Circuit Python libraries in Blinka. This is a chance for us to take a look kind of more objectively at how things are going within the broader CircuitPython community. So I will start overall, and then go to, I will do the core, and then we'll kick it over to Katni and Melissa for the libraries in Blinka updates in just a bit. So first off, overall, we had 58 poll requests merged from 28 different authors, so thank you to all of our authors. Some new names that I haven't seen that maybe were covered before, but this is my perspective, is some new folks, new authors are Angerer, Joe Deller FC, Jonas Schatz, Tawes, VP Tech Ops, and Lashley D-A-V and Stefan Hitterholze. Those are all new authors, so that's out of the 28, so thank you everybody there for authoring PRs. And then on the reviewer side, we had 12 total reviewers for those 58 poll requests, and I just wanted to give a bit of a shout out to Tech Trick and Unexpected Maker, who I don't often see on this review list, so thank you to all of our reviewers and welcome to those newer folks. Next up, we had issues-wise, we had 38 closed issues by 18 people, and 17 opened by 14 people, so we're net down 21, which is awesome. And we have, you know, more than a dozen people interacting with issues on either side of this, so opening or closing them, so that's awesome to see people involved. Okay, next up for the core specific numbers, we had 22 poll requests merged from 16 different authors. I won't highlight some new folks here, but I'll say thank you to all of those authors, really appreciate it. We had five reviewers, thank you as always to our reviewers. We're always looking for more reviewers, so if you're interested in making the leap into reviewing, please let us know we'd be happy to help get you there. And we have 12 open poll requests, where three of them are over 100 days old, so we should take a look at those. And then actually the remainder are 31 days older or less, so that's been pretty awesome as well. Issues-wise, for the core, we had 12 closed issues by five people and 11 opened by eight people, so we're net down one, for a total of 503 open issues. This number is growing slowly, it's not the end of the world. The way that we kind of prioritize what the Adafruit Fundative Folks are going to work on sooner rather than later is through the milestone system. So we have kind of 7.2 milestone, which is the thing that we're wanting to do soonest, and then 7.xx are things that we should probably do sooner rather than later. And then we have a long-term bucket that is stuff that we're going to do in the long-term. So we have nine open issues for 7 to 23 for 7x, and then 440 for long-term. There's a few other buckets there, that's why they don't add up, but that's generally the idea. I think a lot of us are feeling that we probably want to get 7.2 stable release sooner rather than later, so I would not be surprised at those numbers. We took a look at these issues and kind of shuffled them around a bit, so don't be surprised that that happens as well. Okay, and with that, let's get the library update from Catney. Thanks, Scott. So this section applies to all of the Adafruit Circuit Python libraries, which is everything that starts with the Adafruit Circuit Python underscore as well as a few extras. Over the course of the last week, we had 31 pull requests merged from 12 different authors, and I want to point out that most of these authors are the new folks that Scott read off earlier, which is really amazing to see, and 10 different reviewers. And once again, welcome to Tech Trick for joining the review team. That leaves us with 17 open pull requests, which is just bonkers low. I'm very excited. We had 22 issues closed by 12 people and five opened by five people, leaving us with 625 open issues across all of those repositories. 219 of those are labeled good first issue. If you're interested in contributing to Circuit Python on the Python side of things, consider going to circuitpython.org slash contributing. For all of this information and more, if you're interested in reviewing, check out the open pull requests. Leave a comment that you tested it if you have the hardware. If not, let us know that you took a look at the code that it looks good to you or it doesn't. It's very helpful, and once you're comfortable with that, we can look at upgrading you to joining the review team. If you're interested in contributing code or documentation, check out the issues list. If you're new to everything, there are a lot of ways to start, and we've got plenty of those available. We have a guide on contributing to Circuit Python using Git and GitHub, and we're always available on Discord to help out. We would like you to be able to contribute in a way that works for you, so we are always available to help you along that process if that's something you're interested in doing. In terms of library updates in the last seven days, there's one new library, the Circuit Python ADXL37X library, and a number of updated libraries which I will not read off, but they are in the notes if you are interested. And that's pretty much where we are with the libraries. Awesome. Thank you, Katnie. Next up, let's get an update on Blinka from MakerMalisa. Hello. Thank you, Scott. For Blinka, which is our Circuit Python compatibility layer for MicroPython and Raspberry Pi and other single-bolt computers, this week we had five pull requests merged by four authors and four reviewers. There are currently six open pull requests amongst all the different repositories, and there were four closed issues by three people, one open by one person, leaving a net of 70 open issues. And there were 16,676 PiWheels downloads in the last month. We are currently supporting 87 boards. And that's where we're at. Awesome. Thank you, MakerMalisa. All right. And that's it for the Stated Circuit Python Libraries in Blinka. Next up, we have the first of two round robins, which is Hug Reports. Hug Reports is a chance for us to say thank you to folks for the work that they've been doing within the community. I will start, and then we'll go through the list as is in the note stock. So it's not the end of the world if it's not out of alphabetical order like we used to do. We'll just follow the note stock and see where that takes us. So if you do want to speak up, make sure you're listed there so that I go to you. Otherwise I may miss you. So next up, I will start after I take another tanko. So first, I hug to for doing the unsung hero being the unsung hero of releasing libraries. She keeps library releases going and it's awesome. So thank you for doing that Eva. Next up, I thank you to Anecdata for continuing to improve the ESP Wi-Fi APIs and experience. And lastly, a hug report to Tammy for the type PRs and Tech Trick for doing the reviews for those PRs. With that, I will go to the next person and read Anecdata who says a hug report to Michael and Dan H for helping getting my circuit python build environment working again. And next up is Dan. Thank you. Thanks to Tech Trick for continuing to do a lot of type annotation stuff and starting to review library PRs. That's terrific and kudos to Tammy Makes Things and starting to work on a whole lot more PRs whether submitting or reviewing as well. Thank you. Awesome. Thank you Dan. Next up is FOMIGuy. Alright, thanks Scott. Hug reports this week. First one for Nirdoc who converted a old pure python library called PyFleet. It hadn't been updated in many years and it was using python 2 syntax. Nirdoc updated it for us so that we can use it on python excuse me, updated it to use python 3 syntax so that we can then use it on circuit python. Anecdata also helped look into the API that is returning the response that needs this zipping functionality that we kind of got led to. Thank you echoing what a couple of folks have said. Thank you to Tammy Makes Things for getting involved and doing typing PRs and other things around the libraries. Also echoing other folks, thank you to everybody and congratulations and such for joining the review team and continuing to help out in lots of different places across all the libraries and also for prompt fix inside of Blinka this week. So thank you to Tetric to Mark Gambler for looking into a older PR on the core that was dealing with that GZIP functionality that kind of goes along with my first two hugs and then lastly a group hug to everybody. Thank you to everyone who contributes to the amazing community and especially everyone that St. Good wishes my way last week when I ran the meeting for the first time. So thank you to everybody. Awesome, thank you FilmeGuy. Next up is Jepbler. Hello, and yeah I just need to hug FilmeGuy once more for doing more and more. Thanks to Dan for doing that next pre-release of 7.2 to Mark Gambler for reviving interest in the native modules and fixing some build problems with them. And I'm sorry but I couldn't resist tinkering further with it and submitting a separate PR because I never can figure out how on GitHub to work in somebody else's PR branch. Anyway, to Katni for continually wanting to grow your coding abilities and I'm looking forward to a little bit of pair programming with you soon. To Lady Aida, thank you for the reviews and constructive feedback about my work on Adafruit Floppy. To Eva Harada for your keyboard projects it's fun seeing those guides getting close to release I think. And to my friend Steve who is not on the Adafruit Discord for the loan of a classic Commodore SX64 computer for the Floppy project. Awesome, thank you Jepbler. Next up is Jerry. Hi, where'd it go? Come back here. There it is. Yeah, thanks to Katni and Andin for a quick response to a moderation request that I did over the weekend. It was nice to get some quick feedback. And Dan, thanks for the HTTP server demo. It's nice to play with that group hug to everybody else. Awesome, thank you Jerry. Next up is Katni. I got a long list today. That's because there's so many awesome people. Yeah, and my categories apparently. So first up is TechTrick for joining the CircuitPython Librarians review team. A lot of people have covered that but I really appreciate that the reason for that was so that TechTrick could fix all the readme's on the libraries which is also a great thank you. And for fixing the cookie cutter bugs I found when generating a new library there were things that we updated elsewhere that hadn't been updated in cookie cutter. And in addition to fixing all the readme's TechTrick really jumped in and started reviewing a lot of PRs and that's been super helpful. To Tammy makes things for submitting PRs to the libraries for open issues. To Carter for helping me find something incredibly obvious that I couldn't find. To Jeff for offering to help me with some code. I'm looking forward to that. To FoamyGuy for updating a guide for me. To Mark Gambler for writing two new pages and the first one for the new IS-31 code. That's the native slash additions to the library bits that makes things run faster in CircuitPython. And that's really good because I know people are really interested in that sort of thing. To Dan for the latest CircuitPython alpha release. To Paul for the upcoming CircuitPython show podcast. I am recording my episode this week. To everyone who is involved in finding the three layer deep Sphinx bug that was released last week. I think Tectric has all the names coming up. It was like three different libraries that you had to get through before you found the actual issue. And thanks to Tectric for submitting the quick fix and a group hug to everyone. Awesome. Thank you so much, Katani and Kat. Next up is K-Match. Thanks, Scott. So first hug is related to some discord information on the capabilities of the ESP32S3 and Deshapu gave me some interesting reading material on how to drive RGB displays. So that was useful. And second thanks is thanks to Katani. Thanks for always being welcoming and willing to listen. Thanks everybody. Thanks K-Match. Next up is maker Melissa. I wanted to give a hug first to Jepler for keeping on top of the Dublin Linux talk preparations. Hug to any data for testing out the PyPortal earlier today. Hug to Katani for quickly reviewing a PR they've been sitting for a couple of days and hugged everyone who had submitted a PR issue that needed my attention for and for having the patients to wait as they finished up the little FS project and group hug everyone else. Awesome. Thank you, Melissa. Next up I have notes for Mark Gambler. Mark says hug report to Jepler for looking at the native mod work I was experimenting with and hug report to Katani and Anbi for helping the learn system. And next up is Tammy makes things. Thanks. So I have hugs for FOMI guy and Tech Trick and also for Lady Aida. I forgot her on that list for helping me a ton with a bunch of those pull requests related to type annotations. It was very interesting to discover the limits of my understanding of something I thought I understood. Always an opportunity to learn and a group hug to everyone for being amazing. Thank you, Tammy. All right. Last up I've got notes from Tech Trick who says first hug report to FOMI guy Carter Dan H. Narodok and Katani in helping find a bug in Blinka's circuit python typing module quickly. Hug report to Katani and Iharata for helping me roll out the patch to the readmes and trusting me not to squash and rebase everything. Hug report to Gambler for help with explaining the review process. Hug report to Dan H for getting Blinka to work with the CI so we don't have to mock import circuit python typing or other libraries anymore. Hug report to Tammy makes things for the awesome typing PRs and for being patient with me being new to the review process. And lastly a group hug for everyone being so helpful and welcoming. Thank you all. That's it for hug reports. Let's keep on rolling right into status updates which is the sorry, I can't talk and take time because at the same time it just doesn't work. Status updates is also done as around Robin but this time we want to hear a little bit about what you've been working on in the past week and what you plan on working on in the coming week. It's a great way for folks to find ways or things to collaborate on and just give some tips or tricks if somebody's working on something that you've worked on in the past or may have looked at in the past. So this is a great way to see just kind of also the breadth of everything that's going on in circuit python land which is always amazing. So thank you all. I will start and then we'll go down the list of folks in the note stock. So first up last week I was wrapping up the work on the ESP32 S3. I have a PR out for GAT client support. I've got a PR out for the packet buffer test example so that's in the BLE library. And then I also did the updated or created a second broadcast net bridge broadcast net is this like collect sensor data from wirelessly from throughout your house over BLE and the bridge is the thing that listens to those BLE broadcasts and logs those to Adafruit IO. So I have a PR out to the broadcast net repo that does the bridge on a an ESP32 S3 instead of needing a full on Raspberry Pi like it used to be. And then on Friday I started looking into USB host on therapy 2040. I got the example code going. It works with a Microsoft mouse that I've got here. So that's a start and and this week I'm planning on bringing that USB example code into the tiny USB into tiny USB host stack and getting more familiar with both the example code and with tiny USB host stack and trying to get them collaborating and working together as a prerequisite to getting this all into certified on. So that's my week. I should also say that I'm out probably Thursday afternoon and then next week because it's a holiday Monday. I'll be off on Monday as well. All right. Next up is Tammy makes things. All right. Thank you. So last week I submitted a bunch of PRs for type annotations in the libraries. There's one that is still in flight. We're working on a question with that one. The others have been merged. I submitted a PR to add a command line option to the PICU command line utility to specify the boundary for serial connections. I started working on a circuit Python class that represents a deck of cards for a project that I'm working on and I'm trying to make it as generic as I can. So it might be able to be added to the community library bundle at some point. I want it to be able to shuffle cards, pick cards, and I want cards to know how to draw themselves on a display IO group. So I'm working on that. I did a bunch of configuration and set up stuff for my first electronics making stream on Twitch, which, oops, type of there, that should be Twitch, which I'm hoping will happen this evening, Arizona time. We'll see how that goes. This week I'm going to continue working on all of those things and I'm hoping my first Twitch stream will be tonight. The next week is in the note stock and I will probably not be here for the next meeting. I'm out of town Thursday, Friday, Monday, Tuesday, and I'll be traveling Monday, so I probably will not be here. Okay. Feel free to drop notes for the meeting next week if you've got them and also when you go live on the stream, feel free to post your link on the live broadcast chat to let people know that you're doing that. Yeah, I think that's the place. Is it better or do we have a separate announcement channel as well? I don't know. I think live broadcast chat is usually what I do. Okay. Works for me. Thanks. Cool. Yeah, the announcement channel is only for admins. The chat will work just fine and can get people following your streams there. Next up is Dan. Okay, thanks. So, at the end of last week, I released 7.2.0 alpha dot 2 because it was kind of overdue for a release there were a bunch of accumulated changes. And as you read at the top, as Scott read at the top, there are a bunch of interesting things in there, probably most notably the board.stemma I2C, which is really handy. I started looking at Adafruit requests to modify it or to add some async possibilities to it or copy the code or structure or whatever, but use it as a starting point and I found some things that I wanted to fix in it partly because there's some stuff in there that simulates doing split and other things in CircuitPython 6. It's not really necessary anymore since we don't have to support CircuitPython 6 with that library anymore. So, I may eventually have a PR for Adafruit requests. I created a new library which is strictly for type annotation called Adafruit CircuitPython typing that's the CircuitPython typing module which right now is inside Blinka and it seems appropriate to me to move that out of Blinka because it's not always associated with Blinka and we can maintain it separately from Blinka. Blinka is not... All these additions of new types and type annotations don't have to go through Blinka. So, eventually I will try to get that working and change the few places where we need to add this as a dependency on a few libraries that do use CircuitPython typing right now. Finally, I fixed a bug, a time jumping bug on SAMD where somebody who checks the time all the time noticed that sometimes time.monototing that a second goes back or forward by three days, which isn't so great and that person hasn't reported back about whether it's been fixed but I hope that it has. Okay, that's it. Awesome, thank you Dan. Yeah, we almost invented time travel. Alright, next up is the Xiaomi guy. Alright, thanks Scott. So, this past week I got about half of the Winamp player that I've been working on for PyPortal. I got about half of the guide done and I did a bunch of commenting and documenting the code so that that's ready to get posted. I just need to wrap up the last couple of pages and I'm hoping to do that this afternoon. I started preliminary work on a project to pull data from this government web traffic API but ran into a hurdle because the server only sends data GZIPT even if you try to ask it for plain text it will respond to you with GZIPT data so it seems that browsers handle this automatically and so I didn't realize this until I got started on the microcontroller but I do have a couple more things to talk about that later in the weeds so I did start looking into the options for that and like I mentioned I'll talk a little more later but the other stuff I got up to was testing some tweaks inside of cookie cutter and then looking into the issue that arose from the circuit python typing that ended up in a fix inside Blinka and so that's what I've been up to. Thanks. Awesome, thank you filming guy. Next up is jepler. Hello, this ended up being kind of a long block of text even though it didn't feel like a lot so last week was another week of Floppies while doing that I successfully learned how to use the second core on RP2040 to enable streaming flux data to the computer in real time that's in the Arduino environment in fact most of this is in the Arduino environment so keep that in mind. I successfully wrote a D64 non-copy protected image to a floppy and booted it on a genuine Commodore SX64 which my friend told me is the portable version of the Commodore 64 and the first color portable computer and we put a video of it up on the Adafruit YouTube and the Adafruit blog I'll drop that link in just a second in the text chat. There is one weird MFM decoding bug that appeared with the new feature so I need to chase that down before we can think about merging the feature into Adafruit Floppy and as far as that relates to circuit python I'm still waiting for the repo the Arduino repo to settle down before adopting the latest to circuit python so if you want to try it you still have to try the older version from the pull request or build it yourself to try the few things with the floppy that does work in circuit python Last weekend I did finally do a few circuit python things I put in the second of a pair of PRs to add wrap and wrap target directives for PIO programs it can increase the performance of your PIO program in some extremely specific cases by removing the need for a jump instruction the PRs are both in but I haven't actually tested it on hardware so it should be considered experimental. My own use of PIO doesn't need it as urgently as I thought but I decided to finish the PRs anyway for the sake of completeness and I did close a couple of PRs of mine that weren't ready and that I had failed for weeks and weeks to get back to I would be happy to see anybody else interested in them take them up and finish them. This week my main goal is to merge micro python I think version 1.18 into circuit python. I don't think it has incompatible changes but if it does we will need to hold that until 8.0 so figuring that out will be kind of first on the list and then just getting an idea of the scope of how much work it is but I have some optimism that I can finish that this week. Awesome, thanks Jeff. I think you're right from my understanding of the latest micro python releases that it won't be too bad. My understanding is the next one will involve NPY version change which will need to do a major release for. Yeah, it sounds like there will be some really good benefits of that but for our users we'll have to hold it for 8.0 Yeah, I'm very excited about that. For those of you who haven't been following along, Damien is working on the ability to basically run NPY code from the NPY file which means that it won't take as much RAM as it does now which could be really cool. Okay, next up is Jerry. Hi again. So for all you RFM9x fans, I stumbled across at least a new to me library for the Raspberry Pi for RFM9x stuff. I'll link to it on there. In there they explained it's outgrows from other projects that have been around for a long time. But one of the nice things that handles interrupts pretty well and excuse me. And it does a much better job of working with Arduino pair, you know, if you pair it with an Arduino board I've had a lot of trouble with the circuit Python library when you when you're trying to do the reliable datagram mode and do the AC responses or catch the AC responses from an Arduino and this seems to do that a lot better. So there's still some quirks I'm running into with it but it's been fun and I'll be doing a lot more testing with that but it looks really promising fixes for the Pi side. Also I found a little bug typo in a recent update so I put it in a PR and I was really pleased to see that somebody's actively maintaining it because there hadn't been any action on the library in about 10 or 11 months but the PR immediately got accepted and implemented so it was good to see. And then if anyone does want to go use it if you install it via pip you get an older version they apparently haven't updated whatever it is to get it out there so you need to do a local install to get the latest versions which one nice feature is that the old version used to import NumPy which it didn't need but it did anyway and that's been fixed but one of the things I discovered in doing that was that if you have one of the libraries and you're sitting at the top level of it all you have to do is pip3install. And it installs your local version so if you make changes apparently that's the proper way of doing this with pip and who knew? Somebody should write this stuff down I never came across that before I'd always tried to use setup.py and do an install which I get all these nasty looking deprecation errors from and so it seems to be that's not the way to do it anymore but again, I made the last one to know that but it's really been nice and so I'll do much more testing on that this week and then there's a bunch of issues outstanding on the RFM9X stuff with these modem configurations that just make my head hurt when I try and test them but I'm keeping to trying to understand it and then I just started on a little trivial PR to the PN532 NFC reader library a discord user reported a problem when you tried to ever read failed trying to make it fail more nicely that's about it. Awesome, thank you Jerry. I think the switch to the pip3 install thing has come about from the Python packaging folks where there's a lot of different ways to package things now rather than just setup.py and then Dan points out there's the dash e so that it will do sim links instead of copying the files over oh and that way you can just edit the files and it will automatically use those again or use the edited version cool mindful. Thanks Jerry. Alright next up is Katny. Hello so last week I updated the 0.56 inch 7-segment backpack with the Stem AQT version we updated the board to have Stem AQT connectors and the guide is now updated I created the .star single LED status LED template I hadn't run into needing it yet so I hadn't generated it and has been running through a lot of board guides and putting all the templates in and obviously things like itsy bitsy and trinket have .star's only one and needed that template so I finally got around to doing that I updated the mcp4725 guide with the Stem AQT version I created a welcome to circuit python learn group it's a single link that goes to the foremost linked circuit python guides groups are something that has been in learn for a very long time but not very highlighted so it's something that learn dev is working on right now is making them more forward facing to users easier to find and making them more useful because they are super easy it is a very useful feature but we haven't been using it so there is going to be a page that you can go to that is like an explore page which will have groups on there that have a quick description and an image so you kind of can go and say I want a lightsaber project or whatever something like that and then it will be like here is all the light sword related projects and it's all in one place so it kind of usurps needing to search because search doesn't always return what you need so we are going to start putting more of those together I decided on doing only one further call for input this year this was discussed previously in my circuit python 2022 post and 2020 post I guess but I am going to do a call for input for circuit python day that's I believe August 19th this year so about a month ahead of time I think is about how long we did the one for this year for 2022 I will be putting out a call for input for folks who are interested in letting us know what they still want to see out of circuit python if there is anything new that sort of thing whatever comes to mind who knows where we will be by August as quickly as circuit python evolves so I am hoping that it inspires some new input I started on the ADXL 375 guide I wrote the ADXL 377x circuit python library and started updating the Vemmel 7700 guide with stem and QT version as well today so far finished and put the ADXL 375 guide into moderation and continued the Vemmel guide update this week which is actually hopefully this afternoon I am going to be adding an offsets functionality to the ADXL libraries starting with the 34x it is basically it is a manual calibration where you set it flat and you look at the numbers and you say okay it should be 0 it is 15 so you do a minus 15 for the offset and hopefully I can get that sorted out the rest of this week we will be finishing the Vemmel 7700 guide working on finishing the feather TFT guide including circuit python demos for the display there was a lot of feedback on that guide most of which was hey the one thing that people want to do is use this TFT and there is no example for it so we are going to fix that I say we I mean me I am going to do the Essentials template for async.io which goes along with all the other templates that have been going into the new board guides that is going to be a simple example pulled from the async.io guide and like I said will be included in every one of the board guides so folks will have a lot more exposure to async.io at that point which will be good and then once I am caught up on guides I still need to get some content up on circuitpython.org slash trademarks we do have the content it is in a very pretty PDF translating that to HTML is I could make it look pretty ugly and get all the content up there but it turns out Justin one of our developers has offered to help me make it pretty so I will have help there and hopefully it should at least have some resemblance to our fancy PDF when it is all said and done and in other news I should finally have some time to get back to the mailbox project this box of parts has been taunting me for a few weeks now and Jerry I hope to be pinging you this weekend or possibly this week with some help forgetting that going and that is what I have got awesome thank you catney next up we have Kmatch thanks Scott so this past week I updated the focal touch library it is a pastive touch panel library that currently as it existed handled screens with one touch point but I came into a touch panel and it has another chip that can monitor 10 touch points at the same time so I extended that library to also accommodate that chipset next thing is following up on some feedback I have gotten from gamblore and foamy guy suggesting how to consider handling touches using the core circuit python keypad module looking at that it looks to store interrupt pin timings but I am not quite sure how I can use that best to trigger a read of my touch panel since I needed the timing as well as some other data the position data pulled by I2C but suggestions are welcome on how I might do that or if that is bordering on interrupt handling maybe that is a core related issue but any suggestions feel free to send them along and follow those up related note on widgets for displays I created a circuit python org library for a vertical text scrolling box and I realized conflicts with foamy guy's recent horizontal scrolling box so I may need to reconsider that so feel free to give suggestions on that but the link is there and I got an ESP32 S3 board and I got REPL running on it so a lot of good work everybody is doing to make that so easy this coming week I am going to spend time more on trying to understand touch gestures and how to translate them into just points into some actions so between 1, 2, and 3 points just a few notes on how I am thinking about trying to handle it but first I need a way to visualize what is going on so I am actually looking at some of the other widgets and how to update them so I can plot some of the motion and velocity acceleration of the touch points so I can not just measure the data and put it in a spreadsheet and then deal with it later how do I just on the fly display it so just following the rabbit hole a little bit further and work on some other libraries in the process thanks awesome thank you K-Match it makes me the ice grid sea polling thing is something that has come up a lot I wonder if we actually need to think of a way of doing ice grid sea data buffering in the background sort of thing could fit into that as well okay next up is maker melissa hello last week I finally finished the little FS sporting project and integrated the whipper snapper firmware uploader so whipper snapper can now run on the ESP 8266 for anyone who has not been following along that was basically taking the little FS which was coded in C and converting it to native JavaScript at least enough of it to be able to create an image I fixed a weird issue on the 2.7 inch display in arduino where the colors got inverted if you use the reset pin so it wasn't working on the breakout but it worked fine on the shield I fixed an issue with the raspberry pi blink install script when the python command didn't exist that wasn't a common case but it apparently did happen for some people I tested a few PRs that were waiting for my review and I started adding some new boards at circuitpython.org that were missing so this week I'm gonna finish up adding those boards and then work on catching up on some more github issues and maybe work on some guide updates later and that's it awesome thank you melissa next up we have notes from mark gambler so I'll take a timecode and read those off mark says last week updated the native module code from micropython to work in circuitpython largely untested but will compile and didn't crash when I ran it discussed with foamy guy the need for an unzip type function that exists in xmod slash uzlib this week time is tight but I think putting a decompressed module like micropython in the shared binding slash module pattern is doable this is similar to what was started in PR 1274 first try will be just to get it going the old PR expanded on it I believe and lastly this week fixes the native PR module PR an example tests jebblers done I do not plan to take this code much further this time but if anyone has questions on it let me know I could also be convinced to look at it more if there's a lot of interest the first look was mostly to learn more about the that area of the code and to see if I if I could all right and lastly I have notes from tectric so tectric says last week learning the ropes of reviewing patch the issues with the split documentation sections in the readmes worked on some follow up PRs for the belee libraries fixes for the blink of circuit python typing library touching up the cookie cutter per cat knees recommendations and then this week taking some time to work on real life stuff but hopefully some odds and ends like bug fixes and library typing when there's time and with that we're into our last section in the weeds does anybody I know we're running a little bit later than we have been does anybody in the weeds need to go first I don't think I don't think Melissa or Jeff have time constraints I don't either have a couple topics in there but I don't have any time constraints already well I know some folks have to leave so in case somebody's about to leave remember that next week's on Tuesday it's 24 hours later than normal normal so just just a reminder to that before we get into some weeds and with that for me I go ahead and talk about your first your first item here right let me get scrolled down so this one comes out of something that I was looking at last week the web telescope data API that is this one is directly from NASA which is nice but it turns out that there is something going on with the SSL I think it is with that server I guess that's leading to us not being able to fetch data from it currently in circuit Python and I think it was anecdata so a late hard report to anecdata tested this out I think with the ESP IDF example code so like just using directly the ESP IDF and running it on I think an ESP32S2 and it seemed to work that way it was able to successfully you know mediate the SSL and get the data from there so I guess my question is like what all goes into updating the ESP IDF in the core and is that like a whole can of worms that causes a bunch of other problems or is that something that's relatively easy to try to tackle well it depends it depends on like what I tend to like to do is have us track a branch of the IDF that's not the main branch there's a lot of turn that happens in their main branch especially right now so we're on we're on the branch for their 4.4 release and so I would so it's easy to update along that release branch moving off that release branch to like their master branch is a whole other thing because they're currently working on 5.0 so they're making a lot of changes okay so my preference is that we stick kind of along their latest release branch I would say that if it's not fixed in the newest versions of that which they do pretty actively fix stuff in we should bug them about it and see if they'll back port the fix to their 4.4 branch okay cool I'll have to dig a little bit and figure out like which version it was specifically I did not end up looking into it but yeah I will check on that and then if it is the other one in that branch that we're not using we can look into it if there's not then I will do what you mentioned and ping them and see if they'd be willing to back port it into that branch for us the other thing we do occasionally have our own like we have our own version of the IDF branch in case we want to apply fixes to it so that's another option that we have Jeff is asking do we know what the problem is does it have to do with a missing certificate that is possible I don't know for sure I know the most elaborate error message that we've gotten to come out of it is just like SSL handshake error so that does sound like it could be a missing certificate to me I will say I don't have too much experience with SSL and HTTPS beyond just setting it up and making sure it works so some of the particulars are a little over my head is there oh yeah I don't if anybody could point me in the right direction to like how to try to test that or how to try adding a different certificate or something like that I'd be more than happy to try to do that but I don't know exactly how to go about it I would talk with Brent I think Brent is the person that if I need to know SSL certificate stuff I would talk with Brent okay because he's done a lot of that for all of the different IoT services that he's worked with yeah that would be ideal I guess if that turns out to be the issue if it's as easy as just updating a cert that's probably I would guess a whole lot easier and less likely to be a gigantic ordeal so yeah and I think we may actually have like we're using the certificate bundle that Nina uses as well which is the one that Brent has maintained for the IOT library stuff IOT library stuff I think okay so there's some possibility there maybe that gets it's updated possibly that resolves it for us I think the baseline for the certificate bundle comes from like I think Mozilla actually maintains like a bundle of root certs I think that's where it comes from plus any that we need to add I will mention it to Brent doesn't look like doesn't look like he's in the chat here but I'll ask Brent this week about that he should be responsive if he ping him I think he's around the other one I think that pretty much covers the first topic unless anybody has anything else to add but the second topic here is more along the lines of the GZIP utilities which I mentioned a little bit earlier quick rundown basically we have this other API which is also actually a U.S. government API interestingly enough but this one we are able to resolve the certs and everything we don't have that problem with this one but the data that we get back we try to parse the JSON that's in it and it doesn't work and it turns out the reason why is because the data is GZIP so the server always returns the data GZIP that didn't show it to you but so far our libraries like requests and like ESP32 spy and stuff like that and the Wi-Fi libraries in the core they don't do any of that automatic unzipping and so we have kind of I guess two paths forward that I see one of them is basically turning it on inside the core the ability to unzip or use zip I guess probably micro zip is the name there is a module from MicroPython that exists it's just not turned on in MicroPython somebody had started a PR at one point to do it but there were some additional changes that were requested and that person didn't end up I guess wanting to do it so it ended up getting a little stale but if we now have a specific need for it maybe now is the time to finish that up and then get it merged that way in which case then either user code or library code could make use of it so that's one option is kind of like turning it on in the core getting that PR resolved or starting a new one the other one is going with just pure Python inflation code which does exist there's an older library out there called Pyflate I think I mentioned before it needed to be updated because it hadn't been updated in quite a while it was using Python 2 code but that did get updated and we were able to successfully use it so that's kind of the other option is doing the inflating from pure Python code and then I will mention the one sort of follow up step beyond either of those doesn't really matter which one of those two we choose both of them will give us the ability to inflate gzip data and so then the next question becomes do we want to have requests or some other library that's in the stack try to automatically handle it I noticed on cpython requests I can fetch that same URL and it does seem to just silently do the unzipping so I figured it might be nice to match but I could also see a case to be made like adding extra stuff into requests and not everybody will need it so maybe it makes more sense to just say user code needs to fetch it and then unzip it manually rather than it just kind of magically happening when you do the request I think you probably wanted to behave the same but you needed to be careful and like I did some work to make sure that when we JSON decode stuff we don't have to load the entire giant string so like making sure that we can gzip kind of on demand not all at once that was I started kind of looking into that front really I started looking at it from the angle of trying to make requests give a better error when it came across gzip data and that was something I noticed is that there's something with read into it's basically like it looks like it's being able to parse the JSON in a buffered way without doing all of it at once and I did have some trouble trying to figure out how to like read the first couple of bytes and then I would from those decide if it's gzip data or not and then if it is raise that new error or if it isn't then just do the normal stuff but what I was finding is it seems like way that buffered loading occurs it almost seemed to me like it was one time as soon as I accessed the data the first time it didn't really want to let me access it anymore so I think it is I think it might be destructive I think the hurdle the only way I would know around that is storing it which it seemed not ideal since it would cause it to all the whole JSON to get loaded in memory so it's another kind of wrinkle is if we do want it to be automatic we'll have to figure out a way to kind of peak at the first couple of bytes without um losing access to the rest of them I don't think you need to do that I thought there was a header field that says that it's compressed so you know before you get to the body that it's going to be compressed yes I do think there is a header in this case yeah it returns the header content encoding with the value gzip which this is utterly broken because you it shouldn't send back gzip unless you say you will accept it and even if you say accept encoding identity which means it shouldn't compress it it still returns it compressed I think this website is broken personally I but I suspect the government will not look into it and fix it in any sort of timely manner I think that support could be really helpful especially for embedded because a lot of apis are giant text blobs and giant text blobs compress really well so like I think it's a worthwhile feature for us to have even if the reason that we have to add it is this broken website and it does look like I'm looking at the header it does come back with content encoding gzip so I don't think I've done it before but I assume that requests the request library must give us a way to access the headers so I could check that header and use that as the key to know um I think it just has dot headers because it's gotta load it to know whether it's chunked and stuff I will um I'll try that I think short term is just make requests try to throw a better error so that the next person that comes along it will get a clear message that the just needs to be unzipped and then I know Mark Gambler was going to look into that core PR we also have the follow up option if that doesn't pan out for any reason the Python code so is there any opinion on whether requests would handle it automatically to match the C Python I think it should because that's the way the regular request library we try to make it want to make it be like the regular request library yeah it should I would say it should if it can and if it can't it should do the nicer exception that you're talking about adding okay alright um I think that's all that goes into that unless anybody has anything more to add but that gives me the next couple of stones to try to hop to so I'll just say that UZlib has a stream API oh nice so that can maybe work sort of the same way that the JSON is doing its different stuff yeah nice yep well thank you thank you to looking into for looking into that it's like 12 what was it 12 something PR like it's pretty pretty awesome that it's something we wanted to do for a while yeah yeah and huge things as well I'll mention again to AnikData and AirDoc both both of whom I would not have been able to get even this far without so thank you to those folks as well cool alright um thank you filming guy next up is maker Melissa hello so one of the issues that we're running into is on certain boards like the matrix portal just the whole bundle of libraries that we need to add on to the board are really too large for it to run and so we suggested freezing in like the um portal based library for instance into there I noticed there's some other libraries that it are used on the matrix portal for instance uh like the request library that are supposedly in the frozen folder but they're also not accessible so I don't know how that exactly works they're in the frozen folder but they're not accessible right like if I want to import aid for request for instance so just because it's in the frozen folder doesn't mean it's enabled for a particular board okay you have to actually enable frozen libraries for a specific board so circuit playground express for example if you go into one of the um board files I don't remember which one it should be pretty obvious um there's like frozen libraries like are listed and they're enabled in that particular board so if you wanted to freeze requests for example into matrix portal you would have to actually go into the board file and set that yeah that's it right there so that's one thing uh now like bus device is frozen into there even though it's not specified so I don't know if that's like a certain one that's frozen into all boards we have a device now is native yeah ah okay that's what I didn't realize okay and you're doing this Melissa for memory savings is that your goal yeah okay so this is the thing that hopefully the newer version of MicroPython will fix for us okay cool um but in the meantime I think it's fine to freeze it in okay sounds good yeah with portal base we're using it on several different boards mm-hmm Melissa if you need help feel free to ask okay it's also not updated very often anymore so it seems I could candidate right uh that's it for me sweet thank you that was a a quick one uh right last up we have jet blur hello I think Scott this may be a you have opinions kind of question I don't I don't ever have opinions I don't know what you're talking about but uh with mark reviving the interest in the so-called native modules um which if you're not familiar with them um they are a way to include uh code compiled for the microcontroller in an mpy file and it's potentially more efficient anyway are there some boards where we want to consider enabling it I think it's possible that the rp2040 and expressive boards um given that they have a lot of RAM comparatively seem like good um candidates but um you know if we're gonna work on making this work and take pull requests about it we should enable it for some people you know for some boards where we think it could be helpful to people um so here's what I'll say I'm not against it but I think that there's a big hurdle that needs to be figured out before it's something that we actually support and it's the idea that native modules are port specific or at least CPU architecture specific yeah there would be two different forms there'd be one for the um expressive CPU boards and one for the ARM boards and maybe different ones for the ARM with and without hardware floating points so there are gonna be some variables there for sure right right yeah so I think I think we just need to make it very clear probably in both the file naming like the file naming needs to include like what architecture it's geared towards so that we can just be like oh yeah like you need a file that has this extension instead of just doing NPY right because NPY will work across architectures as long as it doesn't have native code um and then we should have really good error messages when people do try to or or have a the wrong architecture file there as well those are good points I hadn't thought about actually using the extension what I think MicroPython does is their convention is like say your module is um foo they will name the NPY file foo underscore x64.mpy where x64 is the common instruction set for desktop computers which was what I was testing mm-hmm and so you know it's in the name but it's not in the extension so we could potentially change that part of it I guess you know makes us do more work but it could be better for users I am pretty sure that when it's brought in you get a decent error message uh rather than just running code that is meaningless to the microcontroller that you have but I would have to double check on that yeah so that's my concern like I'm not against native modules I'm concerned about the maintenance burden of folks that are trying to use native modules that are for the wrong platform yeah so there may also be some tooling that we need to do around native like libraries that use native modules maybe we actually need to say like if it's generic it needs to actually like have a CI tooling that generates all the different combinations of architectures that it's yeah the CI tooling would be a whole new thing before we could ship like installable via circup modules so that would definitely be you know part of the whole solution yeah so I think how much of that we really feel we need to have in place before we would enable it in the you know my gut would be we can enable it in the core and then we don't even need to take advantage of it right away but we've enabled our advanced users to test it out and kick the tires we'll find out more of the details about it from them as we create the tooling the rest of the tooling around it right but at the same time like any conventions that you want to establish are easier to establish up front so like maybe it's maybe we should check file extension just to force it right like to check the file suffix just to make sure that it follows that convention sure would you be willing Scott to after the meeting just write up a few of those thoughts kind of a checklist for what we would do before we would enable it maybe on either Mark's pull request or mine that's related to this because otherwise I'd be tempted to just go enable it for Fetver RP 2040 you know for my own convenience in testing and just put it in the branch and then it would be there do we have do we have a native modules issue already I don't actually know if there's an issue mark and I were both working on separate pull request okay because I think I think an issue might be the right place to track these like higher level like goals yeah no that would be good too and then we could just link link to that issue from the PRs yes exactly let me make a note to myself on some paper that is on my desk I'm gonna have to go get lunch here shortly so I'm gonna do something today I need to note it down alright anybody else who wants to chime in about that I guess the other thing I will note about native modules before we move on is I don't think that there's a way to like efficiently work with a with our kind of shared module objects like you can't write a common howl call inside of a native module because they aren't available in the linkage between them so we might also in the future figure out here are the things that we're gonna add and make available from a native module that are in addition to what MicroPython has they basically don't have any of the machine interface stuff in there and I'm not sure you know you couldn't create an I squared C thing with I just think it doesn't work it's for compute stuff so it's great for being able to import Zlib which is one of the example modules but it's not great for I want to implement an I2C driver that needs to go in the core or operate in the background so it has limitation I think that's a really good point that could justify it like our bus IO and digital IO and microcontroller APIs are pretty damn stable so like I would be okay making those kind of public APIs in the sense that native modules can link against them if it means that for these folks like Kmatch that want to be able to do background background stuff for I2C maybe that's the way to do it Yeah as far as I understand it there's kind of two costs to adding these things and there is the you're committed to it cost and there's the you pay like the cost of one function pointer within flash for each thing that you expose and that cost is pretty minor at the scale of the RP2040s spy flash memory but the one where you're committed to it and also we might end up wanting to probably need two separate tables or something so that when MicroPython adds four more items they don't want a position where our first four items are otherwise it was a compatibility nightmare so we might need to do something else before we go adding to adding APIs that aren't in MicroPython Yeah I think it could be really interesting especially if that's our solution to the background story and maybe what we also need to do in the common how naming is actually call them like public common how like I know they're super long right now but your games are getting really long Scott I but but in this case I think it would be really nice for us to distinguish common how APIs that we think are private in the sense that native modules can't deal with them and then the ones that are public right like it is important to have that distinguish distinction just how much is public how yeah it could just be public how that would be fine but yeah having a if we expose or if or when we expose those things like just having a way to designate them as such yeah I think proving that we could do just pure compute native modules first is the way to go and then figuring out you know what is what is the good subset to expose of MicroPython specific hardware APIs would be a second thing that we could look at even you know version nine I don't we we don't have to get that right up front we can wait before we then do anything until late right right yeah I think you're right in that we should figure out what the baseline we want to do is and before we turn it on so that people can just experiment with it so I agree we do there all right well that that answers what I was looking for thank you all right well thanks for bringing that up Jeff and let's go to the meeting wrap up I will take one final time code first and foremost another reminder that next week is a day later than normal so we'll see you on Tuesday February 22nd at the normal time thank you all for joining us let me stall while I scroll down in our overview doc this has been the CircuitPython Weekly for February 14th 2020 thank you to everyone who participated if you want to support Adafruit and CircuitPython and those of us that work on CircuitPython 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 on Tuesday next week 24 hours later than normal but at the usual time 2pm eastern 11am pacific the meeting is held on the Adafruit Discord server which you can join by going to the URL adafru.it to be notified about the meeting and any changes to the time or day you can ask to be added to the CircuitPython Nisa's role on Discord and with that we hope to see you all next week thank you all thank you thanks everyone