#circuitpython-dev
orchid basinBOT
manic glacierBOT
tulip sleet
https://blog.adafruit.com/2025/09/07/circuitpython-9-2-9-released/
CircuitPython 9.2.9 released!
- Fix network crashes on Pico W; fixes regression since 9.2.5.
slender iron
I haven't had great sucess capturing traces externally. I was trying with imx more than rp2350. I was trying to use an orb trace to do it.
I had the best success with ETB on the SAMD21 where you can look back at what happened before a crash
I'm around now and will be off and on this week. First step is to get debug logging going via DEBUG=1 build and capturing the uart
lone axle
<@&356864093652516868> The CircuitPython meeting will occur here on Discord about 40 minutes from now at 2pm Eastern 11am Pacific. Notes and hug reports can bee added to the shared notes doc https://docs.google.com/document/d/10SvxnkxPP0HhgSv0_x4WXYV0ySvnUcm6KjmpRXEPlUQ/edit?usp=sharing. We look forward to hearing from everyong.
turbid radish
If you all see good items, please send them to cpnews@adafruit.com
onyx hinge
Hi all, just listening in.
If I can have a few minutes in text chatwith some of y'all (dan/scott/maybe tim?) before you go, I have a question that I didn't feel rose to the level of needing to be in the weeds.
turbid radish
Thanks Tim
tulip sleet
sure
lone axle
Thanks everyone, have a great week
onyx hinge
basically -- I've decided that for my personal projects, I want to start moving off of github. I've selected codeberg as my new home for open source development.
The question is whether CircuitPython Community Bundle is interested in accepting projects whose home is not on github.
If no, I'll leave jepler_udecimal where it is. If provisionally yes, I am interested in being the guinea pig for this.
tulip sleet
if you can do submodules from there, I don't see anything wrong with that
onyx hinge
I think there's no problem at the technical level with git, but for instance if you need to report a problem against jepler_udecimal you'd need a codeberg account.
(or you can still @ me on an issue on github in the community bundle repo, I'll have a github account indefinitely and for adafruit work)
(and I guess it'd have to be the same for anyone who PRs the addition of their project to the community bundle)
lone axle
Agree'd having non-GitHub repos in the community bundle sounds fine to me. We'll want to make sure Circup / Adabot / Build tools don't have any problem with it, so having a willing guinea pig is good.
tulip sleet
that is a consideration for the library author about being able to get feedback easily. If it's easy to get a codeberg account, then seems fine
onyx hinge
oh yeah there may be problems at other levels of the tooling. guinea pigs good.
tulip sleet
make sure we use git and not gh, and don't use a github Python library, etc
solar whale
@lone axle Where can I find the new work that has been done on the SPI register bits? Just curious?
lone axle
The reports generator might assume github repos in some places, but I'm not sure if it actually grabs stats from the submodule repos in the community bundle, or just the community bundle itself.
onyx hinge
yeah lots of adabot stuff is using github API queries. those would not work against other forges.
lone axle
<@382939733107408897> Where can I find the new work that has been done on the SP...
I don't have it pushed anywhere yet. I'll try to get a branch up with it this after noon and send you a link when it is.
onyx hinge
If it turns out to be a whole thing I'm prepared to leave jepler_udecimal on github.
solar whale
I don't have it pushed anywhere yet. I'll try to get a branch up with it this af...
Thanks -- No rush.
onyx hinge
anyway, that was my question, thanks for taking a moment to talk to me about it!
lone axle
Thanks for popping in!
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/1uoxUASzgEdYKXVSxoizL9sWmy7A4cxbn5Zr8vzxTOSI/edit?usp=sharing
full plume
If it turns out to be a whole thing I'm prepared to leave jepler_udecimal on git...
Is this something where you'd specifically prefer to "not have it on github", or just that there's somewhere else you'd rather host the "root" repo and related workflow bits? If you want the main workflow for jepler_udecimal somewhere else but you're not opposed to having a it on github, would simply mirroring it on github be enough for this to "just work" even if some of the CP dev-ops tooling is github specific?
onyx hinge
@full plume at a minimum, I will be leaving "archived" copies of all my stuff on github indefinitely. jepler_udecimal doesn't see much development, so if there's much trouble moving it to codeberg while remaining in the bundle, I'll probably just leave it on github unarchived indefinitely instead.
fleet hollow
@onyx hinge Have you considered self-hosting a Gitea server?
onyx hinge
@fleet hollow yes I've considered that too (gitea or forgejo, which is a fork of gitea. codeberg uses gitea forgejo) and decided that for now anyway I didn't want to host my own service
in theory someone will be able to sign up on codeberg if they want to make a pull request or issue, while I would almost certainly not allow signups on a self-hosted forge instance
I think a goal of forgejo is to figure out "how to do federation, similar to mastodon" but I don't know how much progress is happening there. https://radicle.xyz/ is also interesting, taking a distributed network approach.
fiery pecan
I haven't had great sucess capturing traces externally. I was trying with imx mo...
I tried it myself sometime after posting that. I first had to set up debugging, as explained in #circuitpython-dev message. Although I was initially having trouble reserving an unused buffer in SRAM, once I finally found a way to do that, the rest of the instructions from the linked repo were relatively easy to follow. In the end, I was able to get a list of memory addresses. At least from my understanding, the output was the most recent program counter values reached before interrupting the GDB continue command.
tiny peak
@slender iron I'm guessing you haven't had time to look at it yet, but I made a new PR for the USB stuff and I also found a plausible explanation for what's going on with that magic 20ms delay. The PR doesn't address that part as I'm not sure what the best approach would be. Seems like it might make sense to modify TinyUSB with an option to disable its class drivers and add a new tuh_something() function for checking when a device is fully enumerated (minus the class driver bit that currently happens).
Current situation is that CircuitPython's awareness of which device addresses TinyUSB considers to be valid relies on callbacks which are part of TinyUSB's asynchronous interface configuration and class driver binding mechanism (which is somewhat incompatible with how the PyUSB API works)
tulip sleet
Current situation is that CircuitPython's awareness of which device addresses Ti...
Would it be possible to note when the callbacks occur, and if we ask to early for the information, return an error or None or some "Not yet" indication, to indicate that the user program should ask again later?
If you think TinyUSB could use a new feature, then feel free to open an issue there.
tiny peak
That's basically what's happening now. The issue is that TinyUSB doesn't appear to have a notion of an enumerated device where the enumeration process ends with assigning an address and checking the descriptor info (to pacify devices that change their behavior based on what descriptor and string requests you make).
... rather, the enumeration ends with an asynchronous process (i.e. relies on tuh_task() being called many times by RUN_BACKGROUND_TASKS) of interface configuration and driver binding.
It's only at the end of the asynchronous driver binding, which can take some time, that CircuitPython gets notified of a device becoming available. I'm less clear about potential delays when a device is unplugged.
There are 2 problems:
- TinyUSB is binding drivers in some cases while the PyUSB API presents the abstraction that devices will appear in an unconfigured state (no longer true if TinyUSB has set a configuration and opened endpoints)
- The async stuff can be really laggy
So, if I haven't significantly misunderstood something, there's kind of an impedance mismatch between how CircuitPython is using TinyUSB and how TinyUSB was built to be used (automatic class driver binding)
To resolve this, it seems like there would need to be a moderately significant API and enumeration state machine change on the TinyUSB side, coordinated with a change on the CircuitPython side, maybe?
tulip sleet
if we were not trying to emulate PyUSB, do you think a better API could be developed on the CircuitPython side?
tiny peak
It might be a lot more efficient to just use TinyUSB's class drivers. In particular, for MIDI, I think it has some capability to convert MIDI events into a stream?
Not all relevant device types have class drivers though. For example, IIRC, there's no gamepad class driver
tulip sleet
The reason for PyUSB was just to have some "standard" API, and to maybe make user code compatible so it could be used through Blinka
tulip sleet
as another example, we tried to emulate pyserial for usb_cdc.Serial, but it's not exactly the same, and pyserial itself has some idiosyncrasies, and trying to be completely compatible with it was not sensible.
This is much further away, it sounds like, but maybe it would be easier not to try to be so close, and put a layer for our own API on top of PyUSB for the Blinka case (if that is even worth it...)
tiny peak
Having worked with the PyUSB-like usb.core.* API a lot in the last year, I have kinda gotten the impression that its shaped in a rather awkward way for microcontrollers. If the fast endpoint polling happened in C-land somewhere, then events popped up in Python-land through a buffered stream API, I expect the CPU load could be a lot lower.
As a counter-point, there's such a wide variety of USB devices that it's really, really nice to be able to write device drivers in userspace rather than kernelspace (hence PyUSB)
On the balance, my personal inclination would be to see how far it's possible to go by smoothing out rough edges with the current PyUSB-like API.
tulip sleet
i haven't used usb.core at all myself, except to look at it, so I can't say very much useful. But it's obviously worth thinking about this some more.
we can think about a better API in the long run. maybe add some polling calls if that would help
tiny peak
FWIW, I'd be inclined to just polish up the current usb.core stuff and see how things look once that's done
A key test would be whether it's possible to write MIDI synth stuff that doesn't drop notes using the current API
tiny peak
Pyusb does have a similar issue because of an os kernel
Good point. I wonder if the impedance mismatch could be mostly resolved my providing a way for usb.core.Device.detach_kernel_driver() to get TinyUSB to unbind its class driver. Currently, it only knows about detatching keyboards from the CircuitPython core.
slender iron
Good point. I wonder if the impedance mismatch could be mostly resolved my provi...
May just be a bug. We're the only users of detach. I wanted to make universal host drivers so matching pyusb made sense
tiny peak
May just be a bug. We're the only users of detach. I wanted to make universal ho...
By my reading of the code, I doesn't look like TinyUSB actually provides any way to unbind a driver. So, to get detach working, that would need to change. Might be a lot simpler to just have a TinyUSB config option to totally turn off all the class driver stuff though. For that to work, there would also need to be a way to check if the enumeration process was complete (in the absence of class driver mount/umount callbacks)
Implementing those changes would probably be fairly straightforward. My main hesitation would be how to test it (upstream supports a whole lot of hardware), and how the necessary API changes might interact with all the other stuff that uses TinyUSB other than just CircuitPython.
tiny peak
we can think about a better API in the long run. maybe add some polling calls if...
Tonight I've been looking into how the supervisor uses TinyUSB's HID class driver for keyboard input (which I wasn't aware of until just recently). From what I'm seeing, it seems plausible that the existing tuh_hid_report_received_cb() callback function in supervisor/shared/usb/host_keyboard.c might be pretty easy to modify for also reading mouse and gamepad input. Something on the order of just maintaining a cursor (x,y) coordinate and gamepad report FIFO as globals in the supervisor, then letting whatever new usb_hid_something API provide access to those.
Not sure if it would be a good idea to do that, but it's possible that might work for an input device API that was a whole lot less complex than building drivers on top of usb.core.Device. Seems like both mechanisms could coexist just fine and people could choose what they want to use by calling usb.core.Device.detach_kernel_driver(), or not.
No clue what the implications of that approach would be for Blinka
The main possible benefit would be getting to use TinyUSB HID driver's support for HID gamepads. I'm not sure how that would compare to using a CircuitPython gamepad library built on top of the usb.core API. It's possible the TinyUSB class driver approach might allow for much lower CPU use and a correspondingly higher frame rate for games.
slender iron
Not sure if it would be a good idea to do that, but it's possible that might wor...
I think we have a bug to make a pyserial equivalent core module with a similar approach.
I'd follow what you can do in Python on Linux.
tiny peak
@slender iron Thanks for the USB PR merge! It's exciting to have hotplugging working more reliably.
slender iron
<@252717193496756235> Thanks for the USB PR merge! It's exciting to have hotplug...
Thanks for digging into it!
tiny peak
I think I've got a workable fix for the issue where polling usb.core.Device.read() too fast can make the board crash
Dan has some related concerns about whether my fix is masking a deeper issue in TinyUSB. Might be. Dunno.
But, seems like pretty good odds that a bunch of stuff will start working more reliably if we just call tud_task() and tuh_task() at the beginning of each usb.core public property or method to make sure the TinyUSB task queues are all caught up.
For whatever reason, relying on the 1024 Hz timer schedule of RUN_BACKGROUND_TASKS seems to be insufficient
wraith crow
In supervisor/shared/usb/tusb_config.h is this correct?
// Always use PIO to do host on RP2.
#if !CIRCUITPY_MAX3421E
#define CFG_TUH_RPI_PIO_USB 1
#else
#define CFG_TUH_RPI_PIO_USB 1
#endif
It seems strange to do the same thing on both branches, I would have thought that MAX3421E implemented a host stack that wasn't PIO based but I guess it's possible that on the RP2xxx chips it is?
tiny peak
In supervisor/shared/usb/tusb_config.h is this correct?
```
// Always use PIO to...
I saw that too and wondered about it. No idea why it's like that though.
drifting token
Hi folks. I got an Espressif esp32-c3-lyra-v2.0 dev board recently and am trying to get CircuitPython set up. This board has no DAC, but it does have a pin connected to a Class D amp that is connected to speaker pins. The Espressif sample code in the esp-adf uses the I2S hardware in a PDM mode to use only the data pin to drive the amp, and it sounds half decent.
The quickest way to a prototype was to#ifdefthis board into the audiobusio code and use the PDM mode, but @tulip sleet correctly pointed out that this prevents the use of I2S on this board. It would be better to somehow pass a param into I2SOut() to specify PDM mode.
I'm entirely unfamiliar with how these APIs are designed, need recommendations on the appropriate way to approach an API change:
- Add a keyword arg to
I2SOut()for PDM mode specifically for this board. I'm not sure but I think I need to update the API across all the ports to allow for this. - Allow passing in
Nonefor thebit_clock,word_selectandmain_clockpins, and implcitly go into PDM mode on ESP32 hardware when only thedatapin is provided. It does look like I need to handle this error checking in theshared-bindings, but otherwise shouldn't have to touch any other ports. - Implement this as
audiopwmioinstead. It looks likeaudiopwmiodoes not exist on the Espressif port, so I'd have to implement it from scratch.
tulip sleet
Hi folks. I got an Espressif esp32-c3-lyra-v2.0 dev board recently and am tryin...
Sorry that I missed that Espressif doesn't have audiopwmio at all. I haven't found another chip family that does PDM Out with the I2S peripheral, though they all do PDM In, to support PDM microphones.
PDM is better than PWM for audio, is my limited understanding. It's easier to implement the filtering. So I think implementing actual audiopwmio is not worth it.
your alternatives above:
- Yes, an optional keyword arg, and then an additional arg to the
common_halconstructor on all ports, which most would just ignore.
It would also be possible to have different signatures forthe constructor across the ports, based on pre-processing flags, but we haven't done that before, and I'd be reluctant to start. - This kind of implicit mode changing is obscure, and there might be other reasons to omit those values, conceivably.
- as I mentioned, probably not worth it
if you made a draft PR that just included the common-hal changes, one of us could do the API side, or guide you through it. The API addition is not actually that hard. So add an extra arg to the constructor, and temporarily make it always turn PDM mode on. Then you could test it.
slender iron
I think it'd be ok to implement audiopwmio using PDM on ESP.
It's two techniques to fake an analog voltage on a single pin
In contrast to mod:audioio, the pin(s) specified are digital pins, and are driven with a device-dependent PWM signal.
tulip sleet
i was thinking that they end up doing the same thing, albeit with a different-shaped waveform, but the filtering required is different. it could be renamed to audiopulseio.PulseAudioOut to be more general, but maybe that's being pedantic,
drifting token
@tulip sleet thanks. Adding a flag to I2SOut() certainly seems the simplest for me.
audiopwmout is easy to use, and a lot of samples use it, so I think there is an argument to go that route from the API perspective. From a high level it's a pin that drives an amp/speaker?
I'm not familiar with the internals, does audiopwmout handle all all the DAC config internally and hide that from the user?
tulip sleet
<@329766224093249548> thanks. Adding a flag to I2SOut() certainly seems the sim...
it doesn't use a DAC at all. It uses a PWM peripheral driven at a "carrier" frequency which it modulates. The API is here: https://docs.circuitpython.org/en/latest/shared-bindings/audiopwmio/#audiopwmio.PWMAudioOut
for chips with true DACs, there is audioio, which controls a DAC to produce true audio output, no filtering needed.
vernal sage
I am (foolishly) trying to build an image for a ESP32C61. I managed to get a reproducable circuitpython-firmware.bin after updating esp-idf and few esp api changes. What is a reasonable size for the bin with no wifi/ble? I have an espressif dev board showing up today so I'll try it regardless and try to work backwords to get at least wifi working
slender iron
I am (foolishly) trying to build an image for a ESP32C61. I managed to get a rep...
it needs latest esp idf
vernal sage
I'm quite please with how similar our branches are for the amount of cpp/c I touch. Mostly the same besides the make file and updating GPIO_PIN_MUX_REG refs since it seems to not be implemented or deprecrated with the C61. I'll probably switch to your branch and cherry pick the board specific bits tonight and see how much farther I can get with flashing
full plume
CircuitPython and C++?
onyx hinge
@tulip sleet @lone axle I think trying to move udecimal to a different git forge is probably going to end up creating problems / showing limitations with adabot that would be time consuming to properly address.
That being the case, wdyt about transferring the udecimal git repo into the circuitpython organization on github? It's used in (just) two projects on Learn, fwiw, one of which was even by somebody besides me.
@tulip sleet can you add me back to circuitpythonistas at your convenience?
lone axle
<@329766224093249548> <@382939733107408897> I think trying to move udecimal to a...
that sounds fine to me. I added circuitpythonistas role to you as well.
onyx hinge
ugh, oops, I have made a mistake. time of making mistake = in the past.
https://pypi.org/project/circuitpython-jepler-udecimal/ and https://pypi.org/project/jepler-circuitpython-udecimal/ both exist.
onyx hinge
OK I can just archive the wrong one. this is fine 🙂
vernal sage
I managed to get a "working" firmware.bin last night for esp32c61 after getting around this error assertion "flash_mmap_malloc_internal_cb != NULL && flash_mmap_free_internal_cb != NULL" failed: file "spi_flash_mmap.c", line 195, function: spi_flash_mmap. If I remember correctly that was deprecated so I'm not sure where it's even pulling that in from. I've nuked esp-idf and made sure it's circuitpython-v5.5.1, rm'd ~/.espressif. I hit this error last night and got around it but I can't seem to remember how now. Any other artifacts I am missing?
commit f4fddd2d05b44d1d606b546b596d17de0a73e9eb (HEAD, origin/circuitpython-v5.5.1)```try running it again
I just hit the same exact bug 🙂
did you call install.sh again?
vernal sage
Try running what part again? Yeah I just tried checking out circuitpython-v5.5.1 directly and did the install.sh again
vernal sage
Oh the build completes and it flashes, once I reset the board I hit that assertion
vernal sage
Last night I had it past that and it made it through the bootloader and was calling app and then I started to hit other things
slender iron
I'm hitting that assertion from within CP
lone axle
@solar whale sorry it took me a few days to circle back. I had some weird stuff from a prior attempt at a combined driver that I wanted to cleanup before sharing.
Here is my working branch for register_spi: https://github.com/FoamyGuy/Adafruit_CircuitPython_Register_SPI/tree/updates_and_things. The main changes I made so far were adding functionality to set the command bit in the MSB of address byte, and changing it to only write a single byte when it is sending the address/RW command. With those changes I'm able to successfully use a bmp580 via SPI.
I have not addressed the polarity of the RW command bit yet, we'll need a mechanism for that since some devices use opposite.
solar whale
<@343570430042308609> sorry it took me a few days to circle back. I had some wei...
Thanks -- I'm curious about how you implemented it. I'll take a look at it and see if I can get it to work with the RFM library...Hopefully I'll have time to play with it in the next week or so.
lone axle
an argument passed to the constructor for polarity would be nice. But the Bit/Bits classes usage as descriptors, and the goal of a combined driver that can work for either I2C or SPI without having to duplicate all of the descriptor definitions make it tricky. I'm not sure if constructor argument will end up being possible.
solar whale
As I recall, the main issue I had was just how to modify the existing code to use it. Can you please post an example of how you use it for the bmp580.
solar whale
an argument passed to the constructor for polarity would be nice. But the Bit/Bi...
I have only run into needing to switch the polarity for the stmpe610 which has been deprecated...but there are a lot of them "in the field"
lone axle
As I recall, the main issue I had was just how to modify the existing code to us...
I believe this version of the spi bmp5xx driver should be working with the version of register_spi in my working branch: https://gist.github.com/FoamyGuy/fa1b7aad14990a0f3470c1c403a06e31
It works essentially the same way as adafruit_register.i2c_bits and similar classes. Descriptors defined at the class level sort of "magically" get accessed as int or boolean types after being defined.
solar whale
Thanks -- I have to shake off a few cobwebs and delve back into it. I needed a good project!
lone axle
Thanks -- I have to shake off a few cobwebs and delve back into it. I needed a ...
If you are interested in it from the angle of combined drivers that do both I2C and SPI, I've submitted my attempt at an implementation of that here: https://github.com/adafruit/Adafruit_CircuitPython_BMP5xx/pull/2
vernal sage
@slender iron I managed to fix my checkout and at least am not crashing immediately on the mmap assertion, any pointers where to look next for this?
slender iron
How'd you fix it? What does it do?
vernal sage
vernal sage
make fetch-port-submodules
cd esp-idf
git checkout origin/circuitpython-v5.5
g reset --hard
# new shell
. ./esp-idf/export.sh```I think something was lingering in the esp-idf component submodules
slender iron
```rm -rf esp-idf/*
make fetch-port-submodules
cd esp-idf
git checkout origin/ci...
Try 8bd1a8eb6d from my branch. I can get a prompt on the C6 now
vernal sage
I'll give it look. Dropping the spiflash is interesting since right now I am failing esp_flash_api.c:rom_spiflash_api_funcs->start(chip); but I think I may have some bad pin defs for the spi psram
full plume
going by git-blame comments, it looks related to optimizations - specifically related to word vs byte copies. If it's aligned on a 32 bit boundary, it will copy 32 bit words first, then one 16 bit and/or one byte for the remainder. Wouldn't be surprised if the standard glibc version does even more complicated stuff (beyond just dealing with 64 bit words), so there could be plausible justification for having "our own version". That said, seems like it should be primarily a MicroPython level change. You'd think it would be simple to have GitHub pull up a pretty diff between a source file and it's "ancestor" in another repo (like micropython/micropython), but nooooo.... or maybe it's just me missing something obvious. But an old school side-by-side MK1-eyeball compare shows the main difference being extra conditional compilation directives in CP to skip the optimization unless CIRCUITPY_FULL_BUILD is true - save space for tiny boards?
fiery pecan
going by git-blame comments, it looks related to optimizations - specifically re...
That's the most recent git blame, but it goes back much further: https://github.com/dhylands/micropython/blob/f14b92b9e13c9cb9f54a1d740dbea1eeedeccb5b/stmhal/string0.c#L4
fiery pecan
That's the most recent `git blame`, but it goes back much further: https://githu...
Additionally, according to https://github.com/micropython/micropython/issues/337, there was a migration to a "HAL". Around the time the aforementioned file was created, there existed an (almost) identical copy of that file in stm/string0.c, without the keyword "hal" in the path. I'd assume it was literally copied from that. The oldest git blame of that file is here: https://github.com/dhylands/micropython/blob/ed65605edc5c1376947a34723b9c750400b5a028/stm/string0.c#L4
wraith crow
I think I have the firmware fully working for the Olimex RP2350pc, the only problem is that in addition to the Circuit Python changes, it took commenting out three lines of code in tinyusb->rp2040_usb.c. I suspect that means I need to open an issue with hathach/tinyusb but does that mean I need to write some sort of non-circuitpython standalone reproducer?
tulip sleet
I think I have the firmware fully working for the Olimex RP2350pc, the only prob...
Not necessarily. You could explain what you needed to do, and why those lines should be deleted.
wraith crow
Ok thanks. I suspect It’s not as simple as deleting the lines, but I think there’s a pending PR that holds promise. Unfortunately, when I try applying it I still have issues. I think I’ll try explaining my situation on that PR first though
lone axle
There wasn't any bootloader update required for Metro RP2350 between beta.2 and beta.3 was there? I have a metro that I just upgraded via UF2 and afterwards it comes up with only CPSAVES. no CIRCUITPY
full plume
Additionally, according to https://github.com/micropython/micropython/issues/337...
Yeah, I'm sure there's a much deeper backstory (which I'm not familiar with) related to the string0.c history in microPython. I was just looking into why we have our own customized version of string0.c in CircuitPython.
upper radish
Included has been a labor of, let's call it love, for the past few weeks; this proof-of-concept was developed with help from Claude Code and has grown out from another CircuitPython-related project. This fork https://github.com/johnnohj/web-editor of the CircuitPython.org web-editor includes a web assembly build of CircuitPython under a new 'Virtual' workflow option, giving users access to a CircuitPython interpreter inside the browser. Focus has been on implementing a functional REPL experience. References to other features serve as suggestions for future integration. Instructions included to spin up a local dev server on localhost:3000 - I hope this effort provides at least a novel curiosity for those interested to try. 
full plume
Included has been a labor of, let's call it love, for the past few weeks; this p...
Very cool concept! I'm really tempted to give this a try, but I'm afraid it might be too much of a distraction until I get a few other things finished. Definitely on my "check out soon" list though.
upper radish
Very cool concept! I'm _really_ tempted to give this a try, but I'm afraid i...
Any and all insight - doubtless more expert than mine - welcome once you're able to circle back around and give it a try
slender iron
@lone axle do you have time to chat about the i2c/spi unification?
lone axle
<@382939733107408897> do you have time to chat about the i2c/spi unification?
I can now if you're able.
wraith crow
In case anyone's interested in my tinyUSB journey https://github.com/hathach/tinyusb/pull/2474
vernal sage
How do you enable coredumps for espressif? More specifically how do add the espcoredump component? It seems like anything I add in the Makefile and it just gets pruned
slender iron
How do you enable coredumps for espressif? More specifically how do add the espc...
make sure to add it to the CMakeLists.txt file too
vernal sage
So far I've come to the conclusion that it is hanging in the xPortStartScheduler esprv_int_set_threshold call. Just skipping that for giggles and I end blow past the yield but some progress
slender iron
what version of my branch are you based on?
vernal sage
I pulled the two commits last night after you squashed
vernal sage
I am partly chocking it up to the c61 still being alpha in 5.5 given logs like this
W (1060) clk: esp_perip_clk_init() has not been implemented yet
This is where things are at though: https://github.com/dbd/circuitpython/commits/dbd-esp32c61/ Mostly c61 specific besides these two
6ad2bc082c [ports/espressif/digitalio] update GPIO_HAL_GET_HW reference for IDFv5.5
63e04bfa3d [ports/espressif] stop relying on GPIO_PIN_MUX_REG for IDFv5.5
All this effort for just 2MB of PSRAM
I (764) esp_psram: Speed: 80MHz
I (1286) esp_psram: Adding pool of 2048K of PSRAM memory to heap allocator
@slender iron Success!
0;🐍REPL | 5.0.0-beta.0-4145-g24b25d4d23-dirty
Adafruit CircuitPython 5.0.0-beta.0-4145-g24b25d4d23-dirty on 2025-09-13; ESP32-C61-DevKitC-1-N8R2 with ESP32C61
>>> import gc
>>> print(f"Mem free: {gc.mem_free()/1024/1024:.2f} MB")
Mem free: 1.98 MB
@crimson ferry it is hard to tell the 4MB and 8MB QT Py S3's apart -- it's only the chip labeling
esptool.py chip_id may help:
$ esptool.py --port /dev/ttyACM0 chip_id
esptool.py --port /dev/ttyACM0 chip_id
esptool.py v4.8.1
Serial port /dev/ttyACM0
Connecting...
Detecting chip type... ESP32-S3
Chip is ESP32-S3 (QFN56) (revision v0.1)
Features: WiFi, BLE, Embedded Flash 4MB (XMC), Embedded PSRAM 2MB (AP_3v3)
crimson ferry
I never bought any No PSRAM, it's definitely a 4/2 S3 that was working, but maybe part of flash is bad. But I have it working on a reverse TFT S3 now.
crimson ferry
sorry, I was wrong, apparently did buy a no-PSRAM o_O
tulip sleet
The no-psram board was introduced first, I believe. It has a noticeably lower SKU number
vernal sage
@slender iron was wifi working on your c6 from your branch?
vernal sage
Ah got it working updating the ordering and setting the storage type
slender iron
<@252717193496756235> was wifi working on your c6 from your branch?
You are working ahead of me so I haven't tested it on the C6 yet.
vernal sage
Oh sorry thought you said you had a prompt on one before. I'll split out my changes for esp-idf stuff and the c61 bits so you can cherry-pick just the one if you need it
At this point I think it is just bt, pcnt, rmt and twai_ll. I atleast have bt buildable, it got weird since the kconfig just points to source the esp32c6 but I think I did that in sane manner, but that was hanging or core dump. I don't recall which. The rest I haven't dug into since I was prioritizing wifi.
slender iron
Oh sorry thought you said you had a prompt on one before. I'll split out my chan...
Where are your changes? I'd love take a look
vernal sage
Where are your changes? I'd love take a look
Still need to test the PinAlarm changes but digitalio seems to be working along with the reset_all_pins
tulip sleet
@lone axle hi - I'm working on https://github.com/adafruit/circuitpython/issues/10461, but I can't seem to get any sound out of the Fruit Jam whatsoever, whether with speakers or headphones. I've tried a couple of wavefiles. Here is a simple test audio player that does not seem to be working:
from audiocore import WaveFile
import adafruit_tlv320
import time
import board
import busio
import audiobusio
i2c = board.I2C()
dac = adafruit_tlv320.TLV320DAC3100(i2c)
dac.headphone_output = True
dac.speaker_output = True
dac.configure_clocks(sample_rate=16000, bit_depth=16)
audio = audiobusio.I2SOut(board.I2S_BCLK, board.I2S_MCLK, board.I2S_DIN)
wave_file = open("/mak16.wav", "rb")
wave = WaveFile(wave_file)
while True:
print("play")
audio.play(wave)
while audio.playing:
pass
time.sleep(1)
Is there something you can see I'm doing wrong? Tested with mono 8 bit and 16 bit 16 kHz wav files.
lone axle
<@382939733107408897> hi - I'm working on <https://github.com/adafruit/circuitpy...
try checking what dac.dac_volume and either dac.speaker_volume or dac.headphone_volume are set to based on which you have output device hooked up to.
tulip sleet
can i have both devices hooked up?
tiny peak
maybe unrelated to your problem, but audio quality will be much worse on the headphone output if you don't do dac.speaker_output = False before dac.headphone_output = True. Sounds a lot better if you pick one or the other.
tulip sleet
dac.dac_volume=-20.0
dac.headphone_volume=-52.7
dac.speaker_volume=-20.1
I have only ever done one or the other. I'm not sure if both will go at the same time.
tulip sleet
set dac.headphone_output = False, no help. I am using some Apple earbuds that have a mic too. Maybe I should try TRS instead of TRRS
the example is just cribbed from the issue
tiny peak
you could try increasing the headphone volume with dac.headphone_volume += 10 or maybe += 20. Maybe start with the earbuds not in your ears
tulip sleet
is dac_volume = -20 OK?
tiny peak
somewhere on github there's a sample app I wrote that uses a synthio test tone with serial console commands to let you interactively tweak all the volume settings
tulip sleet
or should I increase that too? IIf I understand right, there are two gain stages
wraith crow
I don't know how the interaction with headphone_volume and speaker_volume work but I'm generally running with dac_volume higher than that
tiny peak
I recommend using headphone_volume and speaker_volume as gain controls to adjust for differences in sensitivity between audio output devices (which vary in impedance and loudness). Then, once balanced, you can use dac_volume as the regular volume adjustment control for your user facing UI.
If you look at the FruitJamOS repo where it does volume adjustment stuff, that will give you an idea of a good target range for dac_volume. Tim knows more about that.
lone axle
There appears to be something else going on I think
I'm not getting any sound attempting to play wave files either now when doing it direct with TLV library as shown in the code above. Playing them through the Fruit Jam library is working though.
tiny peak
Is this right (from example code above:
audio = audiobusio.I2SOut(board.I2S_BCLK, board.I2S_MCLK, board.I2S_DIN)
looking at my volume adjuster sample app, I did this:
audio = I2SOut(bit_clock=I2S_BCLK, word_select=I2S_WS, data=I2S_DIN)
makes sense to me, the issue is from a while ago and maybe Tim was using different pins due to a pin swap
tiny peak
my memory is fuzzy, but was it the MCLK and WS pins that got switched around rev C?
lone axle
looking at my volume adjuster sample app, I did this:
```
audio = I2SOut(bit_clo...
which rev of fruit jam hardware did you have?
tulip sleet
I have the product one with the wrong IR resistor
you must have been testing with an early one. OK, I think that's it
tiny peak
which rev of fruit jam hardware did you have?
I have a rev B and a rev D, but that sample code was for rev D.
lone axle
yeah, init should be like this:
audiobusio.I2SOut(board.I2S_BCLK, board.I2S_WS, board.I2S_DIN)
I do think I was using the one with swapped pins when I made the issue.
tulip sleet
the speaker is ridiculously quiet even with dac.speaker_output = True
I made the gain 0 instead of -20
tiny peak
that's odd. Are you using the Fruit Jam kit speaker, or something else?
tiny peak
you might also try Tim's FruitJamOS stuff to see what you think of its default volume range
The driver is set up to be pretty quiet to avoid accidental hardware damage
In most use cases it will probably be necessary to provide UI controls for increasing the volume, and perhaps to restore a saved volume
for a while people were blowing up their speakers
tulip sleet
i was in the loop for the code review but didn't actually try it 🙂
wraith crow
just me blowing up speakers I think 😁
lone axle
I am thinking of bumping the default volume a little higher still. At the same time as swapping to use floats 0.0 - 1.0 for volume in fruit jam library. I tested before with synthio but have found the waves included in the boot animation and some of the projects still come out on pretty low.
tiny peak
at one point tannewt zapped the DAC on one of his prototype boards too, IIRC. Seems like he mentioned that on one of his last Deep Dive shows.
manic glacierBOT
thorny jay
I made the gain 0 instead of -20
I played with the FruitJamOS, and I could not figure out where the sound was supposed to get out of...
I connected the speaker, and expected to hear something, but not really (using the boot animation, and using the music game).
Then I connected/added a headset, and there I could hear a little bit. (it was not clear to me if I had to disconnect the (official) speaker.
Also, it was not clear exactly where to glue the speaker, or let's say in what direction... there is a mark on the PCB, but that place is full of component. I did not see clear instruction on the learn guide (but I did not search much).
PS1: I installed everything one or two weeks ago maybe, so I might not have the latest version.
PS2: I have two FruitJam, but I only tested one, I could test one with the speaker and the other one without the speaker.
PS3: I don't hear very well, but people around me had the same issue.
tidal meteor
Just to let you know that "Make Magazine" just published my article about CircuitPython on the Oxocard Connect : https://makezine.com/projects/programming-the-oxocard-connect-with-circuitpython/
tulip sleet
I played with the FruitJamOS, and I could not figure out where the sound was sup...
I had the same q about the speaker, and ended up using thick foam tape to mount it over the components. But I asked ladyada later, who said it would be better to mount it on the cover plate over its space.
The current volume settings are quite low and will be tweaked.
tulip sleet
Just to let you know that "Make Magazine" just published my article about Circui...
Great! I have sent that on for publication in our weekly newsletter. Send news like this to cpnews@adafruit.com
tulip sleet
I played with the FruitJamOS, and I could not figure out where the sound was sup...
I inquired: you can mount the speaker front side against the top plate use the self-stick ring. This will be added to the guide.
wraith crow
I played with the FruitJamOS, and I could not figure out where the sound was sup...
Most of the fruit jam programs default to headphone output. To direct audio to the speaker you can add the “audio” parameter to the launcher.conf.json file
lone axle
I've made a note on my list to update that page with the audio controls.
I'm going to update the fruit jam lib to use 0.0 - 1.0 range first so the docs can reference that from the beginning.
I will expand the guide more generally to mention the default behavior of audio and how to change it.
wraith crow
Until foamyguy’s updates, For speaker {“audio”:{“output”:”speaker”}} 😁
wraith crow
I played with the FruitJamOS, and I could not figure out where the sound was sup...
I would also recommend updating the firmware, libraries and fruit jam os frequently, it’s still early days and things are changing
thorny jay
I would also recommend updating the firmware, libraries and fruit jam os frequen...
Fully understand that.
I wanted to start a list of "imperfection" from an "end-user point of view".
- Sound was issue number one.
- Switching to terminal display between FruitJamOS and "FruitJamApplication" is also "uggly" and I would prefer the terminal to be hidden, and just a black screen.
- Maybe some lack of common behaviour between application (like how do I get out of a game/application)
- Maybe common setting (like sound level) but I have seen issue or stream that let me to believe that this is worked on.
I am not sure the best "channel" to share "opinion" about the "look and feel" of the resulting CP+FruitJamOS+Application combo.
lone axle
Fully understand that.
I wanted to start a list of "imperfection" from an "end-...
An issue on the Fruit Jam OS repo is probably the best place to start a discussion: https://github.com/adafruit/Fruit-Jam-OS/issues
Switching between terminal and display is not something that the Fruit Jam OS layer has control over I don't think. CircuitPython itself automatically shows the terminal when it starts up. The "launching apps" mechanisms involves restarting circuitpython so it will show the terminal when that happens unless behavior in the core is changed I think. In any case I'd want a change like that to be optional if possible because I find the switching kind of charming in a way even if it's jarring by modern UX standards.
As for common behaviors: ctrl+c should be able to exit out of any app/game. Then can go back to the launcher with ctrl+d. Other games/apps do provide other mechanisms as well like pressing q at the end of the game will exit a few of the ones I made but it is up to individual apps to provide any behavior beyond the ctrl+c / ctrl+d that is built-in to CircuitPython.
vernal sage
Didn't realize that was going to post here and made the comment so it wouldn't get lost in discord. Apologies if comments on drafts are discouraged
orchid basinBOT
tiny peak
CI maintainer folks, I got a build error on this PR which seems to have been caused by a http 403 from attempting to fetch a Ubuntu 24.04 image from Azure. The error only happened for one build. Looks like something weird is going on.
lone axle
CI maintainer folks, I got a build error on [this PR](https://github.com/adafrui...
I think it sometimes just fails the network requests. I can be re-run, but I'm not sure if only for a single device.
it may have been an issue with the server hosting the file at the time the request was made.
plain oasis
While creating a PR for the MMA8451 library i noticed that the ruff formatter when run locally fails to start because rule E999 is available anymore but selected by default. Is there any specific configuration required to run ruff locally?
Makes it a bit problematic to check if it meets the rules before pushing.
lone axle
While creating a PR for the MMA8451 library i noticed that the ruff formatter wh...
What version of ruff are you using, and how do you launch it? We typically use pre-commit to run ruff and the other checks, and it seems to be working okay inside that repo:
~/Adafruit_CircuitPython_MMA8451$ pre-commit run -a
check yaml..................Passed
fix end of files............Passed
trim trailing whitespace....Passed
ruff-format.................Passed
ruff........................Passed
reuse.......................Passed
I have installed it from pypi so currently 0.13.0 and ran ruff check directly assuming it uses the provided ruff.toml
This contains E999 but ruff fails with
Cause: Rule
E999was removed and cannot be selected.
lone axle
looks like that is quite a bit newer than the one specified in the pre-commit files: https://github.com/adafruit/Adafruit_CircuitPython_MMA8451/blob/467029d217e2c9c42d5cb2195286731a2caba2b2/.pre-commit-config.yaml#L12-L13
I think you'll either have to use a lower version, or run it via pre-commit instead of directly.
I'm not opposed to updating to a newer version of ruff, but that will require a much wider change in the cookiecutter and all the rest of the library repos, since we use the same configuration in all of them. It would be good to get rid of deprecated configs ultimately.
plain oasis
Good to know. Just noticed that while checking the PR after the first verification failed. Then for a local check removing E999 or using an older version is probably enough.
btw. regarding the open PR i am open to feedback if a different approach is preferred to ensure a proper delay after the MMA8451 reset. A simple 1ms delay is in theory enough but as the startup time is not really specified in the datasheet a dynamic retry loop may be more reliable.
lone axle
I think the latest version is good, I reviewed the PR, thanks for working on that.
manic glacierBOT
slender iron
Didn't realize that was going to post here and made the comment so it wouldn't g...
They are welcome! Thanks!
slender iron
@vernal sage want to PR your changes into my branch?
actually I can just pull in the commits
slender iron
@gilded cradle I'm using code-beta.cp.org with an ESP32-C6 via the internal usb to serial converter. On connect I'm seeing the device reset. Is the editor doing this or my OS?
vernal sage
I did a bit more testing from from branch, I think the C61 is done at this point since it is missing RMT/PCNT/TWAI. I flashed a TinyC6 and the default neopixel test was running from. I tried to flash the MetroS3 but that likely needs a partition update as well the lib changes you mentioned your PR
slender iron
kk
I'm starting with C6 testing and will do the others this week
Thanks for the help!
just pushed my branch with your changes plus the string0 change
vernal sage
I foolishly didn't check the C61 block diagram before starting this whole thing so I'll probably have the C5 branch up tomorrow. All I want from a board is matter/thread and some PSRAM. Hopefully that is just the boilerplate stuff though given the TinyC6 worked fine
orchid basinBOT
manic glacierBOT
wraith crow
@lone axle I just noticed in the recent learning guide PRs, you left it so that volume_override_danger set both the volume and the new safe limit. In your deep dive you had mentioned that you thought they should be separate. Did you change your mind? If not, and you don't have time, I can throw a quick PR in tonight to set them as you had defined in the deep dive.
lone axle
<@382939733107408897> I just noticed in the recent learning guide PRs, you left ...
I didn't change my mind, must have just overlooked it. If you're up to it can you go ahead and swap them to 0.0 - 1.0 volume values like ones from this this PR: https://github.com/adafruit/Adafruit_CircuitPython_FruitJam/pull/22 I will do that soon in any case if not. Once that is updated in all the places where the volume API is used I'll move those PRs out of draft.
wraith crow
okay, I'll submit a PR later tonight that does both...
lone axle
Thank you!
gilded cradle
@slender iron I'll have to take a look
slender iron
I'm monitoring the esp_log via uart to see that the device restarts due to the serial to jtag triggering it
could be a linux thing
or maybe some restart trigger leaking over from a shared serial library?
gilded cradle
@slender iron I don't think it's resetting. Does the reset cause it to disconnect?
slender iron
no, but it does the startup blinks again
it doesn't fully connect afterwards anyway. I was just starting to debug it
does it work for you?
gilded cradle
Yeah, it seems to work fine for me on mac.
I was able to connect, open code.py, edit it, save it, and run it.
slender iron
I was able to connect, open code.py, edit it, save it, and run it.
Thanks for testing it! I'll dig more tomorrow
willow totem
How do I see the partition size circuitpython creates on the fruit-jam? I want to consider matching the app / user-fs ratio for the WipperSnapper installer. Tried using picotool partition info but didn't show anything / recognise the setup (CPY v10).
I've gone with 8mb/8mb for "reasons" (adafruit_fruitjam.menu.flash.16777216_8388608), but this is the choice list: https://github.com/earlephilhower/arduino-pico/blob/master/boards.txt so was wondering if there was a better option.
crimson ferry
How do I see the partition size circuitpython creates on the fruit-jam? I want t...
check mpconfigboard.h for the port and the board… the only thing I didn’t see there was where the saves partition goes
willow totem
check mpconfigboard.h for the port and the board… the only thing I didn’t see th...
where's that then? I looked at https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/boards/adafruit_fruit_jam/mpconfigboard.mk and then just now here too: https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/mpconfigport.mk but couldn't see any relevant numbers
oh 🤦♂️ the .h in generic port folder, sorry
crimson ferry
(and .h in board folder, where the saves partition is defined… but where does it go? 🤷♂️)
willow totem
the size and offset thing, I forgot it's possibly dynamic as such too, just above here (link goes to some flash autodetect thing I was referencing for something else ) https://github.com/adafruit/circuitpython/blob/ffc42b9f0f4aa5e812de5302bc217e1dd5a0f8b6/ports/raspberrypi/supervisor/internal_flash.c#L81C35-L89C6
crimson ferry
I wish all boards had a saves partition, even if it was small… Some place to put things more complex than bytes in flash by code.py
willow totem
yeah it's a good one. I also like the idea of accessing log files that way, read-only to the user
not sure the longevity of flash and logging but ignoring that...
slender iron
anyone use a c6 over serial with code.cp.org?
tulip sleet
@slender iron re the automount bugs: i have not yet found the cause of the disconnects on atmel-samd. forcing tud_task() calls every msec doesn't solve the problem. There are differences in supervisor/port.c and usb.c between ports that work and those that don't. I added a task-ready check but it didn't help.
The 70-second auto-restart on Linux also happens on RPi Linux, so it's generic. I have a USB trace that shows some activity from the host at that time, tickling the SD drive, it appears.
We talked at the Wednesday meeting about maybe turning the automount stuff off for 10.0.0. Our we could have it on only for Fruit Jam and other boards where the automount can be done before, but that doesn't solve the 70-second restart on Linux. Happy to talk about this if you have time.
tulip sleet
anyone use a c6 over serial with code.cp.org?
are you testing with beta-code or code?
there is a fix in code that is not in beta-code, I thnk, that Tim made a day or two ago and I approved
manic glacierBOT
tiny peak
The CircuitPython meeting is today, right?
lone axle
The CircuitPython meeting is today, right?
yes
tulip sleet
<@&356864093652516868> (Bi)-weekly CircuitPython audio meeting is in about 1.5 hours, 2pm US ET, 11am US PT. Add your notes to https://docs.google.com/document/d/1uoxUASzgEdYKXVSxoizL9sWmy7A4cxbn5Zr8vzxTOSI/edit?usp=sharing
vernal sage
@slender iron did you ever get a C5 to repl?
Of course as soon as I ask, openocd wants to play nice. Back to gdb it is
slender iron
<@252717193496756235> did you ever get a C5 to repl?
I haven't tried the C5. My goal is to test the most common chips to ensure we can switch to 5.5 for those
C5 and C61 are just a bonus
lone axle
Thanks for hosting Dan! have a great week everyone.
tulip sleet
@slender iron: Chromium bugs related to DTR/RTS:
original description of problem:
https://issues.chromium.org/issues/420689824
fix to above was broken:
https://issues.chromium.org/issues/437068905
bad fix was undone by finch killswitch:
https://chromium-review.googlesource.com/c/chromium/src/+/6828531
actual bug was fixed:
https://chromium-review.googlesource.com/c/chromium/src/+/6830530
tulip sleet
Here is the notes document for the Monday October 6, 2025 CircuitPython (Bi-)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/1Tbs6tWOH9oaIUS1076qzb8weuu53jphB2x7t-8VxvgQ/edit?usp=sharing
crimson ferry
os.uname() is getting deprecated(?), but sys.implementation has private methods. What is the canonical way to programmatically get the port, chip ype, etc.?
crimson ferry
thanks, we don't really have port available directly, but I can infer it... I'll lean toward sys.platform and sys.implementation
is RP2040 different enough from RP2350 to have sys.platform be the chip and not the port (as opposed to Espressif)?
tulip sleet
is RP2040 different enough from RP2350 to have `sys.platform` be the chip and no...
look at os.uname().sysname and .nodename ?
if we had platform, it might be more helpful, but very little room for it on small SAMD21 builds
I don't know where MicroPython is going with this. That comment about deprecating uname is pretty old
os.uname() is Linux only on CPython
crimson ferry
I think for now I just need to distinguish ports (probably sticking to S3 and RP2350 in those ports)... some data interfaces behave differently by port... so I can do conditionals on port. If I absolutely have to, I can vary by chip.
tiny peak
Question for folks interested in making games: Has anybody put any thought into the problem of doing 2D or 3D graphics on Adafruit boards at a higher frame rate than what's currently possible with CircuitPython displayio? I expect that would be possible in Arduino, but doing game logic in C is less pleasant than a higher level language. I've also been considering things like Love2D on Raspberry Pi, the TinyGL software rendering library, etc.
Broader context for my question is, I've got an idea for a game I'd like to build using 3d wireframe graphics, or perhaps simple 3d shaded graphics. I'm wondering if I could somehow coax CircuitPython into giving me a tolerable frame rate on a Fruit Jam board, maybe by adding some new performance-oriented graphics API to the core. OTOH, it might make more sense to build on a different software stack, like maybe Lua and TinyGL on top of Arduino or Pico-SDK.
tiny peak
Or phrasing my question a bit differently: Would it be totally ridiculous to even consider attempting to add a limited OpenGL-like (TinyGL) software rendering API to CircuitPython?
Or from a third angle: What do core devs think of the potential long term maintenance impact for adding more game-framework-like features to CircuitPython vs. an approach of porting (or creating) a Lua-scriptable game framework to run on top of existing Arduino libraries (or Pico-SDK)?
fiery pecan
Question for folks interested in making games: Has anybody put any thought into ...
Someone has done that for the https://www.adafruit.com/product/5289 already: https://github.com/bernhardstrobl/Pico3D
tiny peak
Someone has done that for the <https://www.adafruit.com/product/5289> already: h...
oh wow! very interesting.
blissful pollen
Or from a third angle: What do core devs think of the potential long term mainte...
I love the idea of more libraries to help support games (though I'm sure a lot of it could be pure python). I did some investigation on speeding up DisplayIO a couple years ago. The short answer is the framework isn't set for "fast" speeds you may want in a 3d engine. You would likely need a new module to support the calculations. I haven't looked at it lately though.
At the same time directly blitting a Gif from OnDiskGif was able to get decent rates. So it is possible.
wraith crow
It doesn't appear that the adafruit_fruitjam library in the bundle circup uses has been updated with the most recent PR (5 days ago)....
fiery pecan
oh wow! very interesting.
However, the device it runs on doesn't exactly fall under the category of "Adafruit boards" that you initially asked for. Although it was sold on Adafruit's website at one point in the past, it's technically manufactured by Pimoroni.
tiny peak
However, the device it runs on doesn't exactly fall under the category of "Adafr...
eh, close enough. The code is very interesting. Looks like they use geometry exported from Blender and feed that into a custom rendering engine that keeps one core busy. Then the c++ game logic runs on the other core. So, that at least validates the idea that software rendering of mildly complicated geometry ought to be doable. I'd expect that though. The bigger question would be how to package a rendering API such that you could do game logic in a scripting language that wasn't terrible for beginners to use.
tulip sleet
@tiny peak Scott might have more to say. displayio was inspired by the display architecture of memory-limited game systems, with tiles and sprites.
We have talked about doing lvgl. I'm not sure how good that is for gaming.
tiny peak
I don't think lvgl would really help much as it seems heavily oriented towards making 2D GUI stuff for touchscreens (lots of IO widgets for making forms and control panels)
For making stuff like platformer games, or perhaps the kind of 3D you'd need for a lo-fi flight simulator or racing game, it would be useful to have a library that's oriented towards a game rendering loop. Like, the loop would target 60 or maybe 30 fps, and each time through it would check inputs, update all the world state, then render a new frame from scratch.
tiny peak
For 3D stuff, it would also be helpful to have code to help with things like culling, shading triangles, animating the camera, and such.
It would also be really nice to have something that could sync the animation loop with the PicoDVI vertical refresh.
I'm not sure if it would be practical to modify CircuitPython to be compatible with that style of animation loop.
lone axle
It doesn't appear that the adafruit_fruitjam library in the bundle circup uses h...
I made a release in fruit jam repo just now. It should get picked up for the bundle / circup tomorrow.
@tiny peak I don't have much experience with it, but there is also a stage module https://learn.adafruit.com/circuitpython-stage-game-library/overview which is more aimed towards game graphics as I understand it.
full plume
<@1220648290941669377> Scott might have more to say. displayio was inspired by t...
You can do custom graphics under LVGL, and some people have used it for games. Although that's really not it's primary purpose, it does have a decent 2D canvas and I've used it in C++ projects (Win11 build of my ESP32 Christmas tree firmware - using LVGL canvas to emulate 1050 NeoPixels...)
stuck elbow
For making stuff like platformer games, or perhaps the kind of 3D you'd need for...
but you don't need C code for that, you can make that framework in python, using displayio or stage under the hood
full plume
IMHO getting non-trivial 3D graphics in CircuitPython would be a major uphill battle which might not be feasible to run on most current CircuitPython boards. Python support for 3D graphics has been a side quest of mine for a long time - I went so far as building a python wrapper for OpenGL at one point. It's been a few years since I went searching for a decent solution - most of my use cases involve highly interactive visualization of very large data sets. I've yet to find something that does that well with Python bindings.
stuck elbow
IMHO getting non-trivial 3D graphics in CircuitPython would be a _major_ uphill ...
yeah, 3d without hardware acceleration is really not great
full plume
Python support for 3D rendering has gotten better though - I've played with Panda3D a bit and it seems promising for gaming. However, getting it running well on a CircuitPython controller could be challenging.
Most Python "3D" systems are wrappers around C/C++ libraries. AFAIK there's not a trivial way to port CPython-API based wrappers to build as Micro/CircuitPython extensions. It's also likely that those wrappers (and the underlying C/C++ 3D engines) use some form of RAII based on CPython reference counting, which is not going to play well with Micro/CircuitPython's GC memory model.
FWIW there is cheat/hack that indirectly lets you have a UI with 3D from an embedded controller - which I haven't technically done with CircuitPython but I'm certain it could work well. You run the UI in a browser page, with REST/WebSockets keeping all the "moving parts" in sync but all the display and rendering done on the client. I've done this with Next.JS apps using three.js, where the entire UI is deployed as static javascript (+html,css,...) served from a micro SD card on an ESP32.
So it's not on a directly connected display (like the dvi out on a FruitJam), but it is "self contained" (i.e. you don't need anything installed outside your controller - just something with a decent browser which can connect over WiFi). It even works with my Android phone.
fiery pecan
So it's not on a directly connected display (like the dvi out on a FruitJam), b...
That sounds similar to using https://app.lizardbyte.dev/Sunshine/ to stream games from a gaming desktop, to a PC handheld (such as the Steam Deck).
frail swallow
using an xiao 2040 and can't see to get it in read/write so I can write a config. boot.py is correct to my knowledge.
I tried an nvm route but also had issues and couldn't get it working.
[Errno 30] Read-only filesystem
import storage, usb_cdc
import board, digitaliobtn = digitalio.DigitalInOut(board.D2)
btn.switch_to_input(pull=digitalio.Pull.UP)
storage.remount("/", readonly=False)if btn.value:
storage.disable_usb_drive()
else:
storage.enable_usb_drive()usb_cdc.enable(console=True, data=True)
crimson ferry
nvm should work no matter what... can you post the code and exception?
@frail swallow is the intention for this boot.py to allow writing to the CIRCUITPY drive from code.py?
frail swallow
yes, I just need a place to store/update a config, allowing code.py to create/update the config
frail swallow
Let me set back up nvm and see
crimson ferry
is there an exception in your boot_out.py?
slender iron
@tiny peak I'm open to adding another module to support 3d rendering
likely that'd need to be based on some 3d engine for microcontrollers
and ideally the api would match something from CPython
I don't know of any microcontrollers with 3d accelerators. most are for 2d
phone class SoCs will have 3d GPUs but they are much more closed ecosystems
fleet hollow
@slender iron @tiny peak I'd love to see _stage.render expanded to support framebufferio.FramebufferDisplay. From there python-ugame/circuitpython-stage could be updated to support the Fruit Jam and other boards with picodvi. 3D acceleration would be cool, but getting 2D graphics to render faster is of higher priority imo in order to enable more detailed action games (platformers, etc).
vernal sage
@slender iron esp32c5 branch is up if you want to poke, definitely some stability issues that I need to sort out but it does boot to repl fine after an initial reset. Seens like there are some issues with SPI at >40m when tuning
tiny peak
Thanks to all the folks who gave feedback on the graphics stuff. Sounds like there's general interest in adding better support for a faster way to do game graphics. I didn't know stage was a thing, so I'm definitely gonna need to look into that a bit.
stuck elbow
Thanks to all the folks who gave feedback on the graphics stuff. Sounds like the...
it's very minimalistic, I made it before displayio was there
tiny peak
It sounds like there are at least two different levels of capability that people are interested in. First would be just faster 2D graphics, perhaps achievable by modifying the stage module so it can be used with more boards. Second would be some kind of 3D capability using a software renderer (perhaps TinyGL).
stuck elbow
it could be possible to do 2d graphics with a framebuffer instead of computing the pixels on the fly like displayio does, it would use more memory, but would be faster for some kinds of graphics
tiny peak
I'm particularly interested in lofi 3D capability suitable for building stuff with visual complexity on the order of old school MS Flight Simulator.
tiny peak
Not sure. I'm not knowledgable enough about the implementation details of such things. I just know I'd like to make a flight simulator.
stuck elbow
mode7 let you do fake perspective like this https://nesdoug.com/wp-content/uploads/2020/04/fzero.gif
and you could rotate it too
tiny peak
oh, that looks very Outrun
stuck elbow
there are some arcade flight simulators that used this
tiny peak
I'm thinking FPV racing course kinda thing
stuck elbow
lotus esprint ;-)
but it's all flat
you can have other airplanes and vehicles, and maybe trees or buildings as sprites, but no things like skyscapers or mountains
here's a hang glider simulator for snes using mode 7
tiny peak
oh... cool
stuck elbow
and a star wars space shooter https://i.ytimg.com/vi/WajVBFqDA1s/maxresdefault.jpg
note how they curved the horizon of the death star
tiny peak
hmm... interesting. One thing about old game console video modes, if I understand the history correctly, is that a lot of that stuff used hardware acceleration. So, on a board without such accelerator chips, I'm not sure there would be much benefit over just using a software renderer in the style of TinyGL or Pico3D.
I've been thinking in the direction of: What if Love2d, but with OpenGL 1.1-ish level graphics implemented with a software renderer, and maybe in Python?
stuck elbow
it's much cheaper to display a single rotated and scaled texture, than to render hundreds of textured triangles with occlusion
tiny peak
interesting. In any case, I'd like to figure out something that would let me do 3D graphics that look like old Bruce Artwick games.
tiny peak
maybe a generation or two ahead of that if possible, but yeah. terrain and obstacles with either wireframe or shaded triangle stuff. possibly textures, but I care less about those.
stuck elbow
so those were done with a framebuffer and a Breshenham line drawing algorithm, and some basic projection math, later maybe some occlusion stuff
it was done purely in software on early pcs, amigas, atari st, etc.
tiny peak
I've toyed with the idea of trying to implement something from scratch according to the principles described in Artwick's "Applied Concepts in Microcomputer Graphics" book.
Trouble with that approach is it would be pretty unfamiliar to folks who are used to modern stuff. That's why I've also been wondering if I could maybe port a scaled down version of Love2D to Fruit Jam if I used a software renderer. Might be easier for folks to understand. Dunno.
stuck elbow
yes
stuck elbow
you can easily do love2d-level stuff with displayio already, you just need a python library that would implement the familiar functions
tiny peak
yeah. To me, for 2D stuff at least, it seems like the first choice path ought to be adding a module to CircuitPython, or modifying an existing module. The trick would be to come up with an API and implementation that works for action games where the whole frame gets re-rendered at a reasonably high frame rate.
stuck elbow
yeah. To me, for 2D stuff at least, it seems like the first choice path ought to...
why do you need a module? the game engine stuff doesn't need to be in C, displayio pretty much already covers the parts that need to be fast
stuck elbow
displayio is not slow, the displays you are using are slow
you have to push all those pixels over a single wire
a rewrite won't help with that
tiny peak
I think we're in danger of wandering off topic for this channel. I don't want to hassle the other folks in this channel with arguments. I'm gonna peace out for now. Maybe we can discuss more later.
stuck elbow
this channel is for circuitpython development, so it's on topic here, we can create a thread if you worry about others
slender iron
my thinking for displayio is to have a second implementation of it based on LVGL for higher end (aka not RAM limited) MCUs. LVGL already has a way to accelerate 2d stuff with MCU accelerators and we could expand that as desired
displayio performance as it is scales with the number of pixels that need to change. a pico 8 celeste style game with limited motion should be plenty fast. a scroller like mario will be tougher because each pixel needs to change. I always aspired to using the scroll ability of SPI display but it is often in the wrong direction
slender iron
<@252717193496756235> esp32c5 [branch](https://github.com/dbd/circuitpython/comm...
Nice! I'm not surprised since C5 support was just added
vernal sage
Whats a reasonable amount of time for a board to start? I'm sure there is a range but 14 seconds does seem kind of rough. I suppose this could in #help-with-circuitpython but this is more an issue with changing from flash storage to ram so wifi/bluetooth are initialized at boot every cold cycle
code.py output:
0;🐍10.0.0.114 | BLE:Off | code.py | 5.0.0-beta.0-4141-g0613f28042-dirty
========== TIME ==========
22:23:38 - 23/9/2025
========== DONE ==========
0;🐍10.0.0.114 | BLE:Off | Done | 5.0.0-beta.0-4141-g0613f28042-dirty
Code done running.
Press any key to enter the REPL. Use CTRL-D to reload.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
0;🐍10.0.0.114 | BLE:Off | code.py | 5.0.0-beta.0-4141-g0613f28042-dirty
========== TIME ==========
22:23:52 - 23/9/2025
========== DONE ==========
Also that reliability with the C5 was just bt trying to read nvs before it was initialized, so it would core dump, warm cycle before flash was reset and then would start up into safe mode. Switching to no NVS storage seems to have things working pretty well
slender iron
14 seconds with wifi starting isn't super crazy to me. It does at least one scan to find the channel to connect to
it should be two seconds or so without wifi
one second for safe mode blinks and one for bluetooth blinks
vernal sage
Ah okay, those blinks seem to line up with what I'm seeing
tiny peak
my thinking for displayio is to have a second implementation of it based on LVGL...
Does LVGL 2D acceleration do anything useful on MCUs below the level of Cortex M52/M55/M7/M85 with Helium support?
lone sandalBOT
tiny peak
From a quick look at the LVGL and ARM Developer docs, I'm wondering if Adafruit sells any boards besides possibly the Metro M7 and Teensy 4.x that would have the right instruction set features to benefit from LVGL's 2D acceleration stuff.
tulip sleet
From a quick look at the LVGL and ARM Developer docs, I'm wondering if Adafruit ...
Does the M33 in the RP2350 have some useful instructions?
tiny peak
as far as I can tell, M33 doesn't do the Helium vector instruction stuff
it's not clear to me if M33 has any lesser instruction set features that can be used by LVGL for acceleration
At first glance, my impression is that the stuff mentioned on the LVGL 2D acceleration docs page doesn't seem like it would apply to the RP2350. Might be wrong about that though. IDK.
tulip sleet
as far as I can tell, M33 doesn't do the Helium vector instruction stuff
interesting article confirming what you said but also pointing out M5x: https://www.techinsights.com/blog/arm-brings-helium-small-cpu
tiny peak
likely that'd need to be based on some 3d engine for microcontrollers
From reading what people have to say here, on reddit, HN, and so on, I get the impression that not a lot of people do 3D stuff in desktop python, and it's quite rare on small microcontrollers. Like, 3d game engine for microcontrollers may not be a thing. (obligatory mentions: yes PyGame, Panda3d, Ursina, Pico3D do exist, but they don't seem very popular).
My point is that it doesn't seem like there is an existing game engine or framework for Python that people consider to be in the same league as other choices like Love2D, Defold, Pico-8, Godot, Unity or Unreal, etc. From what I read about PyGame, its API apparently lacks important features that are needed for many types of 2D games.
stuck elbow
I wrote a bunch of games, both in love2d and in pygame, and I never noticed pygame missing anything
but it's a library not a framework
tiny peak
one of the specific complaints I saw about pygame was that if you wanted to do a scroller with camera tracking, you had to implement all the coordinate translations on your own.
and people also mentioned they thought the API was generally pretty low level so you ended up having to build a lot of stuff on your own (things people missed having from engines that included more stuff by default)
haven't tried it myself, so I don't have much context to weigh those claims
The overall impression I got was, if we want to find good APIs to emulate -- stuff that lots of people like for building games of different styles -- it might be worth looking at how some of the popular Lua-based frameworks and engines work.
My tentative plan for the moment is to try some tutorials and experiments with Love2D, PyGame, and maybe some other stuff, then revisit all this later when I have more experience.
stuck elbow
and people also mentioned they thought the API was generally pretty low level so...
that is all true, as I said, it's a library you can use to build your own game engine, not a framework that already does everything for you
then again, plain love2d doesn't have much implemented either, I remember I had to do my own sprites, which pygame already had
my impression is that most of the lua and javascript game frameworks are based on this idea that you get a clean canvas, and draw all the game graphics on it from scratch every frame, which really doesn't work that well with non-accelerated platforms
displayio was based on the gameboy, nes, snes etc. platforms, where you have a number of tile grids and sprites, and where you only update the parts that have changed from the last frame
full plume
my impression is that most of the lua
slender iron
From a quick look at the LVGL and ARM Developer docs, I'm wondering if Adafruit ...
It isn't just instruction set that matters. Sometimes it is a separate peripheral. ESP32-P4 has one we can likely use too.
fleet hollow
it's very minimalistic, I made it before displayio was there
In your opinion, would supporting _stage on the RP2350 result in a performance boost over displayio for tile-able graphics? I've started some porting work to get it running with framebufferio.FramebufferDisplay, but I'm not quite there yet to be able to run tests.
stuck elbow
In your opinion, would supporting `_stage` on the RP2350 result in a performance...
stage works on the rp2350 just fine, and since it does less than displayio, it's faster
fleet hollow
stage works on the rp2350 just fine, and since it does less than displayio, it's...
Ah, I thought it _stage disabled on platforms that weren't directly supported by the library (pybadge, etc). Still, I think framebuffer support is needed for picodvi output.
stuck elbow
Ah, I thought it `_stage` disabled on platforms that weren't directly supported ...
ah, yes, it only works with fourwire displays
stuck elbow
you would have to pretty much rewrite it for anything else
full plume
@slender iron just a heads up - not quite PR ready yet but that's the plan.... I've added some extra tracking inside gc.c / gc.h and calls to get at the extra info in modgc.c. It keeps a running total of how much is allocated at any given time, so you can call gc.mem_alloc_live() and get the result effectively instantly (especially compared to gc.mem_alloc(). I also added gc.mem_quick_free_live() and gc.mem_quick_used_live() (apologies for lazy naming - that will be fixed) which "walk the heap" like gc.mem_free() / gc.mem_alloc() but run around 300% faster. Source is at https://github.com/jbrelwof/circuitpython/tree/gc_extensions if you're curious.
My use case is a fairly complex profiling harness which tracks elapsed time and GC allocation. Since there can be dozens of before/after samples per single "main loop" iteration, the overhead for gc.mem_alloc() rendered the system nearly unusable when doing a "full depth" profile with memory tracking enabled. Using gc.mem_alloc_live() drops the overhead to around 20% compared to profiling completely disabled - whereas the overhead was more like 95%+ with gc.mem_alloc().
manic glacierBOT
slender iron
My use case is a fairly complex profiling harness which tracks elapsed time and ...
I think I'd prefer these go in a new module. gc exists in CPython and we're already not matching it. I'd rather not make it worse. A new module also makes for an obvious way to enable and disable it
memorymonitor is an example
tulip sleet
@slender iron I am going down a rathole of automount issues. in main.c we have this code, which is about 6 years old:
static void stop_mp(void) {
#if MICROPY_VFS
mp_vfs_mount_t *vfs = MP_STATE_VM(vfs_mount_table);
// Unmount all heap allocated vfs mounts.
while (gc_nbytes(vfs) > 0) {
vfs = vfs->next;
}
MP_STATE_VM(vfs_mount_table) = vfs;
// The last vfs is CIRCUITPY and the root directory.
while (vfs->next != NULL) {
vfs = vfs->next;
}
MP_STATE_VM(vfs_cur) = vfs;
#endif
it looks like it is assuming that there are no non-gc-able vfs mounts between gc-able vfs mounts in the linked list. I think that assumption could be incorrect, what with CPSAVES and automounting. Maybe it still works by accident.
also I see a a number of places callling gc_nbytes() to see if something is gc-able, but we now have bool gc_ptr_on_heap(), which is more efficient, and should work just fine, I think.
this is not urgent. I can talk to you tomorrow about this, just giving advance warning
there is also a catch-22 on auto-reload if you write to a code.py-mounted filesystem. When you write to that filesystem, it will trigger an autoreload, stopping the VM, and the filesystem will get unmounted, because it is gc-able. So writes to user-mounted filesystems should not trigger auto-reload ever.
(I started writing a lun_is_automounted() routine and then stumbled into the rathole above.
manic glacierBOT
manic glacierBOT
manic glacierBOT
lone axle
@slender iron I made some progress on register refactor. Submitted https://github.com/adafruit/Adafruit_CircuitPython_Register/pull/59 draft with a SPI implementation.
I still have to do the I2C implementation and some more cleanup and testing. But open to get feedback when you have time to look.
slender iron
<@252717193496756235> I made some progress on register refactor. Submitted https...
Nice! Will look now
tulip sleet
<@252717193496756235> I am going down a rathole of automount issues. in `main.c`...
@slender iron I have something read-only/read-write stuff to ask you about if you are free. I have something in half an hour
vernal sage
What was the reason neopixel_write uses rmt instead of ledc for espressif? Seems like ledc has the wider class of support so you could use it on the C61 and C2
devout jolt
What was the reason neopixel_write uses rmt instead of ledc for espressif? Seems...
I think ledc is only for PWM of “dumb” LEDs, not for addressable LEDs
full plume
`memorymonitor` is an example
Yeah, fixing the names and moving it the API wrapper to a separate module are part of getting it "PR ready". But it will still require changes in gc.h and gc.c, although those are all wrapped in #if CIRCUITPY_GC_TRACK_LIVE... so you can choose whether or not to add the tracking logic at compile/build time.
tulip sleet
@slender iron it turns out an ordinary file open() from CircuitPython don't use filesystem_lock() or blockdev_lock() at all. The open just checks filesystem_is_writable_by_python() ., which checks MP_BLOCKDEV_FLAG_USB_WRITABLE, which is only set/cleared by filesystem_set_writable_by_usb().
So the USB MSC side may do blockdev_lock(), but the CIrcuitPython side pays no attention to that. The filesystem_lock() and blockdev_lock() are used in the common workflow routines.
slender iron
<@252717193496756235> it turns out an ordinary file `open() `from CircuitPython ...
oh oops! I thought I had that covered. That'd explain why it doesn't work
slender iron
Yeah, fixing the names and moving it the API wrapper to a separate module are pa...
You can move them behind the same flag that enables the module
tulip sleet
oh oops! I thought I had that covered. That'd explain why it doesn't work
Can we talk on audio/video about this one more time? I will take notes! I am still not sure about who should grab the lock when. One trouble is that tud_msc_is_writable_cb() grabs and holds the lock immediately, and that's called as soon as the host side sees the device, even before there's any intention to write any files from the host side.
i have somebody coming over briefly in the next 15-30 minutes, so short or could be after that.
slender iron
Can we talk on audio/video about this one more time? I will take notes! I am sti...
rynn just went down so I'm free for 45 minutes at least
manic glacierBOT
copper crescent
Not sure where to put this really but there's a mismatch between the board_id in https://github.com/adafruit/circuitpython-org/edit/main/_board/ai_on_the_edge_cam.md and the circuitpython source https://github.com/adafruit/circuitpython/tree/main/ports/espressif/boards/prokyber_ai_on_the_edge_cam which is breaking downloads.
I assume the "org" side is what needs the fix (renaming the images/md etc)?
lone axle
I assume the "org" side is what needs the fix (renaming the images/md etc)?
It could be fixed on either side I think, but I would lean towards updating the org site data instead of the core repo.
IIRC the folder name in the core repo needs to match the board_id value inside of the cp.org data file for that board.
Thanks for reporting this I'll try to get a fix in for it today.
copper crescent
It could be fixed on either side I think, but I would lean towards updating the ...
thanks for fixing 👍
tulip sleet
@slender iron I have release notes for 10.0.0 rc.0, so I think I will just go ahead.
orchid basinBOT
orchid basinBOT
tulip sleet
https://blog.adafruit.com/2025/09/30/circuitpython-10-0-0-rc-0-released/
Highlights of this release
- Allow chained calls for audio effects and audio mixer.
- Bug fixes.
full plume
You can move them behind the same flag that enables the module
Will do - once I figure out all the bits & pieces for adding it as a separate module
slender iron
@tulip sleet I'm tempted to have you do 10.0 today. I'm out 10/8-10/15 so doing it now gives me time to help fix bugs. Otherwise we'd wait two weeks
tulip sleet
<@329766224093249548> I'm tempted to have you do 10.0 today. I'm out 10/8-10/15 ...
I was thinking the same, tonight or tomorrow afternoon. I'm out in the earlier evening today, and will be out until early afternoon tomorrow.
slender iron
I'm out Friday during the day as well
tulip sleet
so tonight if we don't hear anything bad. I want to xref the OPEN INSTALLER guide in the Factory Reset pages, but that should be quick
we are not going to get a bunch of rc.0 testers -- those people have already been testing all the betas, and the recent changes are simple or isolated.
slender iron
yup, agreed
orchid basinBOT
tulip sleet
CircuitPython 10.0.0 released!
https://blog.adafruit.com/2025/10/01/circuitpython-10-0-0-released/
See the release notes for changes from 9.x.x.
manic glacierBOT
autumn jasper
hey guys. I noticed that with CircuitPython it is not possible to use the usb host functionality with the Raspberry Pi Pico's built in micro usb port. This seems to be possible otherwise: https://github.com/rppicomidi/midi2usbhost
I'd like to maybe add this functionality to CP. Any idea where I should start looking?
tulip sleet
hey guys. I noticed that with CircuitPython it is not possible to use the usb ho...
We use the PIO USB Host if we want host capability. Otherwise you lose a lot of ease of use in the development cycle. For instance, the REPL would need to be done over serial, CIRCUITPY would not be expose,d etc. Do you have a particular use case in mind that would want to use the built-in host capability rather than something like https://www.adafruit.com/product/5723 ?
The RP2350 fixes all the known errata for native USB host on RP2040.
autumn jasper
The RP2350 fixes all the known errata for native USB host on RP2040.
Actually this is the Raspberry Pi Pico 2 I'm using.
I'll look into PIO USB Host.
tulip sleet
I'll look into PIO USB Host.
you can always add a USB socket breakout. And https://www.adafruit.com/product/6200 has two USB host ports (there's a USB hub on board)
CircuitPython 10 (and earlier) has usb_host support on Pico 2 (and Pico)
autumn jasper
CircuitPython 10 (and earlier) has usb_host support on Pico 2 (and Pico)
Yes, but not with the built in micro usb port, correct?
Where you would use something like an OTG cable and power the Pico externally
Like the github repo I linked earlier
tulip sleet
that's right, that usb_host support is PIO. We have a lot of USB breakouts. Do you want micro-B or would you prefer a USB-A
autumn jasper
Ok. Actually I needed to use the built in micro usb because I soldered a design of mine to a protoboard with a JST connector hooked up to VBUS so I could power the Pico 2 externally and then use an OTG cable
so to use a USB A port for usb host functionality I would have to desolder some of that ahaha
I'll probably solder a newer version accounting for that
tulip sleet
well ... you could do hours of software dev or alter the design 🙂
autumn jasper
I just assumed that CircuitPython would be able to achieve what that github repo did
autumn jasper
well ... you could do hours of software dev or alter the design 🙂
yeah that's true hahaha
so... to clarify: with PIO usb host I could potentially use 2 GPIO pins for Data + and Data -?
autumn jasper
thanks for the help! I'll probably just add another JST connector for Data + and Data - and cook up my own USB A port
tiny peak
re the RP2040 USB host stuff using the Pico's microUSB port instead of PIO... IIRC, somebody around here (can't remember who... perhaps RetiredWizard?) was recently looking at how to do something similar to add support for the Olimex RP2350pc. If I'm not totally misremembering, I think that board has its USB A jacks wired up to use the onboard USB peripheral instead of PIO. There may be some github issue and pull request discussion about it. My impression from what I remember of the discussion was that it wasn't an easy thing to get working with CircuitPython? Might be wrong about that.
wraith crow
re the RP2040 USB host stuff using the Pico's microUSB port instead of PIO... II...
@tiny peak @autumn jasper I was working on getting the microUSB working with the native tinyUSB stack. I have a CircuitPython PR ready that was needed to allow non-PIO USB Host to work when USB device was disabled but I also ran into an issue in tinyUSB that was resulting in a safe mode crash. I was able to work around the safe mode crash by commenting out a section of the tinyUSB code. I added the information to an open tinyUSB PR but I believe the fix I had could create problems when USB Host was used for something other than a keyboard or mouse. I think it may have simply ignored some data if it was received out of order or before earlier packets were processed (I didn't get deep enough to really understand what tinyUSB was doing and I don't know the USB protocol). I'll probably go ahead and submit the CircuitPython PR just so folks can look it over but I'm not sure it's going to make sense unless someone capable of digging into the tinyUSB problem has the time and inclination to do so.
manic glacierBOT
autumn jasper
<@1220648290941669377> <@224258212432445440> I was working on getting the microU...
I'll try compiling CP with your PR right now!
And after altering the board files for the Pico 2? Or is that not needed here?
autumn jasper
the flag "CIRCUITPY_USB_HOST=1" should be added, correct?
wraith crow
the flag "CIRCUITPY_USB_HOST=1" should be added, correct?
Yes and CIRCUITPY_USB_DEVICE=0 and CIRCUITPY_USB_VIDEO=0, you'll also need to add CIRCUITPY_CREATOR_ID and CIRCUITPY_CREATION_ID, for testing you can just use the USB_VID/USB_PID for those values but eventually you would need to create proper values.
I don't think the tinyUSB stack will handle USB_MIDI but you can give it a try. Also, with this build attempting mouse input the way it's currently being done with many short timeout calls is causing a tinyUSB panic. Keyboard input seems to work fine. I do have a hack to Device.c that basically turns off the timeout on usb reads and avoids the panic, however then mouse reads become blocking.
Overnight, it occurred to me that keyboard input must be checking if any USB input is ready before attempting to read the USB data and if I could modify the timeout function on the generic USB read to do the same thing before starting a USB xfer then tinyUSB would not have to attempt and abort so many transfers which would probably avoid the panics I'm seeing on mouse reads. When I get going this morning, I'll dig in that direction 😁 that was a dead end....
wraith crow
And after altering the board files for the Pico 2? Or is that not needed here?
You might be able to simply use the artifact from the PR, assuming the GPIOs that are exposed on the olimex RP2350pc work for you.
Using this technique you won't get a CIRCUITPY drive or be able to use the native USB port (microUSB) as a REPL terminal. To interact with the device, you'll need to define UART pins and connect a terminal or USB FTDI cable. board.c should construct your host port in board_init and CIRCUITPY_CONSOLE_UART_RX/TX sets up the console
crystal fractal
Trying to build CP on macOS 15.7 on Intel, getting the following error, looking for advice:
$ gmake -C mpy-cross
gmake: Entering directory '/[redacted]/circuitpython/mpy-cross'
- Verbosity options: any combination of "steps commands rules", as `make V=...` or env var BUILD_VERBOSE
GEN build/genhdr/mpversion.h
QSTR updated
GEN build/genhdr/qstrdefs.generated.h
Module registrations updated
GEN build/genhdr/moduledefs.h
Root pointer registrations updated
GEN build/genhdr/root_pointers.h
In file included from ../py/emitnx64.c:16:
../py/emitnative.c:2423:5: error: variable length array folded to constant array as an extension [-Werror,-Wgnu-folding-constant]
2423 | MP_STATIC_ASSERT(MP_OBJ_STOP_ITERATION == 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../py/misc.h:57:51: note: expanded from macro 'MP_STATIC_ASSERT'
57 | #define MP_STATIC_ASSERT(cond) ((void)sizeof(char[1 - 2 * !(cond)]))
| ^~~~~~~~~~~~~~~
1 error generated.
-e See https://learn.adafruit.com/building-circuitpython; Adafruit Discord #circuitpython-dev
gmake: *** [../py/mkrules.mk:104: build/py/emitnx64.o] Error 1
gmake: Leaving directory '/[redacted]/circuitpython/mpy-cross'
$ git rev-parse --short HEAD
a54ddb329b
$ gmake --version
GNU Make 4.4.1
Built for x86_64-apple-darwin24.0.0
<@&356864093652516868> Reminder: The (Bi) Weekly meeting is scheduled to occur here on discord today at 2pm US Eastern / 11am US Pacific, just under 90 minutes from now. As always, notes and hug reports can be added to the shared doc https://docs.google.com/document/d/1Tbs6tWOH9oaIUS1076qzb8weuu53jphB2x7t-8VxvgQ/edit?usp=sharing and we look forward to hearing from everyone who can attend.
lone axle
<@&356864093652516868> Bi-Weekly meeting is getting started now.
lone axle
Have a great week everyone 👋
tulip sleet
Thanks 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/1LMG6qyV-DP5TUlEeVBjLp1mIY5y-KvM_xqybEOMvSCI/edit?usp=sharing
slender iron
@tulip sleet just updated my 5.5.1 branch and S3 is working for me. esp32 and c3 also worked the last time I tested. c6 it boot looping
gonna try and jam out an epaper driver for liz before I leave
tulip sleet
<@329766224093249548> just updated my 5.5.1 branch and S3 is working for me. esp...
what got updated?
slender iron
not sure exactly but I removed some debug prints I'd left in
from debugging the c6
they weren't committed so it makes sense that it worked for thach
manic glacierBOT
