#circuitpython-dev
orchid basinBOT
proven garnet
I'm doing a quick crawl through the ReadTheDocs CI status via adabot tools - I noticed that some of my older libraries that were transferred to be under adafruitwere failing doc builds. I'll tag any repositories it catches with issues. (also, howdy!)
proven garnet
Okay, I think the only things that I need help with in fixing this is:
- Adding the RTD webhooks to the GitHub repositories for the following new RTD projects:
https://app.readthedocs.org/projects/adafruit-circuitpython-pio-uart/
https://app.readthedocs.org/projects/adafruit-circuitpython-prompt-toolkit/
- Adabot should accept the invite to be a maintainer on RTD.
candid sun
<@&356864093652516868> We'll have our weekly meeting in about 60 minutes from now in this text channel and in the circuitpython voice channel. Please take the time to add your notes in advance to the document: https://docs.google.com/document/d/1LkWa9fIlK7wzdpeyxYi2RbaUSO2Dx84AvcDQm40nA7s/edit?tab=t.0 -- I look forward to everyone's updates!
lone axle
Thanks for hosting Liz. Have a great week everyone 👋
candid sun
Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1jvf9RJemO6wEgcF2ca4Y0_FeNHtK9IuHQa1Ij3aErYc/edit?tab=t.0
manic glacierBOT
Maybe the last 3 characters in the filename are consistent. Looking back at screenshots from when it occurred before I found a third instance with a different filename but only the first character differs between all 3 of them. I believe the other times the file appeared matched this pattern as well but I don't have screenshots of any others.
lone axle
@candid sun the reproducer for the s2 sleep / flash corruption thing is in the issue here: https://github.com/adafruit/circuitpython/issues/10398. It expects settings.toml entries for WIFI_PASSWORD, and WIFI_PASSWORD (intentionally different from the default ones to avoid web workflow starting up), and ADAFRUIT_AIO_USERNAME, ADAFRUIT_AIO_KEY as well as a random feed on AIO.
jaunty juniper
fun fact, yesterday or so I had weird circumstance where two mounted CP drives became suddenly called "Untitled" (or something like that) when I connected a third board (I have more boards connected but not mounted), and some reset was required to fix it (didn't reboot the computer, or restart the Finder). That's MacOS 15.4.1. Never seen that before, couldn't repro. 🤷
ionic elk
Is there some contributor documentation on translations? Looks like it's what's failing my CI builds
devout jolt
Is there some contributor documentation on translations? Looks like it's what's ...
The main thing I always forget is: if you make any changes to the strings in the code, be sure to run "make translate" at the root of the repo to update "locale/circuitpython.pot" and then be sure to check that file in with your change
jaunty juniper
I note that make translate is not mentioned in https://learn.adafruit.com/building-circuitpython
manic glacierBOT
Thanks for the reply, but I just tested it and its the same issue happening all time... even with busio and board.IMU_SDA and board.IMU_SCL.
But really thanks and how can I know for the future how to find real name of pins ?
Sorry the issue is in french but it's saying that at line 10 : runtimeerror: no pull up...
Ohhhh you're right I just see it now we have to enable a pin to start I²C. THANKS all fast and kind amasing community <3.
My final code is up here
ionic elk
I note that `make translate` is not mentioned in <https://learn.adafruit.com/bui...
I thought I'd done the make during my pre-commit but it seems something went wrong. Definitely agree it should be in the build guide!
ionic elk
@tulip sleet wondering the best way to handle duplicate VID/PID for the alternate ROS builds I've been creating for a limited number of boards. Given that microROS is large and may not be commonly used, I've been enabling it only for "alt" builds of boards, such as espressif_esp32s3_devkitc_1_n8r2_ros. Would it be permissable for these alts to share the original VID/PID, as they are the same board with limited additional software? Or should I figure out a different solution?
tulip sleet
<@329766224093249548> wondering the best way to handle duplicate VID/PID for the...
Yes, that's fine, since its' the same board with the same capabilities. It is possible to make aliases of boards
ionic elk
What's an existing alias I could look at for reference, to suppress the CI error?
tulip sleet
What's an existing alias I could look at for reference, to suppress the CI error...
like the 4H version of the CIrcuit Playground Express, or the displayio build of the CPX, etc.
devout jolt
Yes, that's fine, since its' the same board with the same capabilities. It is po...
I have a similar (to me) question: Locally I have a raspberry_pi_pico_synth board that's just raspberry_pi_pico but with CIRCUITPY_AUDIOEFFECTS=1 (not every effect works, but many do!) Otherwise the board has identical VID/PID but a changed USB_PRODUCT="Pico Synth". I've not ever tried to merge it because I figured it would cause problems. But if I did, what should I do?
ionic elk
Apparently, you register with circuitpython/tools/ci_check_duplicate_usb_vid_pid.py
ionic elk
@tulip sleet this is thinking ahead a lil but micro-ros has a construct called a "service" which is basically a function callback requested over the network. Do you think it's feasible to call a user-created circuitpython function during a polling or wait loop that rclcpy creates?
tulip sleet
<@329766224093249548> this is thinking ahead a lil but micro-ros has a construc...
This is possible, it's what is done for adafruit_sdcard for instance (calling py code from native code).
Another thing to consider is whether to create an _rclcpy interface that provides the basic data objects, but implement some higher-level stuff a Python library, so you don't have to implement everything in C.
manic glacierBOT
I pushed my working tree: https://github.com/bablokb/circuitpython/tree/rp2xxx_powman
Note that this is based on 9.2.8.
I am also adding an image from ppk2 that demonstrates the behavior I described above. In this test, the system needed four attempts to enter the power-off state, but that count is random.
devout jolt
I'm trying to implement a driver for an SPI DAC (MCP4822) on rp2 that requires the per-sample bits to be shifted up in the word and other bits to be set per sample (for gain, channel, etc selection). I'm looking at rp2's I2SOut.c & PWMOut.c and both just set up the DMA to the output register and start it going. Is there a way to have a per-buffer callback be called so I can modify all the samples before DMA sends them out to SPI?
left mirage
Hi, curious if there is a port of circuitpython capable of building/running on the nRF24LU1+ microcontrollers (the ones used in logitech unifiy receivers)
devout jolt
Hi, curious if there is a port of circuitpython capable of building/running on t...
Looks like those only have 16kB of RAM, so, no. And they’re based on an 8-bit 8051 core
left mirage
Looks like those only have 16kB of RAM, so, no. And they’re based on an 8-bit 80...
Makes sense, thanks
manic glacierBOT
atomic summit
Hiya folks - before I open an issue in github, I wanted to check if anyone has been seeing the old
RuntimeError: No pull up found on SDA or SCL; check your wiring
In 9.2.7/9.2.8 on the Espressif port? Specifically the ESP32-S3?
I get that every time I try to initialise the I2C using i2c = board.I2C()
The board has 10k pull-ups on SDA and SCL.
It even fails if I try to setup the bus directly
>>> i2c = busio.I2C(microcontroller.pin.GPIO9, microcontroller.pin.GPIO8)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: No pull up found on SDA or SCL; check your wiring
Same board works fine in Arduino and scanning finds the I2C device without issue (plus I can communicate with the device).
Scanning...
I2C device found at address 0x36 !
found 1 devices, done!
Is this a know issue? This is happening on a new unannounced board, but the board works in MP and Arduino/PIO... so not a HW issue.
Is there a way to disable that check?
devout jolt
Hiya folks - before I open an issue in github, I wanted to check if anyone has b...
Which exact ESP32-S3 firmware are you running?
atomic summit
Which exact ESP32-S3 firmware are you running?
I'm seeing this on my TinyS3, FeatherS3 and ProS3 firmware - 9.2.7
and 9.2.8 on TinyS3
devout jolt
I'm seeing this on my TinyS3, FeatherS3 and ProS3 firmware - 9.2.7
and 9.2.8 on ...
Weird! I don’t see anything oddball in the port definitions for the TinyS3
atomic summit
Adafruit CircuitPython 9.2.8 on 2025-05-28; TinyS3 with ESP32S3
>>>
>>> import board
>>> board.I2C()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: No pull up found on SDA or SCL; check your wiring
>>>
There have been no CP changes to my boards for a long time.
If this is not a known issue, I'll keep hunting here before I raise an issue
devout jolt
There have been no CP changes to my boards for a long time.
If this is not a kn...
Normally I’d say this would be a peripheral power or pull-up issue but I think not here. I’ll try an S3 later tonight when I get to a computer.
atomic summit
Normally I’d say this would be a peripheral power or pull-up issue but I think n...
yeah, 100% not the case here of a HW /periheral power isue. Boards work great outside of CP.
Ok, I think I know what it is... 2x I2C devices on the board, both on the same I2C Bus. One powered up and one powered down. CP doesn't like that.
However the pullup check is doing it's thing, the power state of one of the devices is influencing it, which is shouldn't.
if I have the both powered, it works:
Adafruit CircuitPython 9.2.8 on 2025-05-28; TinyS3 with ESP32S3
>>> import board
>>> board.I2C()
<I2C>
>>>
we really need a way to disable the pull-up check
if either are powered down, or both are powered down, it fails.
The fail should be the lack of initialising the peripheral, not a pull-up failure.
Thankfully I can work around this now I know what it is... but I feel like I'm being punished here for a valid HW design implementation 😉
devout jolt
Thankfully I can work around this now I know what it is... but I feel like I'm b...
I’m kinda surprised it works under Arduino. The pull-up check is just checking to see if either pin is pulled low. https://github.com/adafruit/circuitpython/blob/48891653e5ab0b6999f4d34bde6fd985dcbb9e77/ports/espressif/common-hal/busio/I2C.c#L62
atomic summit
it's def working in Arduino. So can I disable CIRCUITPY_REQUIRE_I2C_PULLUPS in my firmware to get around this?
devout jolt
I think so
devout jolt
I wonder if the difference is that Arduino I2C drives SCL high on init while CircuitPython relies on the pull-ups, meaning the misbehaving device doesn’t mess up the bus
atomic summit
I'll do some extra digging when I'm back at work next week and report back, thanks for your help @devout jolt 🙂
atomic summit
Hmm, I have another weird issue that I cant find anything about online... all of my boards I'm flashing CP 9.2.7 or 9.2.8 onto, via UF2, wont appear on my Mac running macOS 15.5 - they all appear as NO NAME in /Volumes and don't mount, BUT they all mount correctly plugged into my wife's Mac running macOS 14.x (can't remember which) and on my son's Win11 notebook.
But they will mount the UF2 drive if I push them into that on my Mac, but wont ever mount the CIRCUITPY drive.
I've now tried this on 11 boards (a mix of TinyS3, FeatherS3 and ProS3) and some with CP installed from my testjig (rPI) and some done manually on my Mac (erasing teh flash, flashing UF2, then mounting and copying over CP).
Initially I thought it was the "didn't format the partition properly, so the volume didn't get named" issues that we've seen in the past, but these boards all mount correctly on other machines.
Anyone here using macOS Sequoia 15.5 (24F74) that can confirm or refute there's a macOS issue?
jaunty juniper
Anyone here using macOS Sequoia 15.5 (24F74) that can confirm or refute there's ...
there is that: #circuitpython-dev message
but I haven't heard more on that. I haven't updated to 15.5 for now just in case.
have you tried manually unmounting/remounting it to see what happens ? (using umount and mount)
thorny jay
It seems that the following message is in my discord buffer since last meeting:
Thank you @tulip sleet (and @crimson ferry) for the in the weed answer/idea (from last week?).
The network code I am working on only care about one interface, the "native" on that board, or AirLift or WizNet. And I think that order is the prefered one, so I can check in that order:
- Does it have (try import) wifi? => use that
- Does it have board.ESP_CS => try AirLift
- Try WizNet else there is no networking anyway.
atomic summit
there is that: https://discord.com/channels/327254708534116352/32729899633265869...
Oh no! It can't be that the flashing failed as it mounts ok on other machines, and most of my boards tested were flashed on my rPI testjigs... so I don't know if it's exactly the same or not, bt def seems to be a regression in macOS 😦
But at least now I know it's not just me.
And I only moved to 15.5 yesterday 😦 I think my Mac Studio at work is still 15.4.. maybe
jaunty juniper
somebody seemed to have an issue flashing in 15.5, but that was solved with redownloading the uf2 so it was seemingly unrelated
jaunty juniper
However the pullup check is doing it's thing, the power state of one of the devi...
it pulls down and sees how fast it takes to come back up, based on the frequency demanded. So I assume when a device is powered down it makes the pull up become too weak/slow for the test ?
For the default 100 kHz it maths to waiting like 13µs for example:
// We must pull up within 3us to achieve 400khz.
common_hal_mcu_delay_us((1200000 + frequency - 1) / frequency);
now I'm curious what it would look like on an oscilloscope to see why the test fails, but you probably have better things to do 🙂
atomic summit
Well, I'm at home, and it's a piublic holiday tomorrow, so home then as well, so can't get in front of a scope till mid week. If I remember, and have time I'll see what I can capture
manic glacierBOT
manic glacierBOT
tulip sleet
<@&356864093652516868> Our weekly discord meeting is in just under 3 hours. Add your notes to https://docs.google.com/document/d/1jvf9RJemO6wEgcF2ca4Y0_FeNHtK9IuHQa1Ij3aErYc/edit?usp=sharing. See you! See the top pinned message for more info.
thorny jay
If the weekly meeting is today, I just added hug reports.
It seems that I have not done any CircuitPython in the last 6 days, I have not even implemented any of the suggested improvement to my "auto-detect" network python file.
Also no in the weeds question.
tulip sleet
I'm working on a getting a working microphone. Be there in a minute or two
lone axle
https://shawnhymel.com/2759/the-wrong-way-to-use-ai-and-how-to-actually-write-better-code-with-llms/
uncut nexus
sounds quite cool, foamyguy!
turbid radish
Thanks Dan!
lone axle
Thanks for hosting Dan! Have a great week folks.
tulip sleet
Here is the notes document for next Monday’s CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1hl0zjeBqJOAb7zaFQRHPTIioSjKfkTWbpw1xtVEOyEo/edit?usp=sharing
ionic elk
@tulip sleet Should I keep my ESP_LOGW calls, or toss them? Normally I'd maybe leave them as comments, with their associated messages in in case the module needs further in-depth debugging, but I want to adhere to expected style.
Also, were you saying that mp_raise_RuntimeError_varg(MP_ERROR_TEXT("ROS failure at line: %d"), __LINE__); will turn into a unique QSTR and not save space?
thorny jay
So the FruitJam with build-in C6 AirLift is like a PyPortalTV.
In my solar panel monitoring journey, I used Feather RP2350 + AirLift FeatherWing + HSTX2DVI to display exactly the same thing as on a PyPortal, with exactly the same 320x240 resolution.
Is there any FruitJam / Metro 2350 / Feather RP2350 code example that does more than 320x240, because the pixel are rather big on a "TV". It's ok to lose colors.
Also I was wondering if it was possible to use the "text" mode and do better there with pseudo graphic character, like in old Basic Home Computer. Or custom font.
I guess memory is the issue, in the good old days, computer had "sprites" to have moving objects, and that was not taking much space as there was no frame buffer, but the screen was render line by line based on sprite position. Of course this is far from displayio.
tiny peak
So the FruitJam with build-in C6 AirLift is like a PyPortalTV.
In my solar panel...
To see what's currently possible for RP2350 DVI video output resolutions and color depths in CircuitPython, take a look at the docs for picodvi.Framebuffer
If you want to get fancier than that, you might look at using Arduino instead of CircuitPython
tulip sleet
Also, were you saying that `mp_raise_RuntimeError_varg(MP_ERROR_TEXT("ROS failur...
No, that will not be a unique qstr, it's fine. If you are raising errors, I wouldn't leave the ESP_LOGW's in. Since they are turned off in a non-debug build, I think it would be better to raise the exceptions, especially when the implementation is young and you want to help people debug it
ionic elk
I've deleted te ESP_LOGWs that occured during runtime, but I was more referring to the ones on errors that cannot be processed at runtime, in de-init and reset
thorny jay
To see what's currently possible for RP2350 DVI video output resolutions and col...
By the way I saw your color pallet Playgound page, thanks: https://adafruit-playground.com/u/SamBlenny/pages/fruit-jam-color-checker
I was hoping for example code, because the documentation is not so clear:
On RP2350, output resolution is either 640x480 or 720x400. Monochrome framebuffers (color_depth=1 or 2) must be full resolution. 4-bit color must also be full resolution. 8-bit color can be quarter, half or full resolution. 16-bit color and 32-bit color must be quarter or half resolution due to internal RAM limitations.
So I should be able to do 640x480 full resolution in 8-bit?
As oppose to all the example I see that are 320x240 with pixel doubling.
manic glacierBOT
manic glacierBOT
manic glacierBOT
ionic elk
Getting a zephyr error, ERROR:__main__:autogen_board_info.toml is out of date., anyone know how to fix that?
it's in zephyr-cp, seems unrelated to my PR
ionic elk
The CI seems to skip zephyr-cp normally, maybe it's because I've added a new module to shared-bindings
onyx hinge
@ionic elk seems likely, that file appears to include a line for every module , = true or = false depending whether it's included. If that's accurate, then those files would all need to be regenerated if a new module is introduced.
The source file says this, but it didn't seem to show up in the build output: autogen_board_info.toml is missing or out of date. Please run `make BOARD={board}` locally and commit {autogen_board_info_fn}." I don't know whether you need a zephyr setup in order to do this successfully.
but probably
the context is https://github.com/adafruit/circuitpython/pull/9955 and the CI errors fwiw
ionic elk
Having to have a local zephyr setup to add a module for a totally different port seems a bit onerous
I'll see what I can do but that seems like something that ought to be reworked
onyx hinge
@slender iron if you have a chance, maybe you can weigh in. are @ionic elk and I overlooking something, or is it necessary to install zephyr and build every zephyr board, just to add a line for a new shared-bindings module that is disabled on all zephyr boards?
tulip sleet
I'll see what I can do but that seems like something that ought to be reworked
why don't you try to edit those files by hand (despite what it says) and add rclcpy = false to the .toml file. You could try it with just one and see if that board builds.
ionic elk
seems to have done it, but now there's random errors in the i.mx port
related to the USB core? error: unknown type name 'tuh_bus_info_t'; did you mean 'tuh_itf_info_t'?
I'm fairly confident that's an entirely unrelated infrastructure issue.
onyx hinge
@ionic elk if you look at the changes tab of your PR you can see that your PR modifies the tinyusb submodule. This often happens unintentionally. It could lead to the message you got. https://github.com/adafruit/circuitpython/pull/9955/files#diff-749a20dad23785e96fde6ded78481c711e4cdc1f60d8adde2ceb7404f7be7c0e
ionic elk
wait, no, it's not, I got a tinyUSB submodule update
oh yep ninjaed
yep must have snuck into a PR somehow
onyx hinge
it happens often enough that it feels like a git flaw, even though I don't know how it should be fixed. (for instance, "git commit -a" will do it, if you haven't been careful to "git submodule update" whenever switching branches)
ionic elk
nah I think this was me being lazy on literally the last commit I made
I didn't do a git status like an idiot
onyx hinge
for years I tried criticizing my colleagues when they made that mistake but it didn't work and also they hated me 😜
jaunty juniper
I made a shell alias st as a shortcut, sometimes I type it in chat boxes by mistake
ionic elk
it happens often enough that it feels like a git flaw, even though I don't know ...
if git were to add anything, I feel like the most helpful thing would just be a reminder at the end of merge messages. "Submodules have been changed, but not updated", or something
ionic elk
finally done!
slender iron
<@252717193496756235> if you have a chance, maybe you can weigh in. are <@323278...
Look in tools in the zephyr port. There is a script to do it there I think
jaunty juniper
@tulip sleet I use en_US so I don't usually pay much attention to translations, but I could look more actively at new weblate PRs. I can also look at fixing the french on weblate
proven garnet
Reviewing this PR, it looks good but wanted to check about the change of no longer returning a location when there is no fix. The change itself seems reasonable, but I don't have a good sense of how much legacy code will need to be changed or updated, like Learn guides.
https://github.com/adafruit/Adafruit_CircuitPython_GPS/pull/115
tulip sleet
<@329766224093249548> I use en_US so I don't usually pay much attention to trans...
That would be great, if it wouldn't take a lot of time. Besides english and french, do you know some other languages? My french is low intermediate but not for technical
tulip sleet
<@329766224093249548> I use en_US so I don't usually pay much attention to trans...
I could just ping you on french translations
jaunty juniper
I could just ping you on french translations
sure, I can set a filter on Weblate and French too (I usually let github emails go to a github mailbox, but filter some like mentions and review requests to remain in my inbox)
jaunty juniper
and I don't have enough German left in my brain to help with that (or latin, but we don't have a latin translation anyway, alea jacta est or something)
hidden fulcrum
Hello,
I am a developer at Luftdaten.at.
We are using CircuitPython with the ESP32-S3 for our air quality sensors. For educational purposes and ease of use, we require WiFi Enterprise support in order to use these sensors at universities with eduroam.
Specifically, we need support for EAP-PEAP and EAP-TTLS authentication.
I would be willing to contribute this functionality to CircuitPython, and I would greatly appreciate a brief overview of the required steps to get started.
Lg, Nik Sauer
stuck elbow
Hello,
I am a developer at Luftdaten.at.
We are using CircuitPython with the ES...
did you already get the firmware to build?
thorny jay
Hello,
I am a developer at Luftdaten.at.
We are using CircuitPython with the ES...
Maybe it should start with an issue on the git.
Then if you want to talk live publicly about it, it could be discussed "in the weeds" on a Monday meeting here on Discord.
I am just a member of the community, you can get better suggestion from someone working for Adafruit.
tulip sleet
Hello,
I am a developer at Luftdaten.at.
We are using CircuitPython with the ES...
We are happy to work with you on such a PR. These two guides will be helpful:
https://learn.adafruit.com/building-circuitpython
https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github
tulip sleet
I believe MicroPython has already done some work on this, which may be helpful to look at. Their API is different, but the ESP-IDF-level code would presumably be similar.
mortal kernel
@tulip sleet While we're waiting for an official update from Pico SDK 2.1.1 to 2.1.2, I need to cherry-pick some PR's from the develop branch. A way to do this will be to create a branch circuitpython-2.1.1 in our forked repo from the 2.1.1 tag and cherry-pick to that. Alternatively, we could move to the upstream develop branch, but that will require updates to other libraries as well and entails some risk of other issues cropping up. We're currently using a branch force_inline_critical_section_2.1.1 in our forked repo that is based on upstream tag 2.1.1, so what I'm proposing is a variation of that with a more generic branch name, similar to what we do with ESP-IDF.
tulip sleet
<@329766224093249548> While we're waiting for an official update from Pico SDK `...
That sounds fine to me. They seem a bit overdue for another release.
tulip sleet
<@329766224093249548> While we're waiting for an official update from Pico SDK `...
I just looked at the commits in develop, which has a number of interesting changes. Which other libraries would we need to update? If we moved to a particular commit on develop, we could test against that. We will need to update the other libraries anyway at some point. It might be less work to use develop for now, since we are still doing alpha releases, and by the time we get to betas or final, 2.1.2 should be out.
I am just trying to save some work here. Of course, tracking down new bugs is also work.
mortal kernel
I just looked at the commits in `develop`, which has a number of interesting cha...
The libraries we'd need to update are, at least,: cyw43-driver, lwip, and mbedtls. There could be others. I've re-synced the develop branch of our fork, so it's up to date (less my most recent power manager PR which is in the PR queue). So we'll still need a branch in our fork, say circuitpython-2.1.2-develop, to pick up that PR. I'm game for going that route.
tulip sleet
The libraries we'd need to update are, at least,: `cyw43-driver`, `lwip`, and `m...
do lwip and mbedtls need to be updated due to (solely) cyw43-driver?
and your power PR is held up because you need the 2.1.2 fixes? I just want to make sure I understand.
tulip sleet
The libraries we'd need to update are, at least,: `cyw43-driver`, `lwip`, and `m...
we can talk about this in audio to save typing
mortal kernel
@tulip sleet Just back from my walk. I'm not sure about the lwip, mbedtls, and cyw43-driver inter-dependencies. I need the upstream power PR to get down to the 0.5 mA on deep sleep. There's also an LPOSC setting issue that's fixed on the develop branch, plus Scott's PR, plus my PR for the PICO_RP2040 and PICO_RP2350 macros. After thinking it over, I'd rather go with a circuitpython-2.1.1 branch in our forked repo that cherry-picks what we need, as I'd first proposed. We can move to the official 2.1.2 once it's released. That way we're not taking on a conversion that may or may not be complicated. No idea why 2.1.2 is delayed, but it has been a while. If you'd like to talk about it, give me a ping.
tulip sleet
<@329766224093249548> Just back from my walk. I'm not sure about the lwip, mbedt...
I understand. Fine to go ahead with the cherry-pick branch
onyx hinge
@ionic elk @tulip sleet @slender iron late follow up: I've never installed/configured zephyr but running python ports/zephyr-cp/cptools/update_board_info.py from the top dir of circuitpython regenerated a bunch of files, possibly successfully. it added a bunch of = false lines, which surprises me a bit because I thought the code was checking whethere there was any change, including lines for disabled modules. but, I didn't check too closely what happens at CI time.
if these files can be generated so easily (less than 100ms here!) maybe they don't need to be committed after all. Is this used by zephyr or just for docs/shared_bindings_matrix.py ?
or my understanding is incomplete, more likely.
but I think that script might be the one tannewt meant is good for just adding the =false lines for new shared-modules
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
ionic elk
<@323278594258370561> <@329766224093249548> <@252717193496756235> late follow up...
sounds reasonable to me. But a heads up that I probably won't be contributing much to solving the issue since it's unrelated to rclcpy
tiny peak
Two part question for folks involved with RP2350 HSTX DVI stuff:
- Am I just imagining this, or was there some discussion of making an API thing that would give you a way to be sure of the exact picodvi video mode that's in use when code.py starts?
- Is there a plan for adding a
picodvi.Framebuffer.color_depthproperty so that it's possible to detect the full video mode at runtime? (widthandheightproperties are already present)
Context: It's currently not possible, as far as I can tell (10.0.0-alpha.x), to detect which video mode picodvi is in. So, you kinda need to always do a release_displays() and then create a new picodvi display at the start of code.py. That can get you into trouble with heap allocations.
Detecting width and height works fine, but it's also important to know about color_depth.
I was thinking of making a github issue with a feature request for adding an picodvi.Framebuffer.color_depth property, but I'm not sure if I've overlooked some existing way of managing the video mode.
manic glacierBOT
manic glacierBOT
mortal kernel
@tulip sleet I'd like to go ahead with the merge now. OK with you?
tulip sleet
<@329766224093249548> I'd like to go ahead with the merge now. OK with you?
yes, sure, I wasn't sure if you were looking at something before re-approving
mortal kernel
I'll build after the merge to get a good look at what's happening with NLR. It's one of those things where I can guess what the build is doing, but actually examining a build with symbols in GDB tells the real story.
mortal kernel
@tulip sleet I've verified that for Espressif builds for Xtensa and Risc-V cores that the native NLR implementations from Micropython are not used. Instead, both use Espressif's longjmp.
tulip sleet
<@329766224093249548> I've verified that for Espressif builds for Xtensa and Ris...
hmm, I wonder if it's turned off somewhere. I'm confused why the nlr*.c files are there at all if they're not used. We can look to see which PR's added those and what they say.
mortal kernel
hmm, I wonder if it's turned off somewhere. I'm confused why the nlr*.c files ar...
We set MICROPY_NLR_SETJMP to 1 in ports/espressif/mpconfigport.h which turns off native NLR for CP for all Espressif core flavors. There's no real performance advantage to using the native versions since using the non-native version gets to equivalent native code in longjmp/setjmp with a trivial amount of linkage. Looks like an exercise in Yak shaving to me.
One more thing, if we turned it on we'd get a regression for at least Xtensa cores!
lone axle
<@&356864093652516868> The weekly meeting is scheduled to occur today at the usual time 11am US Pacific / 2pm US Eastern. About 90 minutes from now. Feel free to add your hug reports and status updates to the notes doc https://docs.google.com/document/d/1hl0zjeBqJOAb7zaFQRHPTIioSjKfkTWbpw1xtVEOyEo/edit?usp=sharing. We look forward to hearing from everyone.
tulip sleet
Thanks @lone axle !
lone axle
Thanks everyone, have a great week.
Here is the notes document for next Monday’s CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1hI6KHn3VmxD-cUztuCCBbLCvQCurP2DwukbjIUZbScU/edit?usp=sharing
manic glacierBOT
orchid basinBOT
ionic elk
Is it worth it to make a new issue about adding message types to rclcpy or should I just chat about it in this thread if stuff comes up
tulip sleet
https://blog.adafruit.com/2025/06/17/circuitpython-10-0-0-alpha-7-released/
Highlights of this release
- Update frozen modules.
- Merge updates from MicroPython v1.24.1.
- Espressif:
- Expand the CircuitPython firmware partition on non-USB boards, allowing more space for features in the future.
- Fix
pulseio.PulseInlength limitation. - Initial implementation of MicroROS.
- Nordic: reinitialize BLE properly after deep sleep.
- Incorporate fixes from CircuitPython 9.2.8 and later:
- Fix
dequebug. - Fix I2S audio file read causing memory corruption.
- Support "Spectra6" six-color e-ink displays.
- Fix
audiodelays.Delaywhenfreq_shift=True. - Board fixes.
- Fix
tulip sleet
Is it worth it to make a new issue about adding message types to `rclcpy` or sho...
If there's work to do, you could make an issue (with tasks, if that makes sense). You can use an issue for your own record-keeping: that's fine. I'd mark it long term
tiny peak
@lone axle color_depth detection PR works great on Metro RP2350 no PSRAM and Fruit Jam Rev B! 🎉 👍
lone axle
<@382939733107408897> color_depth detection PR works great on Metro RP2350 no PS...
Nice, thank you for trying it out!
zinc walrus
I noticed a slightly confusing name collision in the Adafruit Learning System Guides.
There are two folders named CircuitPython_Logger with entirely different applications. The one under CircuitPython_Essentials demonstrates data logging to the file system, whereas the top level folder demonstrates debug logging to the various handler backends.
I don't know if those folder names are cast in stone due to inertia, but it's at least worth considering a different name for one of them.
jaunty juniper
I noticed a slightly confusing name collision in the [Adafruit Learning System G...
what is the issue ?
zinc walrus
what is the issue ?
Words? Language? Disambiguation? Two separate examples for markedly different libraries and concepts sharing identical names in a beginner's learning guide?
I realize there are higher priorities, so if no one else is bothered, then neither am I.
jaunty juniper
Words? Language? Disambiguation? Two separate examples for markedly different li...
Disambiguation of what ? Did you have an issue downloading something ?
This repository is part of the learn guide backend, in this case they are the files for this guide page:
https://learn.adafruit.com/circuitpython-essentials/circuitpython-storage
And this guide:
https://learn.adafruit.com/a-logger-for-circuitpython
to be clear, this repository is NOT a learning guide, it's a repository of files for learn.adafruit.com
thorny jay
Disambiguation of what ? Did you have an issue downloading something ?
This repo...
About the Learn "back-end git", is there a way to find what guide use a folder (reverse lookup)?
When you are in a learn guide, you see the code, and I guess you can find in the git that same code.
But if you are in the git, and find an interesting piece of code, how can you get back to the learn guide web page to have more info and context on the usage?
willow totem
Looks like the circuitpython-stubs is still at alpha 4, not 7. Not sure but maybe something going on with releases @lone axle.
I used --upgrade --pre
lone axle
Looks like the circuitpython-stubs is still at alpha 4, not 7. Not sure but mayb...
interesting, yeah it looks like no releases made it up to pypi since alpha.4. I will try to look into that
tulip sleet
interesting, yeah it looks like no releases made it up to pypi since alpha.4. I ...
I was just going to ask you about this. I opened an issue, and confirmed it happened again with the alpha.7 release last night: https://github.com/adafruit/circuitpython/issues/10361 as mentioned, I think this might be due to https://github.com/adafruit/circuitpython/pull/10312. The error quoted in the issue is functionally the same as the failure last night: https://github.com/adafruit/circuitpython/pull/10312
I looked at this a bit and didn't see an obvious cause
jaunty juniper
About the Learn "back-end git", is there a way to find what guide use a folder (...
not that I know, a search in the learn guide for the terms in the directory name should generally be close enough, or maybe a google search with the code ?
like a specific enough code snippet
I found the guide that uses the CircuitPython_Logger directory by putting the directory name directly in the learn guide search. Works even better with a name like "Trash Panda" 😄
thorny jay
Yeah, that is what I had in mind too, the link is one way.
I try to not sneak in too much in the learn repo, as it is easy to be spoil on incoming guide or product.
manic glacierBOT
manic glacierBOT
lone axle
I was just going to ask you about this. I opened an issue, and confirmed it happ...
I've replicated the issue with extra stuff in the name inside a local container so I can start tinkering to try to fix it. #10312 I am not sure about. I'm not very familiar with build_board_info.py, at first look it seems to me that create_pr() is used only during the release process. I think make stubs itself is creating a tar.gz with that 'weird' name even if just run normally outside of the release action.
I'm not sure how it gets the filename it uses though. Perhaps something related to git describe and some new version of something with new behavior started being used.
tulip sleet
Somehow it's not picking up the release tag that is created during the release process, or it's creating a new tag instead of using the existing tag. But I don't know how. I think you are right about git describe.
lone axle
as an aside, I gave claude the docs task from the actions yml file and asked it to create a Dockerfile that would setup a suitable environment for testing. It had to fill in some gaps that we rely on other actions for, but did a good enough job.
I think the root cause is here: https://github.com/adafruit/circuitpython/blob/main/Makefile#L286 this is using python -msetuptools_scm to get a version number. When I run that command I get the full string which is now being put into the tar.gz files 10.0.0a8.dev3+g25132775c1. I will try to tweak it to omit the 3rd decimal and anything after.
zinc walrus
to be clear, this repository is NOT a learning guide, it's a repository of files...
Well, that repo has been my beginner's learning guide, but I understand it's not a user-facing resource.
tulip sleet
@lone axle The weird thing about the stubs problem is that if you just do make stubs, it does the right thing:
$ make stubs
...
Successfully built circuitpython_stubs-10.0.0a7.tar.gz and circuitpython_stubs-10.0.0a7-py3-none-any.whl
When I ran make stubs inside of a local container it did come with the dev+hash stuff also
lone axle
No, I just cloned main and updated submodules
tulip sleet
yes, that would be a "dev" version. It's like the CI is not finding the tag, or it thinks there are commits beyond the tag, or maybe the build is just dirty for some reason so it generates a dev tag
try that checkout in the container
The upload to S3 part is also OK. The name is fine. See the stubs listings here: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/stubs/
It's just the twine part that seems not to be working
maybe we should look inside the .tar.gz file and see what the version nams are
lone axle
the python command still outputs the dev stuff even after checking out alpha7
git checkout 10.0.0-alpha.7
...
HEAD is now at c5128a9902 Merge pull request #10430 from dhalbert/update-frozen-modules-2025-06-17
(venv_cp) root@85594a1475ba:/workspace# python -msetuptools_scm
10.0.0a8.dev0+gc5128a9902.d20250618
But make stubs does result in a clean name
Successfully built circuitpython_stubs-10.0.0a7.tar.gz and circuitpython_stubs-10.0.0a7-py3-none-any.whl
I think that first thing is the key problem. so setuptools_scm is not figuring out the python version name properly.
is that how it used to be done when the alpha.4 release worked? Or mabye there was an update to setuptools_scm that broke things
inside the .tar.gz looks ok too
lone axle
It was changed to use the setuptools_scm thing here: https://github.com/adafruit/circuitpython/pull/9948/
tulip sleet
that is a long time ago. alpha.4 was May 4
lone axle
but there were successful alpha releases of stubs on pypi as late as may 4th
lone axle
The version of python inside of the container was released shortly-ish after the most recent successful one
Python 3.12.3 (main, May 26 2025, 18:50:19) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
not python, but setuptools_scm
locally I have
$ pip3 list |grep setuptools
setuptools 75.8.0
setuptools-scm 8.1.0
i will see if I can update both and then what happens
lone axle
I'm not entirely sure what setuptools_scm is or how it got installed honestly
tulip sleet
it's install by pip or pip3. it's part of the notoriously messy python release stuff. python release tooling is awful
lone axle
I do have a newer one inside the container
setuptools-scm 8.3.1
i just upgraded and am rebuilding stubs
just doing make check-stubs, it's still OK, but let me try the `python -msetuptools_scm you did before and after
what directory did you run that in
lone axle
Ah, I think I must have bungled something earlier when I had it output the dev+stuff
doing that again now and it's the clean version 10.0.0a7
I had some changes in my local copy for a moment that might have impacted it. But I am on alpha7 branch now and it does report the clean version
tulip sleet
but you did run python -msetup_tools_scm and it got a bad version
(.py) halbert@cod:~/repos/adafruit/circuitpython$ python -msetuptools_scm
10.0.0a7
hmm
zinc walrus
I found the guide that uses the CircuitPython_Logger directory by putting the di...
I wasn't trying to burden you with minor name changes (I realize those directories and filenames are already embedded throughout the website), but thought I'd share my perfectionist observations here.
As for the Learn Guides, I've been programming since the Apple 2, and I'm typically fluent enough to prefer browsing the repo directly for quick syntax examples. For unfamiliar concepts like asyncio however, the elementary introduction articles are absolutely fantastic and greatly appreciated. Sincere thanks to all who contribute.
full plume
I have some CircuitPython licensing questions regarding a project (https://www.lumensalis.com/Projects/LCPF/) I'm releasing.
Here are some relevant details:
- it is NOT an Open Source project
- is free for use in personal projects, but the current license effectively prohibits everything else
- this is probably temporary - my intent is to change to a dual-licensed model with the default being a generally permissive OpenSource(ish) license for everything EXCEPT commercial/for profit use, but that's later. For now consider it "free as in beer"
- does provide complete and non-obfuscated source
- built on (stock unmodified) CircuitPython
- depends on various bits of the Adafruit CircuitPython library bundle
- supports a variety of AdaFruit StemmaQT products
I obviously want to know about anything I'm doing that technically violates any licensing terms, but I also want to make sure none of it would violate the "spirit" of expectations for CircuitPython. I haven't seen anything along the lines of "don't use our terms unless you're using an OpenSource license", and CircuitPython uses the commercial-friendly MIT license, but still... I hope - but do NOT want to assume - that this is "acceptable"
Here are my specific questions:
- Is it OK to use CircuitPython in the project name? (currently called the "Lumensalis CircuitPython Framework") I think it meets all the requirements for branding at https://docs.circuitpython.org/en/latest/README.html#branding except for being listed on circuitpython.org, but I'm guessing that is for hardware products (i,e. controller boards) wanting to use "CircuitPython" in their naming/etc.?
- Is it OK to redistribute individual modules from the Adafruit CircuitPython library bundle? I'm creating a combined zip containing my own framework code and assets along with various dependencies from the bundle. Primary motivation is to streamline the "getting started" process - install the firmware (using, for example, https://circuitpython.org/board/lolin_s2_mini/), extract the contents of the distribution zip file to your CIRCUITPY drive, and you're all set - ready to start using it in your code.py.
- Is it OK to incorporate elements from CircuitPython images/logos into a custom logo for my project?
jaunty juniper
my understanding is that if it's a fork you are not to use the name or logo, but I would actually email pt@adafruit.com for that kind of inquiry.
FYI if your plan is streamlining distribution, there are ways outside of CP to make a bin or UF2 that contains a pre-filled CIRCUITPY drive (depending on the targetted port)
full plume
I'm not too concerned about disappointing the hard core "software must be free" copy-left crowd that would consider even the MIT license "evil", but I certainly don't want to offend any of the major contributors/supporters of the CircuitPython project.
jaunty juniper
(so no zip required)
oh actually did you read this ?
https://github.com/adafruit/circuitpython?tab=readme-ov-file#branding
full plume
my understanding is that if it's a fork you are not to use the name or logo, but...
It's not a fork - it's a separate framework (primarily python code) written for CircuitPython with dependencies on various modules from the Adafruit bundle.
jaunty juniper
oh I see
full plume
oh actually did you read this ?
<https://github.com/adafruit/circuitpython?tab=r...
I think so - looks like that's the "source" for the link I mention in docs.circuitpython...
full plume
FYI if your plan is streamlining distribution, there are ways outside of CP to m...
I've considered this option and might explore further. Didn't find any clear instructions on how to bundle additional bits in the UF2, but I didn't dig for long and I figured there's probably a way.
jaunty juniper
yeah that's not my domain, it seems like it should be fine, but I would email pt to ask if you are unsure
full plume
One of the biggest hurdles for a technophobe is getting the board set up the first time - i.e. before it has a UF2 friendly bootloader installed. The web-based process on circuitpython.org/downloads isn't as simple as I'd like for the kind of users I'm trying to support. OTOH it really is a pretty impressive system, and I think it's almost as simple as it can be given what it's trying to do.
jaunty juniper
I wrote discotool manager to make a UI for installing and updating libraries, the alternatives being circup (command line) and the vscode extension, but it doesn't handle installing Circuitpython itself. I'm not really actively adding features to it currently. Thonny does that for Micropython I believe...
full plume
There are only a few things I can think of that would make it less intimidating. Of course they'd also make it less flexible, which I suspect would not be a welcome tradeoff for most CircuitPython users.
full plume
I wrote discotool manager to make a UI for installing and updating libraries, th...
I think Thonny can do it for CircuitPython too, if your board already has a UF2 bootloader installed
jaunty juniper
oh yeah it does esptool too, nice
full plume
My ideal would be a simple button/ link (per finite set of board types) on my website, i.e. "Install on a LolinS2 Mini", that steps them through the hardware-specific side of the process (i.e. restarting in flash update mode, selecting your USB port) and takes care of everything else without giving them any unnecessary (for the very specific use case of my framework) choices. The current process has about a dozen steps. https://www.lumensalis.com/Projects/LCPF/LCPFDocs/Controllers/LolinS2Mini/
full plume
If you could "pre select" things, like
- Full Circuit Python install of a specific version
- yes we're overwriting everything
- ideally figure out the appropriate drive once the bin level UF2 loader is installed, and again after the UF2 image is updated
- before/after labels can change and be board specific, BUT the "preselect" config would also be board specific, so for example it would know to look for "S2MINIBOOT" when updating the UF2 and "CIRCUITPY" for the rest (adding extra libs, wifi-credentials, etc.)
- if you can actually get at drive labels from a browser...
and add additional board-specific "help" details - with pictures or maybe even video - on the exact start steps, you could have a significantly less intimidating process.
Just an FYI, this is a rather unique project which is OBSESSIVELY focused on being non-programmer-friendly as the top priority, with everything else like performance and ease of extending (vs using) the framework in a distant second place at best. It is very architecturally opinionated/biased towards that focus, and actually does a few things I consider bad practice outside of it.
tulip sleet
How well does the OPEN INSTALLER button on https://circuitpython.org/board/lolin_s2_mini/ do for you?
full plume
It's almost reducing Python to a DSL for configuring what hardware you have, and what behaviors you want. Ideally there's no "traditional" imperative lower level programming - and by "low level" I mean things like "set this LED to blue", "set this servo to 30 degrees", "is this switch closed" ...
I already have all this mostly functioning, but whether it will be as accessible and intuitive as I'm hoping for non-programmers reamains to be seen.
full plume
How well does the OPEN INSTALLER button on <https://circuitpython.org/board/loli...
For me personally it works great. For the rather narrow focus of the LCPF project, I'd prefer something with fewer options - guardrails and training wheels - to make it less intimidating. But I really wouldn't consider building that myself - it's not a simple problem and the OPEN INSTALLER already deals with the worst parts. Even thought I could reinvent that wheel, I sure wouldn't want to maintain it.
However, if my project takes off, and the source for all the OPEN INSTALLER plumbing is available, I might someday consider building a general extension on top of OPEN INSTALLER to allow for a tightly scripted "beginner mode" installs similar to what I described above. IMHO it would make a lot more sense as an enhancement for OPEN INSTALLER in general than some forked hack.
All that said, the "getting started" guide for my project is currently based on walking them through the process using OPEN INSTALLER on circuitpython.org, which is a major improvement over requiring them to, say, install the Arduino IDE or VSCode or heaven forbid esptool just to get the firmware loaded. In terms of making it as easy as possible, this is still something I'd like to improve, but it's "close enough" to be a ways down the priority list compared to other things I want to simplify.
tulip sleet
got it -- I misunderstood where your project fit in the initial setup workflow
full plume
yeah, if I could point people to the right controllers with an appropriate verrion of CircuitPython preloaded, that would sidestep most of this. Unfortunately the "right" controllers - at least initially - need to be ESP32 variants with UF2 and CircuitPython support AND be pin compatible with the Wemos D1 Mini layout. Unfortunately, AFAIK Adafruit doesn't make anything like that (D1 Mini compatible), and I haven't seen any others with CircuitPython - or even UF2 support - preinstalled (although some come wtih MicroPython, but not UF2).
tulip sleet
yeah, if I could point people to the right controllers with an appropriate verr...
so a wifi-capable board, is needed, is that right?
full plume
One other major bugbear is NeoPixels/WS21812s. I've been using and abusing them with glee for a long time, but a lot of the people I want to "enable" find soldering about as intimidating as programming. I'd love to find a source for varied (single/stick/matrix/ring) NeoPixels with small pigtail connectors preinstalled. You can sometimes find them (especially flex strips) with the JST 3 pin 2.54 pitch connectors, but those are a bit bulky. I've used 3pin JST1.25 for years , but that's not something my "target customer" will be exited about soldering to a PCB. (OTOH, for my own projects I've hand-soldered 2020 SMDS: https://www.adafruit.com/product/4684)
tulip sleet
a general solution to this would be a solderless header pin. There are those hammer ones, but I don't know of single-pin solderless solutions.
full plume
so a wifi-capable board, is needed, is that right?
For beginners, yeah. The biggest requirements out of the gate are (physical and electrical) pin compatibility (different pin addresses are fine) with the original Wemos D1 Mini and solid UF2-based CircuitPython support.
tulip sleet
https://electronics.stackexchange.com/questions/562836/solderless-header-pins points to a dead sparkfun link
i think you still need a jig and a tool of some kind. maybe a dowel is good enough
why is the Wemos D1 the "standard" in this case
this is getting out of circuitpyton-dev relevance
I think you could drill a hole in a dowel to make a tool to mount these
full plume
https://www.digikey.com/en/product-highlight/m/millmax/press-fit-pcb-pins-for-pl...
I'd love to keep this conversation going - this is an issue I've been chewing on for many years - although maybe in another channel? I'm actually somewhat surprised that I'm not seeing a NeoPixel / adressable RGB specific channel here. I do have one on the Lumensalis discord ( https://discord.com/channels/880111998455672942/1376955862941306990 ) although its new and hasn't had much (cough ANY cough) traffic yet
tulip sleet
#moving to #help-with-hw-design
lone axle
@full otter maybe hold off on the RTD config change if you want. I'm following a lead on another way to resolve this issue that hopefully won't require changing the config
full otter
<@600738113442283529> maybe hold off on the RTD config change if you want. I'm f...
I just came back from having dinner so I didn't get the chance to apply those changes before you released version 8.60.3 haha. Lightning fast!
lone axle
I just came back from having dinner so I didn't get the chance to apply those ch...
Nice. Hopefully we're at or near the end of issues that crop up from 8.60, I'll keep an eye out for a bit though. Feel free to ping me here or github if you have any other weirdness in actions or anywhere when it seems like you haven't changed anything.
full plume
Is there any specific reason CircuitPython doesn't provide/support importlib beyond keeping the firmware size little smaller? It appears that it is supported in micropython.
full plume
I have some workflow patterns I've used with python systems that depend on reloading. The 'auto-restart' on writes to the CIRCUITPY drive provide a similar benefit which has been "good enough" (actually better in some ways) to keep me from digging into this earlier, but I'm starting to miss some of the things it doesn't do. Specifically, reloading modules on the fly without restarting the application. Probably not something your average CircuitPython (or even Python in general) developer should be fiddling with - beyond trivial scenarios it often causes more trouble than its worth unless you fully understand the implications and use some specific patterns to keep code "reload friendly". But if you set things up properly, there are some cases in which it can provide a vast improvement in workflow efficiency.
full plume
It looks like I might be able to recreate enough of my reload patterns by using __import__, but I'm not positive if that will be enough. I haven't messed with anything at that level (i.e. without using importlib) in Python 3.x. And it looks like CircuitPython does support import...
spare jacinth
Is there any specific reason CircuitPython doesn't provide/support `importlib` b...
i barely find any matches of "importlib" when searching on micropython's repo on github, and those are for tooling outside of MCU; there are no matches on micropython-lib either... what/where did you saw?
anyway, what are you trying to do? might be possible in a few lines of custom code; just like you already did for reloading a module, by removing it from sys.modules
full plume
i barely find any matches of "importlib" when searching on micropython's repo on...
I don't recall the exact source (and I'm not finding it) where I read that micropython supported importlib, but it appears they were wrong. Wouldn't be surprised if 'they' were an AI.... Anyhow, given all the interesting machinations under the hoods in importlib, it would probably need to be substantially modified to work on CircuitPython (or micropython) - mostly simplified.
full plume
anyway, what are you trying to do? might be possible in a few lines of custom co...
I'm hoping that will be enough. There appear to be some quirks with nested modules though
jaunty juniper
note that you can reload with supervisor.reload(), save some data between reloads in alarm.sleep_memory if available (we don't have a clean mechanism for that otherwise without using flash), and use supervisor.set_next_code_file before it to reload with a different main script
full plume
I'm looking for python-style reload of a module without restarting
It's not as generally useful, bit it can make your workflow much more efficient in a few cases
jaunty juniper
ah it's more for dev workflow, not for use in the final running code ?
full plume
ah it's more for dev workflow, not for use in the final running code ?
that's the most likely scenario. It's kinda like working on an engine while it's running. Actually it's a lot like that.
(although at least it's much less likely to cause any permanent damage)
(assuming you're not doing it in a live algorithmic trading application running at the hedge fund you're working for)
full plume
the specific current use case is working on some logic for fancy multi-LED patterns . Being able to update the logic with minor tweaks while it's running. Having to restart every time, even if it only takes five seconds to get back to where the pattern is running again, can make it harder to maintain momentum. To be fair, I didn't realize it was only (actually a little less than) five seconds to restart - felt a lot longer (although that may be because I recently turned WiFi off which can add quite a bit of time to a restart).
jaunty juniper
having web workflow on can help as it auto connects and maintains the wifi connection between reloads
I don't remember what board, not on non-native wifi
full plume
having web workflow on can help as it auto connects and maintains the wifi conne...
thanks, I didn't know that - could be quite helpful at some point. I'm typically using USB repl + writing to CIRCUITPY, although for some reason the auto-restart on CIRCUITPY drive writes isn't working at the moment. I don't think I turned it off
I'm primarily editing module/library code which might be a bit challenging for the web workflow. Although it could probably replace what I'm doing with Thonny - that's where I access the USB REPL/console out but the only file I open is code.py (which almost never get's touched).
jaunty juniper
I'm not saying to use it, you can have it enabled and use USB
the web workflow is agnostic to what files you are editing, it all works the same, it's a just a file name
full plume
There's a lot of supporting stuff in my project that doesn't end up on the CIRCUITPY drive (including docs, all the .git bits, ...). I've got hooks in VS Code detecting any writes to the module/library source and then copies them to the CIRCUITPY drive. I'm a bit skittish about doing library development with git on a USB drive.
Not to mention all the fancy back end "helpful" bits in VSCode python extensions for auto-complete, syntax checking, etc will probably be much happier with source on an SSD
jaunty juniper
that makes sense
I'm waiting for someone to write a sync script that uses wwshell (which is part of circup)
full plume
yeah, so far my libraries have about 6500 lines across 121 python files
full plume
I'm waiting for someone to write a sync script that uses wwshell (which is part ...
I might take a crack at that after I start using circup
my approach so far is rather... primitive, but it's simple and it works. But only for CircuitPython 9.x, so I'll need something better soon.
tiny peak
I'm waiting for someone to write a sync script that uses wwshell (which is part ...
I may not fully understand what you're trying to do. But, for me, using rsync generally works great (source dir is a build directory in my github repo, target dir is CIRCUITPY)
all of my recent Playground guides use that setup: one Makefile target builds a project bundle zip file, and a second rule does the rsync.
full plume
looks like wwshell is related to the BLE workflow (Bluetooth) so it would work in scenarios where you don't have a CIRCUITPY drive available
jaunty juniper
wwshell is a file client for the web workflow (hence the ww part)
full plume
I might take a crack at that after I start using circup
If you're using VSCode, I think the approach I'm using wouldn't be hard to adapt. Same detection logic to catch when the file changes, then you'd simply use wwshell (assuming there's a CLI or better yet can import it into a python script) to send the file instead of copying it to the CIRCUITPY drive
import sys, shutil, os.path
print( f"args = {sys.argv}" )
targetDir = "D:\\lib"
submoduleDir = 'lumensaliscplib\\lib'
def syncFile():
def writeLog( s:str ): print( s )
filename = sys.argv[1]
if not filename.startswith(submoduleDir):
writeLog( f"skipping {filename}, not in {submoduleDir}" )
return
inLibFilename = filename[len(submoduleDir)+1:]
target = os.path.join( targetDir,inLibFilename )
writeLog( f"updating {filename} to {target}" )
shutil.copy( filename, target )
if __name__ == "__main__":
syncFile()
pretty simple
then add this under "settings" in the code-workspace file
"commands": [
{
"match": "lumensaliscplib.*\\.py",
"cmd": "echo runOnSave matched ${relativeFile}"
},
{
"match": "lumensaliscplib.*\\.py",
"cmd": "python ${workspaceFolder}\\devOps\\fileSaveSync.py ${relativeFile}"
}
]
},```(adjusting for your directory structure)
and install the "Run on Save" extension
it's a hack, but it actually works quite well most of the time
there's plenty of ways it could be improved, but that should be all you need if you're comfortable fiddling with VSCode under the hoods
however, I wonder how many people using CircuitPython are actually using git or working with more than a handful of their own source files ?
lone sandalBOT
onyx hinge
Hello from Oslo!
tulip sleet
lovely!
tulip sleet
<@&356864093652516868> The regular Monday audio meeting will be in 3 hours at 2pm US ET // 11am US PT. Add your notes to https://docs.google.com/document/d/1hI6KHn3VmxD-cUztuCCBbLCvQCurP2DwukbjIUZbScU/edit?usp=sharing. See (well, hear) you!
lone axle
Here is the issue where the second weeds topic arose from: https://github.com/adafruit/Adafruit_CircuitPython_BusDevice/pull/102
Thanks for hosting Dan! Have a great week everyone!
note, that issue was created 1/14, so it is not related to current issues with Blinka. But it was on A64-OLinuXino by Olimex device which I wasn't familiar with.
tulip sleet
Here is the notes document for next Monday’s CircuitPython Weekly Meeting (June 30). It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/177RrtFUmsky3b2Wjl8vVRVqceU6LJavFfWSm2krT_TQ/edit?usp=sharing
proven garnet
I'll check out the meeting when it's uploaded, thanks Dan and all!
proven garnet
@lone axle @tulip sleet Catching up now!
Ah, I can provide some context about requirements.txt being dynamic - I believe it's because you could theoretically change that at install time and install requirements "dynamically" whereas the list in pyproject.toml is truly part of the file. A good example would be Blinka, where you can analyze the system at install time and see that if you're on a Raspberry Pi that you should write some other additional libraries to a file. It's dynamic compared to that (and is likewise called such in pyproject.toml when you use the requirements.txt file.
But you are entirely right, it's not much different that what we have today effectively.
I do agree that having the dependencies in their own file is extrememly readable. I think I could automate it to be equally legible but definitely admit that is a downside of moving away from it.
I think I'd also end up defining the documatation and optional requirements in pyproject.toml as well, which is possibile and wouldn't change the way its done for optional now from the user's perspective (pip install library[optional])
jaunty juniper
how would you write requirements.txt dynamically when using pyproject.toml ? is there a way to make it run a script ?
proven garnet
Also, thanks for bringing up the projects like the screenshot one. I also see @jaunty juniper typing so I'd want to make sure circup doesn't break.
proven garnet
how would you write requirements.txt dynamically when using pyproject.toml ? is ...
I added some tools in Adabot that function more like text parsers and editors as opposed to git patching, so I'd basically write up a script using those to read the current contents and add them in the correct place to the pyproject.toml file.
jaunty juniper
oh ok I see what you mean
proven garnet
So they would still be defined ahead of time like they are now, just housed in a different file
lone axle
@proven garnet would switching to reqs in pyproject.toml negate the need for our custom solution from https://github.com/adafruit/circup/pull/188, and discussed further in https://github.com/adafruit/circup/issues/195 ?
proven garnet
<@135415127879974912> would switching to reqs in pyproject.toml negate the need ...
If I'm understanding the PR correctly, no I don't believe it will. It will use the standard dependency declaration (project.dependencies) which will attempt to download from a package index I believe. So we'd still need a solution for custom requirements not available on PyPI.
You COULD define a "circup" option similar to "dev" or "optional", but that is a hack, and if someone tries to do a now valid pip install library[circup] then pip will throw a fit and it probably wouldn't be clear to the user what went wrong.
I'll add it as an issue to the bundle as suggested, and see if I can scope out any unintended consequences to guides or other projects, thanks!
lone axle
Sounds good, thank you!
proven garnet
As I catchup live, my apologies for my attrocious grammar - it didn't help that I wrote these last minute
After a quick look, I'm not sure if it was tied to the other issues with Blinka based on the board that was used. Still, I also agree with the sentiment regarding the second issue - I do think it's really a botched install of Blinka. I think it's just more unfortunate that the mechanism for trying to announce the issue is getting unintentionally silenced.
I also agree that patching is probably overkill, especially if it's not widespread and downloading the missing library fixes the issues as @lone axle says
Thank you!
lone axle
I am trying to add a property getter to a class in the core. I basically copied one from another class and tried to change the relavent names and things for the intended use. The code compiles, but trying to access and print the property results in <bound method>. If I add parenthesis to call it as a function instead of access as a property it returns the expected value. I'm sure there is something relatively simple wrong with the declaration but I have been unable to spot it. Is anyone able to tell what is making it only work as a function instead of a property?
static mp_obj_t terminalio_terminal_obj_get_cursor_y(mp_obj_t self_in) {
terminalio_terminal_obj_t *self = MP_OBJ_TO_PTR(self_in);
return MP_OBJ_NEW_SMALL_INT(common_hal_terminalio_terminal_get_cursor_y(self));
}
MP_DEFINE_CONST_FUN_OBJ_1(terminalio_terminal_get_cursor_y_obj, terminalio_terminal_obj_get_cursor_y);
MP_PROPERTY_GETTER(terminalio_terminal_cursor_y_obj,
(mp_obj_t)&terminalio_terminal_get_cursor_y_obj);
// ...
// ... locals dict:
{ MP_ROM_QSTR(MP_QSTR_cursor_y), MP_ROM_PTR(&terminalio_terminal_get_cursor_y_obj) },
at first it seemed to me like the issue is the "get" in terminalio_terminal_get_cursor_y_obj at the bottom in the locals dict. Looking closer at the unrelated property that I copied from it doesn't have "get" in that variable/address ref. I tried removing that so the code matches more closely the one this was copied from, but then cursor_y is not available at all on the object as a function or a property.
tulip sleet
at first it seemed to me like the issue is the "get" in `terminalio_terminal_get...
The get is the problem, but i think there may be a missing typeflag as well. Hold on...
change the third arg in MP_DEFINE_CONST_OBJ_TYPE (at the very end of the file) from MP_TYPE_FLAG_ITER_IS_ITERNEXT, to MP_TYPE_FLAG_ITER_IS_ITERNEXT | MP_TYPE_FLAG_HAS_SPECIAL_ACCESSORS,
lone axle
Thank you! that did it 🎉
winged oyster
Dear all, I am new to Discord and to Adafruit #circuitpython-dev. I am directed to this channel by the CircuitPython compiling error to seek help. I have search this channel for 9.2.8 build error support and found nothing specific to the topic. Would I be able to ask for help here with building circuitpython 9.2.8 on local machine? I have used Adafruit's learning guide on "Building CircuitPython" by Dan Halbert and had no problem building and using version 9.2.7 and 10.0.0-alph.2 for ESP32_S3. I recently pulled to update my local clone to release 9.2.8 and 10.0.0-alpha.7. I used git checkout to 9.2.8 and used the same learning guide to guide my build. This time, however, I run into an esp-idf ble_store.h error. Has anyone encounter this error?
manic glacierBOT
lone axle
Dear all, I am new to Discord and to Adafruit <#327298996332658690>. I am direc...
can you copy/paste the full error output here? that will make it easier for people to help.
winged oyster
Yes, certainly. Thank you for helping! I didn't know if this is the right channel to seek help on this topic so I did not include the full error output in the previous message. This is the error: -- Build files have been written to: /home/user/Adafruit/CircuitPython/ports/espressif/build-waveshare_esp32_s3_touch_lcd_2/esp-idf
QSTR updated
GEN build-waveshare_esp32_s3_touch_lcd_2/genhdr/qstrdefs.generated.h
Module registrations updated
GEN build-waveshare_esp32_s3_touch_lcd_2/genhdr/moduledefs.h
Root pointer registrations updated
GEN build-waveshare_esp32_s3_touch_lcd_2/genhdr/root_pointers.h
In file included from esp-idf/components/bt/host/nimble/nimble/porting/nimble/include/syscfg/syscfg.h:9,
from esp-idf/components/bt/host/nimble/nimble/nimble/include/nimble/ble.h:25,
from esp-idf/components/bt/host/nimble/nimble/nimble/host/include/host/ble_gatt.h:31,
from ./common-hal/_bleio/Service.h:15,
from ./common-hal/_bleio/Connection.h:18,
from ../../shared-bindings/_bleio/Connection.h:11,
from ./common-hal/_bleio/Adapter.h:14,
from ../../shared-bindings/_bleio/Adapter.h:12,
from ../../shared-bindings/_bleio/init.h:14,
from ../../main.c:60:
esp-idf/components/bt/host/nimble/nimble/nimble/host/include/host/ble_store.h:145:18: error: 'MYNEWT_VAL_BLE_GATT_CSFC_SIZE' undeclared here (not in a function); did you mean 'MYNEWT_VAL_BLE_GATT_CACHING'?
145 | uint8_t csfc[MYNEWT_VAL(BLE_GATT_CSFC_SIZE)];
| ^~~~~~~~~~
-e See https://learn.adafruit.com/building-circuitpython; Adafruit Discord #circuitpython-dev
make: *** [../../py/mkrules.mk:93: build-waveshare_esp32_s3_touch_lcd_2/main.o] Error 1
lone axle
Yes, certainly. Thank you for helping! I didn't know if this is the right chan...
have you done both esp-idf install and export?
it looks like some of the requirements it's expecting to find aren't present
instructions are on this page: double check that you've completed everything here: https://learn.adafruit.com/building-circuitpython/espressif-build
manic glacierBOT
winged oyster
it looks like some of the requirements it's expecting to find aren't present
Yes, I did esp-idf install and export according to the steps outlined in the build guides: https://learn.adafruit.com/building-circuitpython and the espressif-build https://learn.adafruit.com/building-circuitpython;.
Before posting for help, I completely rebuilt everything twice from scratch—starting with a fresh git clone of the main branch and attempting to build for the Adafruit Feather ESP32-S3 boards. The error message remained the same in Adafruit and Waveshare S3 boards.
Based on your insight that the error likely points to a missing build requirement, I’ll focus more closely on verifying the requirements during my next clean rebuild. Thanks!
devout jolt
Yes, I did esp-idf install and export according to the steps outlined in the bui...
If it helps, these are the exact commands I used just now on MacOS to build CircuitPython for ESP32:
git clone https://github.com/adafruit/circuitpython.git
cd circuitpython
make fetch-tags
pip3 install --upgrade -r requirements-dev.txt
cd ports/espressif
make fetch-port-submodules
./esp-idf/install.sh
. ./esp-idf/export.sh
# we're now running different python so:
pip3 install -r ../../requirements-dev.txt
make BOARD=adafruit_feather_esp32s2
<@&356864093652516868> We'll have our weekly meeting in about 60 minutes from now in this text channel and in the circuitpython voice channel. Please take the time to add your notes in advance to the document: https://docs.google.com/document/d/177RrtFUmsky3b2Wjl8vVRVqceU6LJavFfWSm2krT_TQ/edit?tab=t.0 -- I look forward to everyone's updates!
lone axle
Thanks for hosting Liz, have a great week everyone!
tulip sleet
thanks!
candid sun
Here is the notes document for the next CircuitPython meeting. It is in 2 weeks on July 14, 2025 at the usual time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1tNfH3S0mIj57cCBzMRyaPH49nARgvj3ZDp2TbR1Nd4o/edit?tab=t.0
ionic elk
Has anyone ever messed with Open Pixel Control for Circuitpython? Through espressif?
Have a buddy asking me about it. I found some old adafruit guides that use it but nothing more recent. It seems like it was useful for LED art installations so I found that surprising
I guess maybe if you want something to connect to OPC, it doesn't need to do anything else. So there's no point in using anything other than default hardware for it
orchid basinBOT
manic glacierBOT
winged oyster
If it helps, these are the exact commands I used just now on MacOS to build Circ...
Thank you, Todbot, for sharing your list of commands for building CircuitPython!
Your list has been extremely helpful in narrowing down the potential source of the error. I was able to execute the commands without issue, with a minor modification to set up the virtual environment on Ubuntu 24.04 LTS. After comparing your list with mine last night, I believe I may have identified the cause of the problem. I plan to conduct further testing after work to confirm, and I'll post an update here once I have more results.
winged oyster
Thank you, Todbot, for sharing your list of commands for building CircuitPython!...
@devout jolt Can you share your list of commands for building any recent stable release, say 9.2.8?
Your list of commands build CircuitPython to the latest version, which is now 10.0.0-Alpha.7.
I would like to build the latest stable release, 9.2.8. After running make fetch-tags, I checked out 9.2.8 and repeated the remaining steps on your list, but encountered a different set of errors. The Adafruit build guides offer limited instruction on how to build older releases. Thank you!
tulip sleet
<@352910176736772096> Can you share your list of commands for building any recen...
Use the gcc 13 release specified in the guide. At the top level, do make remove-all-submodules, and then either do make fetch-all-submodules or descend into the port you want and do make fetch-port-submodules. But knowing the errors would help 🙂
there are sometimes problems of tools changing out from under us, but that usually shows up in the CI more than in local builds
devout jolt
<@352910176736772096> Can you share your list of commands for building any recen...
It's basically the same, just switch to the tag. Specifically, here are the commands I used to build CircuitPython 9.2.8 for an ESP32-S2 Feather:
git clone https://github.com/adafruit/circuitpython.git
cd circuitpython
git checkout 9.2.8
make fetch-tags
pip3 install --upgrade -r requirements-dev.txt
cd ports/espressif
make fetch-port-submodules
./esp-idf/install.sh
. ./esp-idf/export.sh
# we're now running different python so:
pip3 install -r ../../requirements-dev.txt
make BOARD=adafruit_feather_esp32s2
I'm using arm-none-eabi-gcc version 14.2.Rel1, if that matters. As DanH said, what exactly are the errors you're seeing?
orchid basinBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
tulip sleet
CPY BUILDERS: Here is a bash completion script that will do tab completion on make BOARD=<optional-prefix><TAB>. source this. There are some standard places to put this script, but it overrides the system-supplied make completion script. I'm currently trying to figure out, so far unsuccessfully, how to make them cascade: https://github.com/scop/bash-completion/discussions/1400
full plume
CPY BUILDERS: Here is a bash completion script that will do tab completion on `m...
been a while since I did deep bash magic, and I'm not sure if this is even close but it looks like bash-completion has a way to auto-register completion files. If I'm reading correctly, renaming your script to make, _make, or make.bash and putting it in ${BASH_COMPLETION_USER_DIR} should work. It also appears that ${BASH_COMPLETION_USER_DIR} can have multiple paths, and these are searched before the built-in completion scripts. However, I'm not sure if this actually helps - in theory it should at least make your script "just work" without having to source it directly. But unless it magically merges multiple entries in the search path, that probably won't help much.
full plume
CPY BUILDERS: Here is a bash completion script that will do tab completion on `m...
another possible hack - not sure this would work and it's moderately ugly but....
before your _make_board_completion you could add
source <LOCATION_OF_BASH_COMPLITION_BUILTINS>/make
which should pull in the "default" implementation as _comp_cmd_make,
and then insert
else
_comp_cmd_make
at the end of _make_board_completion (before fi) - that might make it
fall through to the original behavior when yours doesn't match?
(or it could fail spectacularly - haven't have to do any serious bash scripting for years so I might be a bit rusty)
I'm assuming you're trying to "append" your completion logic to bash-completion's default logic for make without simply copying and pasting <shudder> it out of completions/make ?
tulip sleet
I'm assuming you're trying to "append" your completion logic to bash-completion'...
Right -- I understand the pathing for the bash completion scripts, but there is already a supplied script that does something useful. I want to augment that, not replace it. complete -F function_name command_name does s replace, not an augment. Yes, I could put one inside the other, but that's not very maintainable. But one of the bash-completion authors made a suggestion here: https://github.com/scop/bash-completion/discussions/1400, and it works.
manic glacierBOT
devout jolt
Not sure if this is useful for others, but I put together a little command-line tool to quickly print out a particular board's board.* pins for a given board_id, if you have a circuitpython repo checkout. I use it when helping the occasional newbie who are trying to use board defines that might not exist on their particular part. I call it cirpy-showpins: https://gist.github.com/todbot/e91853b9d5e021405bb9a85081a39163
Output looks like:
% cirpy-showpins.py circuitplayground_bluefruit
board_id: circuitplayground_bluefruit
pins: A1 A2 A3 A4 A5 A6 A8 A9 ACCELEROMETER_INTERRUPT ACCELEROMETER_SCL ACCELEROMETER_SDA AUDIO BUTTON_A BUTTON_B D0 D1 D10 D12 D13 D2 D3 D35 D4 D5 D6 D7 D8 D9 I2C L LED LIGHT MICROPHONE_CLOCK MICROPHONE_DATA MISO MOSI NEOPIXEL POWER_SWITCH RX SCK SCL SDA SLIDE_SWITCH SPEAKER SPEAKER_ENABLE SPI TEMPERATURE TX UART
this looks good -- I wonder if it should be in the support matrix or on the board page too. It could go fetch pins.c from github.
i was thinking of adding a "Convenience tools" page to "Building CircuitPython" for the bash completion script I just got working, and maybe this too
devout jolt
this looks good -- I wonder if it should be in the support matrix or on the boar...
ooo! I was wishing this list was on the per-board download page 🙂
tulip sleet
we could run it as part of the data generation for a board fomr cicuitpython.org and/or the docs build
tulip sleet
@lone axle mind approving https://github.com/adafruit/circuitpython/pull/10463 as well? I don't think you need to do any testing; the fix is tested by the testing that runs at build time, and Jeff is the part author of this simple fix.
After that I will make an alpha.8. thanks.
orchid basinBOT
tulip sleet
https://blog.adafruit.com/2025/07/08/circuitpython-10-0-0-alpha-8-released/
Highlights of this release
- Increase the firmware partition size for ESP32-S3 boards with 4MB flash, allowing more features to be included, including BLE. You must update the TinyUF2 bootloader on these boards. See the release notes for details.
- Merge updates from MicroPython v1.25.0.
- Fix regressions caused by SD automount capability.
- Add
Terminal.cursor_xand.cursor_y. - Add
picodvi.Framebuffer.color_depth.
winged oyster
Building CircuitPython on Local Machine
turbid radish
This morning I finally got a Code Page 437 truetype font that converted to an LVGL font with most of the glyphs intact. That font loads up fine in CircuitPython.
After awhile I need to see if I can get that font to work in a Terminal window. That would finally get me CP437 characters in an ANSI terminal so I can look at emulating some PC games with the right character set.
willow totem
This morning I finally got a Code Page 437 truetype font that converted to an LV...
ooo which did you use? We might want such a thing for our wippersnapper lvgl boards to emulate the way we're doing OLEDs/CharLCDs with adafruit_gfx / code page 437.
turbid radish
The fonts are at https://github.com/jcs/ansiterm. I had no luck converting the Old Skool PC CP437 fonts from TT to LVGL which is sad as they have the best selection.
strong violet
CircuitPython library bundles are created by applying circuitpython-build-tools to each submodule of the bundle repository. circup downloads the whole bundle and extract only small part of it. What if circup downloaded the snapshot of the library repository at requested version (tag) and built that specific part of the bundle itself? This would reduce the download times, and the user could install older versions if required. Has this been discussed before? Do you see some clear problems with this approach?
jaunty juniper
what do you mean extracts small parts of it ?
circup downloads the zip from the latest release of the bundle which contains the libraries, dependencies, and examples
do you mean perhaps a mechanism to only download what was updated since the last download ?
that would be quite complicated. Downloading a specific version for a library could be possible since the repository urls are known and so the library's release zip for that version could be independently downloaded
we could could download libraries one at a time (and cache it) like pip does but I think that could be more downloads and a worse experience for the usual use case ?
dunno, maybe it could be an interesting option to test and compare
strong violet
I mean if I need to circup install adafruit_character_lcd, cicup downloads lot more than I actually need. Instead, it could download latest bundle info, find out that the repo is at https://github.com/adafruit/Adafruit_CircuitPython_CharLCD, download the snapshot at latest (or requested) tag and build only part of the bundle from this
jaunty juniper
yeah but it downloads the bundle only once, and then it can use that to install the dependencies too (of which there's 2, technically 3 with bus device)
but yeah I know the feeling that circup downloads a bundle every time I use it, but it's actually only once a day (if necessary)
(which is why I setup a cron job that runs circup at night to preload the bundle every day)
strong violet
The benefit of focused download is that one can also request older versions
full plume
I have the following code
self.pulseIn = pulseio.PulseIn(pin, maxlen=120, idle_state=True)
self.decoder = adafruit_irremote.GenericDecode()
setting up an IR remote receiver. In 9.x this worked fine on all the ESP32 variants I tested with. In 10.0.0-alpha8 on a Lolin S2 Mini, it fails with espidf.IDFError: Operation or feature not supported on the first line (creating the pulseio.PulseIn instance). @mortal kernel I'm fairly certain it still worked when I was testing with your ESP-IDF 5.4.1 branch a few months back.
There are some open issues regarding pulseio.PulseIn and ESP32s on the repo, but I didn't see anything obviously related to this exception or as a regression in general (worked in 9.x, fails now). Should I add this as a bug report?
jaunty juniper
The benefit of focused download is that one can also request older versions
yeah versioning is not a thing with the bundle, but then again the policy of the bundle is to be compatible with the current versions of Circuitpython so downloading an old version is a rare edge case. It would require something to peg a version to avoid update to change it, and there is currently no version management for dependencies, so it would be up to the user to peg the versions of dependencies if necessary.
You can open an issue in the circup repo with your suggestion, it's the best way to keep track of the idea
full plume
Requesting older versions could cause a lot of weird issues without introducing a dependency management system to the user's code (i.e. code.py, etc), which feels like a bit of overkill for typical CircuitPython users? Also, it might be tricky to incorporate into existing CircuitPython workflows without chewing up precious space on the controller's filesystem. It's fairly simple to skip circup and maintain your own "dependency bundle" for deployment if you want full control over individual package/module versions.
jaunty juniper
I have the following code
```python
self.pulseIn = pulseio.PulseIn(pin, ...
I did a manual bisect and this seems to be what broke it
https://github.com/adafruit/circuitpython/pull/10397
fix "pulseio.PulseIn maxlen is limited to 128 in esp32"
(by manual bisect I mean I use these files and try different versions using binary search to find when it stops working, luckily the files go back to before the bug, but the PR files get purged regularly https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/lolin_s2_mini/en_US/)
full plume
I did a manual bisect and this seems to be what broke it
<https://github.com/ada...
Should I be adding to the conversation on that link (even after it's been merged to main), start a new issue, .... ???
tulip sleet
Should I be adding to the conversation on that link (even after it's been merged...
How about opening a new issue with your breaking example, and tag the PR author in that issue, nothing that it used to work?
full plume
fwiw it fails with espidf.IDFError: Operation or feature not supported for values of maxLen >= 30, but espidf.IDFError: Invalid argument for maxLen < 30
full plume
How about opening a new issue with your breaking example, and tag the PR author ...
I'll try slimming it down to a small example - which should be easy enough as long as it still breaks...
tulip sleet
I think the PR author did test it, so it's surprising. If they left a test program in the PR, see if there's anything diffrent.
they submitted the PR to solve their problem with it
jaunty juniper
I really just ran this as a test (on a lolin S2)
import board
import pulseio
pulseIn = pulseio.PulseIn(board.A0, maxlen=120, idle_state=True)
(actually I wasn't sure what pins were eligible, so I ran a loop on a list of pins with a context manager and try/catch, but then I reduced it to that)
full plume
(actually I wasn't sure what pins were eligible, so I ran a loop on a list of pi...
It seems plausible that it could be a pin-related issue, but I'm using the same pin (IO35) on the same (Lolin S2 Mini) board that worked fine with 9.x
jaunty juniper
yeah it works in alpha 6 and anything pre-10397 I tested
turbid radish
Weell, I used my working teminalio.Terminal sample program to try to load a LVGL font instead of terminalio.FONT. I got the dreaded "TypeError: Unsupported font type". I may have to wait until Scott gets back to ask about using a terminal font other than terminalio.FONT. 😮
full plume
Weell, I used my working teminalio.Terminal sample program to try to load a LVGL...
I haven't tried LVGL in CircuitPython yet, but I've done a decent bit in the last year with LVGL in C++. If you can share a link to your teminalio.Terminal sample program, I might be able to figure something out.
turbid radish
SPDX-FileCopyrightText: Copyright (c) 2021 Randall Bohn (dexter)
SPDX-FileCopyrightText: Copyright (c) 2021 Anne Barela for Adafruit Industries
SPDX-License-Identifier: MIT
Modeled on https://github.com/circuitpython/CircuitPython_Module_Examples/
blob/801475f745fe2a61738f1abed3bd01007118efa3/terminalio/
terminalio_terminal_example.py#L5
import board
import displayio
import terminalio
import picodvi
import framebufferio
from adafruit_bitmap_font import bitmap_font
displayio.release_displays()
fb = picodvi.Framebuffer(320, 240, clk_dp=board.CKP, clk_dn=board.CKN,
red_dp=board.D0P, red_dn=board.D0N,
green_dp=board.D1P, green_dn=board.D1N,
blue_dp=board.D2P, blue_dn=board.D2N,
color_depth=8)
display = framebufferio.FramebufferDisplay(fb)
group = displayio.Group()
display.root_group = group
palette = displayio.Palette(2)
palette[0] = 0x220000 # not so dark Black
palette[1] = 0x00FFFF # Cyan
ROWS = 12
COLS = 40
font_file = "fonts/CP437-8px.bin" # Test external LVGL font
font = bitmap_font.load_font(font_file) # Use font = terminalio.FONT for built-in
font_glyphs = ""
for i in range(256):
font_glyphs = load_glyphs(i)
w, h, _, _ = font.get_bounding_box() # last two are x_offset and y_offset
term_bitmap = displayio.Bitmap(320, 240, 2)
termgrid = displayio.TileGrid(
term_bitmap,
pixel_shader=palette,
y=20,
width=COLS,
height=ROWS,
tile_width=w,
tile_height=h,
)
group.append(termgrid)
term = terminalio.Terminal(termgrid, font)
term.write("Terminal %dx%d:\r\n" % (COLS, ROWS))
term.write(" %dx%d pixels.\r\n" % (COLS * w, ROWS * h))
term.write("VT100 protocol.\r\n")
term.write("Both carriage return and line feed \r\n are required.\r\n")
while(True):
pass
full plume
# SPDX-FileCopyrightText: Copyright (c) 2021 Randall Bohn (dexter)
# SPDX-FileCo...
According to the docs for terminalio.Terminal, you might not be able to do this. term = terminalio.Terminal(termgrid, font) expects a fontio.BuiltinFont for the font parameter. And the BuiltInFont docs say "Creation not supported. Available fonts are defined when CircuitPython is built. " .
full plume
Looking under the hoods, it seems unlikely that ... yep, that loading a regular font (bitmap_font.load_font(...)) will work but lvfontinfo might
Internally, lvfontinfo.OnDiskFont appears to be creating a fontio.BuiltinFont
lone axle
@tulip sleet on fruit jam rev c with the ESP32 C6 I am noticing that frequently requests end up failing with a timeout. I turned on debug in espspi and see that part way thru receiving data it starts reporting ESPSocket: 0 bytes available over and over until timeout. I have done some troubleshooting around this and have a few findings and a few questions.
- Where is the best place to create an issue for this? core, esp32spi, nin-fw?
- I noticed that the response is being read in 32 byte chunks which seem to be iterating "somewhat slow". Even when the request does occasionally succeed it takes what feels like a long time for the amount of total data being fetched. I've realized that I can increase the chunk size to
1024here inside of requests: https://github.com/adafruit/Adafruit_CircuitPython_Requests/blob/5e646b244cf36f879f15aaf77a270e4c7e6e8336/adafruit_requests.py#L313 and it seems to make the requests much faster and make them finish successfully more reliably. Each chunk read iteration doesn't seem to take appreciably longer than the 32 byte ones. I have yet to have it fail with a timeout using1024whereas without that change sucess is only maybe 1/10 or so. Do you think it's worth trying to add an API to requests for the user code to set this value in order to work around this issue? or better to leave it as is and dig further to figure out root cause / other solution?
tulip sleet
<@329766224093249548> on fruit jam rev c with the ESP32 C6 I am noticing that fr...
one q is whether this behavior is any different than AirLift on a plain ESP32
crimson ferry
@lone axle does it do this with a variety of servers?
lone axle
I have really only tested only adafruit product API: https://www.adafruit.com/api/products/6358. I ran the requests simpletest on it a week or two ago a couple of times and I think it was failing some of the requests to httpbin also but I did only cursory testing of that at the time. I'll try it and a few other servers in a bit when I return from walk.
lone axle
one q is whether this behavior is any different than AirLift on a plain ESP32
would Feather RP2350 + Airlift Featherwing work as a way to test that? If so I could test that out as well I think.
tulip sleet
would Feather RP2350 + Airlift Featherwing work as a way to test that? If so I c...
yes, that sounds like a very good comparison test.