 Hi everyone, this is the Circuit Python Weekly for the week of November 15th, 2021. This is the time of the week where we get together to talk about all things Circuit Python. I'm Dan. I'm sponsored by Adafruit to work on Circuit Python. I work on the Circuit Python core in particular. Circuit Python is a version of Python that's designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit. So if you want to support them and support Circuit Python, consider purchasing the hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafru.it slash discord and you'll get a URL that you enter the server on Discord. You hold the meeting in the Circuit Python Dev text channel and the Circuit Python voice channel. This meeting typically happens on Mondays at 2 p.m. Eastern time in the U.S., 11 a.m. Pacific time in the U.S., except when it coincides with the U.S. holiday. There are a lot of U.S. holidays on Mondays. If 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 Circuit Pythonese's Discord role. There's also a calendar available in Google Calendar 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 from the text channel. If you'd rather not have your voice recorded, you are still welcome to participate. The video of this meeting will be posted to YouTube after the meeting is over and the audio will be released as a podcast. If you find this podcast is not available on your favorite podcast service, please 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 Hugg reports and status updates for us in the document, and we'll read them off during the meeting. Okay, and I've already explained a bunch of the other stuff, so we'll just go on from here. Let me put a link to the note stock in the chat. There you go. Okay, I'll take his timestamp and we'll start with community news. I'm putting a timestamp in the wrong place, hold on a second. Okay, first we'll go over some community news, which will be in the Circuit Python newsletter, which comes out tomorrow. We've got sort of the headline news items from the newsletter here. The first one is that CircuitPython 7.1.0 beta zero is now available. It's the initial beta release for CircuitPython 7.1.0. It is relatively stable, but it contains issues we may still address for 7.1.0. So there's a list of things that have been added to 7.1.0 since 7.0.0, most notably keypad.events, now has timestamps. The express port now provides some additional features, I2C peripheral, Wi-Fi monitor mode, ESP32C3 support initially, and parallel image capture support. There's some additions to bitmap tools. There's preliminary support for async.io. You can use the CircuitPython async.io library, which will be in the bundle soon. And I'm writing a guide for that. GIFIO for writing GIF images is available now. HID now provides boot device and feature report support. Rotary.io now lets you set number of clicks per, or the number of counts per transition. The SAMD port now has watchdog and alarm with sleep support. The STM port now supports the STM32LR45, L4R5 chip, and we've merged in the latest release for MicroPython, which is 1.17. Our next news item is about Make Magazine. Make Magazine issues are now available on Internet Archive. There's a link in the notes. If I understand properly, it's sort of like a lending library. A certain number of people can check out a copy, and when you're done, you return it to the Internet Archive. So it's basically like a public library. There's a limited number of copies, and that's how you control how many people can look at it at once. The podcast, sort of podcast, or video podcast, in the last one, Scott was on, and he joined Tom's, the Tom's hardware podcast to talk about a new version of the programming language that boots up on bare metal Raspberry Pi without a host OS like Raspbian required. And also in this issue of the podcast, Les Pounder showed off the new version of the Raspberry Pi OS named Bullseye. Okay, now let's talk a little bit more about the weekly newsletter. Circuit Python with the newsletter is a Circuit Python community-run newsletter emailed every Tuesday. The complete archives are available on AdafruitDaily.com. It highlights the latest Python and hardware-related news from around the web, including Circuit Python and MicroPython developments. You can contribute your own news or project to the newsletter. You can make a poll request on GitHub to the repo for the weekly newsletter. You can also tag a tweet in Twitter with Pound Circuit Python, if you want, and it will notice it. Or you can email cpenews at Adafruit.com. Any of those ways will get us, will get the material into the newsletter for the next week. Okay, now our next main section is State of Circuit Python. The library is in Blinka. This says how we're doing in terms of development and fixing bugs and adding features. So overall, in the past week, there were 122 poll requests merged. A lot of new authors, including URF-DVW, Rezel Manda, Emergery Animator, M.A. Fultonborg, La Brusca, Zebular 13, and Nosferrado Jr., are new people we haven't seen before, we think. There were 19 authors, 10 reviewers, and 17 issues were closed by 12 people, and 13 issues were opened by nine people. So we're ahead of the game in terms of closing issues. In the Circuit Python core, we had 17 poll requests merged by 11 authors, five reviewers. We still got 15 open poll requests. A bunch of those are drafts or are awaiting 800, the initial versions of 800, so they'll stick around for a while, but 15 isn't too bad, and I think a few have been closed recently since this list was made. Six issues were closed by five people, and seven issues were opened by four people. So we've got 450 open issues right now. There are 22 issues that are still open. We hope to fix in some version of Python 7. We've got eight issues that are deferred until 800, and we've got 398 long-term issues and some other miscellaneous issues. Only one issue is not assigned to Milestone, we'll fix that. Our next section is the State of the Libraries, and Katnie, are you available to talk about that? I am, if you can hear me. I can hear you. Yep. Great. So this applies to all of the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore, Circuit Python underscore, as well as a couple of extras, like our cookie cutter and the community bundle. So over the last week, across all of these repos, we had 104 poll requests merged from eight different authors and seven reviewers. One of those PRs was 107 days old, which is good to say that we're still getting through some older ones. I deleted the full list. It was multiple pages long. There is a link to our report if you wish to see all of those merged PRs. And that leaves us with 58 open poll requests. There were 10 issues closed by seven people and six open by six people, leaving us with 627 open issues. 259 of those are labeled good first issue. If you're interested in contributing to Circuit Python on the Python side of things, visit circuitpython.org slash contributing. You'll find this information and more open poll requests and open issues. And you can search the issues by label. If you're new to everything, check out good first issues. Those are a great place to start. And if you're looking for something more complicated, check out bug or enhancement. Find an issue that interests you. Comment on it that you're working on it. If you need help from us, we have a guide on contributing to Circuit Python using GitHub and GitHub. And we're also always available both via GitHub and Discord. So feel free to pop into Discord and post your question or post it on the issue that you are choosing to work on. In terms of library updates in the last seven days, there were no new libraries but a number of updated libraries. And you will see next week that list will also have to be deleted because we just did a major update and all of the releases are being done today. So overall, we finished a series of library updates, including an update to the pilot to run 2.11.1, an update that forces older libraries read the docs to run the latest Sphinx, an update to the pre-commit config to include disabling pilot considered using fstrings, and duplicate code for examples and tests. Where necessary, we also disabled duplicate code for the library code as well. We reverted the increase to the min similarity lines, which is what the threshold that must be met to trigger the duplicate code check. And so we know where there are duplicate code issues in the libraries, and we can address that at a later date. I didn't get to finish typing this out, but a community member is still going through all of the type int PRs, so expect to continue to see those. And basically, we shouldn't have to do another update like this for a while, which is about how it goes. And I guess that's about where we're at. Okay, thank you very much, Katnie. Okay, MakerBlessig, are you available to do the Blinka update? I am, if you can hear me. Yep. Okay, so Blinka is our circuit Python compatibility layer for MicroPython, Raspberry Pi, and other single board computers. And this week we had one pull request merged by one author and one reviewer. There are three open pull requests still, and there was one closed issue by one person, and zero open by zero people leaving a net of 64 open issues amongst all the repos. There were 13,372 PiWheels downloads in the last month, and we are currently supporting 77 boards. And that's it. Okay, thank you very much, Melissa. Okay, now we'll go on to Hug Reports. Hug Reports are where we recognize contributions to circuit Python and its libraries from the community. And people usually have particular people they want to thank. So I'll start, and we'll go down the list and then back around to the top. I'd like to thank Tetrick, who's done all kinds of library and documentation fixes in the past week or so. A tremendous amount of output. Thank you very much. And I'd also like to thank Jeff Epler, who did a flurry of PRs to the core just before he left for a short break. We had a lot of stuff to review over the weekend. Thank you very much, Jeff. He's not here today. Okay, Foamy Guy, who's not here right now, so I'll read their contributions. Thanks to Jeff for finding and reporting an issue with the library example screenshot utility, and Dan H for reviewing the PR to fix it. That's the images that look like screenshots from the Mac in particular in guides, but they're actually generated programmatically. So we can change them easily. Thanks to GitHub user Tetrick for continuing to submit PRs for typing information and other things. Thanks to GitHub user 560 for submitting typing information for the APDS9960 library and working through feedback on the PR for that. Thanks to Katny for looking into an issue with Pylon config, testing out some solutions and providing guidance. And thanks to Mark Gambler for working on display IO support for LED matrix classes. Okay, and Jerry, you can go ahead if you're ready. I am. Hi. Let's see. So everybody involved in the BLE workflow, the pie leap and glider stuff. So really cool new stuff to play with. And to Adafoot for all the new ESP32S2 feather toys. And everybody involved in 7.1 beta release. Congratulations. Thank you very much, Jerry. Okay, Katny. All right. So I have a list here. First up, a hug report to Dylan for getting through the pilot update and all the other various updates. I just listed off in the library section. There was a lot going on and every time we did a patch, I thought of something else we might as well patch while we were at it. So there were a lot of patches. And for those who are not aware of the process, sometimes those patches skip certain libraries. So there's always cleanup afterwards. So it's not quite so simple as just applying the patch and everything's good to go. So it's always cleanup. Thanks to Tech Trick for a ton of help with getting the libraries that were missed in the patch updated with the patch code for being so patient with learning our CI and processes and for working through the type hint issues. To FOMIGuy for thoroughly reviewing type hint PRs and asking thoughtful questions. To Keith the EE and Mark Gambler for helping with reviewing the final pilot PRs. To PT and Aida for IT for getting me set up with an Adobe stock subscription to make doing guided images in a non-potential copyright violating manner, much simpler. It turns out just because it says it's free on Google doesn't mean it's free. Not that there's actually been an issue for me, but this is just, you know, common understanding. So it's not great to use images that aren't obviously licensed and now I have access to tons of stuff that is officially licensed. So I don't have to scramble to dig around anymore. To Jeff for writing me a script to combine the two CSV files available for my Aida for order history, which are order history and products history. The script combines the two so I can go through and identify every product shipped to a specific address. Neither one of those things has enough information, but the two combined has has plenty. And finally to Jeff for teaching me how to do nested with statements. I have already been able to share that with somebody else. And so I'm far more likely to remember it. Thank you very much. That's what I've got. Thank you. Okay. Melissa, can you go ahead? Okay. I wanted to just give a group hug to everyone. Okay. Thanks. Okay. Mark, if you're on, if you're available, always looking. So I'll just say, I'll read marks. Mark, thanks, paint your dragon for all the original IS 31 code I learned from and a group hub because I know I am forgetting others. And now we'll move on to Scott. Hello. First, a hug report to cat knee for the welcome to circuit python revamp and also for jumping into help with the Piley content. I'm excited to get more guides in there. So thank you for jumping into that. Or leaping into that. Should I say a hunger for to Trevor and Antonio for their work on Piley and file glider accordingly. And also a shout out to maker Melissa for all of their work on code dot circuit python org, which is very exciting. And we're just starting to see this push to all these new stuff. And I'm excited for people to try it. So thank you all. Okay. Thank you, Scott. We'll wrap around to the top. I'll read anecdatas who was lurking. Thanks micro dev for the completion of the monitor PR ESP, ESP 32 s to safe mode fixes and review of the MAC address PR. And thanks to Jepler for help with type hints and finding a bug while doing so. Okay. See Grover is also text only. So I'll read theirs. It seems to take another time code or previous time code approximately. See Grover says thanks to the team for the 7.1 beta release and group code to the team and community. Okay. That wraps up hug reports. We'll move on to status updates. I'll start. Main one of the main things I did last week was make a circuit python 7.1 point zero beta zero release. Thanks to S Kerr. I forgot to say who didn't some initial work on that. That was quite helpful. So there were a zillion changes. There were something like a hundred things to put in, I believe, but try out 7.1 point zero beta zero if you get a chance. And I've started working on an async IO learn guide with an overview of what cooperative multitasking is. And I'll give some simple examples. Okay. Foamy guy is not here. So I'll read theirs. Foamy guy is reviewing more type PRs. They've debugged and fixed an issue resulting in extra blank lines in the library example screenshots we talked about before and outside of circuit python. Foamy guy is diving into Phaser 3, the Phaser 3 JavaScript game engine a bit. Ultimately hoping to use what I learned to make a game that is played in a browser on a PC and controlled by a pi gamer connected via USB. Okay. Jerry, are you ready now? I am. See, so still on a pretty limited time availability due to being called back to work, but hopefully be wrapping that up soon and at least it pays for some new toys. Let's see. So I did play with the pi leaping glider. They work really well as, you know, out of the box. It's fun to see him working. And I just got some of the new ESP32 features. I want to give a quick report. A couple of things I stumbled across and from what I can tell, I can't get them to trigger into a UF2 bootloader. So I was talking with Catney. There seems to be some thought that there is one on there, but I couldn't get it to trigger. So what I ended up doing was erasing the loading circuit python, you know, directly. But I found that when I did that, I had to first erase the flash first and put the circuit python or else circuit python wouldn't boot. And I've seen that before on the ESP32 S2s. So just a heads up to anyone else. You can get the bootloader to work great, but I couldn't. And I haven't tried loading the bootloader to it yet. That would be another thing. And another funny little thing that occurred on the boards that have the built-in BME280. I'm seeing or was seeing this intermittent OS Error 19 unsupported operation. Sometimes it happened after it ran, I was running the BME280 simple test. And sometimes it would work for a cycle and then it would give this error. Sometimes it would give the error right away. It tried to be a code.py or be REPL. It's totally unpredictable and now I can't reproduce it. So I don't know. I'll keep, if I can reproduce it, I'll put an issue in somewhere, but it's just so again, if anyone is playing with those boards, let me be interested to see if you run into any of these issues. And then last week I upgraded some Raspberry Pis to Bullseye. And some interesting things there again for people to be aware of. I found Blinka work great, but on the braincraft, the Pi TFT support broke because they made a fundamental change to camera support. The old Raspy Still and Raspy Vid are gone. And so that didn't work. And a lot of other things that I have are broken out from that. There's a lot of information out there on the Raspberry Pi forums. I posted a link. There is a potential work around that I just haven't had a chance to try yet. But if anybody's upgrading to Bullseye, just be aware there's supposedly a very good new camera support, lib camera. But it's just, you know, some older stuff won't work. Good luck. Jerry and your feline assistant. Yes. Willing to help. All right. That's perfect timing on that last meow. All right, so last week finished up the Welcome to Circuit Python Guide update. I may have mentioned it last week. It's still awaiting final moderation. It's super huge. So I understand why it's still final moderation. It's going to be a bit of a task to go through. So there's still one page that's not published. I updated Kucky Cutter to include the read the docs fix, worked with Dylan to patch the libraries with the read the docs fix, put in a few pilot PRs and learn something new in the process. Thanks again to Jeff. Started the guide for the new monochrome 1.12 inch 128 by 128 OLED. I'm now no longer waiting for it to arrive because it's here, but was waiting for the hardware to be able to continue. Approved the final pilot PRs and identified seven circuit playground blue fruit examples that would be ideal for Pi Leap. Submitted all the code to the learn repo and started working on the guides for each of them. They each need a separate guide because that's just how Pi Leap works and there are three out of seven done. They're not public yet, but that'll be soon. So this week I'm going to be finishing up the Pi Leap guides. I'm going to start the Feather ESP 32 S2 guide. Finish the monochrome OLED guide. Make sure that existing pretty pins diagrams are in all the guides and repos they're supposed to be. A whole bunch of them got made when they when Philby and LeMore were working on pretty pins and they never got where they were supposed to be. So I have all the files for those. They just need to be uploaded to various places. Update the pretty pins read me to include instructions for using pretty pins. It currently just has a couple of a couple of commands to run. It doesn't actually tell you what any of it means or how to get set up for it or what files you need to do it, etc. And then that is also in preparation to get Dylan spun up on doing pretty pins and also unrelated spin up Dylan on creating fritzing objects. And I also cannot get these two feather ESP32S2s into the boot loader even with the purple LED which is supposed to be the indicator of when to tap reset. So I will look into why that is but I just wanted to let Jerry know that it's not you and I tried one with the BME and one without. I mean they're the same board. It shouldn't have made a difference but it doesn't. So that is what I've got. Okay, thank you Kat. Okay, Melissa, you can go ahead. Hello. So last week I fixed the PiDFT in Solrf for the update Raspberry PiOS bull release and I wrote a guide for using the new certificate of Python code editor which is now in moderation and this week I'm going to be working on adding missing boards to circuitpython.org. I'm actually working on that now and I'm going to update Raspberry Pi Blinka setup guide with using the Python extended bus library because a few people have requested that feature not knowing that was available. I'm going to maybe work on some circuitpython.org issues or maybe start another guide I'm not sure yet after that and that's it. Okay, thank you. Okay, Scott, go ahead. Hello. So last week I got circuitpython running on the Pi0 2W which was exciting. So basically it's in parity with what I've got on the Pi4 going. It's not perfect so the SD card support nearly works. I'm able to flash my system and that's really good but the problem is that I enabled mass storage over USB and somehow the accesses over USB are causing some problems so I'm going to have to figure out why that is. That's some of my work this week. I figured out how to generate image files that can be flashed with imager or etcher as you tried. That's a great way for us to distribute it and hopefully we can convince the Raspberry Pi folks to actually have in the imager a sub category for circuitpython so it'll be really easy for people to pick that. So this week I'm hoping and hoping and hoping and hoping to fix these bugs that make USB unreliable so that we can have kind of the full workflow going. On top of that there's a little bit more polish to do we do a first first merge and getting it into circuitpython.org. We'll need to polish up the board definition so it has all the pins with all the different names. I want to make it so that displays can be re-initialized at different resolutions and that board.display exists so that you can do more than just see the serial output and then after that probably after that I want to add a page to circuitpython.org for the USB stuff. So we do have PyLeap and FileGlider available as TestFlight which is a link that you click and then if you install the TestFlight app and that then installs these other apps for you to try it's pretty easy and I posted some links in circuitpython.dev last week so if you want to try out these new two new apps PyLeap and FileGlider let me know but I do hope to get a page on circuitpython.org that links to those two apps and also to code.circuitpython.org as well this week too so I'm just, I'm kind of obsessed about getting this PyLeap the Raspberry Pi stuff quote unquote done so that we can get it in so I'll probably just go heads down on that to get started so yeah, that's where I'm at trying to do other things than my brain can't thank you Scott alright now we'll wrap around to the top I'll read Cgrover who's text only Cgrover added three new scalable object classes to the display IO widget library one is a 10 segment stackable bar graph based on the LM391 X family of bar.displaydrivers a stripeable Neopixel object and a stackable four digit seven segment LED bubble display module based on the HP35 calculator display and Cgrover gives a link to a demo on YouTube if you'd like to see that also the newest widget objects are working using absolute display addressing next step is to convert to normalize the dressing to provide display size independence as with the existing scale and magic eye objects three more widgets are planned for the library an analog clock dial a traditional 90 degree analog panel meter and a horizontal edge view analog meter and Cgrover hasn't been able to start working on the new display IO arc method to draw arcs perhaps sometime later this week so these widgets all sound like some fantastic synthesizer kind of panel display is in the offing I guess okay thanks for that Cgrover so if we're now done with status updates we're moving on to the in the weeds section so Scott you're up first yes thank you sorry I'm trying to debug so I was listening to this podcast called change log and they had a person who was working on some project that I forgot them but they mentioned that they're using orbit dot love which is a kind of a community tracker as a way to keep track of like who the most engaged people in their community are and they also have some it also does some metrics around like folks that were active that are no longer as active kind of like coming into your community or leaving your community and I did actually set it up for discord already for circuit python but before I pulled some other sources of data I wanted to get a read of everybody's comfort level if we have a central place that potentially like links people's accounts across services so that this would allow us to say like this person on discord is also this person on github and we can kind of like score or keep track of their involvement across those two platforms before I did that I wanted to run it by people to see if you're comfortable with that or not are do people set up their own associations like I don't think so so these are the so what it what it can be doing is it can it like suggests merges so I've gotten some false positives in terms of like yeah I've gotten some false positives from like discord names that are the same I've gotten some merge options for that I don't know if orbit.love allows like for opt-in by each user I'm also we can do it as a team although at some point it becomes kind of a paid thing where we could actually get more people otherwise I'm happy to also do it in terms of just like let me know that you're okay with that and then either I can give you access or or we can do that so I'm okay kind of like doing it on an opt-in basis but I don't know how much it will try to automatically do for me if I do actually do it on like I'm not sure how I feel about all this okay I mean that's why I'm asking yeah if anybody wants so I do have it set up with discord only and I can add teammates so if you're interested in just taking a look at it in more detail let me know and I'll I can add people as teammates to take a look at it too but I know that we do kind of track community involvement anyway yeah that's right oh my z shell that's when they mentioned it so yeah so I don't have to do it but I know that we do kind of sometimes do want to track how many people are involved so I'm okay not doing this I think it is going to be more work but there is potentially some interesting kind of cross-service stuff that we can see yeah so I think maybe we should just I mean I would say let's go ahead and look at it independently and then think about it and I think we don't have to do the cross-service thing I think the statistics that we might get like github's involvement statistics are kind of hard to understand sometimes and discord also that stuff is publicly available from the API probably but if it's if it's in a nicely digested format that can be interesting so yeah and they do have this notion of workspaces so it's possible we could actually create like separate workspaces for different services so we could at least like aggregate all github involvement across our repos together but not necessarily connecting that to discord yeah I think that would be doable if we found that to be helpful so yeah let me know if you want to be added as a teammate I've only set it up to suck in discord data which I think is okay because I think people need to treat discord as a public thing because anybody can join it and anybody can get access to what's going on there so yeah go ahead and just reach out to me and let me know what you think if you want to try it or if you want to make sure that we don't have anything happen there but it's also not super high on my list I just thought it was potentially an interesting tool for us okay are there other comments about this that anyone has okay well thanks Scott I think we'll all look at it and think about it yeah okay Mark are you available to do your section so I put in the draft PR for the IS-31 driver and I've got a few questions and I understand that most people probably haven't had a chance to look at it so some of these might just be deferred but I put it in draft because there are some finishing polishes that I just wasn't sure the best direction to go that I wanted to put out there so more to bring these up as questions I still have than to necessarily get an answer today so the first was right now should this be in the core and then what board should it be turned on for I have seemed to have got a lot of response that people like this so I'm thinking the answer is yes the first one right now the PR only has it turned on for the one eyeglass specific board I'm not sure how much space it's going to take in the end so is it worth enabling it for more boards or not I think we would need to know how much space it is overall and I haven't looked at the NRF boards and I guess it's not just NRF boards it's any board yeah it should work with any right now I've only tested it on the NRF board yeah I mean it's obvious that it should go on the LED driver board maybe one of those things is like if you don't have that and you want it we have the building circuit by then learn guide and it's not hard to turn on yeah that's what I was thinking as well because we have the demo on PILEEP with the circuit playground bluefruit maybe that would be a second board to have it on by default but I don't know what our space situation for that is it's something I can look at as well just to sort of get an idea so the next one I think I know the answer to but was for these matrices of LED there's a mapping for those that don't know that basically pixel 00 is LED 8, 9 and 10 for RGB now this changes display board so the glasses has one mapping versus the others so my thought is just to pass this in as potentially an array to the initialization does that seem to make sense pass it to the mapping yeah it passed the mapping in well I would probably just do it as a big byte oh yeah it's not something that a lot of people are going to have to manipulate and it's something that you're going to want to make sure is kind of compact and as I thought towards and part of stealing my thunder for question 4 was would a helper python library be worthwhile in this case and I'm thinking yes because then we can provide mm-hmm here is the mapping so you're not trying to map 300 pixels yourself right I'll put in something for that mm-hmm this is one I was less sure on the best way to go is for the gamma table which is fairly necessarily to make it look good it's hard coded in the Arduino driver but of course it would increase build size it can be calculated in RAM so it's kind of a trade off RAM versus build size it's 256 bytes so I'm not sure what the best way to go is that's pretty small from a firmware point of view so unless you think that somebody needs to change the gamut like do you think that's something that people want to vary that was my only thought is if you wanted to vary the gamma value it's hard coded into the Arduino as well as I think that's exponent was 2.6 and tends to work fairly well but if it's calculated at run time then of course it can be varied so are there variants on the LEDs like different not that I've heard of before but I'm not an expert in this area the other thing we've seen in the past like sometimes the manufacturer changes the process like we've gotten the A12 or SK's I can't remember like they changed and they got brighter or dimmer or something and so that's a reason to make it flexible in the future in case there's some manufacturing change in it I think either making it 256 is fine on either the RAM or the firmware size I don't think it makes a lot of difference so you might do the more flexible one well I would say do the flash one do the easiest thing first yeah that's the other thought it's easy enough to change later yeah and the thing that what was I doing like this there was some other thing that I kind of had the same trade off and you also have to account for that if you're generating it and putting it in RAM you're actually adding code size so that 256 bytes is not competing against zero flash space it's competing about against how much code size gets added to store the code that generates the table so the difference is going to be less than 256 bytes so I would just say do the simplest thing okay that one makes sense yeah and the last sorry just to say I don't know how big that code would be but my guess is not that small if it starts being configurable it'll grow in size sure yeah yeah I mean that's a separate reason to do it in RAM and the final one again this is the one that I'm not sure if there's a good answer to today is things like the eyeglasses ring lights and it might be only this board that ever has this where it's like is the display matrix but there's still other LEDs on the board it'd be nice to be able to control both but there's no real way to map that into the display IO because it's dealing with a screen type object the only thing I could think is that the python a python library that at least knows that the I2C for the the display is also going on and can kind of balance the two this might be a for later type deal so right now the library doesn't do any your module doesn't do anything with those no it treats it as an 18 by 5 display okay because they don't map nicely into an XY coordinate I haven't really played with running both the python driver and this at the same time in theory they should work because they're both just sharing the same bus you have a bit of a race condition over initialization whichever is initialized first gets the final say but again that shouldn't matter I'm thinking about this one a little bit more because for my what I hope to finally do with this code myself I would like the ring lights going so I wonder my brain kind of went to the like what if you made the ring lights like separate rows in the display frame buffer the problem is the ring lights are 24 pixels or 23 so it doesn't I thought the same thing if they were both 18 then sure but I wonder if what you do is because you have you're introducing a new object for this right maybe I haven't I haven't looked at it that's yeah maybe what you want to do is actually present a pixel buff on that object one maybe one for each eye or whatever the python library does in terms of like because it produces a pixel buff equivalent right like yeah the only thing I thought there was there are other boards that use this chipset which actually is a question I had well talking in this is I think it makes sense to keep this a little bit generic you threw me off by the fact that you wanted it to work well and it can be something that I can keep poking at after like if it isn't sort of make it break it for now but it's probably play with it on my own to see what I can do I mean it can still be extra rows and just some of them aren't functional that's kind of yeah if it's two rows of 18 and only six of the last row are useful that's that's just the programmers problem so and you're not going to use you're not going to draw shapes or anything in those rows right they're just so they're just you're just going to turn them on and off or something so I mean the idea of making it like a neopixel string or something is kind of could present it as that also but that's pretty complicated problem internally so I mean you could in the same way that you're passing a giant array for the mapping you could also pass like a list of bytes yeah like a secondary yeah for like right like however many pixel buffs you want of that view of this thing and those bytes tell you the RGB numbers for the things that you're going to treat as a pixel buff because I'm just worried that like what if you're going to want to treat it like use the LED animations but also how to display IO going like yeah actually using the pixel buff is and passing something for there is interesting I'll take a look at that I think that is probably what you're going to want I agree with Dan that like there is something interesting about like saying like pixels have special values in this particular spot like in the frame buffer but that's not going to make it easy for people to use the existing LED animations that they probably just want on the rings yeah I'll take a look at that and see what I can do because that that's an interesting idea and then if it can be passed in and then the driver just sort of manages right and you can default it to nothing so that for the like regular and just grid thing yeah and we're going to want like what you're talking about like basic helper libraries on top of this just to do the basic initialization for a particular device yeah that's what I was figuring and so like it's not like people are going to really need to manage these weird byte arrays that do all these mappings it's like very similar to the way that like we have very light wrappers for all the e-ink initialization stuff and all the display initialization stuff like sounds like you're on the right track okay that's good I sort of had some thoughts but I just wanted to make sure it was matching what you guys as well thought yeah I'll take a look I'll take a look in the next couple hours to yeah to look here the only other thing is I've only been able to test this on the eyeglass because that's what I've got so if anyone's got any other devices they want to run it on and let me know how it works that's great okay okay all right well thanks for that discussion thanks a lot okay so that wraps up this edition of the circuit python weekly meeting next meeting is next Monday again at 2 p.m. Eastern 11 a.m. Central this time this this meeting will be up on YouTube in a little while and also on podcast services hopefully the recording has come out fine all right anything else anybody would like to get into the recording right now if not I will stop recording