#circuitpython-dev
manic glacierBOT
tiny peak
So I tried, after many experiments, I
torpid crow
I am trying to integrate a c module into the atmel-samd port but am getting no rule to make target SRC_C. Could someone point me in the right direction?
slender iron
I am trying to integrate a c module into the atmel-samd port but am getting no r...
Please push your code somewhere and a copy of the error
orchid basinBOT
lone sandalBOT
stuck elbow
there is something wrong with the SPI docs, the parameter descriptions don't match the parameters listed in the function definition: https://docs.circuitpython.org/en/latest/shared-bindings/adafruit_bus_device/spi_device/index.html#adafruit_bus_device.spi_device.SPIDevice
tulip sleet
there is something wrong with the SPI docs, the parameter descriptions don't mat...
it looks better in the Python library: https://github.com/adafruit/Adafruit_CircuitPython_BusDevice/blob/main/adafruit_bus_device/spi_device.py. If you feel like opening an issue - thanks, otherwise I will.
stuck elbow
@tulip sleet ^^ done, hope that helps
tulip sleet
tyvm
manic glacierBOT
crimson ferry
@minor wing The espressif port wifi.ap_info code is here: https://github.com/adafruit/circuitpython/blob/1d13e30ac09744168014e2b41698dcc24a5ec965/ports/espressif/common-hal/wifi/Radio.c#L430. raspberrypi port here: https://github.com/adafruit/circuitpython/blob/1d13e30ac09744168014e2b41698dcc24a5ec965/ports/raspberrypi/common-hal/wifi/Radio.c#L378. shared-bindings has the higher-level API shared across ports: https://github.com/adafruit/circuitpython/blob/1d13e30ac09744168014e2b41698dcc24a5ec965/shared-bindings/wifi/Radio.c#L715
I think since espressif was the first and only wifi implementation for years, the CircuitPython API looks like espressif https://docs.espressif.com/projects/esp-idf/en/v5.5.1/esp32s2/api-reference/network/esp_wifi.html#_CPPv424esp_wifi_sta_get_ap_infoP16wifi_ap_record_t. For raspberrypi port, the elements of ap_info like RSSI are likely individual calls into the CYW43 driver, rather than a wholesale copy of an espressif structure.
manic glacierBOT
minor wing
Where (what folder) are the wifi module code files for the Raspberry Pico contained in the circuitpython repo?
/circuitpython/ports/raspberrypi/lib/cyw43-driver ?
tulip sleet
ports/raspberrypi/common-hal/{wifi,socketpool}. ssl in in shared-modules
the cyw43 library that actually talks to the radio module is what you are pointing to
minor wing
the cyw43 library that actually talks to the radio module is what you are pointi...
TY! 🙂
slender iron
@tulip sleet I'm around. Do you need anything from me?
tulip sleet
<@329766224093249548> I'm around. Do you need anything from me?
I am cooking part of the time 🙂 . I could give you a progress report, but don't have any pressing questions.
slender iron
I am cooking part of the time 🙂 . I could give you a progress report, but don't...
I got through email and reviews and decided not to start anything else. Have a good holiday and weekend!
tulip sleet
I got through email and reviews and decided not to start anything else. Have a g...
you too! yum!
urban silo
@slender iron Someone pointed me to your comment
No luck getting the M5Stack Tab5 going with this yet. The USB C is connected to GPIO24/25 which is connected to the serial/jtag peripheral...
If this is still an issue then I have a good solution 🙂
For my product Tanmatsu we have made the same choice to connect the USB-C port to the USB-serial/jtag peripheral, simply because it makes a lot of sense when flashing in a factory and for easy recovery by users. But: while researching we found that we did not have to hook up the second USB1.1 PHY too, it is possible to swap the USB PHYs during runtime without having to mess with efuses.
This function in the firmware for our device implements a simple way to switch USB mode between the debug & user peripheral on the fly as often as you want: https://github.com/Nicolai-Electronics/tanmatsu-launcher/blob/main/main/usb_device.c#L193
Our firmware has MIT license so feel free to reuse this function in CircuitPython provided that our attribution gets acknowledged (2025 Nicolai Electronics).
Hopefully this allows you to add support for more boards that are wired in this way 🙂
minor wing
When running the code snippet found here: https://docs.circuitpython.org/en/latest/shared-bindings/watchdog/index.html on my Raspberry Pico 2W, I get the following error: Traceback (most recent call last):
File "<stdin>", line 4, in <module>
NotImplementedError:
Think I "might have" found the problem. These are the existing files are in ~/circuitpython/ports/raspberrypi/common-hal/watchdog/, they have "no module functions" in the comments. Not sure why documentation says they are functional modules...
minor wing
Ok, so I have determined that I can build working firmware images at this point, now I just need to start making the appropriate changes to the code to get features working properly, so I will be asking questions regarding how to properly make those changes, please forgive me for seemingly "dumb" questions at this point - I'm just trying to figure this out so I can help to contribute...
I'm going to work on Raspberry Pico 2W and Adafruit KB2040, since I have those devices to test/verify with. I have at least 3 things I have found (non-implemented features) for the Pico2W, I'll attempt to do those first.
minor wing
I have now forked https://github.com/adafruit/circuitpython/ main, and created a new branch locally for developing the Pico 2W cyw43-rssi-current_ap fix, should I do all of the build steps listed at https://learn.adafruit.com/building-circuitpython/build-circuitpython to prepare my local branch for building?
tiny peak
@minor wing Things are pretty quiet here for the US holiday weekend. More people will probably be back around to see your messages by Monday.
nimble sparrow
@slender iron I've been wondering why it might be that the ESP32P4 EV board works when other P4 devices don't, and discovered that until recently the EV board used a dedicated CP2102 UART<>USB bridge, which is dropped in the most recent revision in favour of the "native" UART/JTAG device.
So annoyingly someone is bound to eventually buy a more recent version of the board and discover it "doesn't work" as it will act the same as the Tab5, Tanmatsu etc. until we figure out switching/bringing up device mode per @wind anvil 's code snippet above. More annoyingly, I guess that might mean you can't ever have a single unified P4-EV board target...
orchid basinBOT
orchid basinBOT
candid sun
<@&356864093652516868> We'll have our weekly meeting in about 65 minutes from now in this text channel and in the circuitpython voice channel. Please take the time to add your notes in advance to the document: [link to doc] -- I look forward to everyone's updates!
slender iron
<@252717193496756235> Someone pointed me to your comment
> No luck getting the ...
Thanks for the tip! I'll definitely take a look
tulip sleet
I do see my mic level
lone axle
https://www.instructables.com/Raspberry-Pi-Pico-W-Binary-Clock-Weather-Monitor/
https://github.com/Guitarman9119/Raspberry-Pi-Pico-/tree/refs/heads/main/Weather Binary Clock
https://youtu.be/hAAY1Tiw1yg
short tendon
@tulip sleet - please feel free to reach-out if I can test any of the C base airlift stuff
tulip sleet
When I get it to a usable state I'll let you and other folks know -- thanks!
wraith crow
So a lot of times you see a pop up when you're about to access something outside control of the primary OS with a confirmation requirement
Thanks all!
lone axle
Thanks for hosting Liz! Have a great week everyone.
tidal kiln
👋
candid sun
Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1_O2owjB7PZ_xTvg7pxIdX81GBGeHt_-u9CGx5fn2IP4/edit?tab=t.0
slender iron
@tulip sleet do you think it is important to support board.I2C() for zephyr? Or could we do board.I2C for most things? () needs a function call where the version without it is the object directly.
tulip sleet
<@329766224093249548> do you think it is important to support `board.I2C()` for ...
the function could just return the singleton so we don't have to change the API
slender iron
ya, I think that's the best way to do it
I've gotta generate that function I think though
tulip sleet
@lone axle I suggested removing the default value, and now there are compile errors like:
../../shared-bindings/bitmaptools/__init__.c:188:9: error: missing initializer for field ‘defval’ of ‘mp_arg_t’ {aka ‘const struct _mp_arg_t’} [-Werror=missing-field-initializers]
188 | {MP_QSTR_dest_bitmap, MP_ARG_REQUIRED | MP_ARG_OBJ},
this is confusing to me because this code is in I2C.c, for example:
static const mp_arg_t allowed_args[] = {
{ MP_QSTR_scl, MP_ARG_REQUIRED | MP_ARG_OBJ },
{ MP_QSTR_sda, MP_ARG_REQUIRED | MP_ARG_OBJ },
{ MP_QSTR_frequency, MP_ARG_KW_ONLY | MP_ARG_INT, {.u_int = 100000} },
{ MP_QSTR_timeout, MP_ARG_KW_ONLY | MP_ARG_INT, {.u_int = 255} },
};
The error seems specific to the unix port. I see the same locally attempting to build unix port. However I was able to build esspressif and run it on a MagTag.
I am putting them back for now though.
I just found some that are like this:
static const mp_arg_t allowed_args[] = {
{MP_QSTR_dest_bitmap, MP_ARG_REQUIRED | MP_ARG_OBJ, {}},
{MP_QSTR_x, MP_ARG_REQUIRED | MP_ARG_INT, {}},
{MP_QSTR_y, MP_ARG_REQUIRED | MP_ARG_INT, {}},
{MP_QSTR_radius, MP_ARG_REQUIRED | MP_ARG_INT, {}},
{MP_QSTR_value, MP_ARG_REQUIRED | MP_ARG_INT, {}},
};
with empty {} as the default value. Maybe that is better than removing it altogether?
tulip sleet
it has to do with -Wno-missing-field-initializers, maybe, though I don't see that added for non-unix ports. Still looking.
tulip sleet
The error seems specific to the unix port. I see the same locally attempting to ...
what version of gcc are you using for the Unix build locally? I think it would just be gcc --version
lone axle
what version of gcc are you using for the Unix build locally? I think it would j...
gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
tulip sleet
me too
@lone axle there is no explicit setting or unsetting of missing-field-initializers that would affect this that I can find.
simple test program:
typedef struct {
int a;
int b;
int c;
} s_t;
s_t f(void) {
s_t s = { 1,2 };
return s;
}
gcc -Wall -Wmissing-field-initializers -c init.c
arm-none-eabi-gcc -Wall -Wmissing-field-initializers -c init.c
both produce the error, so it doesn't seem to be the compilers. It may be different versions of the C standard being chosen. At some point C started automatically zero-initializing unspecified fields.
I will spend a little time on this to understand it.
tulip sleet
@lone axle this is because of -Wextra, present only on the Unix port compiles, which turns on some extra warnings. Why we have that I don't know, and will investigate further.
tulip sleet
@lone axle I'll make the release for esp32spi unless you did already
lone axle
You can go ahead. I haven't
ebon horizon
@tulip sleet It'll be a day or two before I can test.
tulip sleet
<@329766224093249548> It'll be a day or two before I can test.
thanks in any case
tiny peak
@slender iron I've been tentatively considering improving the implementation coverage for hashlib.sha1 (e.g. already implemented for esp32s3 but not nrf52840) as part of a TOTP token project. It would also be kinda nice to have hashlib.sha256. To get this working on nrf52480 (no existing mbedTLS), I'm thinking it might make sense to use the relevant implementations from a lightweight embedded crypto library (perhaps BearSSL). If I went that far, I wonder if it would make sense to consider doing it in a way that would help with the crypto primitives you need for CircuitMatter (sha1, sha225, ecdsa NIST256p, ecdsa ECDH, AESCCM, etc.). Do you have any plans for how you want to add the crypto stuff for running CircuitMatter on non-unix ports?
slender iron
<@252717193496756235> I've been tentatively considering improving the implementa...
Look at what Zephyr uses
The nordic port will be moving more towards zephyr
though esp will switch later
tiny peak
so is your plan basically to move everything to Zephyr? I've been thinking about a relatively near-term thing. Like, I've got a project working now on a CLUE board with a pure python sha1 implementation, but it takes about 2 seconds to do a sha1.
slender iron
I expect nordic to be one of the first ports to move
tiny peak
I've got another thing that does hmac-sha1 on esp32s3 (c for sha1, python for hmac), and that's so fast already that it's not worth my trouble to mess with
slender iron
since I'm doing support for the newer chips with zephyr
tiny peak
hmm... okay, so my takeaway from that is that adding a BearSSL dependency would be somewhat at odds with what you have in mind, so probably not a great option then.
tiny peak
ok. thanks. I'll see what I can find in the zephyr source.
seems like maybe they use PSA Crypto which is backed by mbedTLS and potentially soc-specific hardware accelerator stuff
there's also some mention of TinyCrypt and kconfig/cmake-configurable crypto backends, but I think that may be older and the new thing is to try to do stuff with the PSA api
lone sandalBOT
manic glacierBOT
minor wing
Hey All, just looking for a reply to my earlier post: https://discordapp.com/channels/327254708534116352/327298996332658690/1444198746488307742 Thanks!
slender iron
Hey All, just looking for a reply to my earlier post: https://discordapp.com/cha...
yes, follow the guide for building
minor wing
yes, follow the guide for building
TY, and I will do that!
lone sandalBOT
slender iron
@tulip sleet how's the esp32spi native work going?
tulip sleet
SPI communication is working (can retrieve version, etc.). I just converted over the scanning code. Getting that to compile now.
it's still the case this code is going to about 10kB or so, and will not fit on SAMD51x19 without us trimming something else out. I am thinking we should write a Python wifi/socketpool/ssl wrapper to substitute for adafruit_esp32spi for such boards
fits fine of course on PyPortal with SAMD51J20
tulip sleet
phone call...
slender iron
what has the SAMD51x19 and a coprocessor?
tulip sleet
metro m4 airlift lite + anyone who uses an AirLift co-processor board like a FeatherWing etc.
we don't HAVE to write this library, but if we do, then it's a largely uniform experience across all the boards, and we drop adafruit_esp32spi in the long run
only diff from regular native import wifi is that you have to specify the pins if needed
so I have an extra airlift_init() routine for that.
(on hold on the phone at the moment)
slender iron
we can see where we're at once the native is done
I think the external airlift board is going to be diminishing returns
tulip sleet
the size is essentially the same if I were to do native adafruit_esp32spi, so that seemed like kind of a waste of time, since it doesn't add an value really (speed is not an issue), and would only fit on pyportal and similar
we already discussed that
slender iron
right
tulip sleet
I'd also like to talk to you about BLE HID seeming to conflict with workflow issues and also maybe bablokb's notes about slower 10.x.x performance when using SD cards
could do video now; phone call done
slender iron
I'm around all day except lunchtime
tulip sleet
now ok?
slender iron
yup
lone sandalBOT
manic glacierBOT
manic glacierBOT
slender iron
<@&356864093652516868> We'll be meeting in just over an hour. I'm excited to chat with you all! Notes doc is here: https://docs.google.com/document/d/1_O2owjB7PZ_xTvg7pxIdX81GBGeHt_-u9CGx5fn2IP4/edit?tab=t.0
tiny peak
Scott, did you happen to see my hashlib PR?
tiny peak
one thing I wasn't sure about was turning it on for boards other than CLUE. I happen to be using that one at the moment, but it seems potentially relevant for other stuff.
tulip sleet
one thing I wasn't sure about was turning it on for boards other than CLUE. I ha...
I would say turn it on for everything that enables hashlib and see if it fits.
tiny peak
oh wow, yikes
slender iron
yes, hashlib shouldn't change shape across ports
tiny peak
so what about enabling the sha256 option?
Like, there was an existing CIRCUITPY_HASHLIB option which I just turned on for CLUE. But, then I also added a CIRCUITPY_HASHLIB_256 and turned that on too.
slender iron
I don't have the context to discuss this yet. Let's discuss it on the PR
tiny peak
sounds good
tiny peak
+1 for a settings.toml option to turn off the boot delay. That would save battery for sensors that do a lot of deep sleep.
slender iron
boot delays are skipped when waking from deep sleep. However if you do the sleep externally it could help.
wraith crow
Thanks everyone 😁
lone axle
Thanks for hosting Scott. Have a great week everyone 👋
tulip sleet
Thanks Scott!
slender iron
Here is the notes document for next Monday’s CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1HoEfxmPuua_fsRhUIkSPLZ6aGZnY1cEgfWfj-oe2_js/edit?usp=sharing
tiny peak
@tulip sleet Currently working on your requested documentation change. Is there a guide somewhere that describes the normal procedure for building docs locally. Scanned through the Building CircuitPython guide but didn't find any obvious mention of it.
slender iron
you can make html in the repo root
tulip sleet
<@329766224093249548> Currently working on your requested documentation change. ...
remove the three spaces before "algorithm":
//| def new(name: str, data: bytes = b"") -> hashlib.Hash:
//| """Returns a Hash object setup for the named algorithm. Raises ValueError when the named
//| algorithm is unsupported.
@tulip sleet here is a small PR waiting for you: https://github.com/adafruit/circuitpython/pull/10719
slender iron
@tulip sleet when you are around, can we talk about supporting two different SPI types interenally?
tulip sleet
<@329766224093249548> when you are around, can we talk about supporting two diff...
i can talk now
orchid basinBOT
orchid basinBOT
orchid basinBOT
manic glacierBOT
manic glacierBOT
orchid basinBOT
manic glacierBOT
tiny peak
Is there an existing plan or checklist for what should be added to core to enable porting CircuitMatter to boards instead of just Raspberry Pi? I'm thinking of:
- Which boards have the right kind of radio -> what vendor SDKs (ESP-IDF and ???) would be relevant to those boards -> how do those SDKs handle hardware TRNG access -> because PSA Crypto needs a hardware entropy source as part of initialization
- What should the module namespacing look like for providing things that CircuitMatter currently gets from importing ecdsa, cryptography.hazmat.primitives.ciphers.aead, ecdsa.curves, ecdsa.ellipticcurve, etc. Would it make sense to just dump all the relevant stuff in a new psa_crypto module or something? (I am assuming that matching the CPython API of the aforementioned modules would involve adding way too much irrelevant code beyond what CircuitMatter needs)
tulip sleet
Is there an existing plan or checklist for what should be added to core to enabl...
There is a branch where I was just trying to get it working in CircuitPython: https://github.com/adafruit/CircuitMatter/tree/circuitpython. I think this branch is not up to date: I have some uncommitted changes. I have multiple clones locally and am not sure which is the most up to date.
This was a "just get it working" effort, which made up some substitutes for various third-party modules and included just enough code to get things working. I got a light bulb to blink. There were issues about doing secure-enough key generation. Because of a security flaw in some encryption scheme (I can reconstruct the details but don't have it at the front of my head), it is necessary to run some aspect of key generation like 100k times to make it sufficiently safe. On a CircuitPython board this could take hours. One solution is don't bother to be so secure, and the other is to run the key generation on a faster computer and copy it over.
When I put the CircuitPython part of this work on hold, we were still thinking about how to move forward with zephyr, etc., and what crypto stuff should really be in C, complicated by what kind of hw support there is on which chips for crypto.
it was not urgent and there were other things to do. There were also complications about which of the major Matter-supporting platforms allowed uncertified devices access.
there were not that many Matter devices available. We thought our focus might be more on building Matter-compatible devices rather than controlling Matter-compatible devices
but we didn't know. And the market momentum of Matter was not clear (and still isn't, though IKEA's new product line is a good push).
tiny peak
hmm... I'm kinda interested in it as a potential extension of the LoRa sensor monitoring stuff I've been doing
tulip sleet
It is a big somewhat messy thing, not as bad a BLE, but still large.
tiny peak
Like, I cobbled together a system that works fine with my own homebrewed MAC layer and LoRa or ESP-NOW for transport, plus some IRC and web. But, that's all kinda weird and outside the phone ecosystem
Wondering if CircuitMatter with Apple Home app integration or whatever might make for convenient sensor monitoring and control panel stuff
plus automated light controls, etc.
tulip sleet
is MQTT a good base for your stuff. Monitoring vs device control (light bulbs, etc.) are kind of two different directions
I think you could do what you want without all the Matter infrastructure.
we have done some Home Assistant stuff
tiny peak
The unifying angle for me is having little notification and status gizmos (that look respectable) scattered around living and work spaces. I'm not worried about data collection. Thinking more about little mini-dashboard/status-light/control panel gizmos
tulip sleet
and Adafruit IO and Wippersnapper are all about monitoring
tiny peak
Yeah... I'm inclined more toward locally hosted stuff
tulip sleet
Wippersnapper will also do output stuff, not just monitoring
tiny peak
(allergic to subscription plans, etc)
slender iron
We were targeting wifi for CircuitMatter first
once we have that, we could look at thread
tulip sleet
wippersnapper has some offline capability. Might be worth discussing your requirements in #help-with-wippersnapper-and-adafruitio
slender iron
I don't know of matter over lora. Matter is built on top of ipv6 generally
tulip sleet
a local MQTT server might serve well, with some kidn of lora gateway
slender iron
I think the main project for local control is home assistant
tiny peak
Context for why I mention the stuff above is mainly to motivate the idea that I'm potentially interested in investing a bit of dev time to move the CircuitMatter stuff forward -- at least far enough to see if it would meet my needs. I don't think AIO or Wippersnapper would be a good fit for me.
At the moment I'm more specifically interested in the angle of integrating collected sensor data (which I already have) with home automation stuff (ambient status displays & light controls). I've evaluated Home Assistant, and I don't much like it. Wondering if CircuitMatter would be better.
manic glacierBOT
tiny peak
All that is to say, if you had some wishlist issues for stuff you'd like done to support porting CircuitMatter, maybe I could implement some of them
If it's too soon, that's fine too.
tulip sleet
I would say Matter and Home Assistant exist at different levels in the functionality stack. Matter has multiple transports and specifies how controllers and devices define themselves and talk to each. I don't know a lot but I see it as similar to BLE service/characteristic/etc. definitions
BLE kinda mixes up the transport level and architeture level.
tiny peak
The angle that intrigues me is that it's got some integration with Apple's ecosystem
Like, if I could tie my sensor system into apple's notification system on my mac and phone, that would be potentially interesting.
same for being able to control lights at my workstation
particularly if I could do it all in a way that didn't have any network dependencies outside my home LAN
I'd be willing to invest some dev time to see if those sorts of things are possible (unless you already know they're obviously not)
tulip sleet
There is no reference-y impl of Matter in Python (there is kind of one for JavaScript, if I remember right). Scott was kinda doing that (but he can speak for himself if this is a mischaracterization), tackling both the device/service definition and the basics to get communication working. I then took that and tried to replace the big cryptography libraries with something that would fit in CircuitPython. That's as far as it got.
It is a lot of code, and the next step might be to see how to get the crypto stuff to be more efficient. But right now it is a thin vertical existence proof.
we have no planning docs or anything olike that
for your practical purposes, I'd say look at stuff that's more mature and that has the Apple Notificiation stuff you want (we have some BLE support for that, and maybe there is also stuff in Home Assistant or something you can hang off a local MQTT server)
tiny peak
okay, so looking at if from a slightly different angle... are you relatively sure that a CircuitMatter implementation of some sort is a thing that you want? (sure enough to justify some potentially failed experiments in attempting to get it to work?)
I'm less concerned about having a thing that works now than I am with having a project that would be cool to write about
tulip sleet
it's a goal, medium-long term. If Matter died on the vine then it wouldn't be.
tiny peak
okay. that helps
what about plans for the appropriate sort of namespacing for better core crypto support on CircuitPython boards? Like, Matter aside, do you know where you'd like ecdsa stuff to live? Would it be better not to mess with such things until the Zephyr ports are further along?
Basically, I'm wondering if this is the wrong time to pursue this stuff as an active project. Perhaps I should just put it on the list of stuff to keep an eye on for later
tulip sleet
I pushed my latest changes; I don't remember exactly what was going on then.
we haven't decided about ecdsa, etc. I was just trying to prune the code enough to get it to fit and just (barely) work.
I think it's premature, yes, and right now we don't have time to do much direction-setting on this. It would be a few months at least, I think.
slender iron
@tiny peak if you want to experiment with circuitmatter then start on desktop cpython
don't require a bunch of pre-work to get into it
tulip sleet
look at the blink.py and cpblink.py examples in main and the circuitpython branch in the repo
tulip sleet
@slender iron do you know of a single C call I can make that will do the equivalent of str(some_object), where some_object has a print routine? It looks like I could use an mp_print_t and a vstr, mp_printf() into the vstr mp_print_t and then convert it to a str, but I thought there might be a single call. I can't find one, which seems a bit weird.
slender iron
I can't think of one off the top of my head either
tulip sleet
thanks - I was stymied 🤷
slender iron
I think mp_printf trick is the way to go
tiny peak
tannewt & danh, thanks for the context on CircuitMatter. Sounds like the thing for me to do is wait and maybe poke at the CPython stuff.
manic glacierBOT
manic glacierBOT
tulip sleet
@jaunty juniper interesting thing I discovered about NINA-FW while working on AirLift wifi. A few years ago a bunch of low-level socket operations were added, here: https://github.com/arduino/nina-fw/pull/81. It's hard to find any public code that uses this, except maybe for https://github.com/gershnik/BetterWiFiNINA, which didn't know about before a few minutes ago.
Your additions to adfruit_esp32spi didn't assume these (rightly so), and I don't know whether there are any bugs.
tulip sleet
may try your Python code, converted to C first, or may try the socket ops
crimson ferry
the NINA BSD sockets API looks nice, and it has select/poll which could help with async on Airlift
orchid basinBOT
manic glacierBOT
tulip sleet
@slender iron may be obvious, but some schemes for doing namespaces in C: https://stackoverflow.com/questions/389827/namespaces-in-c
manic glacierBOT
manic glacierBOT
nimble sparrow
Now that we have stdin injection for USB keyboards for e.g. Fruit Jam, is there a world in which we expand that functionality more generically? I'm playing with the Tanmatsu (https://docs.tanmatsu.cloud) right now with an early working CP build, and I've played with the Lilygo T-Deck in the past. Both have built-in keyboards via I2C daughterboards (in the Tanmatsu's case, @indigo wedge's beautiful keeb), and at the moment the most you can do for either is simulate a REPL by grabbing keypresses and running exec etc. on the input on a carriage return.
lone axle
Now that we have stdin injection for USB keyboards for e.g. Fruit Jam, is there ...
I think the M5 cardputer also has the stdin key injection. It looks like it's using a matrix instead of I2C board, but I think something similar could be possible to implement for the I2C keyboards. https://github.com/adafruit/circuitpython/blob/main/ports/espressif/module/cardputer_keyboard.c Most of it happens in here. There have been some changes and refactoring to it over time, if you search PRs for cardputer, or check git history you could see the evolution of functionality for that device which could be good place to start from for adding similar support to other devices.
nimble sparrow
Thanks, great minds - I just started poking around at how the cardputer does it!
nimble sparrow
I think the M5 cardputer also has the stdin key injection. It looks like it's us...
So the principal issue I'm running in to is the contention this creates between the I2C bus exposed in REPL and the need for any code that monitors and injects into stdin (a la cardputer and keypad) to also access the I2C bus to do so. I can't find a graceful way to arbitrate between the two (a la try/lock when it's two accesses in contention fully in REPL).
urban silo
Hi! I'm trying to get CircuitPython to work as an app, started from a launcher firmware on my ESP32-P4 board. The whole launcher part works and can start CircuitPython as an app without problems 🙂
But... there is one tiny issue: my other firmware expects that the FAT partition uses the wearleveling API provided by ESP-IDF. CircuitPython appears to not use said API and thus overwrites the FAT with wearleveling with its own filesystem on boot. I've solved that for now by patching internal_flash.c to use the inactive OTA slot as the FAT partition.
Instead of this workaround I would like for CircuitPython to be able to mount the FAT with wear leveling. Before I even look into implementing such a thing, what is the stance of the devs here on such a thing and are there things I should know?
tulip sleet
Hi! I'm trying to get CircuitPython to work as an app, started from a launcher f...
The wear-leveling code is not included in the CircuitPython build. The FAT implementation, shared across all ports, is in lib/oofatfs. The lowest-level ESP-IDF actual flash r/w calls are in ports/espressif/supervisor/internal_flash.c. Note that "internal" here is a misnomer, due to how ESP-IDF is structured. Dependin on how the ESP-IDF wear-leveling is structured, that may or may not be the place to add it.
In general, we have essentially no reports of people wearing out flash that might require wear-leveling. But for people who want to do a lot of flash writes, they often end up using an SD card.
MicroPython has switched to using LittleFS in many cases, but it's not available via USB MSC.
What is your higher-level goal here?
urban silo
What is your higher-level goal here?
Integration with the rest of the ecosystem, CircuitPython is one of the apps a user can run, but for example a NES emulator app could use the same FAT partition to store its roms. Apps on the platform can be of two types: main type is just separate firmware that gets started through some bootloader modifications we made which allow starting firmwares from a special flash partition (based on sprites work for the pocketsprite (can be found here if you're curious: https://github.com/badgeteam/esp32-component-appfs). The second type is ELF applets which get started on top of the launcher firmware and can thus hook into the existing library code the launcher itself uses.
We will eventually want to start CircuitPython with an argument string stored in the LP RAM, this will allow a user to select a Python script from the launcher to start it, as an alternative form of apps for the device. When started without a script filename we want to drop to REPL on the on-device screen and keyboard so that people can play with Python on-the-go.
Best case would be if we can integrate all of this in upstream CircuitPython, which is why we will try to keep as much of the required changes as possible within the confines of the board folder
Another fun challenge is the internal I2C bus, we plan on adding our existing C drivers for the peripherals on said bus to the board folder with Python bindings on top to allow for proper semaphore locking on bus access and such, so that we can have regular interrupt handler tasks in FreeRTOS running.
(And a slightly modified ball demo running as python script)
tulip sleet
CircuitPython does a tricky thing, which is that the MBR is not actually written to flash -- it's always the same, so we simulate it. See supervisor/shared/flash.c. This might or might not be one of the problems.
flash_read_blocks()
this might be part of the issue you are seeing, but I'm not sure.
urban silo
As the inactive-ota-partitinon approach seems to work well enough to allow for at least temporary filesystem retention between system updates a potential solution could also be to just mount the other filesystem in a subfolder, like with SD cards
tulip sleet
in the longer run, we are working on a zephyr port to achieve some commonality for a lot of lower level things, like maybe flash management
and definitely BLE and network stacks
i agree that just keeping our filesystem separate is the easiest solution for now
urban silo
Ah yes, I was about to mention that bit too: as the P4 doesn't have a radio built-in we have to use esp-hosted-mcu and a separate ESP32-C6 via SDIO for network.
tulip sleet
since it's your board, you can configure the flash partitions however you want
urban silo
That esp-hosted stuff has been giving me headaches for a while now, I'm at the point I'm separating out all the low-level SDIO stuff and doing version checks before continuing just to avoid crashing on every single tiny thing
urban silo
since it's your board, you can configure the flash partitions however you want
Fair enough 🙂
Then I guess I will go with the mount-in-subfolder approach
I do wonder how difficult it would be to integrate by just mounting with the standard ESP-IDF functions. They do map to the POSIX file calls so without having looked into the custom filesystem stuff of CircuitPython I assume that should just work? 😄
tulip sleet
assuming we make a P4 board it may or may not use the ESP-IDF firmware for a C6 co-processor. We also have a variant of NINA-FW which we've used in the past. In the past we talked to the co-processor with the adafruit_esp32spi library. At this very moment I am working on a native-C wifi/socketpool/ssl implementation that uses the NINA-FW protocol underneath. But we are also considering the ESP-IDF co-processor firmware.
The filesystem mounting code is done at the FAT block level. See the sdcardio and sdioio impls, and also adafruit_sdcard. You provide readblocks and writeblocks. The FAT stuff is done with the existing FAT code.
it is not done at the POSIX system call level
though internally there are "protocols" for doing that between different kinds of filesystems (that's how LittleFS vs FAT is supported, for instance).
urban silo
Oh, that complicates stuff by a lot actually... I assumed it would be the same as MicroPython in just using POSIX calls.. oh well, new challenge 🙂
tulip sleet
We don't have LittleFS built in to CircuitPython, but since it comes from MicroPython, there is latent support, though we have removed a bunch of sources.
that is how MicroPython does it too for block filesystems
at the Python level
I am not that familiar with how to support other than FAT, as I haven't had to do it yet.
urban silo
We're not using LittleFS, but FAT with the Espressif WL library below it
jaunty juniper
I'm curious, what does the ESP-IDF fat wear leveling API do ? Is it a standard FAT variant ? Does it do stuff on top of a standard FAT partition ? Is such a partition mountable on a PC ?
tulip sleet
yeah, does it remap the block addresses?
urban silo
Ah, seems we can just use wl_read and wl_write API calls to allow the standard FAT library to use the flash as if it doesn't have WL
urban silo
I'm curious, what does the ESP-IDF fat wear leveling API do ? Is it a standard F...
It stores pending writes in a RAM buffer or a (for the FS itself) empty flash sector (depending on configuration) to lower the amount of erases needed
nimble sparrow
assuming we make a P4 board it may or may not use the ESP-IDF firmware for a C6 ...
Just so I'm clear, this is on an esp32c6 or some other daughter board?
tulip sleet
Just so I'm clear, this is on an esp32c6 or some other daughter board?
P4 would use a C6 as a WiFi co-processor. Could be on the same board or could be separate.
nimble sparrow
Ah I see, this is for a new board design then?
I thought you meant you were working on a generic new firmware we could use on the C6 on any of these various P4+C6 combo boards
(Tab5, Tanmatsu, Waveshare various, EV)
tulip sleet
I thought you meant you were working on a generic new firmware we could use on t...
NINA-FW for the C6 is already done, and is used on the C6 on the Fruit Jam board.
nimble sparrow
Ahhh, I wonder if we can reuse it
tulip sleet
ESP-IDF supplies several co-processor firmware options, in which they do remote API calls to the C6 from the network stack on the P4 (or other Espressif chip).
They don't use NINA-FW: that takes a different approach with the network stack on the co-processor. NINA-FW origin is much older: from Arduino WiFi shields
https://developer.espressif.com/blog/2025/09/esp-wifi-remote/ is some info from Espressif about co-processor support
they have multiple ways
nimble sparrow
They don't use NINA-FW: that takes a different approach with the network stack o...
Yes indeed, but in this instance we have CP up and running happily on a P4 too
tulip sleet
Yes indeed, but in this instance we have CP up and running happily on a P4 too
We have not tried the non-NINA-FW C6 options from ESP-IDF, but we will at some point. If your board has a C6, you could load the latest NINA-FW and use adafruit_esp32spi now, and when I finish the wifi/socketpool/ssl impl, that will be available with NINA-FW as well.
are you on the same project with Renze or different?
lone sandalBOT
slender iron
@urban silo We'd merge a PR to add the ability to read and write via wear leveling as long as it is behind a flag so boards can opt in.
We already have a way to set which python file to run next too.
lone axle
<@&356864093652516868> the weekly meeting will occur here on discord about 30 minutes from now at 2pm Eastern / 11am Pacific. Add you hug reports and notes to the doc here if you wish to participate https://docs.google.com/document/d/1HoEfxmPuua_fsRhUIkSPLZ6aGZnY1cEgfWfj-oe2_js/edit?usp=sharing. We look forward to seeing folks there.
slender iron
I don't hear Dan either
slender iron
Thanks for the meeting!
lone axle
Thanks everyone, have a great week!
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/1c7VlX4wGl_jU02L7U-7uzNU-X_5s_TJavYiEm-u4RIw/edit?usp=sharing
urban silo
ESP-IDF supplies several co-processor firmware options, in which they do remote ...
This is the main firmware Espressif is focussing on for the ESP32-P4+ESP32-XX as radio combination: https://github.com/espressif/esp-hosted-mcu.
I'd highly recommend circuitpython adds support for that firmware via sdio as it provides much higher data throughput than SPI connection
urban silo
are you on the same project with Renze or different?
Same project, Tanmatsu 🙂
urban silo
<@260113040546988032> We'd merge a PR to add the ability to read and write via w...
Cool! In that case I will add it to my to-do list 🙂
urban silo
https://github.com/micropython/micropython/releases/tag/v1.27.0
Ah, nice they finally added P4 support, cool!
solar whale
@danh a user has submitted a very helpful PR for the adafruit_rfm9x library. I have tested it and it works fine. I don't think it will add many bytes (if any) to the code -- Is it OK to goahead and merge it? I would then like to implement the chamge for the rfm69 library and the rfm combined libraries if that sounds ok. It should help eliminate some packet loss.
@tulip sleet hmm tried to tag you above, but I must have done something wrong 👆
tulip sleet
@danh a user has submitted a very helpful PR for the adafruit_rfm9x library. I h...
That sounds fine, but you might not have privs to make a new release?
solar whale
That sounds fine, but you might not have privs to make a new release?
I used to, but lately, I have just done the merge and let Tim do the release when he gets to it.
tulip sleet
go ahead and merge and I'll make a release. Is there an API difference, or is it basically a "bug" fix?
then you don't have to wait to test the new release
solar whale
No API change -- just an improvement
solar whale
I think it "does no harm" so I am comfortable with it. -- Go right ahead!
solar whale
I implment it for rfm69 and rfm in the next day or so.
tulip sleet
we really appreciate your work on the RFM libraries!
solar whale
Thank you! I doubt any users aother than the author will ever know, but it is a good idea.
solar whale
we really appreciate your work on the RFM libraries!
Thanks -- It's nice to keep involved.
wraith crow
@slender iron I've been working on refactoring and switching my "native" USB host PR to using the CIRCUITPY_USB_HOST/DEVICE_INSTANCE parameters rather than inferring the instance from the CIRCUITPY_USB_HOST/DEVICE (enabled) parameters as you had suggested. It's been slow going as I've forgotten how everything held together but I think I'm back to the point where I have to dig into tiny_usb to figure out why the CIRCUITPY startup is sometimes hanging after the Serial console setup message. Before I did that though I wanted to run an issue by you. Since the CIRCUITPY...INSTANCE parameters are defined as macros in header files and ports/raspberrypi/mpconfigport.h defines a value for CIRCUITPY_USB_HOST_INSTANCE, I had to perform an #undef in the board/mpconfigboard.h file before setting the custom value for the board I'm testing. I don't think I've seen this before so I wanted to see if I've made a wrong turn somewhere along the way. I assumed that you hadn't intended for me to convert the header macro parameters to .mk file parameters so they could be more easily redefined by the board files?
slender iron
I ran into a similar issue recently too
where the port can't set a default value that boards can override
I think we may need to reorder the header includes...
I'd say just change the port value for now
wraith crow
If we're just looking at a short term solution is the #undef an option?
Would setting the USB_HOST_INSTANCE as a port default mess up all the boards that have attached USB A ports wired to pins?
re-reading your response.... when you say just change the port value, did you mean go ahead and change the value using the undef or did you mean change the default value for the port being set in ports/raspberrypi/mpconfigport.h. (I'm thinking you probably meant the undef is fine for now...)
orchid basinBOT
orchid basinBOT
manic glacierBOT
slender iron
re-reading your response.... when you say just change the port value, did you me...
undef is fine. that can actually be committed
slender iron
@tulip sleet my zephyr spi PR is waiting for your review.
tulip sleet
<@329766224093249548> my zephyr spi PR is waiting for your review.
Ah, sorry! I reviewed a lot of it before you requested a review and then I forgot to go back.
slender iron
Thank you! @tulip sleet
solar whale
@tulip sleet Thanks for the merges!
manic glacierBOT
orchid basinBOT
manic glacierBOT
orchid basinBOT
orchid basinBOT
orchid basinBOT
lone axle
If anyone gets a moment I could use a review on: https://github.com/circuitpython/CircuitPython_Library_Screenshot_Maker/pull/33 it's in cp org and can't have the nomal librarians group request review. It updates the screenshot utility to include SVG and HTML project files in the screenshot.
orchid basinBOT
orchid basinBOT
orchid basinBOT
lone sandalBOT
orchid basinBOT
tiny peak
Question on where to file audio issues... In the course of doing a Morse code with sinewave synth thing on Fruit Jam, I've found some fairly annoying audio artifacts. Acoustically, they all happen together with the same reproducer code, but I think there are likely two different things going on:
- Strong clicks on synthio note attack and release: these sound like they have a good chance of relating to the synthio vca envelope or perhaps waveform interpolation calculations
- Aliasing and harmonics that get drastically worse as you decrease the sample rate from 48000 or 44100 down to 22050 or 11025. This sounds to me like there may be a need to adjust the TLV320DAC built in filters to match the sample rate (ensure nothing above nyquist frequency gets sent out the DAC). But, it's also plausible this might relate to synthio waveform interpolation code.
So, should I file a circuitpython issue for the synthio thing and an Adafruit_CircuitPython_TLV320 issue for the sample rate thing? Something else?
I'm also not sure if the attack/release clicks are a general synthio thing or if they are specific to the TLV320. I don't have any other DAC breakouts to compare it to.
tulip sleet
I'm also not sure if the attack/release clicks are a general synthio thing or if...
are you shutting down the software mixer between waveform events? The mixer should keep running during that time. Not sure about the aliasing
what kind of waveform are you generating?
tiny peak
Reproducer code is here: https://github.com/samblenny/synthio-click-reproducer/blob/main/code.py
Not currently using an audiomixer. Tried that according to todbot's tricks page but it didn't seem to make any audible difference.
I'm doing a variation on todbot's numpy sinewave thing, so the starting phase in particular ought to be pretty good, I'd think.
if you scroll back slightly in the #help-with-circuitpython channel, I posted a couple wav files demonstrating how the clicks sound and how I think the note attacks and releases ought to sound (lowpass filtered with sox).
tulip sleet
Reproducer code is here: https://github.com/samblenny/synthio-click-reproducer/b...
are you familiar with the terminology of "key clicks" in ham radio CW (Morse)?
there is no ramp-up or down with your sine wave waveform, so it's going to generate energy away from the tone frequency
tiny peak
I've seen that mentioned, but I'm not super up on the details. The thing that bugs me about this is that setting a vca envelope on the synthesizer doesn't seem to reduce the clicking
tulip sleet
if you look at the spectrum of your first sample in, say, Audacity, you can see this:
tiny peak
If I set 30 ms attack an release times, I would expect that to substantially reduce the clicking, but that does not seem to be the case.
tulip sleet
could you post the .wav from that?
it's bad form in ham radio to have "hard" keying, with abrupt off/on transitions. It makes for a lot of noise outside of the narrow bandwidth of the CW (Morse) waveform
tiny peak
I think the one in the help channel ought to be downloadable? It's pretty similar to what's in the reproducer. I've been working on getting set up with a waveform recorder that I'm reasonably confident won't be applying any filtering, but I'm not there yet. (earlier recording made with macos voice recorder... unsure if it did any processing)
tulip sleet
<@&356864093652516868> Weekly discord meeting is in a little more than 2.5 hours, at 2pm US ET / 11 am US PT. You are welcome to add notes even if you will not be present. https://docs.google.com/document/d/1c7VlX4wGl_jU02L7U-7uzNU-X_5s_TJavYiEm-u4RIw/edit?usp=sharing
wraith crow
The original cardputer board definition didn't support the keyboard in the core either, it was added later
Thanks everyone, happy holidays!!!!
lone axle
Thanks for hosting Dan. Havea great week and happy holidays / new year everyone!
tulip sleet
meeting video posting may be delayed for an hour or two
I'd like to take a walk before it gets dark
thorny jay
The original cardputer board definition didn't support the keyboard in the core ...
Exactly my point, cardputer support improved slowly, first keyboard was in python only, then it was added in core (making it usable for REPL).
To me it is the portable equivalent to FruitJam, a CircuitPython computer.
I am almost sure I would not be efficient at trying to add TCA8418 in the firmware.
slender iron
Exactly my point, cardputer support improved slowly, first keyboard was in pytho...
An LLM will likely be a huge help if you want to point it to the TCA python driver and have it write C for you.
nimble sparrow
Exactly my point, cardputer support improved slowly, first keyboard was in pytho...
That's the theory behind getting a Tanmatsu board def going (including keyboard), proper mobile REPL
tulip sleet
Here is the notes document for the next CircuitPython Weekly Meeting, on Monday, January 5, 2026. We're skipping a week due to the holidays. 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/1XDA3jYN0RWPMOXHo9Wtmsd1KYxSTTbVQ3n7NBdcDr60/edit?usp=sharing
turbid radish
Anyone want to help with pacman on the Adafruit Fruit Jam? I have a port from the Wio version running (with issues I could use help on) https://github.com/TheKitty/pac-fruitjam
uncut nexus
@slender iron Hi Scott! I've built the Zephyr CP for a FRDM-MCXN947 board. I did not find any instructions on how to flash it, so I used the NXP linkserver binary on Windows. It worked; but is there a better way (esp. for use on Linux)?
lone axle
Anyone want to help with pacman on the Adafruit Fruit Jam? I have a port from th...
I took a look at this code and submitted a PR to your repo that speeds up the main game loop. Some of the ghosts behavior still needs some work, they seem to get stuck in corners sometimes. I can try to look into that as well but will probably be after xmas.
slender iron
<@252717193496756235> Hi Scott! I've built the Zephyr CP for a FRDM-MCXN947 bo...
I do make BOARD=foo flash and it'll use west to do the flash
which for that will use linkserver by default. The per-board zephyr instructions are pretty good
slender iron
@potent hound why are you interested in switching?
potent hound
<@746392996467179661> why are you interested in switching?
Well I kinda picked micropython over circuitpython on a coin flip. But now I have a much more robust filesystem setup and reading through the cp docs, I really like how you have all the compatible modules all packed up per-board.
slender iron
I'd definitely want to get the circuitpy drive working well with it
potent hound
And you have a Jumperless now so I can ask you how I should structure things in a non-stupid way.
potent hound
the probe is what sold me
Fair, but when you get it, try it out with Viper IDE, it's pretty sick. And you can probe at the same time
slender iron
we don't have any examples of CP coexisting with a bunch of other code
we assume that it's usually CP VM driven
though we do have a "background task" system to interleave stuff with VM execution
potent hound
Does CP have something like pyexec_event_repl_process_char( c );? I just have a service running in my scheduler that dumps chars from the repl endpoint into that.
slender iron
We may inherit it from MP but I don't know of any uses
potent hound
I think it can be made to work just fine, a lot of it is just my naming conventions for jumperless-specific calls are dumb because I was just trying to get it to work at all and also barely know how to write python
slender iron
much of the pwm ish stuff I'd just want to use our standard APIs
I don't know how the other jumperless stuff is structured
potent hound
much of the pwm ish stuff I'd just want to use our standard APIs
Ha yeah, I didn't have the machine module working when I did that but the regular calls like that work now too (see above)
potent hound
btw if anyone wants to take a look at the code we're talking about
https://github.com/Architeuthis-Flux/JumperlOS
relevant files are MpRemoteService.cpp (the more recent one where I'm actually using MP's built-in raw repl), Python_Proper.cpp (kind of an abomination where I wrote the repl with syntax highlighting and history myself), and then lib/micropython/ for the port stuff and modules/modjumperless.c
slender iron
btw if anyone wants to take a look at the code we're talking about
https://gith...
does it only do repl? Or can you have it run python files stored in flash?
potent hound
does it only do repl? Or can you have it run python files stored in flash?
Oh yeah it can do that. Weirdly, Viper IDE just sends python code the the repl to get the filesystem contents and create / delete files.
slender iron
right. that's common with micropython. thonny does it that way too
CP is a bit different because we'll auto-reload code when written over the usb mass storage connection
(have you tried CP on a board?)
potent hound
(have you tried CP on a board?)
Only a couple times, I guess step 1 is to actually try it, ha
slender iron
make sure you know what you are getting into
🙂
it might make more sense to make a library to control jumperless remotely
then you could do it over ble or web workflows too
slender iron
and if that works really well, then integrate it into all in one
wraith crow
Anyone want to help with pacman on the Adafruit Fruit Jam? I have a port from th...
I'm playing with the controller objects (and adding a keyboard option) and will take a look at refactoring the audio to use the fruitjam library. I've submitted a PR to adafruit_circuitpython_usb_host_descriptors which will allow that library to support gamepads and joysticks. I don't have any usb gamepads to test with and my only Joystick is an old Microsoft force feedback but I'll submit a PR with the updates I come up with and you can have a look 😁
lone sandalBOT
fleet hollow
Anyone want to help with pacman on the Adafruit Fruit Jam? I have a port from th...
Oh lol, I wish I had seen your port first. I worked on this and got it running last night. https://github.com/relic-se/pac-wio/tree/fruit-jam
fleet hollow
I'm playing with the controller objects (and adding a keyboard option) and will ...
Make sure to take a look at the usb_host_gamepad library. It's already working pretty well https://github.com/relic-se/CircuitPython_USB_Host_Gamepad
turbid radish
Thanks @fleet hollow @wraith crow for taking a look - I think it'd be great to have PacMan on Fruit Jam too
fleet hollow
Thanks <@527668354568159232> <@899160869777342464> for taking a look - I think i...
Any concerns about trademark? I could see revising this into a clone of sorts
turbid radish
It can be called something else. I don't think it uses any code from the original
wraith crow
Make sure to take a look at the usb_host_gamepad library. It's already working p...
If I had an SNES to test it would probably be useful but I'm testing with a joystick that the library comes back with as "not recognized". Since PacMan doesn't really use many features of the controller, I think the generic class I added has a chance of working with most analog USB joysticks.
fleet hollow
If I had an SNES to test it would probably be useful but I'm testing with a joys...
If you could share your findings for that device, I'd be happy to update the library to support it.
wraith crow
I'm not real familiar with your library so I don't know exactly what you need. I also don't know a lot about the Microsoft joystick I'm using. It was getting a 13 byte buffer back from the usb reads and I fed a bunch of them into an AI and it told me how to code up a get_direction method that was compatible with the one Anne had in place for the SNES controller class. I also pulled the first three button states off of the 9th byte. The joystick has a directional hat, throttle and z-axis as well as at least 5 other buttons that I ignored and would probably have to be researched if you really wanted to support it.
fleet hollow
I'm not real familiar with your library so I don't know exactly what you need. I...
Could you share the model of the controller, the output of the USB descriptor test on it (from the library example), and your example code if possible. You can add it as an issue here (https://github.com/relic-se/CircuitPython_USB_Host_Gamepad/issues). I'll do the rest of the work of integrating it. I'd love for that library to support as many devices as possible, but I only have so many at my disposal and many of them operate just slightly differently. Thank you!!
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
tulip sleet
<@&356864093652516868> reminder that there is NO meeting today. Meetings will resume next Monday.
hearty lichen
Looking for some CP debugging feedback.
I have mostly esp32s2/3 chips, JLINK looks like a good choice, but I doesn't seem to support these chips - this article seems to indicate that it does - https://learn.adafruit.com/adafruit-metro-esp32-s2/debugging-with-openocd .
Was looking at the ESP-Prog-2 ($15) from Espressif - any feedback about this choice would be welcome.
Thanks crew.
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
orchid basinBOT
manic glacierBOT
slender iron
Looking for some CP debugging feedback.
I have mostly esp32s2/3 chips, JLINK l...
I use ESP_LOG debugging usually. You probably don't need a JLink. The internal USB to serial/jtag is more likely what you want. You'll need to disable CP's use of USB to use it though.
slender iron
#CircuitPython2026 kick off post: https://blog.adafruit.com/2026/01/02/circuitpython2026-kickoff/
tulip sleet
@slender iron still working? have time for a discussion about AirLift heap storage outside VM?
slender iron
<@252717193496756235> still working? have time for a discussion about AirLift he...
yup!
lone sandalBOT
manic glacierBOT
manic glacierBOT
lone sandalBOT
lone sandalBOT
manic glacierBOT
tulip sleet
@slender iron I was wrong about necessity of heap usage when talking to NINA-FW. It's possible to do partial SPI reads and writes and build and parse the messages without doing dynamic allocation. I am reworking the code to do that. So there are no VM vs no-VM heap considerations.
slender iron
<@&356864093652516868> The first community meeting of the year is in just under 20. Here is the notes doc: https://docs.google.com/document/d/1XDA3jYN0RWPMOXHo9Wtmsd1KYxSTTbVQ3n7NBdcDr60/edit?tab=t.0
turbid radish
4☺️
tidal kiln
3.8
turbid radish
Just finished posting the links to that in socialz
The next newsletter will be in inboxes on January 12th
tulip sleet
tidal kiln
^^ they've been on show and tell a lot too. the class looks fun. i'd like to take it 🙂
wraith crow
The problem is that at various times an app can't necessarily update all locations so they may have to be out of sync
turbid radish
Happy New Year everyone
tidal kiln
👋
lone axle
Thanks for hosting Scott. Happy new year everyone 
slender iron
Here is the notes document for next Monday’s CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1Kc6iC6-aOjE3SaAg9BfiK8xVNjm9YW0BBSvjk1jHqU8/edit?usp=sharing
manic glacierBOT
manic glacierBOT
supple plank
Hi, I have some issues building CircuitPython from source. Is this the right place for that?
stuck elbow
yes
supple plank
I followed the manual on https://learn.adafruit.com/building-circuitpython/build-circuitpython
Which more or less boils down to the following steps:
git clone https://github.com/adafruit/circuitpython.git
cd circuitpython/
make fetch-all-submodules
make -C mpy-cross
cd ports/raspberrypi/
make BOARD=raspberry_pi_pico
But then I get a lot of errors like this one:
In file included from ../../py/mpconfig.h:103,
from <stdin>:29:
./mpconfigport.h:9:10: fatal error: hardware/platform_defs.h: No such file or directory
9 | #include "hardware/platform_defs.h"
And indeed, in ports/raspberrypi/mpconfigport.h is #include "hardware/platform_defs.h"
And in the entire CircuitPython tree is no file by that name.
What am I doing wrong? Did I forget to include something?
stuck elbow
did make fetch-all-submodules finish without errors?
you can try running it again
or you can do make fetch-port-submodules in the port's directory
supple plank
I had already done this, but I've ran both again, and both finish without errors. Is the problem with a submodule?
stuck elbow
usually when there are files missing, it's because some submodule failed to be cloned
are you doing this with the main branch?
you could try if you get the same error on a stable branch
supple plank
I've had a few of those, but I could fix them by removing the git repo and the lib directory, and re-running fetch-all-submodules.
I will try again with the latest release version.
stuck elbow
the main branch sometimes gets the exact versions mixed up when there is fresh development with them
supple plank
I've removed the entire circuitpython tree and started fresh again. And this time it build without errors.
Thanks for your help!
Oh, I had to manually install huffman in order to compile mpy_cross. It was not included in the requirements-dev.txt.
slender iron
@supple plank what os are you using?
supple plank
Debian Linux.
serene token
Anyone know exactly where the CircuitPython code is for HSTX/DVI?
tiny peak
for a starting point, look for stuff called picodvi. There's more to it than that, but picodvi will give you some threads to pull on.
if you're using linux and have installed ripgrep (sudo apt install ripgrep), and if you've got an active circuitpython repo with the submodules already fetched, you can do:
$ rg picodvi
from a bash prompt and it will give you tons of stuff about what's spread around where in different files.
some of those locations include:
shared-module/displayio/__init__.hports/raspberrypi/common-hal/picodvi/Framebuffer_RP2350.hports/raspberrypi/common-hal/picodvi/Framebuffer_RP2350.cports/raspberrypi/bindings/picodvi/Framebuffer.cports/raspberrypi/boards/adafruit_fruit_jam/board.c
if you look here:
https://github.com/adafruit/circuitpython/tree/main/ports/raspberrypi
you'll see a submodule reference from the raspberry pi port to the raspberrypi/pico-sdk repo.
If you're logged into GitHub, you can do a text search in the pico-sdk repo (search bar at the top of the github window) for "hstx" to find lots of stuff about code related to hstx:
https://github.com/search?q=repo%3Araspberrypi%2Fpico-sdk hstx&type=code (this link may not work unless you're logged in)
You can also use ripgrep so search the circuitpython repo for "hstx":
$ rg hstx
ports/raspberrypi/common-hal/picodvi/Framebuffer_RP2350.c
36:// This is from: https://github.com/raspberrypi/pico-examples-rp2350/blob/a1/hstx/dvi_out_hstx_encoder/dvi_out_hstx_encoder.c
40:#include "hardware/structs/hstx_ctrl.h"
41:#include "hardware/structs/hstx_fifo.h"
369: uint32_t dma_write_addr = (uint32_t)&hstx_fifo_hw->fifo;
432: hstx_ctrl_hw->expand_tmds =
441: hstx_ctrl_hw->expand_tmds =
450: hstx_ctrl_hw->expand_tmds =
459: hstx_ctrl_hw->expand_tmds =
469: hstx_ctrl_hw->expand_tmds =
493: hstx_ctrl_hw->expand_shift =
501: hstx_ctrl_hw->csr = 0;
502: hstx_ctrl_hw->csr =
532: hstx_ctrl_hw->bit[pins[i]] = lane_data_sel_bits | invert;
@tiny peak Thanks. That should help. Unfortunately I'm currently working in Windows, and I won't have a good Linux system for another couple months, but I'm using MSYS2 and maybe it has ripgrep in its repos. If it doesn't, I'm pretty good with standard grep, and it does have that.
I've seen the HSTX stuff in pico-examples, but it's some form of 8-bit, 640x480 RGB. I've been having a hard time finding HSTX-DVI code for 16-bit 320x240, but I know that's what FruitJamOS is using, so the code for that has to be in there somewhere.
Anyhow, this should help.
tiny peak
many IDEs have some kind of multi-file project search feature. Dunno what MSYS2 is, but I think VS Code has something very much like ripgrep built in, maybe?
Try reading the discussion comments and code diffs mentioned here:
- https://github.com/adafruit/circuitpython/pull/10534 ("fix picodvi refresh rates (use 60Hz)")
- https://github.com/adafruit/circuitpython/issues/10242 ("Metro RP2350 DVI output defaults to 72Hz refresh (capture cards like 60Hz)")
serene token
many IDEs have some kind of multi-file project search feature. Dunno what MSYS2 ...
MSYS2 is essentially a Linux-like environment for Windows. It has a bash shell, common Linux build tools, GCC and so on. It makes coding in Windows bearable. My typical "IDE" is Vim with a Make based build setup, combined with common Linux command line tools like grep and such. So when Linux isn't an option, I use MSYS2 to give me the programming environment I want to work in.
Anyhow, thanks for the additional references!
slender iron
Anyone know exactly where the CircuitPython code is for HSTX/DVI?
Framebuffer_RP2350.c is what you want
runic loom
hi everyone, I have been playing with CircuitPython and TinyML for quite some time now. Today I managed to convert a tiny ML model (CNN) to plain C (onnx2c) code and incorporate it directly as a module in CircuitPython. It's not a generic approach, I mean a model will have to be compiled in with circuitpython source code. Will share my findings soon. Its a tiny CNN that takes 30x30x1 images and outputs 10 probabilities (basically handwritten digit recognition). Will post my code to github soon. I think it opens up a way for people to train their own models in pytorch and tensorflow and bring them to circuitpython
slender iron
hi everyone, I have been playing with CircuitPython and TinyML for quite some ti...
Neat! I'm sure we'd make a blog post with a link to your writeup.
tulip sleet
hi everyone, I have been playing with CircuitPython and TinyML for quite some ti...
Great! How big is the model?
lone sandalBOT
slender iron
@devout jolt @fleet hollow what should the minimum i2s output buffer time be? aka how big can it be before being unresponsive
(I'm working on zephyr i2s)
devout jolt
<@352910176736772096> <@527668354568159232> what should the minimum i2s output b...
in my experience for real-time synths, usually at 22kHz sample rate, a 4kB buffer on audiomixer is about the largest I go before latency becomes frustrating while playing. If doing a music streamer or other less real-time task, particularly if doing Net I/O, I'm sure a larger buffer would be beneficial
slender iron
is that stereo 16bit?
devout jolt
yes
devout jolt
50 msec I think
(at least it feels like ~50 msec, which is actually too big of a lag for most music gear, but I grade on a curve for CirPy 🙂
slender iron
kk, I should be able to do better than that
what are the reasons for that buffer? usb writes?
I am using a zephyr thread to fill the buffer 🙂
should probably add a lock
devout jolt
I am using a zephyr thread to fill the buffer 🙂
Yep, originally because we noticed any USB activity was causing horrendous audio glitches. (the default buffer is very small, like 256 or something). We also found that other supervisor-pausing tasks like display updates could glitch the audio too. So a 2kb to 4kb buffer became pretty standard. Still didn't help with full-screen redraws of big screen or a blocking network read but it helped
slender iron
I'd be curious how the zephyr port fairs. USB and network will be separate threads
screen redraws will be in the CP thread which is different from the audio buffer filling
fleet hollow
<@352910176736772096> <@527668354568159232> what should the minimum i2s output b...
For applications where audio latency isn't as important (ie: games), I sometimes use 8192. Adds a lot of latency, but improves stability.
fleet hollow
50 msec I think
I'm calculating ~10ms. Here's my math, but my understanding of the way things are divvied up might be off:
1024 bytes / 2 bytes per sample (16-bit) = 512 samples
512 samples / 2 channels = 256 samples per channel
256 samples per channel / 22050 samples per second per channel = 0.0116 seconds = 11.6ms
I'd have to double check, but I think the buffer is split between the channels. Would be interesting to do a latency test with a GPIO pin and probe.
blissful pollen