 Hello and welcome to the CircuitPython Weekly Meeting for March 29th, 2021. I'm Scott and I work for Adafruit 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, considering purchase 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 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. The meeting time is changed. We'll notify you via Discord. If you wish to be notified about changes to the meeting, we can add you to the CircuitPython E-Sys Discord role. There is also a calendar available that we try to keep updated if you'd like to subscribe to that. This meeting is recorded. We record audio from the Voice Channel and video of the Text Channel. If you'd rather not have your voice recorded, you are still welcome to participate. Just add stuff to the note stock. The video this meeting will be posted to YouTube and the audio is released as a podcast. If you find this podcast is not available on your favorite podcast service, let us know. There is a note stock to accompany the meeting and recording. If you wish to participate but can't make it to the meeting, you can leave hug reports and status updates for us in the document and we'll read them off during the meeting. The note stock also contains timestamps to go along with the video so you can use the doc to view only the parts of the video that interest you most. The meeting tends to run 60 to 90 minutes so this gives you an option to skip around. A link to the note stock is posted in the CircuitPython Text Channel on the Adafruit Discord every week. Check the pinned messages to find the latest note stock. 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 for microcontrollers newsletter. The second part is the state of CircuitPython libraries in Blanka. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers separate from what we're all up to. The third part is hug reports. Hug reports is an opportunity to highlight the good things folks are doing, taking the time to recognize the awesome folks in the community. The fourth part is status updates. The 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 part is in the weeds. This is the final part as well. 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 as the meeting will go. Next up, we'll get into our first section here which is community news. I'll take a time code. First up and the community news is a big one for the broader open source community. Linux turns 30. Tux turns 30. Oh, it's Tux turns 30. Join the Linux Foundation as they celebrate 30 years of Linux with social media contests, event celebrations and more. There's a link there to the Linux Foundation and Twitter. Next up, the Python software foundation membership drive is happening now from the Python software foundation. As we celebrate the PSF 20th and the Python's 30th anniversaries, we want to welcome everyone to become a PSF member. It's important to us to have a membership that reflects our community. Everyone who uses and supports Python is invited to join us. There are multiple membership levels available. The membership drive ends March 21st, 2021. There's a link there to Python.org. Even though it's over, it's never too late to join the PSF. It's still a good organization that's around. A few projects from the newsletter. First is a Python using PWM on the blue LEDs of the Citron Maker Pi Pico with a serial connected nrf5248 for nrf52840 expressed dotterberg providing the PWM audio. There's a link. Thank you for my guy for posting the links. Next project up is Experience the Joy of receiving your first radio signal that makes Bluetooth FM radio kit available on Tindy. And let's see. Second to last we have a color device that stores all your two-factor authentication that types them in for you via hackaday and reddit. And last up is the emulate, read, write and communicate between NFC devices with the electronic cat's hunter cat NFC board which has a super cute cat on the front as well. And that's it for the newsletter. The or for community news. A reminder the CircuitPython Community Run newsletter emailed every Tuesday. The complete archives are available at www.github.com It highlights the latest Python and hardware related news we're on the web including CircuitPython and MicroPython developments. To contribute your own news or project edit next week's draft on GitHub at github.com There's a draft folder there that you click and you'll see there should be there's one or two and they're dated you'll see it. You can also do that from GitHub itself using the little pencil icon on the top right to make changes. If you have topics as well and aren't comfortable making a pull request you may also tag a tweet with the hashtag CircuitPython on Twitter or email cpnewsatatafruit.com and we'll get it added. So thank you in advance everybody who's contributing to that. Next up we have another section called Blinka. This is where we take an objective statistics view of the parts of the project and as a way to have some some concrete numbers about how the project's going. So let's get into the numbers. Overall we had 45 pull requests merged which seems like a lot but is actually quite common for us now which is awesome. We had 18 different authors let's pick out a couple names that I think are new. Lucas1337 Ehippy Lubarb and L.C. Congdon are all names that I don't recognize although they may have come up before. So thank you to all our 18 authors. Next up I'd like to thank 12 reviewers. Thank you to all those reviewers for supporting the authors and getting their changes merged in. We're trying to always level up people to reviewer level so that we can have more authors. So if you're interested in doing more reviews we have kind of a circuit python librarians team that does reviews across all the libraries and then we also are able to add people to the core repo as outside contributors if they want to review core stuff. So if you're interested in that let us know we'd love to level you up. Issues-wise overall we had 22 closed issues by 12 people and 16 opens by 14 people so we're net down six which is great and lots of people are involved double digits on both of those metrics so thank you to everyone for participating in circuit python. Now let's get into more details. Let's talk about numbers for the core and I won't forget that. Four poll requests merged from three different authors so thank you to our authors there. We had five reviewers which is great. Thank you to all of our reviewers. We have 23 open poll requests so we do have quite the number of open stuff so we should I say this every week and never do it but one way to contribute to circuit python core would be to take a look at some of these old poll requests figure out what was left to do with them and either suggest closing them or picking them up or finishing them any outstanding work items there so that would be huge help. Issues wise for the core we had five closed issues by one person four open by four people so we're net down one which is great. It doesn't tell me who that one person is but thank you anyway to close those five issues. We have a total of 424 open issues with seven active milestones. Milestones are how we prioritize and triage issues as they come in. We have six issues not assigned to milestones so those are the ones that we're going to have to take a look at and we have zero open issues for six XO features and we have one open issue for six two zero so we're quite close to a six two release candidate I believe and then we have 42 open issues under the six XX bug fixes which is a place we're going to have to take a look at and figure which one of those we actually want to do so yeah overall we're quite close to six two RC and then depending on when we land the changes that will trigger seven will either do a six three or we'll do a seven probably seven given that we want to update micro lab and change the APIs there so but even though we'll call it seven we don't really want to like cause things to take a long time so we the pace that we've had in terms of stable releases is quite good so we want to keep that up even if we switch from six to seven okay and with that I'll kick it over to Katni for an update on the libraries thanks Scott so this applies to all of the Adafruit circuit python libraries which is everything that begins with Adafruit underscore circuit python underscore and a few extras including the community bundle we had 40 pull requests merged across all of those repos including with 18 authors and that includes I think all the names you listed off from earlier and 11 reviewers so thank you to everybody involved with that that leaves us with I want to say yeah 63 open pull requests one thing I will say is there are three pull requests that were closed that were 26 days or older the oldest being 55 days so that's really great to see we had 16 issues closed by 12 people and 11 opened by 10 people leaving us with 311 open issues five of which are labeled good first issue if you're interested in contributing to circuit python on the python side of things check out circuit python dot org slash contributing you'll find all of this information and more including open pull requests open issues library infrastructure issues and basically you can search the issues by label if you're looking for something you're new to everything and you're looking for something to do good first issue is a great place to start if you're looking for something more complicated bug or enhancement is also an excellent couple of labels to search and if you're looking to start reviewing pick up any one of those open pull requests take a look at it check it for syntax if you have the hardware test it let us know that you did that's kind of how most folks get started reviewing the libraries is by commenting on open PRs that you've taken a look at it and once you've done that and you're comfortable with it we can level you up to reviewer we had a number of updated libraries in the last 7 days but no new libraries overall I'm glad to see some older PRs being looked into and merged if you're waiting on us for a PR that you have in please feel free to ping us and let us know we're doing our best to keep up with things but older things often get missed it's great to see all the continued contributions especially to the community bundle and that's where we are with the libraries awesome thank you Katnie alright next up we're going to hear from Melissa about Blinka hello let's say I've lost my place here it happens when I paste all that stuff in there yeah okay so Blinka is our circuit pipeline we have a very good layer for Raspberry Pi and other single board computers and this week we had one pull request merged by one author that's Dan and one reviewer that's you Scott there are 6 open pull requests amongst all the Blinka repos and there was one closed issue by one person and one opened issue by one person leaving a net of 54 open issues at github.com slash Adafruit Blinka there were 275 PiPA downloads and we are currently supporting 70 boards and that's it awesome thank you Melissa alright next up is hug reports hug reports is a chance for us to take some time and say thank you to folks for doing awesome things within our community this is done there's a round robin so I will start and then go through the list as sorted in the voice channel I will be mixing in folks that are either text only or not able to make the meeting so I will read off those as we get to them and yeah so hug reports chance to say thank you I think that's it so let me take a tank up for myself and I'll get started first up hug report to Naradok for sorting the language names on circuitpython.org that was awesome thanks to Jose David for helping folks on the rp2040 discord server with circuitpython and then last up thank you to Rob Fenwich for giving me a tip about right clicking in the download list in Firefox to get the original URL which is something I was struggling with on my stream on Friday so thank you to those folks and let me circle around so from anecdote we have a hug report for Brent Rue and the higher effect for reviews from askpatrickw they say thanks to James for the circuit fix which reduces the number of HTTP requests to github next up from Cgrover group hug to the team and the community and with that we're to Dan Hello I'd like to thank Gadgetoy Fivdi and Lady Aida who had all contributed to it and had ideas about the rp2040 i2c issue in which it didn't work with certain i2c devices and we have a good fix it looks like thanks to Kmatch who's been doing all kinds of work on display IO and vector IO and display related things both bug fixes and enhancements that's really great and thanks to Jeff who has started working on the IMX port and fixed a bunch of things that were broken and has had a slew of full requests it's really wonderful okay awesome thank you Dan and next up I have notes from David who's out who says for trying to find a solution to the feather s2dx pin naming confusion oh yeah that's yeah I have work to do there hug report to whoever added the random learn link guide which is learn.aidafruit.com slash guide slash random hug report to Dan H for solving many people's i2c issue on the feather rp2040 number issue number 4482 all the watchers of his stream hug report to Anikdata for the work and example on the network stack and lastly hug report to J4CN for the weed dj hero driver and next up is foamy guy alright thanks Scott this week also start off with a hug for J4CN for working on a fix in the tft feather wing helper to allow it to be used by feathers that have different pin outs hug report to James Carr for picking up some work on the easy make oven to try to make it use less RAM I had started down a road and then kind of tricked myself into thinking it wasn't going to be fruitful but James picked it up and got us the rest of the way there and it turned out that it was helpful so I appreciate that for sure to Kmatch and Jose David for working on a bunch of new awesome display AO widgets and then lastly to Jerry for looking into an issue with the STMPE 610 touch driver that's all for me thanks foamy guy next up is Hierophact this week um no worries snuck up on me my bad this week thanks to Dan for help and discussions about deep sleep the deep sleep api last week um thanks to Tio Mitch and June 2 sack for sticking with their PRs that have been in the review process and putting in the required changes for those um thanks to anecdata for fixing UDP server last week and thanks to Jeff for his continued fixes on the IMX platform some of which were issues that I had in there for quite a long time and I'm glad to see those finished and that's it for me awesome thank you okay next up I have notes from Hugo says group hug also hug report to JP and foamy guy for the work uh put into the touch deck project and guide and the preemptive hug to catney who will be publishing her first solo circuit python newsletter tomorrow no doubt she'll rock it and next up I have notes from jeppler who wasn't able to make the meeting says group hug uh also hug to David and v923z not sure I thank you for spurring on the work with bitmaps a few weeks ago and a hug report to higher effect and arturo and others for setting the groundwork for the IMX RT series mcu's with that we'll go to Jerry there's the button just a group hug for me this week awesome thank you Jerry no next up I have notes from J for scene says hug reports of Dan H and foamy guy for PR reviews hug reports of foamy guy and JP for the touch deck learn guide and tan newt and foamy guy for the streams next up from Jose David we have hug report to K match for reviewing and commenting in all the hard work thanks for helping with my lack of geometry skills and come to the rescue hug report to foamy guy for all the teamwork and next up is catney alright so I have a hug report to Jeff for putting in some extra effort into understanding pilot and pre-commit we still have much to learn a hug reports of foamy guy Jay Matlock and Kevin Jay Walters for submitting PRs to the newsletter this week to Jerry for dealing with a moderation issue sending hugs and support to ET makers Bill Binko and a group hug next up is K match thanks Scott first off thanks to Jose David for all the widget and graphics additions and I put here for your can do attitude don't let anything stand in your way keep on moving that's good thanks to foamy guy and tan newt for the live streams so thanks for putting time into that especially with us looking over your shoulder and there's a whole lot to learn inside of each one of those next off to Jeff and Scott thanks for encouraging always try on new things that are sort of outside of outside of the comfort zone so I appreciate that and lastly warrior of wire for insights into the vector IO module and particularly thank you for your specific defense pixel refresh speed as you put it thanks awesome thanks K match next up is maker Melissa I wanted to hug to you Scott for pointing me in right direction last week with the bundle release generation and to Justin for help with getting me set up on Amazon S3 and fixing some permission issues and a group hug different else awesome thanks Melissa last up we have notes from mark who says for starting me off on audio mixer and where to look hug report to Kevin J Walters for pointing out some audio stuff in the PR to confirm it was an existing issue and group hug and with that we're done with hug reports so thank you everybody for that next step is status updates which is another round robin section this time we're taking a minute or two to talk about what we've been working on in the past week what we plan on working on in the coming week it's a great way for us to stay in sync about who's doing what and collaborate across projects and give tips and tricks so that's where we're at let me start off after high scroll to my own notes so first up I switched the RP2040 and the generic external flash to NVM Toml which is a separate Toml format file database for defining flash settings just a heads up for anybody doing circuit path and core development make sure you init the sub modules directory to get the data slash NVM Toml directory in circuit python otherwise you'll see build errors for the RP2040 that say you're missing the cascade Toml route so that's an issue there and I think people sorted out on the discord already but I thought I'd say here again this week I'm kind of intermingling two things I said finishing up switching the IMX RT to the NVM Toml in circuit python and tiny of do I have UF2 I have most of that work done it needs to be tested but the next big task for me is the BLE workflow which I think a number of folks are excited about I'm excited about it I'm working directly with Trevor who is the iOS dev that has on the app side so he's got cycles right now so I need to actually switch to that and get him unblocked so my plan is to start stubbing out the way that I think the BLE APIs will work I'm going to do it from circuit python and that will unblock Trevor working on the app side of things so how to do discovery how to do the file transfer stuff I'll do that just from circuit python to begin with it won't actually kind of work properly until it's brought into the core but in the meantime we can at least I can stub it out so that all of the app side will be there and David said is that going to be iOS only the BLE workflow well the BLE protocol will be openly documented and we do have an an Android app dev that we work with but it will likely be that the Android stuff will come after the iOS because we want to figure out everything that we want to do from the iOS side first so we do plan on bringing it to Android as well it just won't be quite as quick as the iOS stuff because the iOS stuff is where we'll figure out what we want to do but the goal is to be all open about how it all works so that other people can make other apps and and stuff to work with it as well Hugo asks will BLE include desktop support as well we probably won't do it directly ourselves although the library that I used to stub should actually work with BLE Blinka as well so hopefully so you so you'll be able to programmatically do it but I don't think we have plans on doing like a desktop app or anything somebody else will have to do that okay that we'll talk about this all on my stream on Friday as well people are excited I'm excited it's going to be exciting okay let's keep going or we can talk more in the weeds so C Grover has some notes for us here and says no circuit python activity report this week but unrelated the book illustration project is nearly complete have my drawing skills improved and am I having fun yes and yes are the new skills good enough to put food on the table only if drawn there and next up is Dan okay so mostly in the past two days I guess I've been working looking at there was this there was this problem with the RP2040 where certain IQC devices didn't work and we found that increasing a certain value fixed at somebody a 50 found and it was seen very empirical and the question is there was there some better way to do it and then I think 50 or somebody else also suggested like well if you just look at this more carefully we actually there's a 300 nanosecond delay that's specified by the RTC specification which wasn't really there and this count was moving toward that but it wasn't nearly big enough to actually satisfy the 300 nanosecond delay so I've now submitted a PR which has been accepted to our version of the Pico SDK R4 that calculates the value and makes sure it's 300 nanosecond so that's done and it works with all the devices that I could find and it means this value which was default one and then we try two and then we try five it's actually now 38 which is fine okay it's where it's supposed to be the other values are really marginal like they really just work and that's because it's based on the core clock speed right yeah it's based on the core clock speed so and the peripheral has a default value of one but that default is not a useful default I think the original thought was that it was useful it wasn't because it depends completely on the clock speed and each tick is at eight nanoseconds and we're looking for 300 so we need a much larger value right after that fix is incorporated it looks like maybe with just a couple more like translation PRs and stuff we should be able to make a 620 release candidate so I'll be doing that in the next day or two probably I have to see exactly what's outstanding and whether there's anything else we really should consider getting in and assuming that goes through we'll have a release candidate zero we'll see more people will try it hopefully and then we'll have to stable after that cooks for a while like maybe at the beginning of next week like that which will be great we'll include a whole bunch of great changes after that as Scott mentioned we'll probably try to move on to a 7.00 initial work on 7.00 so we can make a bunch of incompatible API changes that have been waiting in the wing and what I'm going to work on for 7.00 at least to start with is that pressure from various sources for various projects and capabilities to do dynamic usb descriptors including hid descriptors and I'll start working on that that'll be my main task okay thanks Dan alright next up I have a note from David who says when on show and tell to show how to pick you back an ice-grid c-sensor on a stem of qt board which I had not thought it was a really good idea portable co2 sensor with the feather rp2040 OLED and scd30 is a twitter link there checking for friends the lowest cost bill of material for a school co2 sensor testing scd30 plus qt pie and using color to indicate a level I made a stripped down version of LED animation to fit the non-hackspress qt pie accidentally quote-unquote covered the flatulence detector capacity of the co2 sensor and tested djhero for the weedriver and I'll link to those copy link URL paste so there's that and next up is foamy guy alright I will start actually with a hard report that I forgot which was for those c2c stacked up sensors I thought that was a really really cool idea as well that David showed on show and tell and I forgot to put a report in for that so big thanks there for my status reports last week I worked on reviewing PRs for display text and display layout I worked on trying to reduce the memory usage inside the easymake project and I ended up streaming on Friday night scott when you were gone just because there were folks around and we wanted to hang out still so that's what I worked on there and then also on Saturday I worked on I did back into the tiled game map stuff so I worked on movement player movement and collision checking and then later in the day on Sunday actually I worked on the camera view to show a subset of the map so making good progress there for this week I'll be doing another pass through display library PRs that's pretty much a weekly thing I know there's a few out there like progress bar and some ones in display layout that have new changes to look at so I'll be checking those out and then I will be working on the custom font guide this week there's a learn guide for custom fonts and it talks a lot about how to customize fonts and the kinds of things that you would want to customize a font for but it doesn't show necessarily the most basic example of just how to do it so going to work on a page for that and also some more interesting things the font awesome stuff that Jeff was playing with at one point and then the last thing I have is I'm going to keep working on the tiled game stuff and the thing I want to do next is really try to make a more complex you know quote-unquote real game that has some more mechanics instead of just a super basic movement thing like I have now to see where my gaps are at and what else I need to implement still so that's what I'll be up to thanks yeah and if you've looked if you haven't looked at the Celeste Pico 8 version they have some of that where it's like certain blocks are like ice or sticky that sort of thing so you said Celeste yeah I can I can link you to it I actually converted it to Python yeah that'd be awesome I don't think I have seen that I think it's just Celeste.py yeah tenu slash Celeste.py is awesome where that is and it's base it's got links back to the original source too cool thank you yeah thank you for working on all that I'm super excited to see you do all this work because I want to do my Game Boy card at some point and hopefully all that stuff will pour it over okay next up is higher effect already I just noticed that Google has an anonymous axolotl character now and it's adorable so you haven't seen that right now anyway this past week I wrapped up the STM32 low power module with the exception of one remaining bug about returning the correct alarm but it's otherwise all finished and tested on the pie board and the Feather F405 fixed redundancy in the deep sleep manager in Maine that was kind of calling the alarm system constantly in a confusing way this didn't have a lot of impact if you weren't actively trying to debug problems but it made things it made program flow really weird if it was thanks again for Dan helping to confirm and track that down I reviewed new changes to the power API coming in from Jindasak who's working on the NRF port for low power and I put in a PR to try and synchronize the work between those two PRs the NRF and the R2 low power that can go in either before after either of those PRs goes in but just trying to get the API to be the same going forward this week I'm going to get started on the Raspberry Pi 2040 low power system it's going to be my first time working with the R2 2040 so I'll be reading through the documentation and just checking out what kind of tools I've done that a little bit already I know that it's got some flexibility in terms of how you approach clocking clocking down for light sleep and then pin down this remaining issue with the wake up alarm and get that PR in for final review and that is it for me awesome thanks and next up we have Hugo all right I should be terrible now yep I can hear you excellent so last week last two weeks I wrapped up the vertical and horizontal progress the refactor to make pilot happy with the code and I looked into an issue that was on the magtab library recording a crash loop with a bitmap file and I wasn't able to reproduce so I'm going to look into it a bit more but I think it might be something that has since been resolved for this week I'm going to be looking at other issues that are in the backlog that I can get to and assuming that FedEx can actually deliver a set of 20 PC so that it can be a little more productive awesome that's exciting thanks Hugo and next up I have notes from Jeff who says last week spy output on the AMX had some surprises to conquer I think it's solid now I found them fix two problems preventing Adafruit SD card from working with BitBangIO fix some example code based on feedback in the learn system added some tests to Adafruit PIO ASM hoping someone else will add more fix the problem with datetime.timeDelta.totalSeconds losing precision now long intervals are integer number of seconds and short intervals can have microseconds address feedback and learn system guides ran into an assertion error in the RE module would cause arbitrary behavior on MCU file the patch with micro python should also PR it to circuit python ran into a problem with memory view RGB matrix and file the PR this week either moving on to PWM out or moving on to reports that the AMX RT 1020 EVK doesn't boot possibly since five three or bringing up the IMX RT 1024 EVK similar to the 1020 but has flash embedded in the microprocessor package and then fun stuff hope to return to enhancing pulse into work with longer pulses for one of my own projects and without all headed to Jerry Thanks Scott so in the last couple days I've been able to reproduce this issue that a foamy guy now with STM PE 610 on the feather RP 2040 but I can't reproduce it if it's connected to my Mac main to my to an art to raspberry PI can only reproduce it if it's connected to a Mac and but not totally reliably so it's really flaky at this point so at least now I have something I can try and dig into but it's it's pretty confusing and just been doing some more playing with it now and it's getting more confusing so banging away at that and see the fingerprint library there was an update there've been some updates to it recently to add some features to some of the the newer sensors have some nice new features but some of the other sensors don't have those features so there's a little confusion about you know which which which now all commands work and which ones don't it's not a big deal since not many people know about the new commands yet so they're not trying to use them but sometimes we have to figure out a little bit about how to flag that commands which commands which which commands are good for which sensors and then there's a little issue that trying to debug or understand that one of the new commands is setting up the system parameters seems to on the newest sensor seems to need an extra delay don't understand it yet playing with that some more and actually downloaded and tried the new new today 1.1.0 beta 3 and for the first time ever I think it actually works on my Mac so congratulations to and my Caucasians are blooming yay springtime awesome thank you Jerry next up from J4CN added LED on function to Adafruit hidden dot keyboard to check the status of caps lock scroll lock num lock and compose and fix the unit in tft feather ring 2 4 and tft feather ring 3 5 to be able to use the quote unquote non standard non Adafruit feather boards next up we have notes from Zadavid who says last week Cartesian widget take a brief look at the peripherals Pico registers not much progress PR on the equalizer widget inspired by as Patrick W's on the audio mixer new line air new line arrow function using vector IO you can now use it to point things in your screen using circuit python added to the community bundle new candlestick class graphical representation of stock market price movement using circuit python also added to the community bundle this week styles library and getting this in the widgets library and also a slider widget and next up is catney hello so last week was the first time publishing the newsletter on my own I still had a lot of help with content that went out and I expected which was good went through all the other newsletter bits that happened once it's published went through a ton of guide feedback got it down to items that involve others as in it's not something that I have enough knowledge to comment or do something about or significant testing is needed or stuff I don't have hardware for there's only 12 left which is good because I think when I started last week I had 75 published the cyberdeck bonnet and hat guide handed off the midi feather wing guide which is now live anyway JP finished that off so that's ready to go and continued on the template quest so this week publishing my first entirely solo newsletter I will be tomorrow proofreading the IOT newsletter for Brent make sure that that's good to go I will be catching up on replies to some older to-dos that I pinged about at the end of last week there were a number of things in my list that had been forgotten so I pinged about those and got replies on everything and so I need to follow up on all that and then continuing to work on templates have to decide now whether I want to do all the templates at once and then go and put them in the guides or do I want to do one template at a time and put that one template in all the guides not quite sure what route I want to go on that one but once I make a decision then I have a plan anyway the basic blink template is done the next one that's almost done is neopixel blink which is for boards that don't have a little red LED and then the one after it's basically the circuit python essentials guide however we didn't have blink in there because blink was part of the circuit python welcome to circuit python guide but everybody needs blink and we didn't have a real clear way of explaining it for every single board and we sort of generalized and we got a lot of feedback about hey my board doesn't have this, my board doesn't have that doesn't quite work and so we're doing this to avoid that to create a much smoother experience for folks who pick up a board, go to the board guide and then it will be a tailored list of things that looks like every single one was written individually but the point is it's a template that makes putting it on all the guides a lot easier that's where I'm at awesome, thank you Katni next up is Kmatch thanks Scott, so last week added a widget flip input it's an input selector widget did a few minor display related bug fixes also helped with some memory usage for quite a few community or two or three community members and that's a discussion for in the weeds this week I want to review some of the cool widgets coming down the pike, the Cartesian, the progress bar and the equalizer bar and the last widget I've got at least partly started is a scrolling text box which I'll get that in a cube and then lastly fun stuff, so I ordered a teensy 4.1, been hearing a lot about these new chips, so eager to see what you can do with super fast chips and this one in particular has lots of RAM to use or to fill up and then lastly related is how to get a low cost logic analyzer so Scott and Mark have a few tidbits of places to look so I'll check that out I'm super excited you're taking a look at it Thanks Alright, next up is Melissa Hello, so last week I finished the JSON file generation which will be used for several things and it makes it easier to get a list of libraries and their dependencies and current versions I got the dynamic re-bundler working so now you can go to a URL, specify the libraries you want and it'll re-bundle from the main bundle into like a little mini-bundle on the fly I started working on getting the existing circuit Python VS Code plugin figured out both in terms of usage and internal functionality this week I'm going to get the dynamic re-bundler in its final place so people can start using it and I'm going to help update the circuit Python VS Code plugin so it has some of the updated functionality of the circuit like the dependency installation and I'll start on a UI for the I'll maybe start on a UI for the dynamic re-bundler so people can make their own packages easily and that's it awesome thank you Melissa next up I have notes from Mark who says last week Audium Mixer works on RP2040 now and should work on any non-M4 board but only tested on the RP2040 for now other fun stuff tomorrow I survived another trip around the sun happy birthday Mark okay and that's it for stats updates thank you everybody really appreciate it the last section we have here today for our circuit Python weekly is in the weeds in the weeds is a chance for us to talk about like whatever we want basically so this is a chance for any longer form discussions that came up earlier or folks have added during the week so we have two topics now if anybody else has topics please drop those in the notes and we'll start with Kmatch okay thanks Scott so just trying to sort of get a pulse on things that are happening in the discord chat and how best to respond to them and as we give more tools of folks to use up their memory space particularly with displays is what I see need good ways to sort of help people sort out their problems without having to solve everybody's specific issue so I was just looking for inputs on some resources some of which I just found out when I started posing but what I found were two one is there's a frequently asked questions for circuit Python which has a couple of questions but it's pretty basic comments and then it jumps to a super deep dive on MicroPython and a great detailed description on options there another resource was Foamy Guy did a good stream this past Friday on the Easy Bake Oven and basically ways to debug where the memory gets used up but basically just looking for any other good places to point folks to maybe bridge the gap between the basic and sort of super deep options so if you guys have anything else I'd love to hear it and capture it here or I can look for another place but basically I suspect this is going to continue to keep growing and concerns for folks of running out of memory allocation and how can we best help a broad group of folks get what they need Yeah, I think you're spot on saying we really do need an intermediate level guide I've done deep dive streams myself into circuit Python memory stuff using the J-Link GDB capture everything that's happening on the heap sort of things so if you haven't seen those and you're curious you could take a look at those there might be some tooling in there that would be helpful Okay I think that having a debugger probably is a pretty small quantity of folks that would have that so how do folks do it not from the REPL but through print statements or whatever best practices maybe or basically avenues to hunt down and again like I think intermediate maybe is the way to phrase it people maybe have program experience but not on small computers like this where to look We have basically nothing between make sure you're using the .mpi versions of the libraries and here's how you mess with the heap like there's nothing in between you found all the resources we have so I wouldn't I wouldn't keep digging through learn I guess it's just a statement there because I don't think there really is much of anything else that said we would be absolutely ecstatic to have somebody write a guide that fits that sort of intermediate how do you handle memory stuff I mean we obviously hope that with the advent of new boards and so on that we're not running into it but inevitably you're going to use everything up it doesn't matter how much you have that's the whole point you get more or fill it up so I don't think it's something that is I think it's something I guess my point is I think it's something that will continue to be applicable and not get lost in the fray because I think we're starting to see it on bigger boards because initially we're really only seeing it on the SAMD 21 without flash and obviously we're still seeing it there but I think we're actually managing to take some of the boards with flash now and some of the bigger boards with beefier stuff so I don't know if that's something you're willing to look into writing up or just I'm putting it out there for anybody we we would definitely be happy to publish something like that I think how about this how about I'll start with putting kind of maybe a bullet list of these resources and then maybe a few other tidbits that I'm aware of and can find a place to store that and start pointing people that way if that comes up and then we can build on it from there that would be great you could put it on github okay because that would also be a way for folks to collaborate on it as well yeah issues common that would be good okay I will initiate that alright excellent okay and if anybody has any other pointers even just generic non-circuit pipeline related things feel free to ping on discord so I think a related topic to this is as we have bigger boards and do library development on the Raspberry Pi one thing that we could add that somebody might be interested in tooling is actually a way for us to measure how big libraries are in the continuous integration testing so being able to actually catalog the growth or the memory footprint of libraries over time because I think part of the problem that we're seeing is that as we get bigger boards and we develop libraries on those boards we bloat them which means that for the smaller boards like samdy21 they no longer work and I think in this like the easy make oven example I think that is part of where it came up is like the libraries it was using probably bloated a bit over time so I think another tooling piece that would be good would be a way to measure the size of libraries themselves as if once we can measure it then it's a feedback loop as we as people do pull requests and things like that so I think that's another tool in our toolbox that we could do for memory and I think like Anecdata has a related question I think we should just address now Anecdata asks in the doc is a defragmenter function accessible to circuit python a possibility and there so circuit python has gc collect but it does not do any sort of moving of memory gc collect simply looks through all of the heap and removes the objects and frees the objects that are freeable but because of the way that the memory allocations are managed we don't actually know for sure what values and memory are pointers into that memory and so we can't actually change those numbers so we can't actually do any sort of moving there's an asterisk there but like generally we can't move memory the asterisk is that circuit python not micro python but circuit python will do long living which means that for all of the memory structures related to imports they get moved to the top end of the heap and the reason to do that is that it's assumed that those objects live for a long time and therefore densely packing that means that that area of the heap will be densely packed and the rest of the VM's lifetime that's not always true and there's things that you can still allocate in holes there if it comes to it but I think one common misconception is GC collect is now automatically run after import and then also the misconception with GC collect is that you want to do it after you allocate something big but I think the better advice is to actually do it before you allocate something big because there's like bounds that the heap looks for free memory in and those bounds get smaller and smaller as you allocate more and more things and what GC collect does is kind of resets those bounds in the outside so if you do a GC collect before you allocate you're more likely to allocate kind of towards the outside and leave the inside to larger allocations so that's a detail but like yeah it's a hard problem to be able to do fragmentation we would have to change the way that the heap works which is not out of the question but the reality is is that hardware wise we live in this world of Moore's Law still which means that like every year or two we get a lot more memory which means that memory use is not not always the top priority for us to really optimize so yeah there's my brain on all of that any other comments around memory K-Match I think you're right it's definitely something that it would be good to address yeah and I think it's when somebody's formulating their program right they can do some high level things to try and resolve it of course not solve everything so that's what I'm after here how can you do it at that you know when you're coding your Python side so yeah I think you and FOMI guy and like all the graphics folks are really like pushing those boundaries so I think you're gonna have a better idea than I am actually okay well thanks for the input and again if anybody has others feel free I see David Glada has a few things in there too so okay I appreciate that yeah and so I'll I'll just read out what David said for folks who are only listening David said there is the use by biter advice there's use binary font reduce color depth avoid recursivity that's probably related to um pystack exhaust errors which is related but different um and then use a generator rather than build a big list um yeah I think some of it could probably be served by just like being more explicit about what things and how how much memory they take like a list has four byte entries but a byte array has one byte entries for example um that sort of thing um and then uh Jose David has some comments here that I'll just take a time code since we're kind of through this so Jose David added related with K match um do we need with functions and patterns are more memory and time consuming and circuit python to avoid using them in libraries and is this architecture dependent for example the esp32 s2 bus um yeah I think um there are certainly functions and patterns that take more memory um I think generally they're not architecture dependent um the caveat with that is that for networking stuff like esp32 s2 stuff there's just a lot of memory use kind of to begin with um and bluetooth has this a bit as well where like there when you start these networking stack stacks up they tend to do a lot of allocations into the hood so even if you started and you were like oh I've got lots and lots of memory but then you like start up something big and it just takes takes a lot of memory so um yeah I think I think there are general patterns that we could document to be more memory efficient um and having a place to do that would be good but I think also in general like it would be good to have it tools so that we can really measure well and up front um because that that will catch all things that use a lot of memory or a lot more memory than we expected not just the ones that we're kind of aware of um so yeah I think that's for the library side I think really like if somebody wanted to take a look at like run circuit python and QMU and do an import of the file and do like the GC um collect sort of thing and then potentially like once you have that you could dump all of the heap memory and then you could actually do like the charting that I did um when I was doing heap stuff uh where you can actually see like here's the root object here's how big it is and here's how all the things that it points to and how big all those things are as well um so I think there's there's some tooling stuff that could could help alleviate this as well okay anything else I don't think so alright uh and with that I will wrap up I think you everyone let me just scroll down and make sure I don't forget anything in the wrap up um so this has been the circuit python weekly for March 29th 2021 uh thank you everyone who's taking their time to participate we really appreciate it uh if you want to support Adafruit and those of us that work on circuit python consider purchasing from the Adafruit shop at adafruit.com uh the video of this meeting will be released on youtube at youtube.com and the podcast will be available on major podcast services uh it will also be featured in the python for microcontrollers newsletter uh which you can go to adafruitdaily.com to subscribe to just check the python for microcontrollers box there uh the next meeting will be held let me double check before I say this uh next Monday April 5th uh at the normal time which is 2pm eastern 11am pacific um the meeting is held on the adafruit discord server which you can join by going to the url adafru.it slash discord uh to be notified about the meeting and any changes to the time or day you can ask to be sent to the at-circuit python nisa's role on discord and with that we hope to see you all next week uh have a great week everyone uh thank you for joining thanks everyone