 Hello and welcome. This is the Circuit Python Weekly for June 20th, 2023. This is the time of the week we get together to talk about all things Circuit Python. I'm Scott and I'm sponsored by Adafruit to work on Circuit Python. If you don't know, Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support Adafruit and Circuit Python, please 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 Dev text channel and the Circuit Python voice channel. This meeting typically happens on Mondays at 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with the U.S. holiday like it did yesterday. In the notes talk, 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 Circuit Python Nieces Discord role. There's a notes document to accompany the meeting and the recording. The final notes document includes timestamps to go along with the video so you can use the doc to skip around and view the parts of the video that interest you most. The meeting tends to run 45 to 60 minutes. After each meeting, we post a link for the next meeting's notes doc to the Circuit Python Dev channel on the Adafruit Discord. Check the pinned messages to find the latest notes doc 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 part is community news. This is a look at all things Circuit Python and Python on hardware in the community. It's a preview, usually, of the Python and microcontrollers newsletter, but because today is Tuesday, it's actually the top bits of the newsletter that went out this morning. The second part is the state of Circuit Python libraries in Blinka. This is a quantitative overview of the entire project. It's a chance to look at the project by the numbers separate from our status updates and subjective opinions. The third part is hug reports. Hug reports is an opportunity to highlight the good things Hooks are doing, taking the time to recognize the awesome folks in our community. Fourth is status updates. It's an opportunity to report on what we've been up to, take a couple of minutes and talk about what you've been doing in the last week. Since the last meeting, what you'll be up to the next week. Lastly is in the weeds. It's an opportunity for more long form discussions. These discussions can come out of status updates but are more commonly something you've identified ahead of time as to longer status updates. If you have topics, please drop them in the weeds section in the notes document and we go through the list there as well. That covers how the meeting will go and I will switch stocks here and take a timestamp and go into community news. Community news is a section for all things Python on hardware. It's a preview of our Python on hardware newsletter that goes out every week. Like I said before, this is actually what was in the newsletter that was sent out this morning. So first up, Bluetooth arrives for the Raspberry Pi Pico W. A year after the Pi Pico W was launched with its Infineon CYW4349 wireless chip, Raspberry Pi has software to enable Bluetooth for their CSTK version 1.5.1 and a MicroPython. MicroPython support will follow in time, meaning we don't know when we're going to do it. Specifically, we support Bluetooth Classic with the temporary exception of ACL and SEO along with both the BLE central and peripheral roles. Things are also configurable so you can enable Bluetooth Classic and BLE either individually or both have them available at the same time. And that's for the SDK, that is not the supported stuff for CircuitPython right now. Okay. Next up, testing the performance of spy-based LCD displays in Display.io and CircuitPython. And this I found, I think, through somebody on the Discord, so thank you to them. Josh gets a wave share around LCD and measures the response time of drawing the design above with CircuitPython and Display.io. It's at Josh on design. And the conclusion is basically that spy is the limitation to doing full-screen refreshes. All right. Next up, the EuroPython 2023 schedule has been finalized. EuroPython 2023 will be July 17th through the 23rd in Prague and remote. The list of sessions is available with the selected talk tutorials and posters are out now. And there's a bunch of links there. Next up, Espressov issues a free book on the ESP32C3. Espressov has released a new book on their ESP32C3 microcontroller. The free book is 400 pages and available as a PDF from Espressov. And with that, let's wrap up with the details of the newsletter. The CircuitPython Weekly newsletter is a CircuitPython community-run newsletter emailed every Tuesday. The complete archives are available at AdafruitDaily.com slash Category slash CircuitPython. It highlights the latest Python on hardware-related news from around the web including CircuitPython, Python, and Micro-Python developments. To contribute your own news or project, edit next week's draft on GitHub and submit a pull request there. You may also tag a tweet with hashtag CircuitPython on Twitter or email cpnews at Adafruit.com. And with that, let's move on to the state of CircuitPython libraries in Blinka. This report contains information from seven days before yesterday because we're on a Tuesday. I decided to pull the notes from yesterday. Any changes, PRs, merge issues that were yesterday or today won't be included in this report. But I did that because usually it's on Mondays. So next Monday we'll include stats from today and yesterday. All right. Overall, we had eight pull requests merged from six different authors. Thank you to them. Breaker Son is a new author to me there, so highlights to them. Five reviewers supported those six authors. So thank you to all the reviewers. Overall, issue-wise, we had eight closed issues by seven people and 12 opened by 11 people. So we're now up four. And a good chunk, you know, somewhat into the double digits of folks that are working on that. Next up, the numbers or the sub-numbers for the core. We had four pull requests merged from three authors and four reviewers. We have 22 open pull requests, which is kind of under my benchmark of fitting all on the first page. We have five closed issues by four people and three opened by three people. So we're not down two, which is great for a total of 657 open issues. We have seven active milestones, the most urgent one. Milestones are used to prioritize the work for the folks that are funded by Adafruit generally. So if there are issues that you'd like to work on that have been marked long-term, feel free to do that. We're so happy to help you do that and do the review. It's just that we may not do the work ourselves, we being Adafruit-funded folks. So as of yesterday morning or whenever this ran, we had one open issue for 8.2, which is kind of like the most imminent thing. We had 36 open issues for 8XX and 30 open issues for 9.0. I think our intention is to go through the 8XX issues this week so that we can either bundle them in 9.0 or 8.2 because we want to get 8.2 out pretty soon. And with that, let's kick it over to Katnie for an update on the libraries. Let's watch Katnie scroll back to the spot where I'm supposed to be reading from. I know, I have to do that too. All right, so this section applies to all of the Adafruit Circuit Python libraries and all of the libraries in the community bundle. So across all of those, we had four pull requests merged from three different authors and four different reviewers. And three of those were 13 days or older, so it's good to see we're getting through some older PRs as well. And that leaves us with 58 open pull requests. We had three closed issues by three people and seven open by six people leaving us with 619 open issues. 46 of those are labeled good first issue. I'm not going to go through the whole spiel today because my throat is obviously not happy. But if you're interested in contributing, check out circuitpython.org slash contributing, all kinds of info there, and we're always available to help. In terms of library PyPI Weekly download stats, we had across all across 310 libraries, 159,819. And the top 10 downloads are available in the notes. The numbers are surprisingly low this week for the top ones, but actually pretty high for the, because there's a top like three of them that are constantly downloaded and then the rest of them change up and the rest of them are a little bit high, so interesting. And then in terms of the library updates in the last seven days, we had two updated libraries. They're in the notes. We had no new libraries this week and that's where we are with the libraries. Awesome. Thank you so much, Katnie. Next up, let's go to maker Melissa for Blinka update. Hello, for Blinka, which is our circuitpython compatibility layer for Python, Raspberry Pi and other single board computers. We had zero poll request measures this week. There are currently three open poll requests and amongst other repositories and there were zero closed issues and two open by two people. There are currently 96 open issues. There were 11,705 Pi PI downloads in the last week, 6,538 Pi wheels downloads in the last month and we are at 119 boards that we support. Awesome. Thank you so much, Melissa. All right. Next up, let's go to our next section, which is hug reports. This is done as around Robin. I will start as the host and then we'll go through the folks listed in the notes document. If folks are marked as not available, I'll read for them. Hug reports are a chance for us to say thank you to folks for the work that they've been doing within the community or even outside the community, just highlighting cool things that people are doing and thanking them for it. All right. So for me, a hug to Jeff again for the collab on the Swirl Grid. I got one of them when I was in New York last week and I'm excited to see it in the shop I think today, hopefully. And also a hug to FOMI Guy for continuing to debug in the weeds of Display.io. Display was very complicated, especially with all of the different tracking stuff. And so I really appreciate FOMI Guy digging into that and fixing some issues. With that, let's go to Dan. Okay. Thanks to you, Scott, for meeting up New York City. We had a lot of good discussions about many circuit Python things. Taking a lot of walks around the city, too. Thanks to Jimmo for pointing out a confusion of mine about... MicroPython has this new feature where you can sort of store MPY files in a special kind of file system to make them executable directly from Flash, but they don't have to be frozen. And I misunderstood something about that. And so he pointed out where I went wrong about that. Okay. That's it. Thanks, Dan. Next up is DJ Devin3. Thank you. I have a hug to FOMI Guy for some great advice on improving the Bitmap Saver library examples. And I'll echo what Scott said about him deep diving into the display IO stuff. I know he's still going to be doing that this week, so I'm excited to watch him dive further into the request that was in the weeds issues from a couple of weeks ago. It's very, very interesting, and I'm hoping to learn a lot from that. A hug to Ventrue and HerBrain for helping with advice in 3D printing destroy channel. Both have been very active and very helpful lately. A hug to Tyath for helping in the AdafruitIO Discord channel with, specifically with CircuitPython MQTT questions, which is like, you have to go through one layer of CircuitPython and then MQTT adds another layer of complexity. So by the time you get there, you really need someone that's already been there, done that. And Tyath has been very helpful with that. That's it. Thank you so much, DJ Devon3. Next up, I will read for FomeGuy who's missing the meeting. FomeGuy says, a hug to Dan for discussion and points in the right direction about the ESP32 spy socket compatibility. A hug to Vladik for troubleshooting mini MQTT issues and submitting proposed fixes. A hug to SeaGrover, DavidGlob, and others for discussion and ideas about the Enigma Machine MacroPad project I was working on during my stream. And next up, let's go to Jephler. Hello. I have a group hug for y'all and a hug for John Park for doing some research and selecting a piece of software called Rubarb that will turn an audio file into mouth positions and that has to do with this. Teddy Ruck's been a project that I've been working on that Lady A to loop me in on. So yeah, that's what I got. Cool. I'm excited to see that and hear more about Rubarb. All right, next up is Katnie. Of course, I wrote a novel on the day that I shouldn't be talking much. Okay, so first of all, this was actually from last week, but I wasn't in the meeting, so I pasted it into this week. Thank you to all of the Discord helpers, that's everybody in a helper's role, for providing such an amazing amount of help on the server and for always being cognizant of potential issues and bringing them to mod attention and having incredibly thoughtful discussions about all sorts of things that have helped me adapt the server to make it better to serve the community. So this big one is for everyone involved with the Circuit Python project. This past Saturday, I gave my dad my Canary Nightlight, the guide I recently wrote, gave him the hardware and setup for it and after he found the guide and expressed interest in it in a use case, I did not think to update the Wi-Fi credentials or the A to Fruityo credentials. So when I gave it to him, I said I would call him the next day and walk him through changing it. Naturally, the process turned into an ideal, don't they always? I had him download Mu first, forgetting that we were trying to update the .toml file and not the code .py, but it turned out to be good that we had this. First of all, the Wi-Fi error auto reset timing was five seconds. So as it was, the board was rebooting every five seconds because it couldn't connect to Wi-Fi, which meant connecting to the board was not viable. And so I walked him through putting it in safe mode. We tried to update settings .toml only to find out the permissions were corrupted. So I had him create a new settings .toml file, but I also had to walk through the right-click get info way of removing the .txt extension because text said it was being helpful. Back into safe mode, copy the file over, reset again, still rebooting. Back into safe mode, walked him through changing all of the error timings to 60 seconds with outline numbers because I forgot that I had modified the code with no local copy of it here. I explained serial in Mu and finally found out the error turns out the SSID was wrong. Put it into the rebel to stop it from resetting while he fixed the SSID and settings .toml reloaded and it worked. I had him change all the error resets back to 10 seconds, restart, still worked. All of this took about an hour. This is literally the first time he's ever touched code or microcontrollers other than interacting with fully functional demos. The point of this ridiculously long hug story is to explain the reason behind my hug here. I was able to walk my dad through this ordeal and get the project working. Without all of the work we've put into making circuit python super approachable and easy to use, there's no way that this would have happened. So thank you to everyone who contributed to building the amazing thing we have here. You all made this moment possible. And finally, I have a hug for my dad. I'm so unbelievably proud of him for sticking with me through everything above and even asked periodic questions so he could actually understand what was going on to try and learn things as well. And that's what I've got. Awesome. That is like the goal, right? It's like when you hit trouble, you don't get so turned off that you stop. So that's awesome. Exactly. We want that first five minutes to work out for folks, but eventually there's going to be problems. And we don't want to lose folks over issues. Totally. Well thanks for the story. All right. And last up, we have maker Melissa. Hello. I wanted to give a hug to Kat me for some good suggestions on updating a guide and for Liz for taking on how making the guy changes and then a group effort. Thank you, Melissa. Next up we have status updates. We do this in a similar format as to hug reports. But this time we want to hear what you've been working on in the past week and what you plan on working on in the coming week. I'll start and then we'll go through the list just like last time. For me, let me take a time code. I'm back from New York City. I'm getting caught up in stuff and then digging into USB host is the big thing I'm trying to get back to. I've been poking the LLD, which is the LLVM linker a bit to bring some size numbers to the LLVM embedded meeting, which is Thursday morning. I'm trying to find somebody there that is interested in kind of like complimenting me and helping me get LLVM and the compiler tooling stuff. Good enough so that we could switch to it for a circuit python, which is not the case currently. And then I was just talking with Lamor this morning and she's also interested in some more swirl grid sizes because they're very easy to order from JLCPCB and stock in the store. So she's excited about that. I'm excited about it. And so if you have ideas on particular sizes you'd like to see, let me know. DJ Devin, why don't we put that in the weeds asking for a request of LLD and LLVM. So LLVM is a, it's clang as part of it, which it's an alternative to GCC. That's the fastest way to say it. Okay, Dan H, you're up next. Okay, I lost my, here we go. Go on to the next person because I lost my, Okay, your tab. All right, we'll circle back to Dan. Let's go to DJ Devin three. Okay. This week I updated some bitmap saver examples to be more robust and helping to avoid SD card data corruption. Again, thank you to FOMI guy for the suggestions to make that even better. I pushed three new API examples into the Adafruit requests library for open sky networks, which is a public flight database of active commercial aircraft. You can track one specific, there's three separate examples. So you can track one specific aircraft or all aircraft in a small geographic region using Latin lawn coordinates. It can return a lot of data. So it's only recommended for microcontrollers with M4 or better MCUs, preferably S2, S3 kind of thing. You know, a Metro M7 would be fine. User Timex40's project has already been featured in the Adafruit blog if you want to see a great example of what it can do. His example uses a Pi portal, which as everybody know kind of has like its own portal base kind of thing. So I wrote it to be an API to be available for any circuit Python device capable of handling a large JSON data stream using the Adafruit requests library. This week I had family visit and they helped me accomplish more tasks in one week than I could have done by myself in months. So having family over this week during a situation has been extremely helpful and I just want to send a shout out to my brother for being very helpful. And that's just personal news. So thank you very much and that's all I got. Alright, thank you DJ Devon3. I don't know what LLD stands for. I don't think it's the low drive. Okay, let's go back to Dan. Okay, I was looking for the swirl boards and new products and I accidentally overrode my... It's not in new products yet at this second. Okay, so... There was a minute long video posted. Oh good, yeah. And so I'm continuing to work on the MicroArch. I'm going to restart working on the MicroPython v1.19.1 merge. And as Scott mentioned, and I mentioned already we were in New York. I was there Thursday to Saturday. He was there a little longer. It was great to see everyone including the baby and Lamore and Phil. Okay. Okay, alright. Next up I have notes from FOMI Guy to read. I got a little distracted posting that video but I'm excited to see stuff mounted to the sports. Okay, so FOMI Guy says cleaned up the current state of the hidden tile grid issue PR and completed more thorough testing of the problem reproducer and other scripts. Testing the ESP32 spy socket compatibility change in conjunction with MiniMQTT, HTTP server and the Whiskey libraries. I created a PR proposal to move the ESP32 spy Whiskey server module over to the Whiskey library and update it to work with the new compatible socket version. Started coding an Enigma machine app for the MacroPad. It has a basic UI and controls utilizing the buttons and rotary knob to configure the machine settings. Then allows the user to run text through the machine and type out the result over HID slash keyboard. And next up is Jepbler. Hello. I had to get back to my notes because I was trying to look up the info for DJM3. But anyway, mostly I've been up to non-circuit Python work lately. Last week I finished and published a retro computing project based on RunCPM. And there's a link to that in the Learn Guide in the notes doc. You can check that out. And the other thing I've been working on is the Teddy Ruxpin project. And the thing that I've done is create support for patching different mouth movements into a Teddy Ruxpin story. So Lady Aida has done the substituting a different audio file. And I've done substituting different mouth movements. And then when we combine that with JP's use of the rhubarb software to turn your audio file into mouth positions, hopefully Teddy will start to move its mouth in time with the words that it's speaking. And that'll be pretty cool. So this week I'm trying to make all these different data sources come together. I'll do something else when I get done with that. I'm not exactly sure what. And based on the RunCPM project, one of the things that I did was created a USB keyboard to UART serial interface that is half of the RunCPM computer. And I'm really itching to do that with circuit Python where probably that default UART Ruxpin would be treated as the console in and you put that on a DVI feather and plug in a keyboard and now you've got a whole circuit Python workstation and that would be pretty cool as well. And the last thing is I bought the Zelda game by accident and now I just spend all my time playing it. So these other things are things I dream of doing, but what I will be doing is looking for ingredients and things like that in Zelda. That's what's up with me. Thanks, Jeff. It sounds like we're very much thinking about the same USB keyboard to serial things so we should sync up with that. Yeah, sure. Yeah. And I'm really excited. I said this in the text. I'm really excited to hear about the grid going in the store. I didn't know it was moving that fast. So cool. Yeah. I had encouraged Lamor to buy just like five of them to check them out and then she like, they made them really fast or something or she didn't get around to canceling it so she ended up getting 200 and something of them. All right. Cool. So she's got a bunch and we looked at them and they look good. You can see them in the video. But if you have any ideas for them, I'm going to generate some more files for different sizes. So I was going to put like a version number and a different logo maybe on here as well. Yeah. I was just thinking, you know, what are some IKEA product sizes that you might want to put a board in but that was kind of the first one I thought I had but that's all I got right now. I think I decided I want to do a one by two one so you can use it to connect other ones together. You can use the one by two to like bridge between two larger ones. So yeah, I have a whole list that we're brainstorming in. We'll see which ones we actually want to buy. Okay. Next up is Katnie. Hello. So last week published the Neo Key Breakouts Guide and the TRRS Jack Breakout Guide. I started on the I2SBFF Guide. This week I'll be finishing up the I2SBFF Guide and I think next up is the StemaQT GamePad Guide. This past weekend I recently got a new split keyboard which does not have an unpad. I thought initially it might be helpful to have one in case I wanted it. So I decided I would build one. Well, I've had the keyboard for a week or two now and it turns out I use the numpad way more than I realized. So now it's kind of critical. I already had gathered what I needed for the build that hadn't started it. This past weekend I soldered it all up, the method for which turned out to have a learning curve and then got that good to go, tested it with code. It mostly worked. I had one missing wire and one wire in the wrong place and then got that going correctly figured out the code because you got to do some stuff because the numpad is not necessarily a straight up four by five matrix. There are two U keys in it, so you have to deal with kind of having phantom keys, if you will, in the code and then everything seems to be working. So we're not working on the 3D printed case for it. The design for which is nearly completed. We're getting close. I don't know whether there's going to be a guide for this or not, but I'll post pictures somewhere at least and I will consider posting the code and the model files in a repo as well. And that's what I've got. Sounds good. Thank you, Katnie. All right. Last up is Makeup Melissa. Hello. Last week I tested out a bunch of guides related to the matrix portal. I worked on fixing code on the guides that failed and I'm also working on a large guide update that requires a circuit redesign and 3D print design change. And this week I'm going to work on finishing that large guide update and then I'll work on updating the 1.2 inch seven segment display guide. And another news, I participated in my first speed keeping competition this past weekend, which is basically solving Rubik's cubes as fast as possible. And that's it. How did you do? Not too bad. I actually got a personal record and I got this all the time down to about 30 seconds. Wow. That's awesome. Thanks. Congrats. I don't think I can solve them at all. Thanks. I've been doing it since November and it's been getting a little faster each time. Nice. Well, congrats and keep us posted on your PRs there. Thanks. All right. And that's it for status updates. Thank you everybody for participating. The last section we have here is called in the weeds. It's a chance for us to have any more long form discussions that we kind of skipped over previously. We have one in the notes here and then I did mention another with Jeff, but I don't know if we actually want to do that here. So first let's do DJ Devin 3. Okay. I had a brief discussion with FOMI guy about Adifruit request examples changing to settings.toml and not the secrets.py anymore. As long as 9.0 is planned to be a major breaking change, is it time to swap all online examples to settings.toml? I would like opinions and guidance as any new Adifruit request API examples that I or anyone else contributes kind of have to make a choice whether it's going to be, you know, have that integrated with secrets.py or settings.toml. And this will have, you know, breaking changes going forward as most learn guides would probably be affected as well. Basically anything that requires an online project, you know, you have to choose one or the other. So far it's been optional. And, you know, in the future you can always use a py file anyway. But I would like some guidance. You know, is it time for us to start swapping the API examples to settings.toml? Or I have no idea. So I would like, you know, some kind of discussion about, you know, do we do this for 9.0 or just keep it as is? Katnain, do you have thoughts? Yes, I do. 100% we need to be changing this. Yeah, I mean, we do need to be changers. This is the crossover time. So it, you know, secrets.py, does it even still work in 8.0? I don't recall. Oh, absolutely. Okay, is 9.0 when we're not going to make it work anymore? It's all... secrets.py works on top of CirclePython, so it'll always work. Yeah. We could be in like, you know, Python 12, it'll still work. Okay, so here's my thoughts on it, though. I always prefer consistency. And personally settings.toml makes a lot more sense, at least to me, in how it works. Like how it looks and how it works. And that was a huge part of why I pushed also for the change. Obviously, I wasn't the only one involved there, but like I definitely agreed with it. And I do get quite annoyed when I run into, for example, that I think it's either requests or something else I was using recently where it's hard-coded to use secrets.py. It has to be... Like in the examples anyway, it has to be... No, it was in the code. Yeah, maybe you're talking about the portal base that... It was something else. It was something else, because I haven't used pyportal in a while, but I don't remember what it was, but it was a recent project and I was really annoyed because it was hard-coded into the library itself, not the example that I had to use secrets.py. Whatever I was doing was gnarly workarounds for some things. I mean, most people aren't going to run into it, but I certainly did. Somebody's going to. And if you're already getting so used to using settings.toml, which is that most of the learn guides are moving to and so on and so forth, it's going to be confusing, right? When you run into something that requires secrets.py, which you may not have been exposed to if you only started with Adafruit in the last month. And if all the learn guides are already using settings.toml, it'll be the first time that new beginners will run into it. All of the examples that are in Adafruit requests currently use secrets.py except for the new ones that I've been contributing like the Open Sky Network is the only one I think that uses settings.toml. Okay. So I can go through and change all of the API examples. I'm good with APIs and stuff like that, so I can change all of those to settings.toml. I just need the guidance should I? Well, the thing I'm questioning is will what you are doing affect guides and or the code itself? Absolutely. No, it won't affect the library. It will only affect guides, which will force all the guides to then be, you know, need to be updated to settings.toml instead of having anything to do with secrets.py in the guides. And this is going to affect a lot of guides. Anything that's an online guide, it will affect. I don't want to get into the portal-based stuff and the pie portal stuff because that's a whole different animal. I'm just talking Adafruit requests only. Like that's what I kind of specialize in. So my thought is try to start on the ones that don't require learn guide updates. And if there are any. Because I need to like negotiate the learn guide updates on my end. The only other caveat that I had was that there might be some examples in learn guides for like M0s where settings.toml might not work if web workflow is automatically initialized. So settings.toml for the most part will automatically initialize web workflow as well. So we need a way to, especially for M0 boards, to not have that happen. We need like a default, you know, don't run web workflow with this example kind of thing. I don't think we have web workflow and M0 at all. There's no M0 that does web workflow. Okay, well, that solves that. It's going to be on all the ESPs that we'll do that. All the ESPs can handle web workflow in the background really. Okay, here's what I want you to do. And this is silly kind of, but it's not. Please put individual PRs in for each example. And then link in the PR description to the guide it affects. Actually, it doesn't matter if you do a bunch at once. Just link in the description to all the guides that are affected and maybe put in the title, say do not merge yet. And what that'll do is that'll give me a list because I mean, I'm going to have like, you know, arbitrarily or vaguely negotiating somebody to update guides is one thing, but having a list of guides to update will make it easier because then I can say, hey, you know, here's this list of guides that need to be updated before we merge this or when we merge this. You know, can you or whoever I pick to do it? Does that make sense, Evan? Yes, it would be easier on me if I did them individually because it takes time to do. Yeah, okay. Time is not something I have a lot of, so I'm just going to, you know, one at a time kind of thing. Yeah, I didn't want to, I wasn't doing it to limit you. I was trying to make sure I wasn't limiting you, but if that limitation helps you, take it. The previous examples where I did something recently, you know, where we linked and you said, you know, tag you or Eva, you know, kind of thing. I'm used to that now, so I can do that. It's not a problem. Yeah, tag me because I don't know who I'm going to put this on yet and just include do not merge yet in the title, like in all caps. Got it. And that's how we'll do it. We'll just, especially if you're doing them individually and they're happening relatively slowly, this will be perfect. I can just find somebody who's got, you know, a few minutes to change up the guide and then we can merge the thing and do it all at the same time. It'll be good. Yeah, and this is a good time to do it because we're still quite a far way away from 9.0, but we are working towards 9.0. So we're getting to 8.2 here pretty quick. So 9.0 is coming up. What were you going to say, Scott? I was going to say, do we have a feeling of how many examples in the library repo in driver repos are actually used in learn guides versus like the code that's in the learn guide repo? Repository, yeah. Like do we have to be scared? Do we have to make sure or? Well, yes. Yes. Yeah, because sometimes, sometimes LeMore asks for things to be put in the library instead of in the learn repo. Okay. Like particular examples that she thinks having tied into the repo. So if somebody goes there for the code, like having that example there makes more sense. Right. I wonder if this is something we could actually like use CI to do of like, this file is imported into this learn page. Can you have you checked it? Or automatically like, automatically post on the PR to say like, oh, this impacts these learn guides. I will talk to you, Justin. Yeah, ask Justin to see like, if we gave you a file on GitHub, could you tell us what guides it's in? Yeah. And then we could make the GitHub action like follow up and be like FYI, this changes this file that's imported here. I've done about 10 API examples in the Adafruit requests library that are not associated with guides. Basically anything that doesn't have the word API in it is something I've done personally that does not have a guide, but the rest of them that have, I want to say Adafruit underscore, you know, something that doesn't have API. Those I think are all associated with learn guides of some kind. Well, here's the thing. If you change the URL of a file that is linked in learn, it sends an email to a couple of us that says, hey, this embedded link changed, go fix it. So there might actually be a way to have CI be involved. Okay. But I will ask about it. So when it updates the embedded content, it does warn you that like the guide. Yeah, like it does send, there is a signal going out. It's just a question of can we convert that signal to a CI, you know, compatible signal? Well, I'm less concerned if it is, if you are getting notified about it. It's just not something that I had visibility into. Yeah, yeah. I know I understand, but like I said, it's just can we actually convert this to something that CI can use to pop a message in the PR. We'll find out. So start this way, because obviously you're going low and slow if you're just doing them individually and you check one guide or check the guides to see whether it's in there. And we'll see what we can do to automate the finding whether it affects guides part or not. I had no idea that some of this might be hard coded in the library. So if you can remember whichever one you encountered, you remarked that because that's going to be important. It was definitely not requests. I just opened the eight of requests library and did a search for secrets and it's not in there. So requests, you're good to go. Okay. Well, like I said, portal base is affected by that, which affects like that's kind of like the base library for a bunch of different ones, like the matrix portal library, the library. There was a ESP 32 S2 TFT library. The mag tag library. Yeah, it's going to cause a nightmare for anything. Related. Yep. Yeah, no, we're not, I think the plan is not to touch that anytime soon. Okay. That's the library. I'm aware of where it's embedded in there. There's something. Oh, oh, oh, oh, oh, oh. It's a, it's ESP 32 SPI. Oh, the one guy was just working on the one. What foamy guy was just working on that. Yeah. He was like part of the whole thing that foamy guys been doing is like making the ESP 32 spy be more like the regular ESP 32 request thing. Yes. It is the ESP 32 SPI library that, that has hard coded secrets in it. An anecdote is talking about the wifi manager as well. Yeah. It was on the same library. Okay. While foamy guys in there, maybe we can have him take a look at that as well. Well, then we got to figure out what it, what guys does that affect, because that's going to affect like code, you know. Nevermind. I'll be quiet. No, no, eventually we should. I agree. I'm just saying like, that's something foamy guy can actually do, like the whole process of. He's got access to learn guides. So like, that's, that's fine. I'm not at all concerned about him going in and making those changes, because we don't have to find somebody else to step in and do other parts of it. But it's worth mentioning. I will also make a note to bring that up if he's in there. Okay. I've got, I've got a couple of other things I want to do around this too. First, I want to read just what anecdote typed in the chat for anybody who's not watching the chat. So anecdote said, need to make sure we educate users on what, what the key fields and settings.toml do. Web workflow or not. Wi-Fi credentials without enabling why Web workflow. And we need to resolve the question of whether you auto connect is made distinct from the Web workflow settings. Jeff suggested starting with a very small number, though, which I think we are with just starting with the requests examples. And starting with one at a time. Yep. Antic data said secrets.py access tends to be the high level device helper library. Jeff points out about 125 bundle examples seem to use secrets.py about 106 learn files. Antic data says ESP32 spy Wi-Fi manager and ESP32 spy also has enterprise credentials from secrets. Maker Melissa says, I think the way this will affect guides the most is instead of telling users to add some API keys to secrets.py and then to settings.toml instead. Yeah. And I think I actually wrote a page, like a separate page on it. If I didn't, I will. And we can just mirror it in. Sounds good. The other thing I wanted to clarify is when we're talking here about using settings.toml we're talking about using os.getenv to actually get the values out, right? We're not talking about a separate toml parser that we have started to talk about. No, it's just for the purpose of, as Melissa said, for that and any API accesses will have different type of credentials that you might want to store in secrets or settings.py apart from any web workflow, API or settings about toml stuff. Right. So when we're switching over, we're switching over to os.getenv, which is powered by settings. Maybe I should have specified that instead, yeah. Okay. I agree with that direction for sure. So thank you for taking that on and Catany thanks for organizing it. Yep. Anything else? I see Jeff is typing. I feel like maybe I shouldn't say people's users name because on my screen they're elipsized so you can't see the full one. Anyway, yeah. I'll just repeat what I was typing. I would look through the circuit Python issues real quick and I didn't find an issue proposing the enhancement to allow settings.toml to configure a Wi-Fi that will automatically be connected to like before code.py starts the first time without starting web workflow. That does sound like an interesting idea that I hadn't. Oh, here it is. It's 7598 separate web workflow and auto connect. I think that's definitely something to consider but it's separate from any of these particular things, I guess. Right. But maybe definitely something to do in 9. Definitely do in 9. What's nice is not paying that reconnection cost every time your code reloads. That's what I would really like. However, we accomplish that. And Bill points out at some point we should also try to make it store multiple Wi-Fi credentials for portable boards because with software implementations that means no web workflow. And DJ Devon 3 says yes that would be preferable to be able to separate them and disable web workflow if possible for a requests-only project. I do like the idea of auto connect really simplifies like example code because so much of the example code is just like getting connected. Let's make sure. Yes, because for some requests you might have like a settings.toml and a secrets.py for connecting web workflow plus using secrets.py for request projects. So merging it all into just settings.toml is preferable. Cool. And it sounds like this issue is marked for 9.0 and the kind of conclusion was that we would only start the web workflow if you gave it an API password. If you put an API password in your settings.toml. Yes, I think there's like a Wi-Fi password and then an API password. Right. I could be wrong, but I think that has already been started, yeah. Yeah, it's there. It's just if you don't set it the server still starts up and it just gives you errors if you try to do things that are... Okay, yeah, we need to work for it. So we could change that. I think the reason I did that is because you don't want to do the mdns circuitpython.local unless you have the web server actually running. So we'll have to be a little careful on that. Okay. I added another thing in here. Jeff, do we just want to talk briefly about the USB keyboard workflow? Which I think you were alluding to as well. Yeah, so with the RunCPM emulator it was just a matter of oh, I'll patch this one hard-coded UART pin into the code and then it worked for my needs. But that's not probably enough for circuitpython. So... What was doing the conversion for me? The way the keyboard works that I did is it gets the USB HID and it does all of the translation, so like applying what Shift does or Caps Lock or Control does to the rock key codes and it manages the key repeat. And so the software just has to treat it as this UART is typing into the console. Right. Which is a very low... That's the code that I was just thinking... That was the code that I was just thinking I needed to add to circuitpython. And I think we've got the ability to hard-code a UART console in like for the ESP32 boards. Right. That's essentially how they operate, those without... Yeah, my plan was to treat it as another serial input. Right, so like there's that one serial read characters or something, you know, and serial the H, it just has that like all those different types you enable. I was just going to add another one that was like check to see if there are bytes available from the USB keyboard. Right. And just like a serial stream. Would we like have that built into the board definition so it would be just a certain board would have this feature or would it be configured through boot.py or Settings Tomo or something? I think it would be... What was I thinking? I was thinking it would be like Pico DVI. Like Pico DVI is the reverse, right? Like boards can set it up and it just works from the get go or you can instantiate it and then it works. And so I think it would be a... You either have a board that says I have a dedicated host port or you instantiate USB host and then it works kind of from then on. Once USB host is designated. I guess the other thing is the pin that I selected is the one called Rx and so the sender uses a PIO peripheral to create the Yord signal. That's not important but it means we can do it on whatever feather pin we want or any other pin. I mean I was a... Yeah, I was just thinking of it in terms of like just taking input and then putting it into the CircuitPython and I wasn't thinking about bridging it at all. But yeah, basically adapting it so that you just have a USB host serial input. Which I suppose you... You're thinking about with CircuitPython running on the USB host board. Right. Like having native USB hosts. Yeah, and I was answering questions about this other thing. Right, but that code that you have to do the mapping from hit report all the way to serial is exactly the thing that I need or nearly the thing I need. And I was thinking about how to manage multiple keymaps and stuff. Yeah, this doesn't do that. It's purely QWERTY. So you Colemac folks and people with a European as a QWERTY keyboard are not going to be well served by it. Is it code you wrote or... Yes, it's code that I wrote. There was some code that I referred to that there's some in tiny USB and there's another one that I found. And I identified that it was important to have caps lock work and it didn't work with those other ones. So I ended up doing my own implementation. Okay, well that sounds where I need to start. I imagine that you have some tables for mapping from key numbers to ASCII. Yeah, ultimately that's mostly what it amounts to because the USB like A through Z are in order. So you can have a compressed table by saying A and the next 25 characters after that are related. That doesn't work once you change to Colemac or a ZERTY because the thing in the Q's position now is Z so that order is messed up. Are you handling... Are you producing VT100 codes out of this as well? Or the cursor keys there are... Yeah, or like cursor and escape. It produces the keystroke you would expect for escape. For the cursor keys it was doing what CPM... what was frequently seen on CPM keyboards which is sending a single keystroke. It's actually control HJKL just like VIM which was an interesting thing to learn. So like control H is left is backspace. It's all one key and control J is vertical line feed and cursor down and whatever K and L are. And right now there's no support for sending a string there's only support for sending a single character but that would be easily changed I hope. Yeah, so that was my hope. That's what I've been thinking about is converting the hidden reports all the way down to I would say like Unicode Serial. Okay, I see. Yeah, that would be cool too. I was thinking to have the coprocessor board I want to take this same run CPM project and change out the board that has the CPM emulator and the DVI, change out that software for CircuitPython. And so that would be all about having CircuitPython use the key or the ASCII codes that are coming in on the UART RX pin. And that's there you just have to rebuild for it and running CircuitPython on the USB host feather is a different thing. Right. Yeah, but this translation is the shared piece. And the thing that I was thinking about one thing I did find is DJ Devon 3 points out that Naradoc has a good keyboard layout library and it turns out Naradoc like generates that based on some Windows keyboard layout info but I did manage to find like the X.org Linux version. So I think there is a world where we can basically like have a bit packed format of that that you could put dump into boot.py and kind of like I want to replace the QWERTY mapping, right? I want to replace the QWERTY mapping with the Colmak mapping. And so I'm thinking it's just going to end up being like a byte string. Yeah. That in boot.py I'll just say like, no use this keyboard mapping instead or use this. And I think you have to do it before like doing shift. I'm not entirely sure. And so like figuring, looking at how it's done on like Linux was part of what I wanted to do is just figure out like, do we need two steps? Because like if you're a C, if your C character moves, your control C is still copy and paste or break or whatever. I think different people make different choices about that. What is important to them, the position or the legend on the key. Right. I've seen people do both for sure. And so if it's flexible enough, I don't know. Yeah. I wanted to be flexible enough that like, only double the size of the table. Right. Yeah, we don't want a bunch of angry Europeans. They will be scathing but slightly understated about how they feel. I mean, I think it is safe to assume that this is not going to be on the Sandy 21. Like I'm doing on IMX and we'll certainly do it on the RP2040 as well. But we don't have to be as cautious, I don't think. So yeah, if you could point me to that. So you weren't thinking you were going to do it in CircuitPython immediately? No. You were thinking more of the serial you are in to CircuitPython? Right. Yeah. So I wanted to take this existing project and switch it from being a CPM computer to a CircuitPython computer. But the way I have it split, the part where CircuitPython would be running is not the part that's doing the USB host. Right. Well, that would still be really cool if you start working on that and figuring out like what, the next step after getting the serial input is actually figuring out like how would you edit a code.py just from that serial input. And that's the big question of like do we have an editor.py that when you hit escape it switches to that and things like that. Like how do you toggle between running and editing? Yeah. I think Bill has some software that can do that but the question of how you switch modes and exactly what happens. I think it's a neat question. I like this editor.py approach a bit because it gives people flexibility to use different editors. Yeah, Bill has their own curses implementation. That'd be cool. It's absolutely massive. Yeah, that's the hard part, keeping it small. The reason that I wanted to go from keyboard to serial and stream though is that then you could actually like prototype slash test from a host computer over serial. Right. Like if you have escape codes, if you use escape, which is what I've heard people say, then you could do it from TIO and do escape and that would get you into the editor and stuff too, which would be neat. And it sounds like that was more interesting to you, Jeff, because you already have this translator from USB host to serial out. So if you wanted to play with that, that would be cool. One thing I did want to do is I wanted to have a keyboard icon show up in the status bar and keep what's going on. That would be interesting, yeah. Just so that you can tell that like, oh, if I type in, it's going to go into Circuit Python, which gets me deeper into the weeds of like, how would we support emoji characters in Terminal IO? I won't be doing that part, sorry. It's crossed my mind. But we cheat the snake right now because we just dropped the snake code character that we output. And we just hard code putting it in the top left. Okay. Using Unicode and Revolta for status connections, they stand out and are very helpful. It's the escape sequence for terminal detection and size too. Yep, we'll get there. Okay, well, Jeff, if you could link me to that code, I might start with that. Yeah, I will grab you a link in Discord. Let's see how I can start with that. And then I do want to add a thing so that you could, and maybe it's not just boot.py, but basically make it that table mutable. Maybe like copy on write or something so that you can remap keys, because I won't be able to type in Quarity. So I got to think about that. Yeah, our user zero needs support for it so it'll happen. Yeah, and it's good for like, we do have people wanting HID differences too. Right, like, because they're not US. Not US folks. And I'm not the only one that would ever need it. Okay. 104. Thank you, thank you, thank you. With that, let's wrap up the meeting. This has been the status record Python for June 20th, 2023. Thank you to everybody who's taking their time not only to attend in person, but also if you are listening to this after the fact and you made it all the way to the end, we really appreciate it. If you want to support Adafruit and CircuitPython and those of us that work on CircuitPython for Adafruit, consider purchasing from the Adafruit shop at adafruit.com. The video of this meeting will be released on YouTube at youtube.com.adafruit and the podcast will be available on major podcast services. It will also be featured in the Python secret controllers newsletter. Next week, visit adafruitdaily.com to subscribe. The next meeting will be next Monday. I'm just pulling it up on my calendar to make sure. Yep, next Monday at the normal time, which is 2 p.m. Eastern 11 a.m. Pacific. This meeting is held on the Adafruit Discord server, which you can join by going to www.adafruit.it If you want to be notified about the meeting and any changes to the time or day, you can ask to be added to the at CircuitPython NISAs role on Discord. With that, we all hope to see you next week and have a great week right now as well. Thank you all.