 Hello everyone and welcome to the CircuitPython Weekly for December 5th, 2022. This is the time of the week where we all get together to talk about all things CircuitPython. I'm Katny and I'm sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny computers called microcontrollers. Its development is primarily sponsored by Adafruit, so if you'd like to support Adafruit and CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to 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 2 p.m. Eastern, 11 a.m. Pacific, except when it coincides with a U.S. holiday. In the note stock, there's a link to a calendar that 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 those notifications, please ask us to add you to the CircuitPythonista's Discord role. There is a note stock to accompany the meeting and recording. The note stock contains timestamps to go along with the video, so you can use the dock to view only the parts of the video that interest you most. It tends to run 45 to 60 minutes, so this gives you the option to skip around. After each meeting, we post a link to the next meeting's notes document in the CircuitPython-dev-channel on the Adafruit Discord server. Check the pinned messages to find the latest note stocks so you can add your notes for the following meeting. If you wish to participate but cannot attend, you can leave hugger forts and status updates in the document for us to read during the meeting. The meeting is held in five parts. The first part is community news, which is a look at all things CircuitPython and Python on hardware in the community. The second part is the state of CircuitPython libraries and Blinka. This is a statistical overview of the entire project and a chance to look at the project by the numbers. Next up is hugger ports, which is the first of two round robins. It's an opportunity to highlight the good things folks are doing, taking the time to recognize awesome folks in our community. The fourth part is status updates, the second round robin. Status updates is an opportunity to sync up on what we've been up to. Take a couple minutes to 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 leads. This is for more long form discussions that may 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. I will make a note regarding the meeting times. Please look into it for the holidays. We are not going to be holding a meeting between Christmas and New Year's. And we may be moving a meeting or two to Tuesdays and the calendar will be accurate and we will be sure to let you know the week before. But if you're interested in finding that out now, you can check out the calendar. And with that, I will get started with community news. First up 100 circuit Python Blinka compatible single board computers. So Blinka brings circuit Python APIs and therefore circuit Python libraries to single board computers. It's a PIP installable Python library that runs on normal desktop Python. The circuit Python runtime isn't used. Circuit Python libraries can also be installed via PIP. The number of boards that support Blinka is now 100. If you're interested, check out the guide or there's a blog post also linked in the notes document. The project of the week was a Hanukkah lightsaber. A Hanukkah persistence of light lightsaber. And this is a quote from the author. Toward the Jewish month, Kislev, the month of light, I built a Hanukkah lightsaber prop based on a maker's project from the Adafruit company. Besides building the hardware, I made necessary adjustments for the Hanukkah holiday. 30 colored RGB Neopixel LEDs are connected to an Adafruit circuit playground board responsible for processing a bitmap image divided into columns. And when deflected the lightsaber and exposed to a camera with a slow exposure, you'll get an image floating in space without the person even deflecting the lightsaber. Happy holidays full of light to everyone. And there's a link to Instagram there. And finally, Pico Touch Synth. This is a quote from Todd Bot on Mastodon. First light on Pico Touch Synth and the cap sense pads work better than the Pico Touch board. The reverse mount Neopixel LEDs are totally awesome. The test code is in CircuitPython. So that has been community news. It is pulled from our CircuitPython weekly newsletter, which is a community run newsletter emailed every Tuesday. The complete archives are available on adafruitdaily.com, adafruitdaily.com slash category slash CircuitPython. Highlights all the latest Python on hardware related news, including CircuitPython, Python and MicroPython developments. To contribute your own user project, you can edit next week's draft on GitHub and submit a pull request. You can also tag a tweet or a toot to with CircuitPython on Twitter or Mastodon respectively, or email cpnews at adafruit.com. And that is community news. Next up, the state of CircuitPython, the libraries and Blinka. This is a statistical overview of the entire project, and it gives us a chance to look at the project by the numbers. This report contains information from the previous seven days. Any changes made today will not be included. So first up, overall, there were 98 pull requests merged by 20 different authors. A few that I don't recognize are Nicen, Jay Shimbo, Pete Kowalski, Kenneth Ryerson, and E. Karatso. Thanks to everybody who contributed and welcome to our new authors. And we had 11 reviewers. We had 40 issues closed by 13 people and 20 opened by 13 people. So next, Scott will talk about the core, then I will talk about the libraries, and Melissa will talk about Blinka. So Scott, go ahead. Thanks, Catney. State of the Core, 27 pull requests merged, which is awesome. We had 11 different authors. Some new names to me might not be the very first time, but newish to me. Jay Shimbo, Pixel Clay, Bill88T, and BablockB. Thanks to all those folks for being relatively new authors of PRs. We had four reviewers, thanks to Mike Rodev, who's a reviewer off and on. We have 22 open pull requests as of last night. We have three of them that are 150 plus days old. And I think this number is down thanks to Dan for closing some that didn't seem to be progressing at all. Issues-wise, we have 18 closed issues by five people and 12 opened by seven people. So we're net down six, which is great. And there's a lot of people involved, which is also really awesome. We have 577 open issues. This says 24 open issues on 8.0, but we just did a pass, so it's now 18, which is good. We have 504 long-term issues and two issues not assigned to Malistone as of last night. So doing pretty good. We are still slowly growing in issue count, but largely in that long-term category, which is to be expected. And that's it for the Core. Thanks, Scott. Next up, the libraries. So this applies to all the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore, CircuitPython underscore, as well as a few extras such as the community bundle and our cookie cutter. So across all those repositories, I had 64 pull requests merged by six different authors and seven reviewers. We closed out two over two weeks old. One of them was 91 days old. That's excellent. A majority of them were nine days old. These were all filed for a update across all the libraries, which is why the open pull requests from the last meeting was so high. And that's why it's down now. And that leaves us with 39 open pull requests, which is much closer to our usual number. We had 19 issues closed by nine people and six open by six people, leaving us with 585 open issues. 97 of those are good first issues. If you're interested in contributing to CircuitPython on the Python side of things, check out circuitpython.org slash contributing. You'll find all of this information and more, including an actual list of the open pull requests and a list of open issues. If you're new to everything, check out good first issues. Those are a great place to start. If you want to get involved with reviewing, take a look at the open pull requests. If you have the hardware, test it. If you don't, take a look for code syntax spelling, that sort of thing. Leave us a comment and let us know you did that. And once you're comfortable with that, we can talk about leveling you up to the review team. The next step is library PyPI weekly download stats across all of the libraries on PyPI. We had 195,955 downloads and the list of the top 10 libraries from the past week by downloads is listed in the note stock. One thing that is a little interesting this week that I haven't seen since we got back into tracking this is that everyone on the, the whole library on the top 10 list is over a thousand downloads. Typically that's not the case. So there's been a lot of downloading in the last week. Library updates in the last seven days. There was one new library, Adafruit Circuit Python Pixel Map, and way too many updated libraries to list. So that was truncated. And that's what I've got. Next up is Melissa to talk about Blinka. Hello, so Blinka is our circuit Python compatibility layer for micro Python and single board computers such as the Raspberry Pi. This week we had seven pull requests merged by five authors and two reviewers. And there are currently seven open pull requests. There were three closed issues by one person and two open by one person, leaving a net of 86 open issues. There were 33,616 Pi PI downloads in last week, and there were 7,007 Pi wheels downloads in last month, and we are now at 100 boards. And that's it. Thanks for listening. Thanks. All right, next up is hug reports. Hug reports is the first of our two round robins where I will start and then I will go through the list. I will read off notes for folks that are participating but not able to speak, and I will call on folks that are able to speak to read their own. This is an opportunity for us to call out the great things that folks are up to in the community and just generally point out positivity. So, I will start and then I will head down the list. The next two will be people that I read off. Hug report to tech trick for making a about happy and getting the library report running again to know it for designing the stand for my upcoming project guide and shipping me a printed copy to Liz for being an amazing collaborator for being incredibly helpful and supportive and an all around great person. I didn't keep track of anything last week apparently. If I missed you, it wasn't intentional and a group hug for everyone. Next up is notes from anecdata was a hug report for Naradok for figuring out the multi device nature of the mdns host name issue. Next up is see Grover who's text only a hug report to foamy guy for always informative streams and patients with my questions and a group hug. Next up is Dan. Thanks. Thanks to spa blots in discord for and then in GitHub for debugging and then submitting a PR. There was a confusing HTTP server issue, which we tracked down to a dictionary being passed in and having being modified when it shouldn't have been and that was so that was a bunch of us worked on this and we figured it out together. Thanks to Bab lock be in GitHub for GitHub code spaces support for the circuit Python repo. I don't exactly understand this, but it sounds very interesting and I'm trying it. Thanks to bill 80 for the PR for Pico W access point support. A bunch of people are trying that already. And thanks to Jeff and Scott be after our 1pm internal meeting we had a very short 80 bug triage meeting again and managed to reduce the number of 80 bugs. So that's good. Okay. All right. Next up is DJ Devon three but I do not see them so I will read it off. I hugged everyone who agreed to receive a TR cowbell and provide feedback to John Park foamy guy and Reese brothers for their streams I learned something new every stream and a group hug. Next up is foamy guy. Alright, thanks, Kenny. First hard report this week. Thank you to Scott for providing throw review and feedback on the display change that I made inside the core. I learned a lot about both display and more generally just how the core works how to do stuff inside of it. So that was good. Definitely appreciate that. Thank you to everyone who's been discussing and sharing ideas about.info or more generally the way that we store secret information. I think it's a good discussion to be having. Even though it may be difficult to figure out what's the best path forward I think it's good to get it nailed down. So thanks to everyone for being involved. And lastly this week for me thanks to Johnny Bergdorf for putting me in touch with the simple electronics podcast folks may appear on a future episode of that podcast. So thanks. Excellent. Next up is Jeff. All right. Basically, I appreciate people sitting down and talking to me and working stuff through so. You and Dan and I had a good discussion last week. Dan and Scott and I had another useful discussion just before this meeting where we walked through some stuff about. Issues I was working on as well as the whole 80 backlog. And then Dan and Scott in particular for working together and finding a way forward from dot env we'll talk more about that later. And to bill 88 T for the pull requests that implements access point on Pico W. Really appreciate your work on that one. Thank you. Thanks, Jeff. Next up I've got notes from Keith, the E. E. High report to myself for a wonderful write up about what to expect when teaching circuit Python to folks with a programming background who might not have experience with electronics. And the hub for the community as a whole for always being awesome. Next up is Melissa. Hello. So I wanted to give a hug to everyone who contributed to us getting to 100 blink of boards to get need for quickly emerging a PR that brought that show that we had the 100 boards in the pickup Python org and a group of everyone else. Thanks. All right. Next up I have notes from Tammy makes things who gives me a hug report for hosting the meeting and a group hug. Next up is Scott. Good morning. First, a hug to Booleanmatic for fixing an issue with a slow duty cycle setting of PWM on the RP 2040. There's a PR out for that. Based on some discussion in the forums. Hug report to anecdata and Naradoc for helping with the empty NS name mangling debugging and testing. Hug report to evil Dave 666 for fixing your creator ID issue they found one adding another one. Lastly, a hug to Lee Atkinson 24 for the analog Baphio module that I revised last week. All right, thanks. And finally, I have notes for Tectric, who has a hug report for me for helping him out with Adabot and for a great conversation last week to learn more about mastodon. And to Naradoc for paying him about a neat issue with dependencies always enjoyed digging around in the packaging world again. And that is hug reports. Next up is status updates. This will go basically the same way as hug reports. However, this is an opportunity to sync up on what we've been up to since the last meeting and what we're going to be up to until the next meeting. So take a couple minutes talk about what's going on with you. And this is also an opportunity to provide tips and tricks if anybody's got quick questions, folks can answer and if it turns into something longer we can always move it to in the weeds. With that, I will get started. My list is pretty short. Last week I put a mastodon API intro guide into moderation. I moderated Liz's latest guide and updated the feather RP 2040 guide to reflect the latest version which now has a user controllable button. The boot button is now connected to GPIO4 and it is a right angle button so feather wings don't block it. This week, I'll be working on the I spy breakout guide with Liz. And then I have a project guide which is an event countdown timer display using quad alpha numeric three quad alpha numeric displays to scroll text. So that is sitting on my desk and looks excellent in the new stand. All right, that's me. Next I will read see Grover who is text only. Heads down working on a friend's vintage guitar pedal restoration for the last two weeks. Reverse engineered the capacitor leakage damaged PCB to help with component location not to remanufacture the board yet. Had to treat the pedal with great respect since the bucket brigade chips that components are no longer available. And yes the project involves circuit Python for the 80 9833 programmable waveform generator used for the audio tone and sweep tests and a link to that code I think is in the note stock. Developed a proof of concept wrapper class is that a thing that wraps a layer around display dot palette object to make it respond to typical list slice syntax. Imagining all sorts of psychedelic image surgery of bitmap images as a result. And finally snow shoveling lots of snow. Next up is Dan. Okay. In the past week I've been following up on and trying to reproduce a number of issues of 800 issues. Some of them are not reproducible. Some of them I'm not sure about so. I didn't actually solve that many issues but I'm investigating a whole bunch. I reviewed and tested a bunch of other people's PR is not all of them had to do with the core, but they're like HTTP server as I mentioned. So I oversaw and debug some HTTP server issues. That's kind of relapsed with what I just said. I just tried a little thing we have we're having a trouble with Pico W startups and on certain samples of the Pico W. So I just stuck a delay in somewhere and had the people for whom it was a problem tried and it worked for them. And Jeff and I are still scratching our heads about this. But we did discuss it in the internal meeting before this. And I'm going to start to work on beta five release notes. We have a bunch of things that can go in beta five and a bunch of things that can go in beta six. We'll probably just go ahead and do a beta five and do a beta six sooner though. We always say that and we don't always do it. So, but we need to catch up. We're behind it with zillions of PRs that we should put out there in a beta. Okay. Thanks Dan. Next up I have notes from DJ Devin three. Received PCBs of my cutie pie parent BFF. It's apparently useful for LED projects that need a lot of grounds. I will be using it in my dragon mask to make existing wiring much smaller. I have extras if anybody wants one. And there is a picture of that in the notes started assembling and packaging kits for TR cowbells to give away for beta testing. Found some serious hardware design flaws after more testing. I routed things in a way where all I squared C buses are being used should still function as intended. If people want to add a display or other peripherals, they'll have to use SPI only started designing cowbell version 1.3. Hopefully ensuring I squared C expansion and stamina will work. Made a YouTube video and upgrading the battery in a hyper X cloud flight wireless headset from 100 or 1500 million amp hours to 1800 million amp hours. It requires a three wire thermostat type battery that I couldn't find in the U.S. Had to get it from China took a month to arrive and the upgrade process was a success. Next up is foamy guy. Great. Last week I finished up a couple of changes in the core with the pixel map new core module as well as the display APIs. I resolved the issues that were reported in the Python layer for the pixel map. So the Python code that makes use of that new core module. I started working on updating Blinka display APIs to match the new core APIs. But I found that I ran into issues trying to use Blinka display in the way that I was using it, which is with Pi game. Kind of not necessarily how it's meant to work. So I ended up troubleshooting that and figuring out how to get it back to working in my environments and ended up spending most of the time on that instead of actually changing the API like I sat down to do. For this week though I do want to get back into that and actually change the API to match the new core one because we do want to match over there on the Blinka land. This morning I've been doing PR reviews and testing. A big one that I was looking over this morning was for the WizNet library that handles Ethernet connections. And I got the hardware out and we'll do some testing on that later on this afternoon as well. Some other stuff in my mind for this week. I want to try to come up with the easiest way to combine matrix portal projects or really theoretically any of the portal based projects. I've seen folks come on Discord a few times who are not necessarily brand new. They've gotten their matrix portal or whatever device it is, MagTag or whatever. They've gotten it out. They've hooked it up. They've done some projects. They've seen some cool stuff and they can switch between them. But they want to make it to where they can have one code pi that does multiple projects basically. Maybe they switch it with buttons or maybe it bounces back and forth on its own after a few seconds or whatever. I'm not aware of any examples that are quite like that. If anybody knows of one, point me towards it. But I'm going to try to come up with the best way to do that and just have something that we can show people that will hopefully explain the general approach for how to do it. And a couple of specific examples with some of those sort of beginner level matrix portal projects and trying to combine them together. A few other things that I'll be getting into are adding pixel map to the bundle that pixel map library is created. It's all spun up and got all of its stuff in, but it does need to be added to the bundles still, so I'll make that PR this week. And then in project ideas, I'm thinking about trying to make a menorah on the matrix portal and continuing with the matrix portal theme. I'm going to plan out and maybe try a few different ways to animate some little flames on the matrix portal display and see if I can get something that looks nice for that. So that's what I have going on. Thanks. Thanks, Tim. All right, next up is Jeff. Hello. First of all, a belated hug report to see Grover for working on this cool palette stuff. I am excited to see that come to fruition should make for some fun little projects anyway as to what I'm up to. I worked on this.env replacement. I'll continue that this week and in a bit down in the weeds, I will tell you what's going on with that if you haven't been following the PRs. Other GitHub pull requests activity. I opened a draft pull request for a future product called the Adafruit Think, Inc. RP2040. It's a little kind of tricky style board that has a ribbon connector for e-ink displays. It should be cool. I added socket pool.gai error so that when you are using sockets and you get an error, you can tell whether it has to do with resolving the host name or not. That's compatible with standard Python socket module. I wrote a PR called ensure orderly shutdown of SSL socket. And after talking it through with Dan, I think there's just one little cleanup to do and then we will merge that. I also need to test whether there's a different way to cause the crash that was originally reported. This fixes a user reported hard fault. Whether there's another way to reproduce it that doesn't involve the shutdown of the whole Python interpreter. And that will confirm that kind of my understanding and Dan's understanding of what is going on is accurate and satisfied as to what the root cause really is. Let's see. There's some other items in the document. I'm not going to read them all off. The other one that I fixed was there were some problems with SD card IO on the SAMD family microcontrollers where it would say that your pins were in use when they should not have been in use. So I fixed that and I tested it and confirmed that the Adafruit SD IO breakout works with the Grand Central M4. I reviewed and accepted some other PRs including the PyCow access point from a community member. And so my work this week is to complete the next keyboard guide. I have texts that I need to write. I need to complete the wiring for the version that I'm going to photograph in the guide and then make those photos. And then after that it's returning to work on the .env replacement. And that's what I got. Thank you. Thanks, Jeff. Next up is Melissa. Hello. So this last week I worked on rewriting the USB workflow or actually continue doing that to use the file system access API to be able to select a working folder and then I have a PR in for that. I also fixed an issue with the USB web serial connection locking up on disconnect so it doesn't do that anymore. And I helped with adding boards to Blinka and on to circuitbython.org. And this week I'm working on improving the overall connections workflow when there are multiple steps. So like if somebody like connects to serial but doesn't select a file system then it's total handles stuff like that better. And then I'm working on improving the BLE workflow after that. And that's it. Thanks, Melissa. Next up I have notes from Tanny Makes Things. Last week, super busy with work and holidays but did some work on a digital Christmas ornament, a gift for a coworker. And on my attempts to add NRPM message support to Adafruit MIDI. This week hoping to continue to make progress on these things despite the fact that we're doing performance reviews at work. And I'm missing next week's circuitbython meeting for a three hour performance review calibration session. Other had to get new tires on my car because of a huge nail on the freeway. And I was pleasantly surprised when my car stereo noticed the drop in tire pressure and showed me an alert with a screen displaying all four tires, all four tire pressures from the TPMS sensors. This gave me enough warning to get to a safe place before the tire went flat. I'm curious now to look into how TPMS works because that was really cool. Next up is Scott. Hello. I fixed an issue with the ESP32 S3's deep sleep, which has been a long standing bug that we thought was an expressive problem. And it turned out to be because we don't use their build system. There's a weird build flag that we needed, linking flag that we needed. So I found that and fixed it. There is a report that it's not working for somebody, but I'm going to take a look at that because I was testing it and it seemed to be working okay for me. So I'll take a look at what's going on with them. I also fixed the MDNS name mangling issue. The expressive MDNS code tries to make sure that the hostname is unique. MDNS can have a way of seeing if anybody else has the same hostname, but it's not really designed to work when we have two hostnames that we're dealing with, one that's unique like we have and then one that's shared. So I improved their MDNS code to make sure it only mangled the right thing, although it doesn't actually mangled the thing that clies. But anyway, it works, I think, better for a second by then. They opened an issue on their stuff. I also reworked the... Oh, I copied it as audio buffio. It's analog buffio, which is an API for getting a whole bunch of analog samples in a row. Not really meant to do into audio or anything, but you can set how many samples you want and how long. I reworked it a little bit to... The buffer was being passed into the constructor, and I moved it to pass it into the read function, and I renamed that and stuff. So that'll come in the next beta. You can now control C as well if you really slow it down. And now I'm starting to redo the coprocessor API. I've sketched out a memory map module, which will allow for just raw read-write access to particular regions of memory, and that's important for writing to the memory that the ultra-low-power processor on the S2 and 3 uses. And then I'm going to look at the coprocessor API as well. I haven't fully decided what that API is going to be. I don't think... I was just looking at the RB2040, and I think it needs to... It may need to be something more custom. I'm not entirely sure yet what that API will be, so I might switch it from a generic coproc API to a specific ESP-ULP API, maybe. That sounds better to me already. And then I am starting to travel for the holidays next Wednesday, so I'm trying to do any urgent stuff that comes before that. I'll be working some and will have some stuff with me, but not nearly as much as I have here at my home office. So if you have anything that you think is urgent for me, please let me know. And then in non-circuit Python stuff, I'm... I did a Google take-out of... We have two Nest cameras now that we're running in the house. One to watch Ari, who is my kiddo. And then one in the... Yeah, one in is Craven, one downstairs, and I decided to just download all of it to see, which turns out to be about 700 gigs of MP4 video from the last two months of all that. So that's been interesting, and I'm really glad I have fiber internet. I can download a 50 gig file in like 10 minutes? 10 or 15 minutes, which is amazing. And I have a Python script that I'm using to hash all the files before I scroll them away. So hashing them, keeping track of how big they are and storing that in a SQLite database. And I want to do that also because I want to get metadata from Google Photos and be able to know which photos do I have locally, which photos do I have on Google Photos, because they're automatically backed up that I need to download and all that stuff. So that's non-circuit Python things. And then talking a bit more about what I'm doing kind of once I'm in Michigan, which is where I'm going for the holidays. I want to kind of get the STM32G0 StemAQT tooling kind of all the way there, meaning we can like load code and have a template repository for creating code that runs on a StemAQT device. Probably acting as like an IO expander, or I was thinking it would be cool to have a program on the G0 that was literally just like a memory access thing. So you could, in the same way that memory map allows you particular access to stuff, you'd be able to do that over I2C. And basically write Python code that is very slow, but is actually interacting with anything on the other chip, which would be kind of neat. Dan and I talked about using a circuit Python device and PyOCD for a DIY SWJ tag in a pinch sort of thing. So for example, if you have an old NRF board that has a bootloader that can't update itself, this would be a way for us to kind of walk people through using any of our boards that run circuit Python to just like in one time just get it flashed. PyOCD makes it really easy to use plug-in system, which is really handy. And then I'm going to look some more into the logic analyzer software world, because one thing that I've wanted to do for a long time is a basic logic analyzer as well. And I'm kind of brainstorming a feather wing that would be like a combo SWDJ tag and a basic logic analyzer just for like really simple debugging like I squared C and spy and stuff. Yep, so this is the last full week of work at home, and I'll be around off and on over the holidays. And that's it for me. Thanks, Scott. Finally, I have notes from Tech Trick. This is last week, final touches on the PyPI stats reporting for libraries in Blinka. All the bugs should be worked out, but I've said that before. Happy shrug emoji. I'm working through many of the issues regarding typing and library infrastructure in my to-do list and going through a small backlog of PR reviews. This week, getting more information about the pilot update for the learn guide repository, starting to fix the warnings in the GitHub actions, or that GitHub actions is raising about deprecation. And in personal news, finished my last lab for my grad course for an embedded systems course. Thank you to everyone in this community for helping me to learn enough that programming the Arduino in this course in general has been relatively pain-free. Took and passed the Arduino certification test, though I'm still confident in my ability to conjure blue smoke when using one, and learning and practicing my C skills by doing the advent of code and C this year. It makes me appreciate Python, MicroPython, and CircuitPython so much more. And that is status updates, which brings us to in the weeds. In the weeds is an opportunity for more long-form discussions or discussions that just didn't fit in status updates. If you have a topic, please post it while other people are talking. Otherwise, once we get through the four listed here, we'll wrap up. So I will call on each person to talk about their topic. So first up is me. The new Feather RP2040 revision now has a user control button on it. Obviously, there are far more of the previous revision in the wild than the new version yet, and all those original versions will be in the wild for a long time. So how do we handle adding board.button to the Feather RP2040 CircuitPython pin definition? I basically got real excited about doing this, and then it hit me that it doesn't work on, you know, a bunch of... Is there a new board diff? There isn't a new board diff. It's the same product number, right? Yeah. It's a revision of the same product. We won't ever be selling them again with a flat button that isn't user-controlable. Maybe we should make a new definition that's no button. I don't know. Yeah, I know. I gave it a lot of thought, and I don't have a conclusion either. I think that that's sort of... I mean, in the download, maybe we should, in CircuitPython.org, maybe we should have a Feather RP2040 no GPIO4 button or something like that. And it's a different color, right? Yes, it is black again. Right. So that could also be... So I think it sounds kind of good to me to... Rather than have a with button, or maybe we should just have like... What's the color of the other one? Or the other ones could be pink or something, right? Or black, yeah. So I think changing the name of the old one makes sense to me, but I don't... I agree. Because it seems weird to have a weird named one for every board moving forward? Yes. Don't change IDs. You could rename it on the website, but the actual name of the board should be the same. Doesn't it... Doesn't the build have its own name, or does the build pull from the board name? Inside, yeah, inside... Do you understand what I'm asking? So I'm saying that we can copy the old one, call it no button, and then edit the regular one, and don't give it a new name. No. Why not? Because that changes the experience for the people that have the old one. They need to know that the name of their thing changed. Right? It's an ID. It shouldn't mean something else in the future. I would just call it V2, or Rev, whatever. Yeah. If it has a Rev, does it have a Rev on it? Yeah. It's got to have a Rev. I just got one. I think it's D. Well, it's got a D on it. I guess that would not be a terrible way to go, because people can actually look at the board and see the circle. At one point, we had a Rev B for like Metro M4s or something like that. That board went through several. But we didn't sell nearly as many of the other old ones. Something Scott mentioned, tickled. Is it possible to rename everything on circuitpython.org for that board? It'll still be the same. The build or whatever will still be the same. The background stuff will still be the same. Don't include Rev D in the name on circuitpython.org for the new one, but have the build say Rev D in it so that it's different, right? Was that what you were suggesting, Scott? Yeah. That's what I'm saying. The ID should stay the same. But if you want to have, in the human readable version in both, you could say this button or that button. Yeah. OK. Style. I don't mind that at all. I have another idea. OK. Which is, why don't we call the name of the button Rev D button? But how does that, then people without the button can still put in board.revdbutton? Yeah, but they will say, why is it called Rev D button? But they also, they both have buttons. They both have boot buttons. Yeah. But the difference is one of those connected GPIO and the other is not. And I don't think calling it Rev D button makes sense because, A, it won't work with existing code, which a lot of things do. And B, people will still try to use it and it'll do nothing. OK. I think changing it to something weird in the existing build is probably not the best way to go. Right. I don't suppose we can detect when CircuitPython starts whether the button is hooked up in that way or not. I mean, I'm pretty sure the answer is no. And anyway, we can't, we don't have a way to change the content of the pins, the microcontroller. To change the content of the pins module. Yeah. So that doesn't help forget it. So Scott, are you OK with us or me creating the second for Dev calling that one something different in CircuitPython Core and then changing up the name of the existing one on CircuitPython.org, like visually? Yeah. I would change both. I would, I would have, because you're going to want to make it clear what the difference between the two is. Do you want them to have a different, different PIDs, USB? I mean, that would probably be best. I mean, they're cheap. Right. Yeah. Yeah, I don't think why not. OK. I will need help with that. But because I've not done that before, but I'm happy to learn. Can we? Oh. Aha. Now I understand. Well, I just, I was like, what? I don't get it. The boot button is connected to GPIO4 as well. On the new ones only. Right. Before it was just the boot button. That was the very first RP2040 board that she made and she didn't connect the boot button on that one. She put a diode in. So that it can still control the flash. Yeah. It's still a boot button. It just also is available in code, just like it is on the QDPI, just like it is on whatever, like it's the same on all the other RP2040 boards. Oh, right. It's the trick that the Pimeroni people did after we did this first board. Yeah. I just add a new board deaf and call it RefD. OK. And in the text of both boards on trickbython.org, we should say like if your boot button is angled this way. Yeah. And do you have a RefD on there? I mean, there will be a RefE maybe at some point too, so which might have no changes. So I'm trying to think of a better name than RefD, but I don't know. I would just call it RefD and assume that people understand ordering. Yeah. And then you want new PID, VID, or whatever it is that changes? Yeah, PID. OK. Got it. Yeah, VID is vendor ID. Yeah, OK. OK, OK, OK. That stays the same. Got it. Yeah, Dan can show you how to do that or I can show you how to do that. Keen. I already changed the board deaf to include the button, but I didn't get any further with anything. So it's not like PR or anything. It's just local, but OK. Thanks. The next topic is by Jeff. Right. So I was going to talk about this .env thing. And after I get done talking, I will paste links to a couple of issues and to my branch. But basically kind of collectively we identified that there were some things we didn't really like about the .env. Some of those things were the final name is difficult for a lot of people, especially on Mac, to access at all. It's a pain to access hidden files in this way. The .env, there are like packages for .env for several different programming environments, and they all get the quoting and the syntax a little bit different. And so we felt it wasn't quite standard enough. And also it's very different from the way that quoted strings are written in Python. So we went around for a while in a couple of meetings, and we've decided and documented on one of the issues that what we're going to do is implement a subset of the Tommel configuration language, which is similar to any files. If you know those, that's INI initialization files. ANY files would be something else. Anyway, so the new file is going to be called settings.tommel. And to get values out of that, you will use os.getenv, which does work today with .env. It's one of the two ways to get it. That will be the one preferred way to do it once we switch to settings.tommel. And we're implementing a subset of the file format. So you'll be able to read strings and numbers from what is called the global table, which is just the part at the top of the file. This leaves it open that we could later add a maybe implemented in Python as a whole Tommel parser, but that would be for the future. Anyway, and then in the notes document, it shows an example of what it would look like to set your Wi-Fi SSID and password. And of course, we will do our best to update all the guides and docs to reflect this. Due to the timing of things, this is probably not going to be in the next beta, but the beta after that. And yeah, so that's kind of an overview of what's going on. And if anybody has questions, I'll answer them. Guys, I'll mute and go find those links for the chat. I guess it's late. All right. Thank you. All right. Scott, you have the next topic. Oh, thank you. So Dan, Jeff and I were just talking, going through 8.0 issues and realizing that I think what's going to happen is that we're going to do 8.0 betas throughout the holidays and then we'll expect a release candidate in January for 8.0. And then we'll get 8.0 stable in January. I just wanted to give a heads up for folks on that. Any other thoughts and opinions about 8.0? I just wanted to mention that then. The next topic I have is thinking about the new year. We tend to start the new year with posts about what we think Circuit Python should be or do for the coming year. We've called it Circuit Python 2022. And next year is 2023. Usually I kick it off with a blog post on January 1. I just wanted to have an in the weeds topic for thoughts or things that we should do differently this year than we've done in previous years. Otherwise, what it was last year is like it's a kickoff post and we get an email set up an email alias and when people blog post about what they want we'll then kind of like post them once a day or once a week and we'll link to them and have a running list of all the posts that people have done. And then at the end of it we'll have like the final list of folks that have done Circuit Python. 2023 posts at the end of that. So that's typically what we do. Are there any thoughts or things that you'd like to see changed for going into this next year? I mean, I think it's worked pretty well. So I'm not really concerned about applying changes. Like what I would say is if anybody comes up with ideas between now and January 1 please let us know if there's some way you think it could go smoother, that sort of thing. But otherwise I think it works. All right. That works for me. That's how we've done it before. Now I've got to decide what I'm going to write. All right. So I'm going to go ahead and wrap up. This has been the Circuit Python weekly meeting for December 5th, 2022. Let me get to my thing. Thank you to everyone who participated. If you want to support Adafruit and Circuit Python and those of us that work on Circuit Python consider purchasing from 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 adafruit.daily.com to subscribe. The next meeting will be held next Monday as usual I believe at 2 p.m. Eastern, 11 a.m. Pacific. This meeting is held on the Adafruit Discord which you can join anytime by going to adafru.it slash discord. To be notified about the meeting or any changes to the time or day you can ask to be added to the Circuit Python Easter's roll. We hope to see you all next week. Thanks everybody.