 Hello everyone, this is the CircuitPython Weekly for January 24th, 2022. This is the time of the week where we get together to talk about all things CircuitPython. My name is Scott and I'm sponsored by Adafruit to work on CircuitPython. CircuitPython is a version of Python designed to run on tiny computers called microcontrollers. CircuitPython development is primarily sponsored by Adafruit, so if you want to support them and CircuitPython, consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join any time by going to the URL, adafru.it-slash-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 the U.S. holiday. In the Note Stock there's a link to a calendar you can view online or add to your favorite calendar app. We also send notifications about the upcoming meetings via Discord. If you'd like to receive these notifications, ask us to add you to the CircuitPythonistas Discord role. There's a Note Stock to accompany the meeting and the recording. The Notes document contains timestamps to go along with the video, so you can use the Doc to view only parts of the video that interest you most. The meeting tends to run 60 to 90 minutes, so this gives you the option to skip around. After each meeting we post a link for the next meeting's Notes document to the CircuitPython Dev Channel. On the Adafruit Discord, check the PIN's messages to find the latest Notes Docs 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 CircuitPython and Python on hardware in the community. It's a preview of our Python on Microcontrollers newsletter. The second part is the state of CircuitPython libraries in Blinka. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers separate from what we've all been up to. The third is Hug Reports. Hug Reports is an opportunity to highlight the good things folks are doing, taking time to recognize the awesome folks in our community. The fourth part is Status Updates. Status Updates is an opportunity to sync up on what we've been up to. Take a couple of minutes and talk about what you've been doing in the last week since the last meeting and what you'll be up to over the next week until the next meeting. The fifth and final part is in the weeds. In the weeds is an opportunity for more long-form discussions. These discussions can come out of Status Updates or be something you've identified ahead of time is too long for Status Updates. And that's how the meeting will go. With that, I'll get started with Community News after I take a time code and switch to the note stock. Alright, so Community News. This is a look at all things CircuitPython, MicroPython, and Python on hardware. It's a preview of the newsletter that we'll talk about that goes out every week and we'll talk about it a little bit later. So first up, time code. The Raspberry Pi Pico, the RP2040, turns one year old. About a year ago, Raspberry Pi released a new type of product, their first microcontroller, the RP2040, and a development board which uses it, the Raspberry Pi Pico. Usage by the electronics and hobbies community has been quick due to great functionality at a great price point and has generally remained available during the silicon shortage. Bigger companies were quick to release RP2040 boards of their own, including Adafruit, SparkFun, Pimeroni, and many more, as well as smaller companies and individuals. Scores of designs rely on this versatile chip to perform remarkable tasks with lots of RAM, flash, dual cores, and user-programmable PIO. This chip packs a punch. Read an excellent article by Alistair Allen which discusses MicroPython and CircuitPython at raspberrypi.com. Next up, and something I meant to look at that I didn't get to look at yet, a study in the popularity of CircuitPython GitHub repository. An interesting look at the number of GitHub stars awarded to the Adafruit CircuitPython GitHub repo, marked increases on the dates that the Adafruit Pi Portal in 2019 and the Raspberry Pi Pico in 2021 were released. CircuitPython enjoys increased usage in many segments of the embedded ecosphere. Next up, the PiCast celebrates 10 years of Raspberry Pi, new episodes with Lady Aida, Evan Upton, and more. The PiCast celebrates 10 years of Raspberry Pi. Adafruit's Lamour Fried will be on a livecast on February 15, 2022. There's more info from Tom's Hardware and linked to the scheduled event on YouTube. Next, we have some updates for CircuitPython 2022. If you don't know, CircuitPython 2022 is our kind of annual round of what folks want to see from CircuitPython in the upcoming year. We've done it the last few years, so it's a great way to see what everyone is thinking about. Since the last newsletter, we've had updates from FOMI Guy to Shippu, MD Roberts, Mark Komus, Mark S, and Ken all posted to the blog. There's still time to get feedback on CircuitPython 2022. I encourage everyone who hasn't done one to write one up. I'd love to see what you all want to work on. And my goal is to have it all kind of bundled up and ready to go by the end of this week, and I'll talk. I'll mention that again later too, but please do it this week if you're going to do it, if not, that's totally cool too. But I'd love to hear all about it. Next up, we have, oh, the computer was doing something weird. Yes, MicroPython works on MS-DOS 2. Thinking you'd like to program some Python for a retro MS-DOS board or machine? MicroPython has you covered. The link of somebody running MicroPython on MS-DOS 5.0. Apparently a floating point co-processor or separate emulation software is needed also. There's details there for building MicroPython for free DOS. This has all been a preview of the CircuitPython Weekly newsletter. The CircuitPython Weekly newsletter is a CircuitPython community run newsletter emailed every Tuesday morning. The complete archives are available at adafruitdaily.com slash category slash CircuitPython. It highlights the latest Python on hardware-related news around the web, including CircuitPython, Python and MicroPython developments. To contribute your own news or project, edit next week's draft on GitHub. Check out the github.com slash adafruit slash circuitpython dash weekly dash newsletter repo. There's a draft folder there. You can submit a poll request or you can edit the files directly from GitHub. You may also tag a tweet with hashtag CircuitPython on Twitter or email cpnews at adafruit.com. Thank you to Ann for putting that together. Next up, we have the state of CircuitPython libraries in Blinka, which is a statistical overview of the health of the different pieces of the broader CircuitPython project. So we'll go through some numbers for the overall and then go to the core libraries in Blinka after that. Another time code. Overall, we had 60 poll requests merged from 23 different authors, which is awesome. Sixty's a pretty high number for us, so that's great. Thank you, everybody. In particular, I want to thank a few folks that are relatively new based on my recollection. So Emmanuel Tomy, 62, STI 320A, and Zero Hot Pot Man Zero are all relatively new names here. Actually, Ann Lantow looks new to me as well here. I forgot to bold it earlier. Thank you to all of our 23 authors. Also reviewers, we had 13 reviewers for those 60 poll requests. So thank you to all of our reviewers there. We really appreciate you. And as always, reviewers are the folks that make it possible for folks to author poll requests. So thank you to all of our reviewers for being timely with folks and giving feedback. Issues-wise, overall, we had 35 closed issues by 16 people, 25 opened by 24 people. So lots of people being involved, and we are net down 10 issues. So that's awesome as well. And Jeff wants to give a quick hug report early on, a hug report for those folks who comment on PRs but may not be official reviewer status. We've definitely seen this where people say, like, oh, I tried this and it works. That's super helpful. And Jeff also says that if you are one of those folks that have been helpfully commenting but not being official reviewers, we'd love to have you as official reviewers. We're happy to give folks that access. So please let Katni or I know if you want to do that and we'll make that happen, particularly Katni. Katni's much better at it than upgrading people than I am. So thank you, Katni, for taking that on and thanks to all of the folks that contribute on PRs. Okay, let's get into some more details. So let me go over the numbers for the core. In the core in the last week, we had 25 poll requests merged from 13 different authors. A few of the folks I mentioned earlier are there, so thank you to them again. And we also had seven reviewers, which I think is generally more than we normally have. So thanks again to everybody who's doing reviewers in the core. For the core, we have 13 open poll requests. The two oldest are 142 days and 130 days. So those would probably be good to look at. And then we have a number or a few that are zero or one-days-old. Issues-wise, for the core, we had 12 closed issues by seven people and 14 opened by 13 people. So more issues opened than closed. So we are growing a little bit. We have 482 open issues, which is definitely slightly more than before. That's not necessarily the end of the world, but I want to make sure that we are keeping on top of all the issues that we have. And the way that we do that and the way that we triage is through the milestone system on GitHub. We currently have three open issues for kind of the soonest milestone, which is 7.2.0. And then we have 20 open issues for 7XX, which is kind of like the stuff we should probably do for 7.0 stable releases. We also have six issues not assigned to milestones. So that is the bucket where we should really take a look and make sure that things are being looked at and categorized in case something urgent actually comes up. Lastly, we do have this bucket called long-term, which is just things that are great ideas, but not things that we're going to do immediately. And in my book, it's okay for that number to grow, the long-term bucket to grow. So yeah, that's why triage is important. And with that, let's kick it over to Katni for an update on the library numbers. Thanks, Kat. Thank you. So this applies to all of the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore CircuitPython underscore, as well as a few extras, including the community bundle and our cookie cutter. So we have 31 pull requests merged from nine different authors and 10 different reviewers. In terms of merge pull requests, the two oldest were 237 days old apiece, and that's really great to see that we're still getting through with the older PRs. And this is actually a pretty large number of pull requests, which I think some of it has to do with the fact that we just did an update. I think a lot of these are unique. And that leaves us with 29 open pull requests. We have 20 closed issues by 12 people and 11 open by 11 people, leaving us with 634 open issues. 236 of those are labeled good first issue. 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. If you're interested in reviewing, check out the open PRs. And if you're interested in contributing code, check out the open issues. In terms of library updates in the last week, we have no new libraries, but there's a list of updated libraries which you can read in the notes. Overall, we're still getting through older PRs and we're seeing a lot of new stuff as well, a lot of new contributions. So that's really great. So thank you to everybody who's been contributing. And thank you to Early Thank You to Foamy Guy for getting through some of those older PRs. And that's what I've got. Awesome. Thank you, Katnie. All right. Next up, let's go to Melissa for an update on Blinka. Hello. Blinka is our CircuitPython compatibility layer for MicroPython Raspberry Pi and other single board computers. And this week we had four pull requests merged by three authors and two reviewers. We currently have five open pull requests amongst all the repositories. And there were three closed issues by three people and zero open by zero people, leaving a net of 68 open issues. There were 16,656 PiWheels downloads in the last month. And we are currently supporting 87 boards. And that's it. Awesome. Thank you so much, Melissa. All right. And that's it for this Data Circuit by the Libraries in Blinka. Next up, we have Hug Reports. Hug Reports is a chance for us to say thank you to the folks in our community that are doing awesome stuff. It's a great way for us to both acknowledge the cool things that folks are doing and also reinforce the things that we value as a community. So two for one thing there. And I will start, and then I'll go through the list. And if folks are marked as text only or lurking, I'll read it off for you. If it's not marked that way, then I will call on you and let you speak instead. So first up for me, I have two dual Hug Reports. The first is for Game Boiler and MicroDive for both working through longer review cycles. There's a couple of PRs that took a few iterations to get going. And I appreciate that both of those folks are persevering and making changes. And Circuit Pipeline is going to be better for it. So thank you both. And then also in the Discord front, I wanted to specifically thank CareString and AJS256. I think that's the right number for being new folks that are helping others on Discord. I want to make sure that I don't not acknowledge that there are a lot of other existing folks that are helping as well. So thank you to those new folks. Next up, I have notes from Anecdata. Anecdata says Hug Report to Tanute MicroDive and the whole team for bringing the very capable ESP32S3 and Braggum Ports to Circuit Pipeline. Next up from Cgrover. Hug Report to Jerry N and Foamy Guy for quickly reviewing, testing and approving the update to the Adafruit Circuit Pipeline STMPE 610 Touchscreen Driver for the 2.4 and the 3.5 TFT feather wings. Next we have from Charles, we have a group hug. And now we're going to go to Dan. Also in the vein of Discord helpers, thanks to NeroDoc, Hem, Deshipu and Jerry for helping people in Discord. I see that over the weekend a lot. Thank you very much. All right. And next up is Jepbler. Hello. I wanted to start with a hug to Foamy Guy for agreeing to join the rotation of meeting hosts and just generally taking on more duties. To Katni for taking time out to chat about non-circuit python stuff. It's always a pleasure to keep up. And to Lady Aida for supplying me with such fun projects to work on. Awesome. Thank you, Jepbler. Next up is Foamy Guy. All right. Thanks, Scott. Hug Reports this week for Sea Grover who made some nice improvements to the STMPE 610 driver, which is from the TFT feather wings. So those can work with all of our display IO widgets now. So thank you to Sea Grover and also to Jerry who tested that out some. Thank you to Katni who has shown me the ropes for so many different things most recently or I guess soon to be running the meeting, but also so many other things. I really appreciate all the help that I have gotten from Katni. Everyone who wrote 2022 posts, I was reading through those this week. There's lots of great stuff in there and I saw there's some new ones linked up above. So I'll catch up on the rest of those as well. And then a group hug to everyone. Thanks. Thank you, Foamy Guy. And I got two over the weekend. So I'll be doing another Circuit Python 22 post later today. Next up is Jerry. Hello. Let's see. There they are. Yeah, thanks. Oh, no. I scrolled down too far. Thanks to Scott for making the quick and very useful change to the C3 file system to make it writable. And Katni for the really fun project suggestion and C Grover for the new improvements to the STMP 610 library and Dan for rescuing me in a discord chat that I was sort of out of ideas and not really thinking well through. So he took over and made it all good. Awesome. Thank you. Thank you, Jerry. Next up is Katni. All right. So first up to Jerry for talking through and then running with a project idea I have and then providing code for it and thoroughly explaining all of the updates that he's made to Mark Gambler for joining in on the project adding that life Holly batteries can handle serious cold and suggesting solar power. Also to Mark for offering to write up a guide page on the new IS-31 updates. Once those are merged, we can get that published to Fummy Guy for agreeing to join us in running this meeting and for continuing to work through older library PRs to Sheehan who is one of our internal Adafruit folks for the quick fixes to the template setup and the learn system. Every time I find a bug, she's always quick with a fix and that's excellent. And finally to Matt Goff on GitHub for submitting the fix to an issue I filed on the PrettyPins repo a while ago requesting that the title and the product URL be centered to each other when the pin labels are generated. They were right justified and I almost always end up centering them. So I figured generate them centered and deal with it if I have to change it. But it was a very low priority thing and somebody else picked it up and that's excellent. And a group hug. Awesome. Thank you so much, Catney. Next up we have MakerBelisa. I just wanted to give a group hug to everyone. Awesome. Thank you, Melissa. Next up I have notes from Mark Gambler. Mark says, I have a report to Tanute for doing reviews and some great suggestions for the PR I submitted. I have a report to Catney for listening to an idea for a guide edition I had for the new IS31 code I submitted and helping me start with that and a general group hug. And next up is Paul. Thanks for having me. I wanted to give a hug report out to Ann for her work on the newsletter. She's highlighted a couple of my projects. She's given some love to the upcoming podcast and it's really, really appreciated. Awesome. Thank you, Paul. And welcome to the weekly. All right. And that's it. Next up we have Status Updates. This is done as a round robin as well where I will start again and we'll go through the list. Same rules apply. If you're a text only, I'll read you off. Otherwise I'll call on you. And I'm just going by the order of the note stock. I know we got a little out of alphabetical order. So it didn't match the discord, but that's fine. I'm just going by the note stock. So be aware of that. Okay. And Status Updates, it's a chance for you to talk about what you've been working on in the past week and what you plan on working on in the coming week. As a general way for us to know what's going on but also collaborate if we're working on similar things or if somebody is working on something that we've worked on before. All right. So last week, it was a lot of ESP32 S3 odds and ends. Lady Aida was working on some upcoming S3 C3 boards. And so there was a lot of she finds lots of bugs, which is great. So in I don't think any particular order. I fixed a crash when the tick happened on the other core. So I moved circuit python to run on the second core on the S3. But there was a little bit of circuit python code running on the first core that was causing an assertion error and general badness. So everything should now run all of the normal circuit python code should now run on the second core alone. Which leaves the first core for Wi-Fi and VLE stuff, which should be really nice. I increased the amount of heap for the S3 and the C3 for builds that don't have a separate PS RAM. So that's really nice. Both of them have more built-in onboard RAM than the S2 does. So that gave us some more breathing room. I added the Espresso C3 board definition because I have one here and it wasn't added yet. I fixed the NeoPixel weirdness that was happening on the S3 ESP dev boards. It was due to having circuit python float the pins when nothing was using it. And it turns out that floating pins is actually less power efficient than using a weak pull. So now we pull up in almost all cases. So I did some stuff with that. So that's changing what happens when we reset a pin in circuit python. It did cause some bugs so I had to fix that. Followed up with a fix as well. Where it wasn't working on some boards and I should think I think Jerry and one other person found it as well. The C3 file system is now writable from circuit python as well. That was a quick thing that Jerry also thought of. So that was easy for me to do so we did that. So anything any circuit python any circuit python build that doesn't have circuit pi usb enabled will now default to having the file system writable from circuit python which makes a lot of sense. Can I just get a quick question about the C3? Sure. The button defined in the pins is that supposed to be the boot button? I believe so. Okay. I tried it real quick and it didn't seem to respond but before I try anymore I want to make sure it was actually the right button. So I'll try it again and I'll final issue if it doesn't work. Yeah, I probably just messed it up. I've been known to mess the stuff up like that so thank you for trying it. Okay, so this week I'll fix that bug that Jerry's found and then the full week last week was only four days because it took Monday off so I'm excited to get kind of deep into the BLE weeds Bluetooth low energy weeds on the S3 hopefully getting advertising and scanning going which are the kind of the first first steps of BLE behavior and then also I'm planning on I'll be doing circuit python 22 posts throughout the week as they come in so if you do post one please email circuit python 2022 at aderford.com. That goes to Phil and I and I usually will take that and blog them up on the blog so that people see that it's happening and sharing it out. So I'm calling this Friday is the due date for that so please do that this week if you're going to do it and then I'll do a final post for it on Friday this week after my stream. All right next up I have notes from C Grover so C Grover says so that those old TFT feather wings and the inventory could be used on new projects I updated the STMPE 610 driver PR including some new examples and a touch screen calibrator. The new driver provides compatibility with interactive display I.O. widgets and buttons and automatically synchronizes the touch screen orientation with display rotation working on something similar for Adafruit underscore touch screen library three new PCBs arrived and changed project priority somewhat. The PCBs are for feather wing icing the AMG 8833 thermal camera breakouts breakout boards a refactored I squared C motor controller and power monitor combo wing which is a DRV 8830 plus an INA 27 27271 and a refactored NAU 7802 dual load cell wing and next up we have Dan okay thanks I made a minor fix the open function call in circuit python and micro python also doesn't do a very good job of vetting the the characters that are used for modes like read write append and all that and so someone actually discovered a bug bite saying only be instead of RB and thought it was their fault but it wasn't so I fixed that there was even a comment from micro python people like this is a to do so I did it someone else in the forum was having trouble with they seem it seemed like that we sold them some toggle switches that they thought had high resistance it turns out that if you actually pass it through then the high resistance becomes low resistance but that was a very fundamental hardware thing to check I'm debugging various people have had various I2C problems on ESP32S2 and they seem to be getting worse or something I don't know someone mentioned a particular sensor so I'm debugging that I'm also debugging some one wire problems on ESP32S2 and much more interestingly I was able to expose multiple file systems through USB like I have a pie portal that will show circuit pie and also show the SD drive at the same time and this was actually only like seven lines of code but it works much better on Linux than it does on windows or macOS on those the latter two you have to like really disconnect and reconnect USB programmatically but then it does work so what it means is that you'll have easy access to things like SD card drives and this will put something in to do this pretty soon probably okay that's it awesome thank you Dan alright next up is foamy guy alright so I'm still working through older PRs probably the one that I found coolest this week was the STMPE 610 just because I am a sucker for all things display IO updated the NICO CAT program that I showed on show until last week to follow your finger around when you touch the screen so it'll run towards the spot that you touch and we put a little red laser dot in there because I thought that seemed fun yeah thank you this week a new project coming down the pipeline is showing I think on a mag tag or a pipe portal some stats that come from this government analytics website analytics.usa.gov there's a link in the notes if anyone wants to check it out but they provide a bunch of like web traffic and other types of analytics about different stuff and then also I will be working with cat need to learn how to run this this meeting in the future and that's what I have thank you thanks for the guy next up is jeb where hello so I am totally lost last week was floppy stuff again I got flux writing working which means actually putting data back on the floppy disk but that only works in Arduino so far I've started work on grease weasel adding support for a disk format called g64 it's a format that's good for archival storage of coffee copy protected software for the Commodore 64 coffee protected software is something else I'm not sure what that is and I also successfully used an archived mac 800 kilobyte floppy image in a mac emulator which I did a short video of on the Adafruit YouTube I had partial success archiving a Commodore 1541 disk image and using it in a Commodore 64 emulator it will load the loading screen but then doesn't progress beyond that because the image format doesn't use copy protection which leads to the item that I started this list with and then when I was ready for a little breather on the floppy disk stuff I implemented a pure python module for the rp2040 that can drive 8 parallel strands of neo pixels from 8 IO pins it uses pio and I put that up I think on a github just I haven't really publicized it yet so this week more floppy disk stuff including finishing up this g64 disk format and then hopefully I'll be able to show I read this floppy disk into my computer and could run the game in a Commodore emulator should be fun implementing a pio or timer based flex read write for the rp2040 what we found is we we have just these loops coded in C for reading and writing and we'd really like something that is more dependable as far as the timing goes and that's really hard to do with just a loop in C so using a special peripheral on the rp2040 will just make it work better and more consistently I may implement dot wrap and dot wrap target in the pio assembly language and in the core especially if I need it for the pio based flux routines and I may also be bringing in an implementation for the same b51 from paint your dragon for particularly the flux writing that he was kind enough to put together as an example and then if I can get all that done which is really doubtful I will put that neopixel code in a new library to go in the bundle but that is a lower priority since the product called Scorpio isn't going to land in the store for a while yet and in non-circuit python stuff I would love to get a working example for the esp32 s2 tft feathers tft display in Arduino I worked at it for like 20 minutes and couldn't figure it out because I'm not very good at Arduino but I'm sure I can dig something up but if you have something give me a ping and a paper tape reader would be good Jerry let us know when you get that done because very doable project I'm sure and yeah that's what I got so full week thank you Jeff alright next up is Jerry just brings back some fond memories so most of the time I just spent poking and prodding at some of the new builds and just playing around it was fun to see that with the c3 having a readable disk drive I can use something like ampii now to upload files to it which really is nice and and then just having a lot of fun playing with this project that catney suggested taking what I had done a long time ago a little project to have a remote RFM9X controlled switch that could detect a window opening or closing or something like that and then using that for a new application but it's just been fun to review the code and find new ways to do things so keep busy with that awesome thank you Jerry next up is catney alright so last week finished up the qtpi ESP guide found a bug in the qtpi ESP pins for circuit python I discovered that running my touch pin script it returned a pin that it shouldn't have which of course I just assumed was me not understanding what was going on but it turns out it was actually a typo in the pin def board def whatever so fix that I started back in on the feather tft guide and tested that PR to pretty pins that I mentioned during hug reports so this week be spending foamy guy up on running this meeting adding arduino templates to all the rp2040 board guides we were holding off on that until arduino for rp2040 was a more stable and b we were certain which core folks were going to be using all of that has settled out so it's time to get that added I'll be updating circuit python.org slash trademarks it is currently placeholder text and folks are interested in this information so I'll be transferring that from a couple of pdfs we already have with that info in it to that url I'm finishing up the feather tft guide and then a bunch of other stuff when all of that is done the arcade stamina qt guide the mcp4725 stamina qt rev guide update the dot star led essentials template verifying the factory reset templates for rp2040 are good and async io essentials template and in personal info the project that jerry is referring to is my dad their mailbox is about 900 feet from the house and there's a line of sight and my dad wanted to know when the mail was delivered and said maybe I could make a little flag that pops up and I was like no I'm gonna go ahead and one up on this and I have no idea how to use Laura so as much as I puffed up and said I'll do this better I really had no idea how to do it and mentioned it to Jerry because Jerry seems to know a lot about radio etc and that that jumped off and has continued and I'm really excited I have all the parts for it I didn't get a chance to put it together yet but um have ideas and hoping to get that done sometime in the next few weeks so every time he opens the mailbox it would send a notification and in theory I could get it to send him an email or something um and then he'll know when the mail arrives so looking forward to that project that's what I've got awesome thank you catney next up is maker melissa I couldn't find the microphone but no worries okay so last week I worked on porting little FS over to JavaScript and making some good progress on that this week I'm going to continue porting it over but I'm getting into the debugging stages now but I still have some more to convert and I also need to test out a pull request for the ST 7789 display and are doing that soon and that's what I have awesome thank you melissa and that's it for status updates thank you all for letting us know what you're working on the last section we have here is called in the weeds in the weeds is a chance for us to have any longer form discussions that we need um and we've got a couple topics in here already but I do want to let folks know who are listening if you do have more topics feel free to add them below foamy guy here in the note stock and we could get to those as well um but for now let's go to Dan and chat with Dan about what he's uh looking at okay so this is I just came up over the weekend and I'm not I said I would bring it up but I'm not sure whether it's worth discussing or not we'll see but um various people including unexpected maker we're using some pins on the ESP32S2 which don't have any built in pull up or pull downs and they were using them to drive an I2C bus which you can do because they're external pull ups on I2C buses but what they found was what they tried to do there were two problems one was that um we the code was still uh there was there was still code in there to try to check to see whether there were pull ups on the bus and it was actually working I'm not really sure why it shouldn't even try um and then also they found that um when they tried to do a scan on this bus uh because of the way the bus was wired if there was nothing on the bus then each I2C transaction that tried to do a scan would take about a second and so it would take like 70 seconds to scan the whole bus which was ridiculous so um they submitted a PR to limit the time of the bus scan to like 3 or 5 seconds and then I was in here and like I wasn't sure if this was the right way to fix this because we have an ongoing problem that we allow kind of indefinite or quite long if not indefinite um clock stretching timeouts on I2C so in I2C you can talk to a device and a device if the device decides that it wants to take a long time it holds a certain signal for an indefinite period of time and there's actually nothing in the spec that says oh more than a millisecond or more than a second or more than 100 seconds is bad it just it doesn't say so right now some ports do timeouts and some ports don't and some ports will hang indefinite in I2C if the device is badly behaved so I was just trying to think about what the longer term things about this are and whether we might go ahead and approve this PR but then start thinking about how to fix I2C for real and maybe Scott you have something to say or other people who are using I2C a lot might have something to say about this I think I mean my general approach in terms of guarding against bad I2C devices is just like I'm not that thorough person and there's so in my experience like it hasn't come up a lot so like yeah if we're adding a new I2C implementation should we handle timeouts sure but if we don't in existing ports I'm not worried about it mm-hmm I do think that scanning is a separate case so I do like putting a short timeout time on that I think that's more of an artifact of the API from the IDF than it is for I2C right because like if a scan is initiated and the buses are and the clock line is held low due to clock stretching like you should just be able to say like I can't do this right now because the bus is busy and if the bus is not busy and you do and you try it to initiate the transaction by sending the by sending the address out like you could immediately read back whether you get an act or an act so there's really I don't think there's a reason to have a timeout on that thing so the pro for an individual address should like timeout early or something that should be fast right like yeah yeah yeah there shouldn't have there shouldn't be clock stretching at that point right and if there is it would be at the start right and I perhaps it is true that the that the API is not very helpful about this so that it's using a long timeout it's not we can't check up check for this thing at the right time alright I will look at that I will look at the PR in more detail and see if that's an alternative way to do it I can take a look I'll take it a look at it why don't you take a look because maybe you know you I have not done much ESP stuff so you just take a look at that and see if you have a different suggestion yeah and then I think for the for the ESP32 devices that don't have pulled downs right we only need a pulled down to do that test yeah if they don't have pulled downs then we should just assume that it's correct and and everything after that will fail like we just can't test it then right we should just test we should test for those particular pins and we're not doing that right now yeah we should exempt just the pins that don't have the pull down yeah yeah yeah that's just a bug yeah okay so I was looking at that pull request and I wonder whether a better fix would be to check for keyboard interrupt between each probe because then it's like is going wrong you can't hit control C yeah and as long as it completes each probe in some length of time you'll get your device back rather than just timing out the whole scan in five seconds I don't know if five seconds is a good number or a bad number but checking for keyboard interrupt would kind of let you get control back right if you if you need to for whatever reason yeah so you could add a comment to that too yeah okay that'd be great if you can comment on that also cool okay I think that's done with that thank you Dan next up we have a short thing from PomiGuy yeah thank you I was looking for folks if anybody has the feather M0 blue fruit device I don't have one of those and they are sold out or unavailable right now there's a specific PR that's open I'll drop the here in the chat I think the my understanding kind of the primary thing is to make sure that it's not going to make that library too large to import on that device since it is an M0 and I see here that Jerry mentioned potentially testing that out for us so I would definitely appreciate that and I don't think unless anybody has anything else to add I don't think we necessarily need any other discussion on that I noticed in that example the code that's in there it uses some stuff from this KMK driver or KMK module is that built in the circuit python or where does that come from well KMK is a separate project I think that I'll need to look through it maybe a little bit closer I think they essentially this person made a similar type of improvement in their fork of KMK right they're bringing that concept into this library so I think okay she just wanted me to basically pull the PR and just see if I can load it into a a blue fruit without running out of memory yep I believe so and he's picked a code on it to use it yeah yeah beyond maybe simple test or something I'm not actually sure I guess what all this library does but yeah something basic just to make sure that it imports the basic functionality is there and then specific PR I think is just about moving the commands into a a queue basically okay I'll take a look at it it'll probably say probably tomorrow morning right from doing it yeah I appreciate it I think it I would be very surprised if they could get KMK going on the M0 blue fruit because I believe it has RAM problems on the NRF 52A40 which has a whole lot more RAM yeah yeah I think they took I think they took this implementation from their fork of KMK but it's not necessarily that they were using KMK on that device there was just concerned about that specific device since my guess is it's probably the one with the smallest amount of RAM that would actually use this library right what it does yeah and one last fun fact I think the M0 blue fruit is the very first board I tried to get MicroPython running on when I started working for Adafruit because I had because I had won an M0 blue fruit via Ask an Engineer so it was like the only SAMD21 I had like the very moment that they were like do you want to work on this and then I ordered a bunch more and ended up working on the zero primarily I think but yeah fun fact I was like that was the one I was digging through all my stuff and I was like oh I have a SAMD21 I just think it was that cool well that is it for in the weeds I think the last thing here is just a Jerry's reply so let me switch I'll take the timecode and wrap us up thank you everybody for joining this circuit python weekly for January 24th 2022 if you want to support Adafruit and circuit python and those of us that work on circuit python for Adafruit, consider purchasing from the Adafruit shop at Adafruit.com the video of this meeting will be released on youtube at youtube.com and the podcast will be available on major podcast services it will also be featured in the python for microcontrollers newsletter tomorrow at daily.com to subscribe check the python for microcontrollers box there the next meeting will be held let me triple check let me check the convenient circuit python calendar next week on Monday at the usual 2pm eastern 11am pacific time this meeting is held on the Adafruit discord server which you can join by going to the URL www.afru.it to be notified about the meeting and any changes to the time or day you can ask to be added to the at circuit pythonista's role on discord and with that we hope to see you all next week and thank you all thanks everyone