#circuitpython-dev
manic glacierBOT
manic glacierBOT
vernal sage
Just a heads up I think I had the build_memory_info.py wrong for the PSRAM for the C61, should be 32MB and not the 2MB for the board. The C5 branch has it correctly for that variant
tulip sleet
@slender iron I am working on https://github.com/adafruit/circuitpython/issues/10657, which may merit a 10.0.1 in a day or two, since the read/write ability is not what we promised. Also will see if there's anything else worth fixing fast.
slender iron
Just a heads up I think I had the build_memory_info.py wrong for the PSRAM for t...
ok thanks! I'll have you review the PR when it is ready. (I'm out for a week starting tomorrow)
tulip sleet
trouble was if you set the blockdev write operation to MP_OBJ_NULL, nobody is going to be able to write it.
I'll get Tim to review.
slender iron
I can look later today too
fluid hull
I have been meaning to ask this for a while, with regards to bluetooth LE in CircuitPython, I am trying to set some very specific advertising data directly with a byte array and am having the hardest time converting some code that worked fine in arduino using the bluefruit library. Both cases are on an nRF52840 Express Feather.
On the circuitpython side, the low level _BLEIO API mentions anything over 31 bytes automatically becomes extended advertising and the high level adafruit_ble library just says 31 bytes max on advertising data. The trouble I have is that I need to advertise a Complete local name (0x09), a Shortened local name (0x08), a 0x01 flag of 0x06, a tx power level (0x0A), A connection interval range(0x12) and The part that I cannot figure out how to do in circuit python at all a custom complete list of 128bit service class UUIDs (0x07) that is 16 bytes long. for a total of 52 bytes.
I cant even figure out how to set the 0x07 via the library.
On the arduino bluefruit library I was able to set everyting at once win a byte array and used Bluefruit.Advertising.setData(ADV_DATA, sizeof(ADV_DATA)) to set the most of this all at once.
I was still hitting the 31byte size limit so I was able to half bake my solution by excluding the full name
for setting the 0x07 I figure I need to use somthing in the adafruit_ble.advertising.standard portion of the libray but I am starting to get lost in the docs
fluid hull
^ @lone axle or @tulip sleet I'm pretty sure I'm stuck without either of you. In short, is there any way I can set a specific 16 byte (in byte array) advertising packet component of type 0x07 with some equivalent command to arduino bluefruit's Bluefruit.Advertising.setData() command
tulip sleet
^ <@382939733107408897> or <@329766224093249548> I'm pretty sure I'm stuck witho...
i am looking at the code now...
fluid hull
appreciate it, i just wanted to post the short version since I managed to think out my problem by explaining it the long way first 😅
I have actually been stuck on this for years but only now am trying to do it all in circuitpython, and Ideally get the full deal 51 bytes of advertisement out at once.
tulip sleet
BLE extended advertising
slender iron
@lone axle @tulip sleet does it make more sense to add factory class functions? SPA06_003.overI2C() and SPA06_003.overSPI() that inits the device and then calls the constructor?
waiting for the spidevice accessors to land in the core is gonna be a pain
tulip sleet
is it an issue you might want to use an existing SPI?
lone axle
those functions would accept the bus right? either I2C or SPI, and cs object for the SPI one?
tulip sleet
i am afk in 10 mins
slender iron
those functions would accept the bus right? either I2C or SPI, and cs object for...
right, they'd be like the existing I2C or SPI specific constructors
but only have the relevant kwargs and defaults
So, for SPI you'd still pass in the bus and cs but not the polarity and phase
lone axle
Okay, yeah I think that sounds good.
tulip sleet
and the SPIDevice would be available as an attribute? Or used automatically (you don't need to handle it yourself)?
(I am not following the register stuff)
lone axle
My understanding is SPIDevice would get created inside of overSPI() and then passed to the constructor. In the constructor it will create the register_accessor from it which will then use the spi_device automatically internally. The user won't have to handle it at all. The object would technically still be available at something like spa.register_accessor.device but I can't think of a reason any code outside the driver would really need to access it.
slender iron
My understanding is SPIDevice would get created inside of `overSPI()` and then p...
Yup! Better names welcome. I thought about just .I2C() but that may imply a new object type
slender iron
I think I fixed the C6 on idf 5.5.1
just pushed to my branch and will double check it next thursday when I'm back. 👋
nimble sparrow
Hmmm. I'm getting some really weird behaviour off of this
Just trying to figure out if it's something silly in user code...
tulip sleet
Hmmm. I'm getting some really weird behaviour off of this
are you using the PR1059 build? Let me know or post in the PR or open a new issue
tulip sleet
See test program inhttps://discord.com/channels/327254708534116352/1424778936914673766
lone axle
Just noticed the search on the downloads page seems to associate a weirdly large amount of boards with the string fruit j. Adding an a does narrow the list substantially as does searching jam without fruit.
I would have thought it was finding "adafruit" somewhere on the ones it's returning but many are 3rd party and don't seem to mention that in any relevant fields, though I'm not certain what all it searches.
tulip sleet
@lone axle I will do a 10.0.1 release today to fix a regression (can't write to /sd from the host via USB). Above PR (circuitpy_setboard 10661) is not vital, but I'll include it if you have time to review. Anything else you might want in 10.0.1 (any frozen libraries that were updated)?
lone axle
<@382939733107408897> I will do a 10.0.1 release today to fix a regression (can'...
Sounds good, I will take a look at that one in a moment. I am also going to submit a minor docs fix for a TileGrid x TilePaletteMapper thing. Not vital either but just noticed it.
tulip sleet
happy to include that too
lone axle
I don't think any frozen libraries have been updated.
turbid radish
Argh, the code in this PyPortal guide broke, likely in past PortalBase & PyPortal refactoring. The code looks ok if you comment out the QR lines as they are not working. The debug output shows proper JSON reading but it appears to be trying to post the JSON string and not the JSON fields to the display https://learn.adafruit.com/electronic-history-of-the-day-with-pyportal - is anyone familiar with such?
tulip sleet
Argh, the code in this PyPortal guide broke, likely in past PortalBase & PyPorta...
I am not familiar with this at all but would check whether, in pyportal.show_QR(bytearray(response[5]), qr_size=3, x=220, y=10), the desired field is really at [5] or not.
turbid radish
Yes, if I change the "bytearray(response[5])" to response[5] the qr code works. That bug is easy. It's the opaqueness of PyPortal that somehow changed after the guide came out
The JSON fields are not being printed out anymore, just 50 characters of the JSON text
tulip sleet
The JSON fields are not being printed out anymore, just 50 characters of the JSO...
taking a look... [also I will get you a newsletter blurb after I release 10.0.1]
orchid basinBOT
fiery pecan
The JSON fields are not being printed out anymore, just 50 characters of the JSO...
I've ported the code to Fruit Jam OS and found a fix for that issue. Namely, you have to force the HTTP Content-Type header of the JSON data files to be application/json. I've attached the now-working code.
fiery pecan
taking a look... [also I will get you a newsletter blurb after I release 10.0.1]
Unless you already figured it out, 👆
tulip sleet
Unless you already figured it out, 👆
No, I was eating. Thank you! @turbid radish
@turbid radish updated PyPortal version:
fiery pecan
<@378006884122361856> updated PyPortal version:
BTW, one of the comments within that file, that I've copied below, is only relevant for my Fruit Jam OS port in particular:
# originally `pyportal.get_local_time()`
thanks - I thought I had deleted the comment but I forgot to save the change. Revised version
turbid radish
Thanks folks!
tulip sleet
CircuitPython 10.0.1 released!
Highlights:
- Fix 10.0.0 regression preventing writing to a filesystem other than CIRCUITPY via USB.
https://blog.adafruit.com/2025/10/09/circuitpython-10-0-1-released/
nimble sparrow
Is there much interest in an audiomp3-style static module supporting tracker audio (mod/xm/it/s3m)?
Having gone through the pain of integrating libxmp manually for a separate non-MP/CP esp32 project it turns out taking that and mashing it through Cursor to convert it to a shared module is actually pretty successful. I'm half way through reviewing the code for anything dumb.
manic glacierBOT
tiny peak
FYI for folks interested in USB MIDI & synthio (cc @devout jolt and @fleet hollow ), I came up with an interesting result today while trying to see if MIDI running status was responsible for the dropped & stuck notes issue with USB host MIDI. Seems like the actual problem was me using an overly short timeout for usb.core.Device.read(). After I upped the timeout to at least 50 ms, I wasn't able to get any more dropped or stuck notes by bashing on my test keyboard. See https://github.com/adafruit/circuitpython/issues/10554#issuecomment-3399500236
originally I had been using a 3 ms timeout because I was reusing code for polling gamepads and HID keyboards (which often give USBTimeoutError) in combination with a displayio animation loop that I was trying to run at a realatively high FPS.
By my ear, using a USB MIDI polling loop with blocking reads on a 50 ms timeout sounds fine. I didn't notice any issues with latency or synthio glitching. Seems like all the background task stuff works fine while read is blocked, apparently?
I suppose using longer timeouts might get you into trouble if you wanted to run a sequencer track alongside of live MIDI input, but otherwise it seems pretty okay.
I'm trying to figure out if it makes sense to just use longer timeouts, perhaps with a documentation change to that effect... or, if maybe there's a need for better MIDI read support in the core.
manic glacierBOT
quartz folio
@lone axle Thanks for your repsponse to my feature request a few wekes ago to enhance the .json description in the library bundles. I submitted a PR and just wanted you to know that you can find me here if you want to chat about it. https://github.com/adafruit/circuitpython-build-tools/pull/131
lone axle
<@382939733107408897> Thanks for your repsponse to my feature request a few weke...
Nice thank you! I'm out for a few days, but I'll look into this next week if no one beats me too it.
slender iron
@lone axle @tulip sleet at my laptop now. need anything from me urgently? I'm just getting going
tulip sleet
nothing urgent ; I have a couple of PR's (one is in samd-peripherals)
lone axle
Nothing urgent for me either. Spa06 SPI is ready for another look by you I think, but not urgent
slender iron
will try to breeze through my email
slender iron
@tulip sleet want to get your fix in, make 10.0.2, branch 10.0.x, merge idf 5.5.1 and release 10.1.0-beta.1?
(assuming the idf 5.5.1 review goes ok)
tulip sleet
<@329766224093249548> want to get your fix in, make 10.0.2, branch 10.0.x, merge...
whether to have 5.5.1 in 10.0.x or 10.1.0 was exactly what I was going to ask you. I was going to defer the 5.5.1 merge past 10.0.2. Is there anything else we might do for 10.1? If the beta is good we could do 10.1.0 pretty soon. In the meantime there are possibly significant bugs I would fix and merge in 10.0.x while 10.1.0 is cooking
C6 is fine now?
slender iron
I'm not sure about other stuff for 10.1. Maybe dsi displays? Rynn is up now so I'm off
lone sandalBOT
tiny peak
Anybody have thoughts on how (if?) it might make sense to go about porting CircuitPython to the UNO Q? The board is set up so the Dragonwing MPU runs Linux and has the direct connection to the USB-C port (including display output if you use a USB-C dock with PD and HDMI). The STM32U585 MCU is wired up to the Arduino header GPIO but not the USB port. It's apparently meant to be programmed over SWD from Linux on the Dragonwing. It also has UART and SPI channels to the Dragonwing. Presumably those are used to implement the Arduino App Lab bridge RPC functionality.
I wonder if it might make sense to run Blinka on the Dragonwing using a newly written Arduino sketch for GPIO access?
tulip sleet
Anybody have thoughts on how (if?) it might make sense to go about porting Circu...
I think it will take a bit of time for the ecosystem to evolve. There may also be alternative ecosystems that one could build on. Consider the philhower Arduino RP2xxx core, for instance, which is totally independent of official Arduino. There may be alternative RPC impls, for instance. I don't think we have to be first here.
orchid basinBOT
devout jolt
FYI for folks interested in USB MIDI & synthio (cc <@352910176736772096> and <@5...
Interesting, thanks! I forget, is usb.core.Device.read() async compatible so that other tasks run during the timeout? (this is something I can test and answer for myself when I get back to my gear, but if anyone knows...). Because then that would obviate the need for a short timeout
devout jolt
I'm trying to figure out if it makes sense to just use longer timeouts, perhaps ...
I've been pondering if there's a way to add a "MIDI driver" to the core, because responding to MIDI clock in a timely fashion is basically impossible in the interpreter and it's easy for DAWs like Ableton to spew so many MIDI CCs as to flood the input read buffer. Plus it'd be nice to have a fast place in the core for the state machine needed for reconstructing MIDI mesages (e.g. handling running status, sysex, per-message variable-length reads, etc) and maybe message filtering to reduce interpreter code load
slender iron
I've been pondering if there's a way to add a "MIDI driver" to the core, because...
I think this would be great! I suggested modeling the API based on how you'd do it in CPython but I'm not sure folks do MIDI in CPython.
slender iron
Anybody have thoughts on how (if?) it might make sense to go about porting Circu...
I don't think it is worth it. It isn't even out yet and we don't know how popular it will be.
tulip sleet
@slender iron I made a 10.0.2 but all the espressif builds failed when fetching requirements (cryptography in particular but that may just be the first one). Only difference I can see is that Python 3.13.8 was the version used. The last release used 3.13.7. There was an emergency fix for a particular decorator thing and 3.13.9 was released a few days ago, but not sure it is related.
I can't find other people who have suffered from this problem yet.
slender iron
hrmm. I had to cap the cryptography version in my idf update
tulip sleet
it's saying it can't find a usable cryptography version. I wonder if the GitHub Actions infrastructure has some version skew in it
slender iron
it could be that the cache key of deps changed
tulip sleet
also 3.13.9 is not going to be in deadsnakes due to some weirdness in how they tagged it
I was thinking of clearing the caches
we used to have to update the cache key occasionally but I thought we fixed that
slender iron
I bet old builds succeeded because they had old cryptography
clearing won't help. you need to change requirements-dev.txt
tulip sleet
it just says cryptography, with no version restrictions. I think this is an esp-idf-specific requirement
slender iron
right, the esp-idf installs the version it wants and then we upgrade it when installing requirements-dev.txt
tulip sleet
cryptography 46.0.0 came out Sept 16, 46.0.3 was Oct 15
tulip sleet
OH
slender iron
the idf tools cache must have been evicted
tulip sleet
ok, I will make a PR
slender iron
the last green build has a cache hit for the idf tools that the failing build misses
thanks!
another way to fix is to make requirements-dev.txt not update
tulip sleet
do it in the other order, since we may need some stuff it installs that is not part of the ESP-IDF-installed Python stuff?
I think I will not try that now; could be a rathole
tulip sleet
@slender iron I have to go out shopping for a bit
slender iron
do it in the other order, since we may need some stuff it installs that is not p...
don't change order, just make pip not eagerly update the package
orchid basinBOT
tiny peak
Interesting, thanks! I forget, is `usb.core.Device.read()` async compatible so ...
The implementation for usb.core.Device.read() does call RUN_BACKGROUND_TASKS() while it's waiting for a response from TinyUSB. I'm not sure if that counts as a yes to your question or not. For example, in game loops where you might want to update the position or sprite of TileGrid tiles at 30 or 60 fps from a python loop, I'm not sure if blocking on a USB read would mess that up or not. Might also be an issue with audio latency if you wanted to make a synth that merged MIDI input with physical keypress input by captouch or buttons.
tiny peak
I've been pondering if there's a way to add a "MIDI driver" to the core, because...
I actually had some sucess with filtering out MIDI clock messages in Python. The trick is to use a bytearray and memoryview with read() inside of a generator function, then yield the memoryview. In the calling loop, if you use byte comparisons to filter realtime messages rather than using layers of OOP stuff with heap allocated objects, it can run pretty fast. I used that approach successfully to take input from my Arturia BeatStep's sequencer.
This is an example of code for the generator: https://github.com/samblenny/fruit-jam-portable-midi-synth/blob/v0.3.0/sb_usb_midi.py#L111-L134
This is an example of code to filter out realtime messages (by way of ignoring their CIN values): https://github.com/samblenny/fruit-jam-portable-midi-synth/blob/v0.3.0/code.py#L156-L231
tulip sleet
CircuitPython 10.0.3 released!
https://blog.adafruit.com/2025/10/17/circuitpython-10-0-3-released/
Highlights of this release
- Fix SPI DMA on
atmel-samdboards, which fixes SD card mounting problems. - Restore SD card USB presentation on
atmel-samdboards. - No changes in this release for non-
atmel-samdboards.
tulip sleet
**All: **there is now a 10.0.x branch, so if you have a bug fix PR, make a PR against 10.0.x. To get this branch into your fork, do git fetch adafruit 10.0.x:10.0.x (assuming adafruit is the name of your remote to adafruit/circuitpython
orchid basinBOT
tiny peak
Back in late August, there was some discussion here about adding an HMAC implementation to CircuitPython, perhaps by getting the MicroPython implementation working or by using HMAC from some of the recent Matter work. Did anything ever get merged from that? Do we have an official HMAC implementation?
tulip sleet
Back in late August, there was some discussion here about adding an HMAC impleme...
I did some work on that a while ago, and there is a CircuitPython-specific HMAC impl (taken from elsewhere and trimmed) here: https://github.com/adafruit/CircuitMatter/blob/circuitpython/cm_hmac.py. It was just enough to get CircuitMatter partly working.
tiny peak
I did some work on that a while ago, and there is a CircuitPython-specific HMAC ...
Ah, okay. Nice. So, it sounds like the reason I wasn't able to find an HMAC implementation in the core or the library bundle is that there isn't one in either of those places so far.
Is that something that would make sense to add? If so, any suggestions on where? I'm thinking about HMAC in the context of a current LoRa sensor project (sender authentication & replay protection) and a future TOTP token generator project. It seems like there are other uses.
tulip sleet
Is that something that would make sense to add? If so, any suggestions on where?...
I started looking at providing a C-module interface to the cryptographic stuff in mbedTLS, including HMAC, but it looked like a lot of work, and maybe rather port-specific (though I can't remember) so I was just trying to get it to work in Python to start with. Then we could go back and C-ize the slow or large things.
tiny peak
for HMAC-SHA256 at least, doing the whole thing in Python might be pretty reasonable, so long as there's a SHA256 implementation available in C.
If I undersand correctly, the Python part would just need to do a bit of XORing to prepare the inner and outer keys, then a little data plumbing to hash the prepared keys and message or fingerprint
Since hashlib.Hash.update() takes a ReadableBuffer, it should probably be pretty efficient to compute the inner fingerprint digest by feeding it the inner key in one update, then add the message in a second update. Similar for the outer hash.
tulip sleet
I was more concerned with sha256 support. It's in extmod/modhashlib.c but not turned on, I forget why not (maybe it was size, and may now not be relevant given that we grew the 4MB Espressif builds).
Matter is a kitchen sink of cryptography needs. Some notes I made a while ago:
atter crypto notes:
uses Elliptic curve
NIST P-256 curve (secp256r1) aka prime256v1
uses SPAKE2+
needs DRBG
needs TRNG
needs SHA56 hash as Crypto_Hash
HMAC using Crypto_Hash, i.e., HMAC-SHA256
needs ECDH
uses ADEAD AES-CCM for messages
Also see various issues about cryptography, including https://github.com/adafruit/circuitpython/issues/4504 and https://github.com/adafruit/circuitpython/pull/2823
tiny peak
oh, hmm... If there's no hardware accelerated support for SHA256, or at least a C implementation, that would kinda suck
tulip sleet
we have a python implementation right now that Brent worked on and is used for something, I forget, maybe MQTT related
as mentioned in one of those issues, trying to subset CPython cryptography would be painful -- it's kinda monolithic and complicated
the problem I think I was finding with CircuitMatter was less the raw algorithms like SHA256 and elliptic and more all the wrappers like ECDH, SPAKE2+, etc. I didn't try to understand all these, but just tried to find smaller implementations
yes, right now, it's very slow in Python
tiny peak
Where does work on CircuitMatter stand in the grand scheme of things? Is that something you expect to be working on more soon?
tulip sleet
we were pretty interested in it, because there were Matter devices people would want to control from CircuitPython. But it's a lot of code, and there were some issues about using non-certified key pairs or whatever on various platforms. Some allowed that, some didn't. I wrote this down somewhere, but I can't find it right now.
Matter has not broken through as ubiquitous in the consumer market (yet).
there are devices, but it's been slow going
tiny peak
hmm... FWIW, if you want additional help with some of that, it's an area I'm interested in. The two things I care about for my own stuff are IoT/LoRa sensor MAC and replay protection along with HMAC for TOTP tokens
tulip sleet
It's beginning to come back to me... We got simple Matter peripherals working, but they were only controllable from certain platforms. I think Apple and maybe Amazon (?) excluded non-"certified" devices, and I forget the certification details.
another longer term thought is whether to wait for the zephyr port and see what we can use from that
tiny peak
oh... so maybe more of a bureaucratic than technical challenge. sounds like that could potentially be a big hassle.
Is the timeline for the Zephyr port still feeling obtainable with the hands available to work on it?
tulip sleet
Here is a note I made last January internally while trying to get CircuitMatter running on CircuitPython:
CircuitMatter: got further running on CircuitPython. In the key generation phase there is something that’s recommended to be run at least 10-100k times for cryptographic security, which is completely impractical in CircuitPython (would take >3 hours). Temporarily reduced that to move forward. It may make sense to do key generation to be done on a host computer, and then move the keys over for use on CircuitPython.
tiny peak
my impression after poking at Zephyr stuff for a while was that it could end up being a pretty heavy lift to reconcile Zephyr's config-at-compile-time orientation with the CircuitPython way of doing things. Like, doable, but not a small amount of work.
tulip sleet
MicroPython is working on pin reuse at runtime, and we brought that up years ago with the Zephyr folks. We think we might be able to just not assign the pins in the device tree, and still be able to use the drivers in some fashion.
Matter chose some crypto thing that is flawed if you don't take extra special precautions (the 10-100k times thing, I think that was). I think when the choice was made the flaw wasn't known.
tiny peak
is it flawed to the extent of perhaps slowing adoption?
tulip sleet
II think not in general, because the keys are cooked into the device at build time. But I am hazy on this now.
tiny peak
okay, well, my takeaway is that I should probably just do my own thing for my immediate HMAC needs. If you find yourselves looking for extra help with Matter stuff or plumbing up better crypto library support to the core, I'm around and interested.
It could be entertaining to spend more time on IoT and home automation stuff
tulip sleet
The easiest thing might be to get sha256 available for all ports with networking, and then you could find a minimal hmac implementation. I stole one written for MicroPython.
we will circle back and reconsider Matter when Scott comes back more full time. Maybe beginning of the year
tiny peak
The easiest thing might be to get sha256 available for all ports with networking...
from your perspective, is the path clear to do this now that 10.0 has changed the 4MB ESP32 partition layout?
tulip sleet
from your perspective, is the path clear to do this now that 10.0 has changed th...
I don't remember why it wasn't done in the past! Maybe it was just lower priority. aesio's initial motivation was for some Covid-related apps.
i spent a little time looking but I don't see discussions.
obviously it would be great to use the hardware assists if they were available. I think there might be some support for some hw here: https://github.com/adafruit/circuitpython/pull/10027#issuecomment-2643174909
not sure if that is mbedTLS or in pico-sdk
tiny peak
okay, well, I'll see what happens as I get to looking at this. I'm trying to run a LoRa thing on battery power. Doesn't need to be high security, but I want at least some minimal half-decent HMAC. If the available hash algorithm implementations are all super slow, I might need to look at this soon. But, I could probably get by with HMAC-SHA1 if that's an option.
tulip sleet
Scott may be able to correct my deficient memories on this.
wraith crow
okay, well, I'll see what happens as I get to looking at this. I'm trying to run...
I haven’t actually looked at it myself, but @lone axle has an HMAC module in his spell jam project. I Think he needed it for AWS access. It could very well just be the code that Dan pointed to earlier though
tulip sleet
<@&356864093652516868> The (bi)weekly CircuitPython meeting will be in a little under three hours at 2pm US ET / 11 am US PT. Add your hug reports and status reports to https://docs.google.com/document/d/1LMG6qyV-DP5TUlEeVBjLp1mIY5y-KvM_xqybEOMvSCI/edit?usp=sharing even if you can't attend. Thanks!
thorny jay
The diwali-monday-october-20 is only for shipping? Not for meeting?
tulip sleet
The diwali-monday-october-20 is only for shipping? Not for meeting?
It is not a US holiday. I don't see a Diwali shipping notice, but I guess you did.
tulip sleet
got it. it is a float holiday so there is less staff present
lone axle
I'm going to be applying a patch with adabot, and then doing a release for all patched libraries. For anyone with github emails enabled you may see messages for some. I'll do another pass to clean up anything needed afterward as well.
solar whale
👋
tulip sleet
<@&356864093652516868> Bi-weekly meeting starting now.
thorny jay
Hi
solar whale
Sounds good
lone axle
Sounds good
turbid radish
slender iron
Where does work on CircuitMatter stand in the grand scheme of things? Is that so...
I think circuitmatter will be after P4 and Zephyr work. Zephyr will enable thread support on more boards including the new nrf54 series.
thorny jay
TL;DR: Tell your preferred AI about the hardware you have and CP code you want... chances are it will create working code!
Thank you Dan.
lone axle
Thanks for hosting Dan, have a great week everyone.
wraith crow
Thanks 😁
tulip sleet
You're welcome, and thanks everyone for attending.
@slender iron I'll make a 10.1.0-beta.0 release after I do the post-meeting stuff. is the alpha.0 tag at the 10.0.x branch point?
manic glacierBOT
tulip sleet
Here is the notes document for the next CircuitPython (Bi-)Weekly Meeting on Monday, November 3, 2025. 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/1l1zrqcAtX0VFLKH0gB8Cjm_yunue9TulW6c8-hHB6Xc/edit?usp=sharing
tulip sleet
@tiny peak it occurred to me that another reason we didn't do sha256 was that the original requirement was on nRF BLE boards for a covid tracking app, so there was no mbedTLS impl to call
manic glacierBOT
tiny peak
<@1220648290941669377> it occurred to me that another reason we didn't do sha256...
Interesting. I think I saw the PR for that one along with a later issue discussing whether to keep aesio around. I poked at hashlib on the RP2350 and ESP32-S3 Feather boards, which I plan to use for the LoRa sensor thing I'm working on, and they both support sha1. HMAC-SHA1 should be good enough for my current project. I may take a look at SHA256 again after that and before I move on to the TOTP project.
orchid basinBOT
tulip sleet
CircuitPython 10.1.0 Beta 0 released!
- Update
espressifESP-IDF to v5.5.1 and support ESP32-C61.
https://blog.adafruit.com/2025/10/20/circuitpython-10-1-0-beta-0-released/
serene token
Question for CP devs: What was the original intent of adafruit_rgb_display?
I seem to recall reading somewhere that it came from Micropython's module with a similar name, but it feels a bit half baked to me. displayio is a fairly decent high level display library, but there doesn't seem to be any decent low level display library for CircuitPython. rgb_display feels to me like that's what it wanted to be, but it falls rather far short of that. It lacks any kind of buffering options, and it can't load images itself. (It can display PIL format images, but there's no PIL port for CircuitPython, so there's no way of loading images in the correct format.)
I ask, because I recently started working on a project that displayio is not very well suited to, and I have significant experience using real world low level display libraries for video game rendering. I'm seriously considering expanding rgb_display to turn it into more of a full fledged low level display library with buffering capabilities and at least the ability to load PNG images into buffers with the same format as is used by the screen (for fast blitting). If the original intent of adafruit_rgb_display was to become something like this, or if this is even just something that would be accepted if I put in pull requests for it, I'd be substantially more likely to actually do it.
serene token
Another question, closely related to this one: I've just found what looks like a massive design flaw in adafruit_rgb_display, that cannot be fixed without potentially breaking compatibility with Micropython. If I was to copy adafruit_rgb_display into an entirely new module, fix the design flaw, potentially reorganize it to make it better suited as a low level display library, and then add the above mentioned things, is that something that might be of interest for adding to the offical Adafruit modules?
(Note that I wouldn't be able to do this for all 9 drivers in rgb_display, as I only have one them. I'd only be able to do it for ST7789, but others more familiar with the other 8 could probably fix them fairly easily.)
lone axle
Question for CP devs: What was the original intent of adafruit_rgb_display?
I s...
I cannot speak to the original intent of it, as it came about before I got involved. I first got involved around the time that displayio came out and became the more defacto standard that we use for most stuff.
But I can give you my take on it. I think it likely wasn't intended to be low level specifically to be more performant, but rather it was just made very early on and targeted what were at the time less powerful chips with less RAM. displayio makes a nice API, but is more demanding of the resources on the microcontroller.
Once the displayio ball started rolling it became the thing that we default to using for most projects, though there are a few instances like camera preview and I think gifio maybe? where some things get done outside of displayio in order to speed them up.
adafruit_rgb_display remained fairly primitive because it doesn't really get actively developed nearly as much as the displayio based libraries.
@serene token IMO improvements to rgb_display, or splitting to new library if needed with the aim to be higher performance than displayio would be welcome if you're interested in working on that.
New library vs. update existing depends a little on what the issue you found is and what kind of compatibility it breaks and how much existing code would need to be updated.
serene token
The issue I found is the rotation thing I posted an issue for on Github. The rotation argument applies to images being rendering to the display, rather than doing hardware rotation in the initialization. Existing code that uses the drawing functions relies on the current behavior, so fixing this would break that code. If this is acceptable, I think I can provide a fix for the ST7789 driver, but I don't have the time to fix the 8 other drivers. I wonder if displayio handles this correctly... If it does, I might be able to lift it's initialization code for those drivers and fix all 8 of them...
lone axle
as far as I am aware rotation works as expected for all displayio drivers, I have tried on several, but not all of them.
The PIL image thing could be intended for use specifically with Blinka the compatibility layer for linux SBCs. Many Blinka based graphics examples use PIL, I would guess the functions in rgb_display that deal with PIL formats were made for that context rather than CircuitPython on microcontroller.
displayio drivers are sort of split between python code and the core implemenation though. I'm not sure how rotation is handled. Porting the displayio rotation handling may involve looking inside the core implementation.
lone axle
@serene token it looks to me like rotation was first added here: https://github.com/adafruit/Adafruit_CircuitPython_RGB_Display/pull/38 and hasn't really had significant changes since then. It does appear to me like it's only supported in the pillow demos, not an object level property that effects everything drawn (like displayio API is).
I think it's fine to break compatibility with that in order to add a more functional rotation capability. We would need to coordinate updating Learn guide code as nesseccary still though if it changes behavior of anything that does use it.
serene token
I'll do some digging and see what I can find. I should be able to follow the chain of function calls in displayio to figure out where the rotation stuff is.
I think you are right on the PIL/Blinka thing. The rgb_display Learn guide is pretty Blinka oriented. I'm not going to try to reimplement PIL image loading, but displayio has some image loading code I could probably adapt (that's already in the right format for these displays, unlike PIL). If I do this, I'm going to aim for something similar SDL/Pygame, with surface objects that contain image data with functions for copying and such. I don't actually need to touch image() itself, if the image loading functions create surface objects that are rendered to a buffer surface using internal methods. The only compatibility breaking would be the rotation thing. And honestly, I might even be able to avoid that, but it would be much faster to let the display driver hardware do rotation than to handle it in CP before sending the buffer data to the display.
So I guess I'll start looking into displayio code to see if I can find initialization code for handling rotation for all of the different drivers. I won't be able to test most of the drivers myself, as I don't have all the displays needed to do that, but it's at least a start, and I'd rather not do just half the job (or one ninth, in this case), if I can avoid it.
Thanks for the information. That certainly helps. I'm not 100% sure I'll have time for this, but since I need it for my project, I'm hoping I'll be able to manage it.
slender iron
<@252717193496756235> I'll make a 10.1.0-beta.0 release after I do the post-meet...
the alpha.0 one should be on the idf merge commit (one merge after 10.0.x)
slender iron
I'll do some digging and see what I can find. I should be able to follow the ch...
generally displayio drivers don't change madctl to handle rotation. they could from python but don't. for adding a newer low level api, I'd suggest copying the way you'd do it in CPython. That way it it will be cross-compatible.
I do also intend on implementing displayio on top of LVGL at some point to leverage any hardware accelerators that fancier chips have. this would also allow for lower level primitives outside of displayio too
serene token
generally displayio drivers don't change madctl to handle rotation. they could f...
Would it be better, then, to not change madctl and to handle rotation in software? I've had some time to think about it, and while this would be more expensive, I think I can do it in a way that isn't massively more expensive than hardware rotation. Doing it this way, I think I could build an API that won't need to change anything at all within the existing code. Instead rotation would be handled as part of the initialization of the rendering buffer/surface, and the code for blitting would rotate during the blit by adjusting the ordering of the for loops.
As far as what I would do in CPython, I'd do it about the same way as I'm already thinking. I don't really design differently for embedded versus other platforms (in Python), except where it is necessary to fit within the limitations imposed by embedded devices. That said, I do design for optimization more than the average programmer, regardless of platform. I have some experience in video game programming starting in the early 1990s, in DOS/QBasic, where memory was limited to 640kB and CPU speed was on par with mid-range microcontrollers today (286 through 486). If the goal is to ensure that it will also work for Blinka, I don't think that will be problem at all. (I'd actually love to implement a lot of what I want to add in C, but I don't have the time for that, and it would be significantly harder to avoid compatibility issues. Maybe at some point in the future, once it's done in pure Python...)
I'm not familiar with LVGL, but a quick look at the Github page suggests it is promising. I didn't see much about lower level stuff, but the hardware acceleration is certainly a big benefit. And if it does provide even some basic low level stuff, it shouldn't be too hard to build something more complete on top of that.
manic glacierBOT
orchid basinBOT
slender iron
Would it be better, then, to not change madctl and to handle rotation in softwar...
I think we didn't do madctl because we didn't assume that every display had it. I wonder if it would allow us to scroll in any direction. I kind of doubt it.
By model after CPython I mean using an existing library to do what you want and then implementing it for CircuitPython. However, if it is all Python anyway then it could be portable.
I'm not wanting to put a bunch of optimization effort into displayio as-is because LVGL will change it all
manic glacierBOT
tiny peak
For the discussion of perhaps speeding up displayio, something that might be worth considering is whether it would be possible to implement a more direct method of mapping from palette colors to buffer data for blitting as an easy performance win. My vague not-too-carefully-researched impression is that there might be a lot of room for optimization there.
tiny peak
@tulip sleet continuing the HMAC and hashlib sha-n algorithm discussion from the other day... I wrote what I think is probably a reasonably efficient Python function to do RFC 2104 HMAC using hashlib.new() to get a selectable (string argument) hash algorithm. Code at: https://github.com/samblenny/lora-greenhouse-monitor/blob/v0.1.0/sb_hmac.py. It passes all the RFC 2202 test cases for SHA-1: https://github.com/samblenny/lora-greenhouse-monitor/blob/v0.1.0/test_sb_hmac.py. Both the ESP32-S3 and RP2350 Feather boards have 'sha1' as their only implemented hash algorithm for hashlib.new(). So, this works for my LoRa thing now, but it would be nice if 'sha256' could be added.
serene token
I think we didn't do madctl because we didn't assume that every display had it. ...
That makes sense with madctl. I'll implement rotation in software then. That's a solid reason. If optimization is needed, per-driver optimization can be added later.
As far as modeling after something in CPython, I'm going to try to model it on Pygame. I can't guarantee I'll mirror it exactly, mainly because it doesn't all make sense applied to microcontrollers. I'm also considering adding some features that Pygame doesn't have, if I have time after implementing the important stuff. (I have some experience writing a very basic 3D rendering engine, and I'd like to add a few features from that, but they aren't things I need for my current project, so they are more like stretch goals.) But yeah, doing it in pure Python should make it highly portable, especially if I can avoid having to make alterations to the existing code.
tulip sleet
<@329766224093249548> continuing the HMAC and hashlib sha-n algorithm discussion...
I think it would not be hard to get sha256 working on the boards with mbedTLS. There is adafruit_hashlib, which has sha256? Have you checked how slow it is?
tiny peak
I haven't looked at that at all. I just read the code for hashlib to see how the 'sha1' stuff worked
manic glacierBOT
tulip sleet
I haven't looked at that at all. I just read the code for hashlib to see how the...
you could just import adafruit_hashlib as hashlib I think, to test it.
it does sha1 in Python too, so you could test your existing code against it, which might give a lower bound on the slowdown.
wraith crow
@tulip sleet pre-commit is rebuilding circuitpython.pot and dropping two messages. The two messages are no longer used in the 10.0.x modules so that makes sense but the local/circuitpython.pot in the 10.0.x repository is out of date. Should I just go ahead and submit my PR and ignore the fact that it's including the new version of circuitpython.pot?
tulip sleet
<@329766224093249548> pre-commit is rebuilding circuitpython.pot and dropping tw...
it's supposed to make a new version. You have to have an updated circuitpython.pot if you add messages, and pre-commit is checking for that. You can do it yourself instead of taking what pre-commit does. Just do make translate at the top level. It should be the same thing. So, yes, check in the updated circuitpython.pot.
then when it's checked in the PR build it will not complain.
it is running make check-translate to check
The PR pre-commit will not fix things for you. You need to do that in your PR.
just like it will not fix formatting complaints
wraith crow
running pre-commit locally does seem to run the make translate locally but I'll run it again to be sure.. it looks like the circuitpython.pot that I'll be including also drops a couple message changes that are not included in my PR, namely the removal of the runtime.c warning messages and a storage message "filesystem must provide mount method". Should I leave those changes in or manually remove them from the circuitpython.pot I submit?
tulip sleet
don't bother to change anything manually. It's computing what should be in there, and if there are no errors when the PR builds, then it should be fine.
manic glacierBOT
main furnace
What has Dexter been up to? https://github.com/rsbohn/waffle8/tree/main/sketch
scenic ibex
Anyone have any luck getting pre-commit to work on python3.12/Ubuntu 24.04? I'm having a really tough time despite trying multiple package managers and even creating virtualenvs with 3.10
slender iron
Anyone have any luck getting pre-commit to work on python3.12/Ubuntu 24.04? I'm ...
what is happening with it?
scenic ibex
Let me dig up some logs really quick
This is happening even with 3.10, but I was getting some different errors with 3.12, let me grab those too
as a note, running on 3.10/ubuntu 22.04 worked fine
scenic ibex
Hmm
I did also upgrade all the pip packages according to requirements-dev/doc.txt, and do pre-commit clean between runs
Python 3.12 (conda env) on 24.04 (reupload, sorry)
scenic ibex
I believe I do also:
pip install setuptools
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: setuptools in /home/username/.local/lib/python3.10/site-packages (80.9.0)```let me try installing it via conda versus pip though...
Nope, same issue
tulip sleet
I believe I do also:
```
pip install setuptools
Defaulting to user installation ...
I am using 3.12.3 with Ubuntu 24.04 in a venv and it's OK.
you do need to run everything in a venv
scenic ibex
Hmmm, okay, maybe my setup is just corrupt or weird or misconfigured then. I'll try to just create a clean venv or something and go from there. Thanks!
tulip sleet
python3 -mvenv myvenv
source ~/myvenv/bin/activate
should do it, then pip3 install -r requirements-dev.txt
I had a similar but not identical problem here about a year ago: <#circuitpython-dev message>. Updating absolutely everything in my venv fixed it.
serene token
That makes sense with madctl. I'll implement rotation in software then. That's...
Looks like this is going to require significant implementation in C. Using ulab.numpy, I managed to get the data transfer speed from a 2D numpy array to the screen up to...4 to 5 FPS (depending on rotation). The rotation itself isn't super expensive (seems like around 25ms), but the transfer itself seems to taking 180ms to 210ms, for a 320x240 16-bit display (153.6kB framebuffer, for around 850kBps peak transfer speed). With a baud rate of 24,000,000 (can the RP2350 SPI actually go that fast?), I would expect closer to 3MBps, but evidently CircuitPython can't manage that.
tiny peak
Looks like this is going to require
manic glacierBOT
manic glacierBOT
digital shoreBOT
adafruit
upper radish
Look, ma - no hardware! Work continues on the CircuitPython web assembly (wasm) port to further integrate the supervisor and hal with the JavaScript runtime via Emscripten. Now one step closer to being able to write and run your CircuitPython board's code.py in the browser, without a CircuitPython board. 
turbid radish
I've implemented a tone() function for Fruit Jam. I was hoping to have a few eyes on it to ensure I didn't do anything "bad" https://adafruit-playground.com/u/AnneBarela/pages/fruit-jam-tips-and-tricks
onyx hinge
This might be of interest in CircuitPython. The VESA video standard includes a series of formulas called GTF (generalized timing formula) which can be used to set the details of a video mode. adafruit pico-mac uses a version of hstx code nabbed from CircuitPython but I added gtf video mode support: https://github.com/adafruit/pico-mac/pull/10 so e.g., it can do 800x480@60Hz, 1280x720@50Hz, etc., as the underlying video signal resolution.
However, in a "the tail that wags the dog" way, the video generation + USB host support ends up dictating almost all of the other timing details of the fruit jam, leaving you with just 4 core CPU speeds (132 / 176 / 264MHz) to choose from.
Anyway, if someone was motivated I think it would be possible to adapt this back into CircuitPython but it'd be a fair bit of work.
manic glacierBOT
manic glacierBOT
manic glacierBOT
tulip sleet
@slender iron do you have a few minutes to talk about SPI issues? thanks
slender iron
<@252717193496756235> do you have a few minutes to talk about SPI issues? thanks
yup!
slender iron
Anyone have an example of using Terminal from user code? I need it as a reference for issues like: https://github.com/adafruit/circuitpython/issues/10695
wraith crow
Anyone have an example of using Terminal from user code? I need it as a referenc...
I googled "circuitpython terminalio library" and google AI gave me an example. It's probably not helpful for your answer but I do some manual adjustments to the root_group on HUB matrix panels to remove the snake/status line and then manually resize the terminal height/width....
slender iron
I'd prefer if folks would just create their own terminal
though that would only work for their output
wraith crow
I though that was what I remember you saying in the past....
slender iron
if only I had DSI working then I could use the same setup for testing the terminal 🙂
lone axle
@slender iron its not for Terminal directly, but I think this simple example for ColorTerminal should be compatible by just swapping out the class and removing the color specifiers: https://github.com/adafruit/Adafruit_CircuitPython_Color_Terminal/blob/main/examples/color_terminal_simpletest.py
That is the closest to an example that I am aware of. iirc I got a snippet for it from deep dive one day and started building IRC app from that but eventually added color support. I should make the plain Terminal version and add it to the docstrings for Terminal class.
manic glacierBOT
manic glacierBOT
manic glacierBOT
manic glacierBOT
nimble sparrow
if only I had DSI working then I could use the same setup for testing the termin...
Oh neat, is that something on your list? I did wonder if we'd see MIPI/DSI make its way in with esp32p4 boards proliferating
tulip sleet
@slender iron Last night I converted espressif SPI to use a finaliser (took about 45 minutes), and ~~it fixed the SD card crashes!~~So I'll spend the time (with LLM help for speed) to make that change for all the ports. EDIT: not so fast: still not working with a release build as opposed to a debug build.
I think I will make this PR against main instead of 10.0.x, since it's rather wide ranging
lone axle
On the Fruit Jam I think that switching from CircuitPython to something else like apple 2e or 286 emulators, perhaps any arduino/C project? and then back to CircuitPython again results in /saves/ being readonly instead of writeable to CircuitPython. I believe that erase_filesystem() gets it back to working as intended.
Is this worthy of filing an issue about? Or just something that is a fact of life switching between types of firmware on the same device?
tulip sleet
On the Fruit Jam I think that switching from CircuitPython to *something else* l...
saves is not used by the non-CPy emulators, is that right? They should just leave it alone. It might appear as read-only if it gets corrupted. and CPSAVES does not appear when CPy is not running, is that right?
lone axle
non-CPy emulators don't use /saves/ as far as I am aware, but I'm not entirely sure what if anything they do with the flash storage so perhaps there is something I'm unaware of.
I think it might be getting corrupted or erased, I believe I had files on it before switching to and then back from the emulators and afterwards it shows no files and gave me fiflesystem readonly error when I tried to write from cpy code.
CPSAVES does not appear when CPy is not running, that is correct.
I could do a few more tests to be more sure of the exact behavior if it's something we consider problematic. I noticed once a few weeks back when I did the apple 2e guide, and again just recently after switching back to CPy from the 286 emulator.
On some level though I'm not sure there is much that CPy could do about it if some other program happens to break or erase some or all of the flash. It shouldn't do so without reason, but if it does it's beyond our control it seems to me.
maybe just document somewhere what to do if writing to /saves/ reports the filesystem error
slender iron
Oh neat, is that something on your list? I did wonder if we'd see MIPI/DSI make ...
Yup! Just got it working on the P4 yesterday. https://github.com/tannewt/circuitpython/tree/mipidsi
tulip sleet
I could do a few more tests to be more sure of the exact behavior if it's someth...
Do you load the emulator with a UF2 or a .bin?
slender iron
On the Fruit Jam I think that switching from CircuitPython to *something else* l...
It is probably worth filing an issue. We should see what portions get erased and maybe we can improve our detection of whether we need to recreate it
lone axle
Do you load the emulator with a UF2 or a .bin?
UF2.
nimble sparrow
Yup! Just got it working on the P4 yesterday. <https://github.com/tannewt/circui...
Great work
What panel did you test with?
lone axle
I am noticing that having escaped newlines in a string in python code inside of a .. code-block:: python in a docstring in the core causes the docs build to fail. i.e.
message = "Hello World\n"
Because in the .rst file that gets generated it seems the newline has been converted to literal in that context rather than staying escaped within the python string inside the generated .rst file it's:
message = "Hello World
"
Does anyone know if there is an easy way to fix that or an example of any code blocks in the core that have escaped newlines in them I could look at?
double slash is the answer.
message = "Hello World\\n"
should have tried more things before asking
slender iron
What panel did you test with?
The one that comes with the ev function board
I have a waveshare bar display I'm going to try next
nimble sparrow
The one that comes with the ev function board
How're you handling panel init sequence, I guess like any other displayio bus but probably a custom "driver" instance in your test code?
slender iron
How're you handling panel init sequence, I guess like any other displayio bus bu...
Yup, same as FourWire: a byte sequence of commands that the driver IC's library will create
nimble sparrow
Yup, same as FourWire: a byte sequence of commands that the driver IC's library ...
Neat! Mind sharing your test code? I'll see about adapting it to the panel on the Tab5 (an ILC that uses MIPI) to check this carriers over to other P4 boards.
slender iron
@nimble sparrow this is for the EV function board. I have a tab5 too but was going to try and get a waveshare bar display going first
nimble sparrow
I'll give it a go, seems like a good test as the ILI9881C has a fair bit of code for it
slender iron
I'll give it a go, seems like a good test as the ILI9881C has a fair bit of code...
Thanks! That'd be super helpful
Init sequence format is documented here: https://docs.circuitpython.org/en/latest/shared-bindings/busdisplay/index.html#busdisplay.BusDisplay
slender iron
orchid basinBOT
nimble sparrow
@slender iron I'm going badly wrong somewhere even in just getting Tab5 to bring up. I don't suppose you had any tweaks you had to make to the build environment beyond default? Newer esp-idf or anything?
manic glacierBOT
turbid radish
Look, ma - no hardware! Work continues on the CircuitPython web assembly (wasm) ...
DO let me know when you are looking to release, even for testing. cpnews@adafruit.com
tulip sleet
<@&356864093652516868> Here is the notes document for today's CircuitPython Weekly Meeting. Sorry for the delay in posting the link. 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!
https://docs.google.com/document/d/1S9clW6due_EaWHqmgnT70mtlas0AKxHrAGwpB4jYd6Q/edit?usp=sharing
slender iron
<@&356864093652516868> Here is the notes document for today's CircuitPython Week...
The US just changed times. Folks should double check the timing if outside the US.
tiny peak
Am I remembering correctly that Adafruit_CircuitPython_Bundle will pick up new library releases auto-magically if you just wait a day or two?
tulip sleet
Am I remembering correctly that Adafruit_CircuitPython_Bundle will pick up new l...
The bundles are updated nightly.
tiny peak
thanks!
slender iron
<@252717193496756235> I'm going badly wrong somewhere even in just getting Tab5 ...
What error are you getting? I think my branch should be up to date. I'm going to try and get it merged into main before I leave for vacation on Wednesday.
lone axle
Last two weeks sorry. I just merged the numbers manually instead of leaving them seperate.
nimble sparrow
What error are you getting? I think my branch should be up to date. I'm going to...
No meaningful error. Before I even got to the point of giving any mipi code a go I first (as usual) tried to bring up a bare minimum CP build on the Tab5 and ran into a brick wall even at that basic level. I'm wondering if there's some sort of init issue I'm just not seeing, but I'm looking at the Tab5 code for UIFlow (M5S's Micropython fork) and can't see anything obvious
slender iron
No meaningful error. Before I even got to the point of giving any mipi code a go...
My branch has a board def but I haven't loaded it yet. Will try later
tulip sleet
thanks @lone axle !
nimble sparrow
My branch has a board def but I haven't loaded it yet. Will try later
Let me give it a go. I'd happily take having missed something silly.
lone axle
Have a great week everyone 
wraith crow
Thanks everyone
tulip sleet
I edited the meeting notes template to say to send meeting items to cpnews@ (and leave out all the other alternatives). I thought I had done that already but I must have just done it in the actual meeting notes last time.
lone axle
Here is the notes document for the next CircuitPython Weekly Meeting. It is on 11/17 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/1RWdada5krhZGWCBcpPSpDC7PajNVID8J8i5QZuM4gMk/edit?usp=sharing
nimble sparrow
My branch has a board def but I haven't loaded it yet. Will try later
Ah ok I feel mildly better, same issue with your board def as mine
wraith crow
<@662938364173090869> this is for the EV function board. I have a tab5 too but w...
I haven't looked at it in a while but I just pulled out my function board and tried the artifact from your PR. I tried running your mipidsi code.py file and setting the root_group to displayio.CIRCUITPYTHON_TERMINAL but I'm not seeing anything on the display. I assume I'm missing something basic....
slender iron
I haven't looked at it in a while but I just pulled out my function board and tr...
Did you connect the reset line and backlight? What verion of the board do you have?
nimble sparrow
@slender iron glad I'm not going insane.
serene token
Semi-random questions about Fruit Jam OS:
First, is fruit_jam_ja.zip Javanese or Japanese? Typically Japanese is jp not ja, but I would expect to see support for Japanese before Javanese. (Though a quick Google shows that Java has a larger population than Japan, so maybe I'm wrong?)
Second, what the heck is fruit_jam_en_x_pirate.zip?
Anyhow, I thought I would ask. I don't see any notes on the various releases saying what their languages are, and the locale codes aren't always consistent...
fiery pecan
Semi-random questions about Fruit Jam OS:
First, is `fruit_jam_ja.zip` Javanese...
I assume the latter is something similar to the "Pirate Speak" language found in Minecraft.
fiery pecan
I assume the latter is something similar to the "Pirate Speak" language found in...
However, given that it has the same SHA256 hash as the other fruit_jam_en_*.zip files, maybe not. 🤷
stuck elbow
Semi-random questions about Fruit Jam OS:
First, is `fruit_jam_ja.zip` Javanese...
Javanese is jv, see https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes
country codes are different from language codes, because languages are not countries
serene token
I assume the latter is something similar to the "Pirate Speak" language found in...
This would be my guess as well, but it's just a guess...
serene token
Javanese is jv, see https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes
Well that is truly odd. For language specifically, I've always ever seen Japanese as jp in filenames. That even includes certain official fonts used by the Japanese government in official documentation. ISO has Japanese listed as ja though, and jv does make more sense for Javanese, so I guess ja must be for Japanese here.
Thanks! I was not aware of the official standard there. I was clearly only aware of what must be an ad hoc language code or maybe the frequent use of country code in places where language code would make more sense.
stuck elbow
This would be my guess as well, but it's just a guess...
it's for the speak like a pirate day
lone sandalBOT
serene token
it's for the speak like a pirate day
That sounds cool. Thanks for the confirmation!
wraith crow
Did you connect the reset line and backlight? What verion of the board do you ha...
Nope :laugh: that was the basic thing I was missing. Thanks! I now have output on the display. There still seems to be a couple of glitches but I'm not sure there not my doing yet. The EV version is 1.4 although the display says it's for the 1.2/1.3 version so there may be a mismatch there but it probably doesn't matter....
manic glacierBOT
lone axle
I noticed that the downloads page lists the latest dev release as CircuitPython 10.1.0-beta.0 and when I download a UF2 its filename contains 10.1.0-beta.0. But inside of boot_out.txt it lists 10.1.0-alpha:
Adafruit CircuitPython 10.1.0-alpha.0 on 2025-10-20; Adafruit QT Py ESP32-S3 no psram with ESP32S3
That commit has both tags, unfortunately. We'll be doing beta.1 soon which should make that go away.
commit 6fe19f77da0537b124b5c5c3a4138e11bcc97306 (tag: 10.1.0-beta.0, tag: 10.1.0-alpha.0)
Merge: 799f13ce6f 8b1fcb444d
Author: Scott Shawcroft <scott@adafruit.com>
Date: Mon Oct 20 11:00:34 2025 -0700
Merge pull request #10676 from tannewt/idf5.5.1
Update ESP-IDF to 5.5.1
@slender iron did you omit socket.recv() in SocketPool.Socket to save space and encourage reusing buffers? Wondering if we might add it for completeness (as I look at ESP32SPI).
slender iron
<@252717193496756235> did you omit `socket.recv()` in `SocketPool.Socket` to sav...
Yeah, I think I only included the versions where you provide the buffer to require thinking about it
@tulip sleet I think we actually want to refcount mipidsi.Bus because multiple displays could use it
tulip sleet
is FourWire ref-counted the same way?
it relies on SPI underneath, but there's all the copying.
slender iron
fourwire takes a CS pin to differentiate
it's a bit weird because mipidsi.Display is stored next to the buses because the display is actually FramebufferDisplay
tulip sleet
could there be more than one mipidsi.Bus or should it be singleton? I don't know what the hw supports
slender iron
most MCUs I see only support one Bus
some of the newer Pis with broadcom chips have multiple
could statically allocate it
probably still want to refcount its use so that it can turn off when not in use
tulip sleet
that makes sense
slender iron
your finalizer comment made me think about it 🙂
tulip sleet
if the pins are dedicated to only DSI then that makes a difference, I guess. If they can be used for something else if it's not running then more regular deinit is useful.
slender iron
none of the MCUs I looked at share them with anything else
they are 1.2v logic so that may be why
(when single ended)
manic glacierBOT
slender iron
@tulip sleet I'm done working for now. I did test the ev display yesterday and it worked. I saw the issue @wraith crow saw too but it can wait.
tulip sleet
<@329766224093249548> I'm done working for now. I did test the ev display yester...
great - I'll merge and make beta.1
manic glacierBOT
wraith crow
@lone axle Were the Fruit Jam OS release assets supposed to change to the source files?
never mind, I just looked too soon 😁
lone axle
It does take a few minutes to generate and upload.
wraith crow
Couldn't wait 😂
ebon oracle
Hi folks! I'm new to this Discord server but not to MicroPython/CircuitPython.
I'm running into an issue in a library I wrote for inclusion in the Community Bundle,
having set up my repo using the adafruit cookiecutter template.
When I push to Github, the circuitpython-build-bundles step fails because mpy-cross errors out
on syntax pasting adjacent f-strings:
Run circuitpython-build-bundles \
Traceback (most recent call last):
File "/tmp/tmp5wl87qxs", line 163
SyntaxError: invalid syntax
The syntax it's complaining about is this:
def __repr__(self) -> str:
return (
f"Box(x={self.x}, y={self.y}, w={self.w}, h={self.h}, "
f"score={self.score}, target={self.target})"
)
However, I just built mpy-cross from the CircuitPython HEAD and it doesn't
complain about this syntax.
I suspect that mpy-cross needs to be updated in the GitHub actions or the bundling script
but I don't know how to do this.
ebon oracle
It looks like the mpy-cross the actions are using lives in the circuitpython-build-tools module.
ebon oracle
I fixed my code, but maybe the mpy-cross needs to be updated.
tulip sleet
I fixed my code, but maybe the mpy-cross needs to be updated.
thanks for the report. I posted in your issue and made a PR.
ebon oracle
Thanks! I just submitted a PR for the library: https://github.com/adafruit/CircuitPython_Community_Bundle/pull/266
manic glacierBOT
main furnace
Is there a 'hello world' for adding a C module to CircuitPython?
fiery pecan
Is there a 'hello world' for adding a C module to CircuitPython?
It looks like there was one historically: https://learn.adafruit.com/extending-circuitpython
orchid basinBOT
nimble sparrow
Oops, not sure the Tab5 board was meant to stay in 😩
tulip sleet
Oops, not sure the Tab5 board was meant to stay in 😩
it was added as part of https://github.com/adafruit/circuitpython/pull/10703
nimble sparrow
Ah, did the issue with serial/JTAG get resolved?
tulip sleet
I don't know. We can always take it back out
I think you're the only other one with a Tab5. You could try the 10.1-beta.1 build after it finishes
nimble sparrow
Yeah I'll give it a go
tulip sleet
CircuitPython 10.1.0-beta.1 released!
Highlights of this release
- Add mipidsi module to support MIPI DSI displays. Currently enabled for ESP32-P4.
- Fix problems with presenting user-mounted SD cards over USB.
https://blog.adafruit.com/2025/11/06/circuitpython-10-1-0-beta-1-released/
brazen loom
good morning! quick question. I added a board to the circuitpython repo, it was already merged. When should I do the download page PR for the website?
lone axle
good morning! quick question. I added a board to the circuitpython repo, it was ...
I think it's fine to do anytime after the PR in the core is merged.
brazen loom
awesome! thanks
upper radish
DO let me know when you are looking to release, even for testing. cpnews@adafrui...
I think things are strong enough to consider an experimental release for folks to test. https://github.com/johnnohj/circuitpython/tree/wasm-mk2 I'd love to have some experienced eyes look over the implementation because it's at an unusual point where it could lean harder into true CircuitPython build patterns, or else maintain its middle path. I've tried my best to provide clear documentation, and suggest the best way to try out is using the CircuitPython web-editor fork: https://github.com/johnnohj/web-editor/tree/wasm
This is an unusual port because it requires so much beyond the built files and relies heavily on the JavaScript runtime environment. All help tightening this port up greatly appreciated!
manic glacierBOT
sly talon
Hello. I just picked up a waveshare S3 7"/touch. It's the 'A' rev, so resolution is the same as the 4.3, and the product page only shows the 7 has part while the 4.3 doesn't.
Theres a beta release for the 4.3. Can someone point me to a guide to making board packages, and I'll try my hand at setting up the 7.
** 7 has UART, 4.3 doesn't
sly talon
OK, I totally misread that, not the 4.3 after all.
fiery pecan
Hello. I just picked up a waveshare S3 7"/touch. It's the 'A' rev, so resoluti...
Can someone point me to a guide to making board packages, …
https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython
manic glacierBOT
manic glacierBOT
sacred blade
Hello, i've got an adafruit feather rp2350, but would like to use it with micropython (mostly to use the second core, and native modules).
I've tried to create a new board definition, based on the pico2 but with the correct board definition ("adafruit_feather_rp2350") for pico-sdk.
Build and flash ok, but no usb enumeration on boot ...
What are the main differences between a pico2 and a feather_rp2350 that could cause this to fail ?
I'm thinking mainly about a different flash chip, with different clock or initialisation requirements, but then got confused about boot2 and what is initialising the flash...
I'm going to trace the startup process with swd, but if someone's got a hint, that would be great !
stuck elbow
Hello, i've got an adafruit feather rp2350, but would like to use it with microp...
you may get better help with micropython on the micropython's github discussion forum
tulip sleet
Hello, i've got an adafruit feather rp2350, but would like to use it with microp...
did you look at the Feather RP2040 definition in MicroPython (is there one?)?
jaunty juniper
@tulip sleet committed the change to ESP32SPI (also noted the default blocking state is not documented in the core or the library, we could add that at some point)
tulip sleet
thanks!
tulip sleet
<@329766224093249548> committed the change to ESP32SPI (also noted the default b...
I noticed one more thing which I just commented on, and maybe I will add a commit dcoumenting the default blocking state
tulip sleet
@lone axle and anyone else:
The adafruit_esp32spi library and a few others have a redundant module naming structure that looks like this:
adafruit_esp32spi/adafruit_esp32spi.py, which means you usually do from adafruit_esp32spi import adafruit_esp32spi.
Do you think it is worth fixing these in the long run, putting all the stuff in adafruit_esp32spi.py into __init__.py? Then you could just do import adafruit_esp32spi. We could make this backward compatible by doing that and then having an adafruit_esp32spi.py that just does from . import *. Eventually we could get rid of the extra layer.
This structure is present in esp32spi, the wiznet library, the mqtt library, and maybe one or two others.
There are also other .py files that have unnecessary prefixes in the library, like adafruit_esp32spi/adafruit_esp32spi_socketpool.py, which could just be adafruit_esp32spi/socketpool.py. Again could be fixed and made backward compatible with a from <something> import *.
Maybe I am just being crabby because I'm C-izing the esp32spi library, and I'm ending up with very long C function names like common_hal_adafruit_esp32spi_adafruit_esp32spi_esp_spicontrol_get_socket(). But I've always found the identical name nesting to be confusing.
lone axle
<@382939733107408897> and anyone else:
The `adafruit_esp32spi` library and a few...
I am on board with a plan to ultimately eliminate the extra layer of naming. I actually ran across the same naming quirk last week in this repo: https://github.com/adafruit/Adafruit_CircuitPython_ATECC/blob/main/adafruit_atecc/adafruit_atecc.py and considered whether it was worth refactoring.
tulip sleet
yep, that was one of the other ones
there are a lot of examples to change, unfortunately, for esp32spi code
at the very least, we should prevent this from happening in future libraries, but I think these are all historical and people don't generally do that anymore
lone axle
That is true, it will be a lot to update. But a fiarly minor change in most cases. Checking on learn guides that have code broken out into non-embedded blocks will take a little time but I think there won't be too many to update.
having the backwards compatibility in place for a while gives us time to spread it out a little too. And then we can aim to remove in conjuncunction with some future major release.
tulip sleet
a google site search for "adafruit_esp32spi.adafruit_esp32spi" would probably find nearly all
I will open an issue and then do a PR, with new and old compatibility. I also plan to merge https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/pull/218 soon
in the meantime I will do my C-izing in the collapsed naming scheme
tulip sleet
... I did some more reading about this. In larger Python codebases the stuff in __init__.py is largely confined to imports and other housekeeping stuff, and there's usually not real code in it. Of course, most of our libraries are not large codebases at all.
Instead of moving the contents of adafruit_esp32spi.py into __init__.py, we could just put from .adafruit_esp32spi import * in __init__.py. That would reduce the level and still make it backward compatible (forever).
There is also a whole thing about "namespace packages", which are packages without __init__.py, and have special rules. MicroPython (and therefore us) do support them, but not split across filesystems.
fiery pecan
Is the nonintuitive nature of the set pins, □ PIO instruction, when driving the built-in LED, something to be expected? I described my experience here: #help-with-circuitpython message
manic glacierBOT
lone sandalBOT
grizzled dust
N00B questions here: Using adafruit_logging module, created a wrapper around it to implement a lightweight RotatingFileHandler (in order to avoid overrunnign the small onboard storage). (Q1): Is this sometihng the project could use/want in the core? Currently, the code is in .py, but I should be able port to C if need be. and I'm comfortable with git branching and pull requests,. However, I've gone through the project and the Contributing.md, but for the life of me cannot figure out where adafruit_logging derives from. It looks like logging comes straight from MicroPython but is then wrapped. (Q2): Suggestions on where to look? I'm sure it's obvious...
lone axle
N00B questions here: Using adafruit_logging module, created a wrapper around ...
AFAIK adafruit_logging is intended to be an adapted subset of the CPython logging module. If the CPython one has a RotatingFileHandler included I think it'd be fine to include in the circuitpython one as well.
If that is not something that is built-in to the CPython one we'd probably elect to keep it as an example file or elsewhere rather than incorporating it into the library itself.
The code for the circuitpython implementation is here: https://github.com/adafruit/Adafruit_CircuitPython_Logging I don't think it uses the micropython implementation, but I'm not sure. I don't believe that adding that would reqauire any changes in C in the core though because this module is implemented purely in python.
grizzled dust
Wow, thank you. And LOOK --> RotatingFileHandler is in there already. I was fed bad info with my web search (which claimed adafruit_logging did not have a RotatingFIleHanddler). Thanks, anyway.
tulip sleet
Wow, thank you. And LOOK --> RotatingFileHandler is in there already. I was ...
was it an AI result?
sacred blade
did you look at the Feather RP2040 definition in MicroPython (is there one?)?
Yes, I did a cross of the definition for pico2 (mainly setting the target arch as rp2350) and for feather_rp2040 (setting flash size and usb PID & VID), with no success.
tulip sleet
Yes, I did a cross of the definition for pico2 (mainly setting the target arch a...
did you just use the flash info from feather_rp2350?
The pico2 UF2 should sort of work on the Feather RP2350
EXCEPT that you may need to set
#define PICO_XOSC_STARTUP_DELAY_MULTIPLIER 64
in the equivalent place
and all the USB stuff should be RP2350
sacred blade
"The pico2 UF2 should sort of work on the Feather RP2350" -> Yes, that was my hope, but it doesn't. I've tested with #define PICO_XOSC_STARTUP_DELAY_MULTIPLIER 64, too.
tulip sleet
to confirm, does the CircuitPython Feather RP2350 UF2 work fine on your particular board?
I don't know that MicroPython presents a drive. I think not. Does USB serial come up?
sacred blade
to confirm, does the CircuitPython Feather RP2350 UF2 work fine on your particul...
Yes, circuitpython 10.1.0-beta1 works flawlessly
tulip sleet
MicroPython has been moving away from presenting a FAT MSC drive, and instead uses LittleFS on many boards and requires you to use mpremote and similar to read/write files to the filesystem
If the serial port is there, but the drive is not, that's what's going on.
sacred blade
Does USB serial come up : no, no usb enumeration after boot
tulip sleet
hmmm. I am off for 45 minutes or so, will take a further look later
sacred blade
Ok, thanks.
tulip sleet
point me to your repo & branch
sacred blade
I'm wondering if it's not a difference in the flash setup... with the fact that micropython is using pico-sdk 2.1.x and circuitpython a 2.2.x version, with many changes in rp2350 boot seq...
I'll upload my test on github and give you the link.
sacred blade
@tulip sleet : here is the branch : https://github.com/Anton-2/micropython/tree/adafruit-feather-rp2350 with the port definition in https://github.com/Anton-2/micropython/tree/adafruit-feather-rp2350/ports/rp2/boards/ADAFRUIT_FEATHER_RP2350
tulip sleet
<@329766224093249548> : here is the branch : https://github.com/Anton-2/micropyt...
I don't think the pico-sdk version should matter, because it's all MicroPython. But I would check to see if your build env is working. Build the pico2 and see if that UF2 works on a pico2, if you haven't done that already
I looked at boards/ differences and they look fine to me. Only significant difference is that the PICO2 doesn't define the VID and PID.
I looked athe RP2040 vs the PICO and there are similarly very few differences
sacred blade
"Build the pico2 and see if that UF2 works on a pico2, if you haven't done that already" -> yes just tested it now. Same repository, BOARD=RPI_PICO2 make -j 10 deploy -> works on a pico2
tulip sleet
"Build the pico2 and see if that UF2 works on a pico2, if you haven't done that ...
maybe you did this already, but make sure you are doing a clean build for the FEATHER_RP2350 bild
I can try a build locally
sacred blade
make clean is enough or there is a "more clean" option ?
tulip sleet
that should be good enough
sacred blade
.. but it does'nt change the result.
tulip sleet
ok the RPI_PICO2 build works on a real Pico 2 and on the Feather RP2350... Now I'll try the Feather build
tulip sleet
make clean is enough or there is a "more clean" option ?
did you do make clean BOARD=ADAFRUIT_FEATHER_RP2350? OR you can just remove the build-ADAFRUIT_FEATHER_RP2350
sacred blade
did "make clean BOARD=ADAFRUIT_FEATHER_RP2350"
tulip sleet
i'm doing your board build, but in the latest micropython
sacred blade
Ok. But there is something strange in my board/setup as a Pico2 build (or the official uf2 from micropython) does'nt work on my feather...
tulip sleet
@sacred blade still trying things...
my guess is that the Pico 2 build is working for my Feather because my board doesn't happen to need the XOSC MULTIPLER 64. That would vary sample to sample. I've tried removing nearly all the pins, removing the PID and VID, and defining the flash size with a constant, as is done in ADAFRUIT_FEATHER_RP2040, none of which work
I also shortened the name, which seemed to be truncated in the UF2 file by one character
sacred blade
I suspect that the difference is in the flash setup. Circuitpython does some clever thing with a database of flash parameters matched with chip ref (and indeed there is two flash chip listed for the feather, explaining the sample difference, maybe)
Micropyhon hopes that pico sdk will do the job, according to the board choosen by set(PICO_BOARD xxxx)
tulip sleet
the sample difference for the multiplier is due to variations in the XOSC components. But I think may be the flash too. I am trying a few more things related to that.
first I am replacing the pico-sdk .h for the feather with the pico2 one.
there is also a difference in the power setup
... ok yes, after that replacement it works, so the difference is in the pico-sdk .h file
tulip sleet
I suspect that the difference is in the flash setup. Circuitpython does some cle...
OK, it is because
#define PICO_BOOT_STAGE2_CHOOSE_W25Q080 1
is missing from the .h for the feather in the pico-sdk
If I add that, it works, so try adding that in mpconfigboard.h
sounds like we need a PR
sacred blade
Already did, it is in a comment, but i'll try again...
tulip sleet
i also made the flash size 4MB, haven't undone that yet
sacred blade
Tested with #define PICO_BOOT_STAGE2_CHOOSE_W25Q080 1 -> not working.
But if my feather got the other flash chip ( GD25Q64C ? ), it could explain why the W25Q080 or base pico2 variant is not working ?
sacred blade
Hard to read but with a good magnifier I can confirm that your bet is correct. It's indeed a winbond Q64JVX.
tulip sleet
Hard to read but with a good magnifier I can confirm that your bet is correct. I...
--- a/src/boards/include/boards/adafruit_feather_rp2350.h
+++ b/src/boards/include/boards/adafruit_feather_rp2350.h
@@ -82,6 +82,8 @@
#ifndef PICO_FLASH_SIZE_BYTES
#define PICO_FLASH_SIZE_BYTES (8 * 1024 * 1024)
#endif
+#define PICO_BOOT_STAGE2_CHOOSE_W25Q080 1
+
is working for me. I think putting it in mpconfigboard.h is not enough because something else like the stage 2 builder is not looking at that
WHY this is necessary I am not sure.
I have to stop for a while, but it would be worth looking at what's going on in the bootloader build
sacred blade
Ok, thanks a lot for the time taken, it works for me too with #define PICO_BOOT_STAGE2_CHOOSE_W25Q080 1 in the sdk file !
Would never have found it...
tulip sleet
divide and conquer all the way... what is different? pico-sdk files AND your files
eliminate the differences one place then start putting them back
i don't know what's different about MicroPython. If bare pico-sdk works without that define, then what's up?! I can believe CIrcuitPython does its own thing.
need to test whether a simple pico-sdk project works with that board definition
without the extra #define
sacred blade
I've got to drop, it's getting late here. Thanks again.
tulip sleet
I've got to drop, it's getting late here. Thanks again.
FYI, defining
#define PICO_BOOT_STAGE2_CHOOSE_GENERIC_03H 1
explicitly doesn't work. It has to be PICO_BOOT_STAGE2_CHOOSE_W25Q080
tulip sleet
<@&356864093652516868> The (bi-)weekly meeting is in about 1.5 hours, today at 2pm US ET // 11 am US PT. Add your notes to https://docs.google.com/document/d/1RWdada5krhZGWCBcpPSpDC7PajNVID8J8i5QZuM4gMk/edit?usp=sharing. Thanks!
manic glacierBOT
errant grail
lone axle
Thanks for hosting Dan. Have a great week everyone!
wraith crow
Thanks Dan!
tulip sleet
thanks everybody!
lone axle
I am thinking that https://github.com/adafruit/Adafruit_CircuitPython_Register_SPI could be archived and omitted from the adabot reports. The latest versions of https://github.com/adafruit/Adafruit_CircuitPython_Register now have unified support for SPI and I2C. So the separate SPI library won't need to be used.
tulip sleet
is it still in the bundle?
tulip sleet
Here is the notes document for the next CircuitPython (Bi-)Weekly Meeting, on Monday, December 1, 2025. 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/1wqJsxaeDVgu5a84WERN982k61Woc9vpRqD6HiSgmG2w/edit?usp=sharing
lone axle
is it still in the bundle?
it was never in the bundle. It got created but was never fully finished or released.
tulip sleet
it was never in the bundle. It got created but was never fully finished or relea...
Archiving makes sense; I agree
lone axle
I'll update the readme with a pointer to the other register library and archive.
onyx hinge
@tulip sleet some months ago I think we discussed that I want to move my port of the decimal package out of my personal github, and I think we decided to transfer it into the circuitpython org.
if you have a few minutes of time available, I'd like to go ahead and transfer https://github.com/jepler/Jepler_CircuitPython_udecimal into the circuitpython organization; I do not have the permissions necessary to do so. After that I'll make a PR to change its URL in the community bundle [or should it move to the circuitpython.org bundle?]
I've also invited "adafruit-travis" to be an owner of the project so that Adafruit folk can manage it.
tulip sleet
let me see who owns some other circuitpython org projects in pypi
do you want to replace jepler in the repo and library name?
Jepler_CircuitPython_udecimal and jepler_udecimal/
onyx hinge
I have some setting in discord that lets me hold shift over a message and get more options; one is a no-confirmation delete button
I think it's "advanced > developer mode"
tulip sleet
worked for me too!
onyx hinge
thank you for working with me on this!
tulip sleet
thanks for doing it; all transfers completed, as far as I can tell. I should write up all the ownership and username stuff instead of just remembering it.
I transferred the repo to the org. You have to be a member of the org.
you could be a member of the org; there are other outside collaborators
onyx hinge
that's OK, I don't usually need to do anything in there these days 🙂
I think everything should be in order for the rare possibility that you'll need to cut a new release of udecimal. https://github.com/adafruit/CircuitPython_Community_Bundle/pull/267
tulip sleet
@slender iron @lone axle would you have time for an ESP32SPI library/native-module discussion today when you are both on? There are some different directions for me to go in here, and i want to bounce some ideas off you. Thanks.
slender iron
I'll be on in 15 min or so. Just put rynn down
lone axle
Yep, I am available as well.
slender iron
Ok, I'm here
tulip sleet
@slender iron mutable module attributes: https://github.com/micropython/micropython/pull/7591. This is more than 3 years old so I assume we merged it
example in py/modsys.c
tardy plume
I need help. I need to create a variant of a new board for circuitpython. It could be called, for example, "NRF52840 _RAW" it would be exactly like https://circuitpython.org/board/ADM_B_NRF52840_1/ but without #define MICROPY_HW_LED_STATUS (&pin_P0_19) I need to use this pin. Can someone help me? I'm not familiar with github and I don't have the necessary tools for compilation, I have more projects where I would use such a clean board. Therefore, it would be very helpful to me if such a board was officially supported and had updated firmware.
tiny peak
I need help. I need to create a variant of a new board for circuitpython. It cou...
as a starting point, you can read this: https://learn.adafruit.com/building-circuitpython/build-circuitpython
and also this one which talks about using git and github:
https://learn.adafruit.com/contribute-to-the-adafruit-learning-system-with-git-and-github/grab-your-fork-2
tardy plume
I need help. I need to create a variant of a new board for circuitpython. It cou...
So I tried, after many experiments, I managed to compile the code without that line, but it doesn't work. When I run my code, the board resets and I get the error
and the version from the circuitpython website doesn't work either
PROBLEM IN THONNY'S BACK-END: Exception while handling 'run' (ConnectionError: EOF).
See Thonny's backend.log for more info.
You may need to press "Stop/Restart" or hard-reset your CircuitPython device and try again.
Process ended with exit code 1.
─️
Unable to connect to COM40: port not found
Process ended with exit code 1.
─️
| 10.1.0-beta.1-1-gf15d4b2554-dirty \Auto-reload is off.
Running in safe mode! Not running saved code.
You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Hard fault: memory access or instruction error.
Please file an issue with your program at github.com/adafruit/circuitpython/issues.
Press reset to exit safe mode.