#circuitpython-dev
manic glacierBOT
orchid basinBOT
manic glacierBOT
slender iron
would it be weird to have a native settings module with a change() function that walks you through known keys and current values?
I'm provisioning ssid and password on a bunch of stuff
stuck elbow
such a shame that set is already a keyword ;-)
slender iron
I'm thinking you call settings.change() and then it lists all keys and their current values with a number next to each one.
you pick the number and give it a new value
slender iron
I'm somewhat tempted to move the espressif port to the same setup as the zephyr port, cmake calling into async python.
tulip sleet
I'm somewhat tempted to move the espressif port to the same setup as the zephyr ...
would it use any of the esp-idf cmake stuff?
tulip sleet
would it be weird to have a native `settings` module with a `change()` function ...
Remember i already added supervisor.get_setting() to do a parsed os.getenv(). Could have supervisor.get_settings() that returns a dict of them all. Or it could be a dict-like object that is mutable. Or we could implement os.environ that is the string-only values. But the current impl is tiny and does parsing of the .toml on the fly for code-space reasons.
or you could write a tool that changes all the settings.toml's. Not sure it needs to be a CircuitPython API.
The only reason we have settings.toml instead of boot.py (or a settings.py) to set values is persistence, I think.
it's a bit of a question we need a separate language for settings, when we can already parse Python?
slender iron
would it use any of the esp-idf cmake stuff?
I'd be interested if it worked similar to zephyr. Pass in compiler and flags, we create a library and then it links it all together. Yesterday I was fighting the annoying -u linker stuff.
tulip sleet
is it worth it if we are moving esp-idf to zephyr in the same time frame?
slender iron
Remember i already added `supervisor.get_setting()` to do a parsed `os.getenv()`...
I like the idea of a separate module because we can only enable it on certain ports that have room. I also like the idea of being interactive so you can discover settings that my not be in settings.toml yet. (However we could also put those in a dict we return.)
slender iron
is it worth it if we are moving esp-idf to zephyr in the same time frame?
LLMs throw a wrench in that question because it could be straightforward for an LLM to do.
manic glacierBOT
tulip sleet
I like the idea of a separate module because we can only enable it on certain po...
I am not sure weactually need settings.toml. We just need a persistent dict we can get/set in boot.py. The evolution of this is tortured. There is a long discussion in https://github.com/adafruit/circuitpython/issues/7274. I think we said we could not at that time run Python code before starting the web workflow, but I think that may not be true anymore due to our better port_ storage management.
CPython does not provide a good precedent for this kind of settings thing.
tulip sleet
LLMs throw a wrench in that question because it could be straightforward for an...
could you also use an LLM to maintain the current setup?
slender iron
could you also use an LLM to maintain the current setup?
I'm trying
slender iron
I am not sure weactually need settings.toml. We just need a persistent dict we c...
I liked the os environment comparison
I'm fighting the fact that the idf cmake uses -u to pull in the correct impls of things
(I think I just got it)
I'm not exactly sure when the ESP zephyr work will be done at the same time as the idf. The IDF seems to get chip support first now. Not sure how far behind it actually is though. (It doesn't matter if we can't get chips)
tulip sleet
os environment is actually kinda poor because it's just strings -- you have to set up a parsing convention, which is where toml comes in
tulip sleet
I'm not exactly sure when the ESP zephyr work will be done at the same time as t...
agree with that -- but if they eventually put zephyr into esp-idf, that is a new ballgame. But I don't know if that is in the works, or whether it will always be separate
slender iron
I got wifi working just now. I think I'll make a draft PR so others can start to try it
I haven't heard plans to move the IDF to zephyr. I think their version of freertos still does SMP better than Zephyr
(which I think they upstreamed to freertos)
slender iron
I'm sure they are still ahead of freertos. not sure how though
so what do we think about settings?
tulip sleet
so what do we think about settings?
supervisor.settings could return a dict-like object that could be updated at run-time. The initial value would come from settings.toml. Updates would not be written back to settings.toml.
If you don't want it in supervisor, it could be in settings.settings, with a Settings class.
a dict-like object lets you iterate over the keys, etc.
the values could be stored in a real dict, but you look in settings.toml if the key isn't found, and then cache it in the dict
IF you want changes to persist over VM's, then the dict and its object need to be port_malloc'd.
slender iron
`supervisor.settings` could return a dict-like object that could be updated at r...
I want it to modify settings.toml. I'm using it to setup a new board essentially.
tulip sleet
I want it to modify settings.toml. I'm using it to setup a new board essentially...
I think that could be not so easy, since it can have comments, etc.
manic glacierBOT
manic glacierBOT
verbal pivot
hi, i made a new port for circuitpython, anything i should know before making a PR :>
tulip sleet
hi, i made a new port for circuitpython, anything i should know before making a ...
a new board or a new port?
https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github for general github info
if you PR against 10.1.x, it may go in the next 10.1.x release. If you PR against main, it will go in 10.2.x.
lone axle
<@&356864093652516868> the weekly meeting will be ocurring here on discord at the usual time of 2pm US Eastern / 11am US Pacific, about 1 hour from now. Add your hug reports and notes to the document in the pinned messages. We look forward to hearing from all who can attend.
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/1VHGPs23KrEB_xy1HJ36wwLifFg8WdTYGw5IRndSnBVs/edit?usp=sharing
manic glacierBOT
orchid basinBOT
orchid basinBOT
orchid basinBOT
lone axle
@slender iron I've found that building the native_sim board requires libsdl2-dev:i386 but installing that directly on my system wrecked some things because I have 64bit already and there were conflicts with my existing display manager and network manager. Do you have the same issue building the native_sim? If so, have you worked around it somehow? build in container exclusively or something?
slender iron
yup, native sim needs the 32-bit version. works on arch ok. what distro are you on?
lone axle
Ubuntu 24.04
lone axle
it worked to make some builds successfully but installing the required components broke things. After my next reboot my computer came back up to terminal only, I had to repair network access manually and then re-install desktop manager and network manager after removing all of the 32bit things that I installed to make the build.
slender iron
eeesh, I'm not sure
you could try building the 64 bit version but that'll mess up the pointer sizes
lone axle
I will look into getting a container set up
and probably add a warning note to the readme to try to save someone else.
slender iron
works for me! sorry for the trouble
lone axle
No worries. I wasn't paying close enough attention to what all of the apt installs were doing. Luckily claude was able to get me through the repair and help diagnose the cause.
tulip sleet
ubuntu 26.04 final is two weeks away; would be interesting if it didn't have the problem you described
lone sandalBOT
orchid basinBOT
tulip sleet
@lone axle I'm updating the asyncio library. It failed CI, I think due to old stuff in .pre-commit-config.yaml and elsewhere.
I looked in cookiecutter, because I thought its version choices would be canonical and up to date. But interestingly it does not include a ruff-pre-commit entry in .pre-commit-config.yaml. should it, or is that wrong now?
lone axle
<@382939733107408897> I'm updating the asyncio library. It failed CI, I think du...
I think the versions aren't necessarily the issue. It appears to fail some of the ruff checks in the log here: https://github.com/adafruit/Adafruit_CircuitPython_asyncio/actions/runs/24217090441/job/70700112418#step:2:1011
The cookiecutter one that you linked is for the cookiecutter repo itself. Not the templates that it creates new libraries from. That one is here. https://github.com/adafruit/cookiecutter-adafruit-circuitpython/blob/main/{{ cookiecutter.__dirname }}/.pre-commit-config.yaml
It does have a newer version of ruff in here than the libraries currently do. The next patch that I am intending to run will update the libraries to match cookiecutter. The changes from here will help facilitate: https://github.com/adafruit/adabot/pull/415
If you run pre-commit locally does it also fail?
tulip sleet
Thanks; I was indeed looking in the wrong place. ruff-pre-commit is up to v0.15.10 now. There was a new release just hours ago.
pre-commit runs locally.
... there are errors I have to fix
orchid basinBOT
manic glacierBOT
manic glacierBOT
lone sandalBOT
tulip sleet
<@&356864093652516868> The weekly public CircuitPython meeting will be at 2pm US Eastern time, in just over two hours. Add your notes to https://docs.google.com/document/d/1VHGPs23KrEB_xy1HJ36wwLifFg8WdTYGw5IRndSnBVs/edit?usp=sharing
lone axle
@tulip sleet I added a containerfile and a few scripts for building the native sim. There are basic instructions to use it here: https://github.com/adafruit/circuitpython/tree/main/ports/zephyr-cp#native-simulator-build-container The issue I found was that some of the i386 requirements from here: https://github.com/adafruit/circuitpython/blob/1eb34d0f91b81d2919dab65549cc08a1c511f1a1/ports/zephyr-cp/native_sim_build_Containerfile#L9-L10 I was able to install on my main system, but I wasn't watching close enough and they had conflicts with existing packages used by my 64bit OS. So upon next reboot my display manager and network manager and a few other things were gone (removed due to those conflicts).
With the containerfile and scripts I can now make the sim builds successfully inside the container without any issues on my main OS.
tulip sleet
<@329766224093249548> I added a containerfile and a few scripts for building the...
thanks!
lone axle
It could possibly be another symtom of the adaobt/bundle issue. I'll check in on it after the next run.
Ahh, okay cool. thank you!
Thanks for hosting Dan, have a great week everyone.
slender iron
I reproduced the zephyr errors on the mp merge branch locally and claude is looking into it
tulip sleet
@lone axle once again, I have erratic audio, which is strange, because it sounded OK live. If you have a backup recording, I would be grateful for an upload. there are very short interruptions in the audio, as if it's a bad connection, but that isn't true if you didn't hear me that way.
short clip with the problem; don't know what this is
tulip sleet
trying to reproduce now doesn't cause the problem. there are many web post re "choppy audio" in OBS. I'm looking at those
lone axle
I will check my recording. I did hear some gaps in the audio too though during parts. Went out for a walk but will be back in a bit
okay, mine is better than that clip at that section. Uploading now. There are still some spots where it seems like there are short clips of audio cut out. Those are what I heard live as well, the test before was clear but during the meeting I started to hear them.
slender iron
@tulip sleet :
Root cause: The MicroPython v1.27 merge added MICROPY_PYEXEC_ENABLE_EXIT_CODE_HANDLING, a new feature for the unix port that changes how pyexec.c return codes work. When
this feature is disabled (CircuitPython's case), the #else branch defined:
- PYEXEC_NORMAL_EXIT as 1 (was effectively 0)
- PYEXEC_UNHANDLED_EXCEPTION as 0 (was effectively PYEXEC_EXCEPTION = 0x200)
This swapped the meaning of success and failure. CircuitPython's main.c checks _exec_result.return_code == 0 to detect successful execution and uses the PYEXEC_EXCEPTION
(0x200) bit flag for exceptions. With the wrong values, every successful code.py run was treated as an error, breaking the run loop and preventing the process from exiting
cleanly via --vm-runs.Fix: Changed the #else branch in shared/runtime/pyexec.h so that PYEXEC_NORMAL_EXIT is 0 and PYEXEC_UNHANDLED_EXCEPTION is PYEXEC_EXCEPTION (0x200), matching
CircuitPython's existing conventions.
lone axle
Interestingly some parts of what are gaps in my recording are not gaps is yours. And the glitchyness from yours is not in my recording. "time" in "that time of the week..." at the begining is the first gap in my recording. In yours it's got some other artifacts going on but I do hear "time" in there unlike from my recording.
tulip sleet
@slender iron thanks!
slender iron
it passes all my tests locally after that
diff --git a/shared/runtime/pyexec.h b/shared/runtime/pyexec.h
index 9d1ef2a3cb..97ddfad238 100644
--- a/shared/runtime/pyexec.h
+++ b/shared/runtime/pyexec.h
@@ -57,8 +57,10 @@ extern pyexec_mode_kind_t pyexec_mode_kind;
#define PYEXEC_KEYBOARD_INTERRUPT (128 + 2) // same as SIG INT exit code
#define PYEXEC_ABORT (128 + 9) // same as SIG KILL exit code
#else
-#define PYEXEC_NORMAL_EXIT (1)
-#define PYEXEC_UNHANDLED_EXCEPTION (0)
+// CIRCUITPY-CHANGE: CircuitPython uses bit-flag return codes.
+// Normal exit must be 0, and unhandled exceptions use the PYEXEC_EXCEPTION flag.
+#define PYEXEC_NORMAL_EXIT (0)
+#define PYEXEC_UNHANDLED_EXCEPTION PYEXEC_EXCEPTION
#define PYEXEC_ABORT PYEXEC_FORCED_EXIT
#endif```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/1ioxfUHg7Gfp9VHqaWesxemzBYuxDOkT9S4miuQOiqSc/edit?usp=sharing
slender iron
@tulip sleet this is waiting for final approval: https://github.com/adafruit/circuitpython/pull/10923/
slender iron
thank you!
tulip sleet
i missed the review dismissal
slender iron
np
tulip sleet
<@329766224093249548> https://www.dropbox.com/scl/fi/ycrxpq1t25en9qwwppidd/Circu...
all set - thanks!
next time I think I will set up a recording on a second computer. I'm trying to figure out if this is the headset/mic combo, but I'm not sure at all. I have a Monoprice headset/mic, which seems fine otherwise.
but i've had trouble twice now with it.
upgrading to 26.04 when it stops being beta, and assuming that works, will try again then as well
manic glacierBOT
slender iron
@tulip sleet I reviewed the merge and it looks good. Will leave merging up to you
tulip sleet
<@329766224093249548> I reviewed the merge and it looks good. Will leave merging...
Great! I just finished doing some more extensive testing on each port.
manic glacierBOT
manic glacierBOT
tulip sleet
@slender iron if you can review https://github.com/adafruit/circuitpython/pull/10945, then that is the last thing for 10.2.0-rc.0.
slender iron
@tulip sleet want to bug bash tomorrow or friday morning?
tulip sleet
<@329766224093249548> want to bug bash tomorrow or friday morning?
sure, either is fine. You can let me know when you're free.
i have no work-time interruptions scheduled
slender iron
kk, I'm taking the car in tomorrow morning so I'm not sure how long that'll keep me away from my desk. I will have my laptop though
tulip sleet
wherever is convenient for you, probably depends on the wifi, noise, etc.
slender iron
👍 I can do friday morning otherwise
tulip sleet
which will be close to lunch for me 🙂
orchid basinBOT
lone sandalBOT
tulip sleet
CircuitPython 10.2.0-rc.0 is released! Please try it so we can release 10.2.0 final.
https://blog.adafruit.com/2026/04/16/circuitpython-10-2-0-rc0-released/
Highlights:
- New audiotools.SpeedChanger.
- New qspibus support for displayio.
- Stability improvements to USB SD card handling.
- Merge of MicroPython v1.27.
- Update to ESP-IDF v5.5.3.
- Many additions to the Zephyr port.
- Simulated hardware testing is now being done in the Zephyr port.
manic glacierBOT
slender iron
@tulip sleet done with the car and back to my desk if you want to peer claude some issues
tulip sleet
we could go over them and maybe mark some for possible LLM resolution. I did just start to look at them.
tulip sleet
@lone axle @slender iron Hi Tim - re the tests you are adding for these zephyr features being turned on: in some cases (e.g. hashlib, binascii, the modules already have tests in tests/. I don't think we need zephyr-cp-specific tests for these, since the port build should run the regular tests. And if there aren't general tests, then they should be added in tests/.
Another example is https://github.com/adafruit/circuitpython/pull/10951#pullrequestreview-4124462314
slender iron
I'm ok having them both places because the native sim tests will be able to mimic an actual test on hardware too.
tulip sleet
if we ran tests/ on the native sim implementation, that would be the same thing, I think? So we don't really need a second set of tests. If the tests/ tests are inadequate in some way, of course they could be improved.
slender iron
the harness is different because the native sim one builds an external flash image to run on instead of doing raw repl
tulip sleet
but is it true that, say, the hashlib test is testing the same functionality? If we added a new API to hashlib, then we'd need to add a test for that in two places? I would like to the see the test part factored out of the harness part.
or am i confused about what the zephyr-cp hashlib test is doing?
I would say we have redundant tests now, e.g.: https://github.com/adafruit/circuitpython/pull/10939/changes#diff-ddf15076623abb977b33b242b0048124a8eeaa41973f5d07b3c35f5e62aec315 and tests/extmod/hashlib*.py
slender iron
yes, they are testing the same thing in a different way
tulip sleet
it is certainly true the MicroPython test framework is this bespoke thing with its own specific mechanisms and a lot of special cases built in. (I just spent time in there for https://github.com/micropython/micropython/pull/19073). Having tests in a more standard test framework (pytest) is a laudable goal too. It's diversion from upstream vs the advantages of standardization
slender iron
I was thinking about how to do the HIL testing too. I think I settled on flashing the CIRCUITPY portion of flash for every test. That way a test can have multiple files associated with it.
tulip sleet
The UF2 bootloaders may or may not allow overwriting CIRCUITPY? Maybe that's possible on the atmel-samd and the RP2 ones. But the TinyUF2 ones know the partition layout, and might forbid that.
and the nRF52 one is yet another
slender iron
I'm assuming I'd generally go around the uf2 bootloader
tulip sleet
i don't think you have to, or it's difficult (atmel-samd in particular). RP2 could use picotool
slender iron
I'm planning to start with ESP anyway
and many of the zephyr dev kits have built in debuggers
surreal perch
CircuitPython **10.2.0-rc.0** is released! Please try it so we can release 10.2....
Dan, I'm finding some troublesome behavior with 10.2.0-rc.0. I can manage to get it in a state that requires reloading 10.1.4 uf2 via uf2 bootloader to get it to respond again. Essentially my test code for issue https://github.com/adafruit/circuitpython/issues/10054#issuecomment-4217819826 with two watchdog resets followed by a microcontroller reset cause two different boards (Feather and QtPy ESP32-S3) running 10.2.0-rc.0 to become unresponsive (including powercycles) and going back to 10.1.4 and then back to 10.2.0-rc.0 allow them to run again. I suspect you'll want me to log an issue -- do I put it against main or the releease candidate?
tulip sleet
Dan, I'm finding some troublesome behavior with 10.2.0-rc.0. I can manage to ge...
if you power-cycle the board when 10.2.0-rc.0 is loaded does it help?
it should not be necessary to reload an old version. There is no state that is kept.
surreal perch
The serial console remains unresponsive (or my code.py causes it to not respond). I don't have CIRCUITPY available boot.py is disabling USB. So I can't rename code.py (no REPL) and have to reload 10.1.4. However my code.py has a bunch of neopixel status lights and they aren't showing either so I think a power cycle is still leaving the board wedged.
surreal perch
And I have to admit I've never been very good at the timing to set safe mode which might help now.
tulip sleet
The serial console remains unresponsive (or my code.py causes it to not respond)...
Since it's the same code as #10054, only worse, go ahead and add another comment there. We may not consider this a blocker to the release, since you can roll back. In "normal" use it might be ok. If you have a simpler example to run that would be interesting to try
since your current test case is highly unusual
(doesn't mean it's wrong, just unusual 🙂 )
surreal perch
I'm going to see if from repl I can do two watchdog resets and a microcontroller reset once I remove my code.py with the test. I mean if it is as simple as that sequence won't that be concerning.
I'll document my findings on 10054.
Oh and just to complete the thought, on 10.1.4 my test code can run indefinitely WDR, WDR, MCR without hanging or any issue.
pallid swallow
howdy. I'm trying to add support for a board that uses 2 UARTs. intuition tells me i should:
#define CIRCUITPY_BOARD_UART (2)
#define CIRCUITPY_BOARD_UART_PIN {{.tx = &pin_GPIO16, .rx = &pin_GPIO17}, \
{.tx = &pin_GPIO20, .rx = &pin_GPIO21}}
This does create a UART and UART1, however they both seem to use the UART pins and point to the same underlying uart. I shorted UART's GPIO16&17 and left 20&21 open. I tried a bunch of stuff, but most concisely:
>>> import board
>>> board.UART().write("hello") and board.UART().read()
b'hello'
>>> board.UART1().write("hello") and board.UART1().read()
b'hello'
When i disconnect 16&17 and connect 20&21, nothing comes through.
- I looked through the other boards and see while some boards have
CIRCUITPY_BOARD_I2Cand_SPI>1, none have_UART >1 - I looked through the code, and while i don't understand all of it, i didn't see any differences to how _I2C, _SPI, and _UART pin lists were handled in
shared-module/board/__init__.cor elsewhere
So - Am I expecting the wrong thing? Or is there some flaw with UARTs that there can be only one? Or is this how it's supposed to work and i'm misunderstanding. Thx!
tulip sleet
howdy. I'm trying to add support for a board that uses 2 UARTs. intuition tells ...
what is the microcontroller you're using?
what happens if you just create the UARTs with busio.UART(tx=..., rx=...). Do they function? The point of the board mechanism is to provide convenient defaults.
pallid swallow
rp2040. If i busio.UART the pins directly, either pair of uart pins works fine
and IIRC if i swap the pin pairs in the array, it uses gpio 20 and 21 all the time. I'll double check that though.
tulip sleet
I don't see that you can do UART on GP21 and GP20, based on what can be assigned to those pins.
<>
pallid swallow
i just switched to:
#define CIRCUITPY_BOARD_UART (2)
#define CIRCUITPY_BOARD_UART_PIN {{.tx = &pin_GPIO20, .rx = &pin_GPIO21}, \
{.tx = &pin_GPIO16, .rx = &pin_GPIO17}}
and now it works fine on those pins using either uart or uart0, but not 16/17
pallid swallow
rp2040 datasheet and my code disagree 🙂
tulip sleet
you must also create a new CIRCUITPY_BOARD_BUS_SINGLETON . See ports/raspberrypi/boards/adafruit_qtpy_rp2040/pins.c for an example (for a second I2C)
what are the lines for your UARTs in pins.c
that is the standard pinout diagram, I wonder why they were omitted 😕
pallid swallow
awesome, that's probably it, i'll give it a try. not sure how many hours i would have searched before finding that.
tulip sleet
e.g. from that pins.c:
CIRCUITPY_BOARD_BUS_SINGLETON(stemma_i2c, i2c, 1)
...
{ MP_ROM_QSTR(MP_QSTR_I2C), MP_ROM_PTR(&board_i2c_obj) },
...
{ MP_ROM_QSTR(MP_QSTR_STEMMA_I2C), MP_ROM_PTR(&board_stemma_i2c_obj) },
note that the 1 in the first line is referring to the second element of the I2C_PIN array (elements are 0 and 1)
this pinout diagram bug is weird, i'll look further
pallid swallow
yay! thanks @tulip sleet it works!
root cause, pins.c was the first thing i edited before i knew what i was doing and had:
{ MP_ROM_QSTR(MP_QSTR_UART), MP_ROM_PTR(&board_uart_obj) },
{ MP_ROM_QSTR(MP_QSTR_UART1), MP_ROM_PTR(&board_uart_obj) },
so of course they were both using uart.
adding
CIRCUITPY_BOARD_BUS_SINGLETON(uart1, uart, 1)
up top and fixing it to
{ MP_ROM_QSTR(MP_QSTR_UART), MP_ROM_PTR(&board_uart_obj) },
{ MP_ROM_QSTR(MP_QSTR_UART1), MP_ROM_PTR(&board_uart1_obj) },
and it all works as expected. Thanks!
tulip sleet
you're welcome! it is a little tricky.
i think I will annotate that pinout diagram. I already edited when it was originally posted to make it narrower
or maybe I will make one of our style pinout diagrams instead. We have some sw to do that.
pallid swallow
I gotta say - circuitpython changed the way i think about microcontrollers. As someone who's always hated toolchains, it's great. I'm in the process of moving all my class labs away from arduino. So thanks to you and all the devs.
tulip sleet
you're very welcome - making computers easier to use is very gratifying, and making physical computing easier to use is part of that
surreal perch
@tulip sleet I'm logging a new issue against rc0. It is dead simple:
- have storage.disable_usb_drive() in boot.py
- Enable WiFi and Web workflow in settings.toml (tested with two different APs) and didn't need to use web workflow to trigger
- simply execute microcontroller.reset() in code.py one line plus import
Result:
- TFT display stopping at 'boot.py output:' and never showing code.py output: line
- Tested on a TinyS2 brand new install with no other files
- Also tested on AF Feather ESP32-S2 TFT (to see the diag output when USB not available).
- Cannot recover USB access or go beyond boot.py output display on TFT with either reset button or power off/on (unplugging USB and plugging back in).
- Safe mode or downgrading UF2 is required to get access back
- In safe mode you must restart with the boot.py renamed to enable usb and have a normal start before clearing error.
Anyway since I have to find the right page and provide more information in the bug report I thought I'd report it here.
(Not actually related to the WDT Reset Web Workflow problem as this is actually a microcontroller.reset issue)
manic glacierBOT
lone axle
When someone has a moment this screenshot tool PR could use a review. It's in circuitpython org so I can't request from the librarians team. https://github.com/circuitpython/CircuitPython_Library_Screenshot_Maker/pull/36
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/1ioxfUHg7Gfp9VHqaWesxemzBYuxDOkT9S4miuQOiqSc/edit?tab=t.0 -- I look forward to everyone's updates!
tidal kiln
thanks! 👋
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/1Fb4ClW5vcVsv4jzQ-ZAkH4k4HBK1CpD4PxZjpD7Y-Gk/edit?tab=t.0
tulip sleet
@slender iron ok, so my plan is to release 10.2.0 final now with the SD Card fix (and a doc fix and getpass in zephyr). Then I'll make the 10.2.x branch and we'll move on from there, doing important bugfixes on the branch, as usual. Sound fine to you?
surreal perch
I don't want to be a pain so apologies in advance but unless others have tried and not reproduced #10957 I think it is going to cause a lot of people to come to support with wedged boards. It is not an edge case to be running disable_usb_drive and standard WiFi Webflow settings.toml and do a microcontroller.reset. I can cause the problem 100% of the time with ESP32-S2 and ESP32-S3 boards with 10.2.0-rc0.
tulip sleet
I don't want to be a pain so apologies in advance but unless others have tried a...
do you see this in 10.1.4 also?
surreal perch
Nope. 10.1.4 had the WDT issue but not this issue. I mentioned in the bug report that the same code in the bug report just loops resetting the microcontroller without wedging the board when running 10.1.4.
tulip sleet
ok, thanks, I misunderstood. A regression is worth looking at, though in this case, we might tell people to just go back to 10.1.4. I will spend some time on this.
slender iron
@tulip sleet sounds good to me
surreal perch
Also @pale arch saw a similar problem discussed yesterday in #help-with-circuitpython where his custom CP build for a new board based on main was also not getting to execute code.py. Can't guarantee it is the same bug but it has similar behavior.
surreal perch
Oh and @tulip sleet I perhaps don't understand the release process. I was thinking if 10.2.0 became the listed stable release it would cause many more problems as fewer people probably load development vs release version thus causing this issue to become more widespread.
tulip sleet
i misunderstood this particular bug and didn't realize it was a significant regression. There are plenty of bugs that haven't been fixed yet, but if they were already present, the new release is no worse. This is worse.
I am reproducing without boot.py at all.
it is a problem that many fewer people test dev releases. We expect some quick bug fixes to be necessary after a new stable release with significant changes
surreal perch
I'm glad I mentioned it. What makes it even worse in my case is that (at least when the boot.py is in place) the board is unresponsive and needs a safe mode restart to get out of it's hanging loop.
tulip sleet
I'm glad I mentioned it. What makes it even worse in my case is that (at least ...
it seems to be critical that CIRCUITPY_WEB_API_PASSWORD="whatever" is present. When It's commented out, I don't see new behavior in 10.2.0.rc0.
import microcontroller
import time
time.sleep(5)
print("resetting in 5 seconds")
time.sleep(5)
microcontroller.reset()
This is not crucial but, I just tried on two different ESP32-S2s and an S3 and without boot.py but with CIRCUITPY_WEB_API_PASSWORD and CIRCUITPY_WEB_API_PORT set it just loops reseting with no hang. BTW I do have SSID and PASS also set as I suspect you do. I'm not sure what in my configuration is causing the difference. I'm running Mac OSX Tahoe and using TIO to do the USB Serial. And @pale arch also didn't have a boot.py. For the life of me I can't figure out how to trigger without using the boot.py on my end. Also, all my boards are using the latest TinyUF2 bootloader 0.35.0.
surreal perch
@tulip sleet When you said you didn't have a boot.py did you not even have the file. I'm back to needing a boot.py to trigger the problem but it only has to exist. It is empty in my tests so I guess the supervisor.disable_usb_drive() was not the culprit. I can repeatedly cause the problem by having an empty boot.py and repeatedly loop resets without hanging the board with the empty file renamed to boot_dis.py. I'm not touching the settings.toml or the code.py that you used.
tulip sleet
I do not have a boot.py at all.
surreal perch
Ok, well I wish I could reproduce your behavior. Do you have four lines in your settings.toml?
tulip sleet
i have replicated your problem, but I see signs of it beginning as far back as the update to ESP-IDF v5.5.3.
I have:
CIRCUITPY_WIFI_SSID = "MySSID"
CIRCUITPY_WIFI_PASSWORD = "mypassword"
CIRCUITPY_WEB_API_PASSWORD="something"
plus more. I comment out the last line or not. The port is not needed if it's the default one
surreal perch
I got rid of the port -- it was the default but it is in all my duplicated from previous use settings.toml. I don't have any other lines. Since I copied your exact code.py I can't figure out any other differences. Still same behavior of not failing without an empty boot.py. I suppose maybe the board. I'm using tinyuf2 0.35.0 and uf2 not bin rc0 from the CP webpage. Anyway, not important to solving the bug just bugging me 🙂
manic glacierBOT
orchid basinBOT
orchid basinBOT
orchid basinBOT
tulip sleet
@slender iron the background callback PR I felt was a showstopper for 10.2.0 final. We could also include the macOS USB card fix. Do you think an rc.1 with these is in order, or go straight to final?
slender iron
I wouldn't worry about getting the macos stuff in. I think I'd lean final. Otherwise we'll need to wait until next week for it
tulip sleet
I just merged the background callback, so I'll use that as final. the macos fix is not a regression, the other one was
it has the zephyr jpegio you merged too but that doesn't matter
orchid basinBOT
manic glacierBOT
tulip sleet
CircuitPython 10.2.0 is released!
https://blog.adafruit.com/2026/04/22/circuitpython-10-2-0-released/
Highlights:
- New audiotools.SpeedChanger.
- New qspibus support for displayio.
- Stability improvements to USB SD card handling.
- Merge of MicroPython v1.27.
- Update to ESP-IDF v5.5.3.
- Many additions to the Zephyr port.
- Simulated hardware testing is now being done in the Zephyr port.
@slender iron i will merge a few things and make 10.3.0-alpha.0 soon
if I tag 10.2.0 as 10.3.0-alpha.0 also it can cause some build funnies since they share the same commit, so a little ahead is better
slender iron
sounds good to me
manic glacierBOT
tulip sleet
@slender iron I have a discussion topic for when you are around: memcpy on C6 is failing with what looks like an alignment error (32 bit read on an "odd" 16-bit boundary. Weirdly, the same code works fine on C3, and the conditional compilation tests are the same on that platform. However, we treat newlib/nano differently on C6 than C3. I wonder if you have any recollection of this: it was when you updated to ESP-IDF v5.5.1 and moved to the ESP-IDF memcpy instead of the MicroPython string0 one.
I am going to try a simple test program with idf.py. I did spend time with an LLM for several hours on this, and helped with the testing, but its theories were not great. I will try again after furthering targeting.
from Makefile:
# Most current ESPs have nano versions of newlib in ROM so we use them.
ifneq ($(IDF_TARGET),esp32c6)
CFLAGS += --specs=nano.specs
else
LDFLAGS += -T$(IDF_TARGET).rom.newlib-normal.ld
endif
thanks
slender iron
<@252717193496756235> I have a discussion topic for when you are around: `memcpy...
It is changed with idf6 too. I don't want us to use the mp copy. I'd prefer to toolchain one or the ROM one.
do you know which implementation you are using?
tulip sleet
i am trying to reproduce the problem outside of CircuitPython.
I am using memcpy.c in the esp-idf. I have instrumented it various ways to get the bug details.
I actually am using a copy of it inside lwip, because it's only provoked by a string copy when the web workflow returns its version info as json
slender iron
do you have a backtrace? it can tell where it is
tulip sleet
I have considerable detail on that
slender iron
I think there might be a wrapper for the idf
maybe mbedtls isn't being built with it
tulip sleet
let's video if you are available; i can explain
i think this may have to do with unaligned fault handling (software recovery is possible), but I'm not sure.
it is definitely in the ESP-IDF memcpy, else I wouldn't be getting logging from there
backtrace:
0x40804e7c: memcpy at /home/halbert/repos/circuitpython/ports/espressif/esp-idf/components/newlib/src/port/riscv/memcpy.c:75
0x42088c0e: tcp_write at /home/halbert/repos/circuitpython/ports/espressif/esp-idf/components/lwip/lwip/src/core/tcp_out.c:721
that is a partial backtrace. The backtrace script is not really correct. this is via looking at the PC and the RP
as suggested by Espressif
this is a typical crash:
W (10147) memcpy2: aa: 0x40848bcc, bb: 0x42175486, as string: ", "mcu_name": "ESP32C6", "board_id": "adafruit_feather_esp32c6_4mbflash_nopsram", "creator_id": %u, "creation_id": %u, "hostname": "%s", "port": %d,
W (10166) memcpy2: b0 lb: 0x42175486
Guru Meditation Error: Core 0 panic'ed (Load access fault). Exception was unhandled.
memcpy2 is just a copy of the memcpy code so I can call it from tcp_out.c directly and not see other memcpy's that are happening
slender iron
I'm at home and ari is watching cars. (he's home sick)
tulip sleet
ah ok 🙂
slender iron
I'm on my laptop
tulip sleet
in the above aa is the dest and bb is the source (yes, those are really the variable names 🙂
slender iron
it might be worth trying my idf6 branch because it switches to picolibc
tulip sleet
bb is not on a 32-bit boundary.
There is this code in memcpy:
#if __riscv_misaligned_slow || __riscv_misaligned_fast
if (n < sizeof(long))
#else
if (unlikely((((uintptr_t)a & msk) != ((uintptr_t)b & msk))
|| n < sizeof(long)))
#endif
__riscv_misaligned_slow is true, though that seems strange to me. The slow means that there's software ("M mode") that does the misaligned access "manually". If I make that #if 0, the bug goes aaway
this code does not break in the C3 build, but it does in the C6 build. Per the above:
# Most current ESPs have nano versions of newlib in ROM so we use them.
ifneq ($(IDF_TARGET),esp32c6)
CFLAGS += --specs=nano.specs
else
LDFLAGS += -T$(IDF_TARGET).rom.newlib-normal.ld
endif
is in the Makefile, which is weird. Do you have any memory of why you did that? Something special about the C6 vs the C3?
If i undo that, it has linking problems. I'm trying to track that down. I can certainly try with 6.0.0.
mostly I'm asking you because you did the memcpy switchover and made some special exceptions for C6 only.
maybe it was just empirical, but the --specs=nano.specs is unusual
tulip sleet
no problem if you don't remember; I will continue on the track I'm on, and also try 6.0.0. in master, memcpy is rewritten to use some asm, though I tried that new code and it didn't fix the problem.
manic glacierBOT
manic glacierBOT
tulip sleet
@lone axle I did a clean install of Ubuntu 26.04 on Friday and set it up for development, and am using it successfully. I updated the "Building CircuitPython" guide a bit to acknowledge its existence. The setup was pretty much exactly the same as 24.04. I have not tried to test whether your i386 package issues are still present. If there's an easy way to test for that, let me know and I'll try.
A bigger change for me is that I'm trying GNOME with "Dash to Panel" instead of Ubuntu Cinnamon. Cinnamon is behind on incorporating some of the new utilities. But that has no effect on the core stuff I need in any case.
devout jolt
A bigger change for me is that I'm trying GNOME with "Dash to Panel" instead of ...
Ahahaha, I just spent several minutes trying to parse "Dash to Panel" , searching on the web, trying to figure out what the heck it is and why it's named that. Why is it dashing and why towards a panel? Which panel? So, "Dash to Panel" is a Windows-like taskbar at the bottom of the screen, and it combines app launchers and system tray into a "dashboard" and moves to the main Gnome panel, which is I guess the root window of Gnome. I think. Not a good name, but perhaps "Gnome taskbar" was taken
tulip sleet
Ahahaha, I just spent several minutes trying to parse "Dash to Panel" , searchin...
I had to bookmark it just to remember the name. There is also "Dash to Dock", which is now a part of regular Ubuntu. Dash, dock, taskbar, panel -- hard to tell these apart.
Regular Ubuntu GNOME has a dock and a top bar, which I think is a remnant of Unity. I hadn't used that for years. I switched to Cinnamon a few years ago because I could have a thin bottom bar with launcher icons, status info, and a list of windows. But it had idiosyncrasies, including have to do ctrl-C twice often when copying between applications. So now i'm back to to Windows-11-like setup, not because i love it, but because it's usable enough.
at the bottom, and no top bar (seemed like a waste of space to me, so that's why I went looking for something and ended up with Dash to Panel
it has a zillion settings
devout jolt
I assume new Ubuntu follows this wacky GNOME3 way of doing things that Cinnamon is a reaction to? Seems like whenever I'm in an Ubuntu GUI it's confusing
tulip sleet
i think some of the wackiness is lessened from the "Unity" days, which were very Mac-like, and I gave up on that quickly. (App menus at the top of the screen instead of the top of the app menu are not my favorite, but that's gone.
lone axle
Nice, I've been using Dash to Panel for a while. I like its behavior compared to the stock ubunty system bar thing.
stuck elbow
now they put the menus on the window's title bar
lone axle
I do agree the name is very generic though. I wouldn't remember it if not for being bookmarked in my setup notes file.
devout jolt
I just made a new Gnome extension called "Race To Conference" that does that same thing but is even more confusingly named
lone axle
<@382939733107408897> I did a clean install of Ubuntu 26.04 on Friday and set it...
Sorry, missed the i386 part before. The easiest test is installing the things needed to build the native sim. The container file here has the requirements: https://github.com/adafruit/circuitpython/blob/ca4636c285f86a09c98f10d03bc7cf11b0aa1efa/ports/zephyr-cp/native_sim_build_Containerfile#L5-L12 I'm not certain of the entire culprit but I believe the i386 SDL one at least was involved.
If I understand correctly, some of those packages conflicted with 64bit ones that were already installed and used by display manager. So during the install I likely agreed to uninstall the existing ones without realizing the consequences.
But if you can make it thru a successful native sim build on the local machine instead of inside the container and then reboot and it comes back up to the normal GUI then it would mean that 26.04 doesn't have the same issue.
tulip sleet
Sorry, missed the i386 part before. The easiest test is installing the things ne...
The libsdl2 packages are also installed on 26.04, so I think the problem is going to be the same. I wonder why the native sim needs the i386 packages in the first place.
lone axle
I think it has to do with the displayio tests. It simulates a display that can output screenshots like these: https://github.com/adafruit/circuitpython/tree/main/ports/zephyr-cp/tests/zephyr_display/golden.
I think maybe you can run it in a standalone window too but not certain.
tulip sleet
I think the package manager should let you install both versions. I've done this before for other reasons, years ago. one search result (there are many): https://www.reddit.com/r/debian/comments/9e73h2/both_amd64_and_i386_version_of_the_same_package/
gotta be out for a while, but I'll look more
tulip sleet
I think it has to do with the displayio tests. It simulates a display that can o...
I did sudo dpkg --add-architecture i386 and then did sudo apt install --dry-run gcc-multilib g++-multilib libc6-dev-i386 libsdl2-dev:i386 libsdl2-image-dev:i386 to see if it would want to uninstall anything, and it did not.
was it west that did the installs, or did you basically what the container does on your own machine?
lone axle
I believe it was basically what the container does. I don't think it was west install thing that broke it. But I also didn't go back to isolate it.
tulip sleet
I believe it was basically what the container does. I don't think it was west in...
I did basically https://github.com/adafruit/circuitpython/blob/ca4636c285f86a09c98f10d03bc7cf11b0aa1efa/ports/zephyr-cp/native_sim_build_Containerfile#L5-L12, carefully, and not reinstalling some things that were already there (just so they would not be marked as manually installed). Nothing was removed.
tulip sleet
it did not remove the 64-bit libsdl2 stuff:
$ dpkg -l |grep libsdl
ii libsdl2-2.0-0:amd64 2.32.10+dfsg-6 amd64 Simple DirectMedia Layer
ii libsdl2-2.0-0:i386 2.32.10+dfsg-6 i386 Simple DirectMedia Layer
ii libsdl2-classic:amd64 2.32.10+dfsg-6 amd64 Simple DirectMedia Layer - "classic" implementation as non-default
ii libsdl2-classic:i386 2.32.10+dfsg-6 i386 Simple DirectMedia Layer - "classic" implementation as non-default
ii libsdl2-dev:i386 2.32.10+dfsg-6 i386 Simple DirectMedia Layer development files
ii libsdl2-image-2.0-0:i386 2.8.8+dfsg-2 i386 Image loading library for Simple DirectMedia Layer 2, libraries
ii libsdl2-image-dev:i386 2.8.8+dfsg-2 i386 Image loading library for Simple DirectMedia Layer 2, development files
ii libsdl3-0:amd64 3.4.2+ds-1ubuntu1 amd64 Simple DirectMedia Layer, version 3
i am now a bit stuck on pip install -r zephyr/scripts/requirements.txt. It needed libusb-1.0.0-dev, but is now stuck on building hidapi with
/usr/bin/x86_64-linux-gnu-ld.bfd: cannot find -ludev: No such file or directory
I haven't found a libudev*to install yet
but in any case, I didn't have the package removal problems that you did. Did you replicate that on a fresh 24.04 in a container or anything like that?
lone axle
I didn't. I have done the build exclusively inside a container since then, I haven't checked into the display manager inside the container or tried to replicate my setup in one.
tulip sleet
ok, fixed that. only the i386 version libudev-dev was installed. I iinstalled the regular one:sudo apt install libudev-dev
there is some tussling between the zephyr requirements*.txt and the CPy ones in terms of dueling versions. Also grpcio-tools pulls protobuf back by quite a few versions
all set to try a native sim build, but I forget the command I need for that
lone axle
make BOARD=native_native_sim
tulip sleet
`make BOARD=native_native_sim`
hmm
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.5.1")
-- Checking for one of the modules 'sdl2'
CMake Error at /usr/share/cmake-4.2/Modules/FindPkgConfig.cmake:1203 (message):
None of the required 'sdl2' found
Call Stack (most recent call first):
zephyr/boards/native/common/sdl/CMakeLists.txt:6 (pkg_search_module)
they ARE installed, as I pasted above
there are other problems. I can't do a regular board build either
ok, fixed, the container had (commented out) # west sdk install -t x86_64-zephyr-elf. I did west sdk install without the -t .... (I guess that installs all possible toolchains) Now a nordic board builds
native_native_sim still does not build
slender iron
i386 is needed because native_sim is built 32bit by default
so the code behaves more closely to the code on a 32bit micro
slender iron
<@&356864093652516868> We'll have our weekly meeting in about n hour 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/1Fb4ClW5vcVsv4jzQ-ZAkH4k4HBK1CpD4PxZjpD7Y-Gk/edit?usp=sharing Talk with you soon!
@tulip sleet want to video about this memcpy bug?
tulip sleet
<@329766224093249548> want to video about this memcpy bug?
I am on a new track, might have a fix
i would like to know why my native_sim build is failing
given that i have the right i386 packages installed
i'll try again right now, because i've rebooted for other reasons
None of the required 'SDL2_image' found still getting that
is this moved up to 4.something.0 on zephyr yet?
or main, you were going to use main?
lone axle
` None of the required 'SDL2_image' found
` still getting that
I searched back through my history while working on the first native_sim build I did. I got the error __ also. Here was the advice from claude that I followed at the time.
2. The actual failure is missing SDL2 dev libraries. The real error is here:
-- Checking for one of the modules 'sdl2'
CMake Error ... None of the required 'sdl2' found
... zephyr/boards/native/common/sdl/CMakeLists.txt:6 (pkg_search_module)
-- Checking for one of the modules 'SDL2_image'
CMake Error ... None of the required 'SDL2_image' found
native_sim links against SDL2 (and SDL2_image) to provide a simulated display/input window. pkg-config can't find them, so
CMake configuration fails. On Debian/Ubuntu/Raspberry Pi OS:
sudo apt install libsdl2-dev libsdl2-image-dev pkg-config
Then wipe the stale build dir and retry (the failed configure leaves a half-written cache that can confuse the next run):
rm -rf build-native_native_sim
make BOARD=native_native_sim
you can use make BOARD=native_native_sim clean instead of rm. Do try after deleting the old build dir if you haven't
ah, actually the above output wasn't helpful I think
This one was the one that ended up working.
native_sim is compiled as a 32-bit binary (note the -m32 -msse2 flags in the failing gcc command). That requires the 32-bit
glibc headers/libs, which aren't installed — hence:
/usr/include/stdint.h:26:10: fatal error: bits/libc-header-start.h: No such file or directory
Install the multilib packages:
sudo apt install gcc-multilib g++-multilib libsdl2-dev:i386 libsdl2-image-dev:i386
If apt complains about :i386, enable it first:
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install gcc-multilib g++-multilib libsdl2-dev:i386 libsdl2-image-dev:i386
Then rerun make BOARD=native_native_sim. The 32-bit SDL2 packages are needed because the 64-bit ones you installed earlier
won't link against the -m32 build.
i did clean builds ... but, turns out I had installed the i386 versions of the libsdl-*dev libraries, but not the x64 versions.
so I installed those and now it works
so both versions need to be installed. Thanks!
slender iron
or main, you were going to use main?
We're on pre-4.4.0 main
so past 4.3.0 but not post-4.4
I mean to update past 4.4 but I've been distracted in hardware land
tulip sleet
so past 4.3.0 but not post-4.4
as you can see above, I did get it to work, after installing the adm64 versions of libsdl2. so it needs those to build, but it needs the i386 versions to run, i guess
slender iron
good! that's weird
multilib support is probably bitrotting in general
since we're well past the core CPU to 64bit transition
slender iron
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/1rxc6oxuwxAusZ5PpKh_zTZvbefkZWOKUuNJSZOJSQPw/edit?usp=sharing
manic glacierBOT
tulip sleet
@slender iron I now have part of the cause of the memcpy issue, but not the whole thing. I have a very simple reproducer program. If CONFIG_LIBC_OPTIMIZED_MISALIGNED_ACCESS=y is set in the reproducer (which is not the default) or in CircuitPython (it's set in sdkconfig.defaults), then the crash occurs. However, when it's set to n, the reproducer runs and completes, but CircuitPython fails early in esp startup, before main(), with a cache error.
I've been comparing sdkconfig.h etc., and haven't tracked down what else is different about our config that would cause the crash. A video chat might be helpful, especially if you remember whey you did end up setting CONFIG_LIBC_OPTIMIZED_MISALIGNED_ACCESS=y (this was last October in an ESP-IDF update PR).
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
orchid basinBOT
tulip sleet
https://blog.adafruit.com/2026/04/30/circuitpython-10-3-0-alpha-1-released/
Highlights of this release:
- Improve SD card USB presentation on macOS.
- Prefer
foo.pyoverfoo/package when importing, like CPython. - Pin fixes.
- Enable
gifioandstoragein Zephyr port.
manic glacierBOT
manic glacierBOT
runic loom
Hey everyone 👋
I've been tinkering for a while and finally put together something I'd love feedback on — a native CircuitPython module called cnn_helper that lets you run tiny CNN and dense neural network inference directly on the Raspberry Pi Pico.
It's built on top of a small C engine called tiny_inference and compiled into CircuitPython 10.2.0 as a native module. I'm releasing a pre-built .uf2 so you don't need to compile anything to try it.
What it can do right now:
→ Run Conv2d, MaxPool, ReLU, Flatten, Linear layers
→ Load float32 models from the CIRCUITPY filesystem
→ Tiny dense models fit in well under 10KB RAM
The repo also has Python tools to convert any compatible ONNX model to the .bin format the Pico expects.
🔗 https://github.com/code2k13/cp-cnn-extension
This is v0.1.0 and very much a first cut — I'd genuinely love to hear if it works for you, what breaks, and what you'd find useful next. Any feedback welcome! 🙏
A precompiled firmware file is in the releases folder , incase someone wants to try
lone axle
<@&356864093652516868> the weekly meeting will occur here on discord today at 2pm US Eastern / 11am Pacific about 90 minutes from now. Add your hug reports and status updates to the notes doc https://docs.google.com/document/d/1rxc6oxuwxAusZ5PpKh_zTZvbefkZWOKUuNJSZOJSQPw/edit?usp=sharing. We look forward to hearing from all who can participate.
slender iron
Hey everyone 👋
I've been tinkering for a while and finally put together someth...
Neat! I've always assumed we'd match an API that is available in CPython. What sort of functionality can you get out of these models?
slender iron
https://www.techzine.eu/news/security/140826/malicious-python-package-poses-new-supply-chain-threat/
slender iron
risc-v ROM
lone axle
Thanks folks, have a great week everyone 👋
slender iron
you too!
tulip sleet
Thanks @lone axle for hosting!
lone axle
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/1ULRoSo-Bgd8pGDqk-g8L2p2BHvVmc_lU8HrvpRA3okU/edit?usp=sharing
manic glacierBOT
manic glacierBOT
manic glacierBOT
slender iron
@modern sundial want to chat about async when you have a chance?
modern sundial
<@517063956032913415> want to chat about async when you have a chance?
This week is pretty crazy for me, but I at least wanted to tell you I didn’t understand and don’t know how to proceed
slender iron
when you have time feel free to ping me here and we can talk in a higher bandwidth way than PR comments 🙂
I appreciate you circling back to it
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
tulip sleet
@slender iron Claude added (or you?) in the ESP-IDF v6.0.1 PR:
#if defined(CONFIG_SOC_RTC_FAST_MEM_SUPPORTED) || defined(CONFIG_SOC_RTC_SLOW_MEM_SUPPORTED)
...
// Chips without RTC memory can't persist SleepMemory across deep sleep.
...
in common-hal/alarm/SleepMemory.c. Are there are any Espressif chips you know of that don't actually have RTC memory, either fast or slow?
I am asking just to add a warning in the shared-bindings doc if that is a real case.
tulip sleet
@slender iron I think there are no such chips right now
slender iron
@tulip sleet sorry for not getting back. At a kids doctor checkup this morning
tulip sleet
np - i should have just put the q in the PR
surreal perch
@tulip sleet Would it be preferable in the future if I put an issue like the wifi import crash in a new issue rather than reply to the merged/closed #10922? Just trying to figure out how best to contribute.
slender iron
in `common-hal/alarm/SleepMemory.c`. Are there are any Espressif chips you know ...
Looks like C2 and C61 don't have it. H4 is commented out
tulip sleet
Looks like C2 and C61 don't have it. H4 is commented out
i missed those - thanks
tulip sleet
<@329766224093249548> Would it be preferable in the future if I put an issue li...
If it's going to be an open issue, yes. You can mention it in the closed PR to provide a cross-ref, and give more details in the new issue.
An open issue is a trackable thing that must be closed. Something mentioned in a closed PR or issue might get lost
glossy pecan
Is there a more detailed guide to building CircuitPython from source than the Adafruit web pages, especially on macOS?
Have been fighting with the process and keep getting tangled up venv vs conda vs implicit environments, make vs gmake, etc., etc. 😡
tulip sleet
Is there a more detailed guide to building CircuitPython from source than the Ad...
that's as detailed as it gets. I'd say use a venv and use gmake. That should be closest to the Linux way.
But consider use a Linux VM or a Linux dev machine if you want to save some effort.
tame creek
my recollections (maybe a bit out of date) of setting up macOS to build CircuitPython: use Homebrew to install as much of a GNU build environment as necessary to make it work. i think gmake and maybe autotools? though you should probably use the official ARM compiler distributions. also use Homebrew to install a modern python, and use a venv
glossy pecan
Thanks🙏🏻, folks, for the quick response. Linux VM is a great idea. My Mac environment is old and full of historical cruft. Keeping the dev environment clean is especially valuable since I'm working up to porting CP to a new Nordic DK.
By the way, Nordic boards appear in both the Nordic and zephyr port folders. I presume the former are "bare metal" and the latter are built on top of a minimal zephyr os. Correct?
And while I'm asking questions, what's the approved bootloader solution for Nordic boards: leave them with the stock Nordic bootloader or migrate to UF2(? and how?). I have all the Nordic tools.