#circuitpython-dev
manic glacierBOT
brazen hatch
Yea the MAKE flag has 0% chance of working with ansi escapes and bytes.
I did spend half a day now to try making it work
Took 30 minutes to make custom header to include the code
Downside to my "encode it into what looks like malware" approach, is that it takes exorbitantly long for 350k characters to load into the stack, causing a cpu watchdog reset.
I think I should pivot to frozen module generation
I'll just design it so code.py is just import setup and the host application crafts a frozen module containing all the decompression and setup code.
Or an alternative would be to just have default code.py test if the setup module is available.
This would allow people to just include a frozen module named "setup" and be done with the build configuration, simplifying automation as well.
This would allow us to have ci like:
- Take this image file url.
- Extract into frozen/setup
- Enable setup for board
- Build
Actually this whole thing makes images pointless, just a zip
slender iron
I think bootloader would be better since it doesn't require CP to start. It is nice that is universal though. Seems similar to circup
@lone axle any luck with the metro and absolute latest?
brazen hatch
I think bootloader would be better since it doesn't require CP to start. It is n...
Of course it'd be better. But it'd be an unbelievable pain.
My current approach to the issue (frozen + import setup) is a lot more simple and universal.
It's not going to even be constrained by ram.
What do you think about making a default boot.py exist on fresh fs?
try:
import setup
except ImportError:
pass
If there is no vendor flashed setup code, nothing happens.
If there is, it'll take over, doing whatever it wants.
The thing I'm writing will check if .setup_complete exists and only run if not, checking usb mounting state and rebooting if needed.
brazen hatch
zlib
Already did it with my whole project
no complains on esp
Besides, it's useful for more than just packing a whole fs.
You can use it as I said to stuff a download script.
lone axle
<@382939733107408897> any luck with the metro and absolute latest?
Keyboard input to REPL is working now (wasn't for me before). Still no luck with the generic PS3 or the cheap SNES controller using this script that I wrote for the rp2040 originally https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/main/Feather_RP2040_USB_Host/CircuitPython_GamePad_ReadData/code.py
I do think the PS3 controller may be getting further than it did before. It has a blinking red light that seems to indicate an error state. On the old firmwares that just kept blinking forever, on the new one, if I boot the metro up with that PS3 controller plugged in it does settle in to it's normally functioning state of not blinking.
Both my current games use keyboard input though, so this gets me unblocked to run those on the metro. π
slender iron
thach is going to do more debugging I think.
lone axle
@slender iron for the 360x200 display size of PicoDVI what are the supported color depths? 8 and 16 bits same as 320x240? I'm going to update the docs to list that new mode and update to note that it's the default instead of 320x240.
slender iron
<@252717193496756235> for the 360x200 display size of PicoDVI what are the suppo...
pixel doubled or quaded resolutions support 8, 16 or 32 bit color. it is only default for displays that are detected as a multiple of 1920x1080
On RP2350, output resolution is either 640x480 or 720x400. Monochrome framebuffers (color_depth=1 or 2) must be full resolution. 4-bit color must also be full resolution. 8-bit color can be quarter, half or full resolution. 16-bit color and 32-bit color must be quarter or half resolution due to internal RAM limitations.
jaunty juniper
@slender iron speaking of zephyr, is seems like build_board_info.py also errors due to the paths, it will have to be special cased there too.
β― RELEASE_TAG=9.2.4 DEBUG=1 python build_board_info.py
Traceback (most recent call last):
File "tools/build_board_info.py", line 287, in <module>
generate_download_info()
File "tools/build_board_info.py", line 256, in generate_download_info
board_info = board_mapping[board_id]
~~~~~~~~~~~~~^^^^^^^^^^
KeyError: 'nordic'
the code does this:
board_path = os.path.join("../ports", port, "boards")
for board_path in os.scandir(board_path):
perfect, that's got all of the details, the environment docs can link over to there
slender iron
<@252717193496756235> speaking of zephyr, is seems like `build_board_info.py` a...
yup, that'll need to be updated. I should just use the results of getting the board mapping
(How did this not break 9.2.4's release?)
jaunty juniper
seems 9.2.4 was a few days before the zephyr PR was actually merged
slender iron
seems 9.2.4 was a few days before the zephyr PR was actually merged
ah! I thought it was after
slender iron
@tulip sleet here is the close endpoint issue: https://github.com/hathach/tinyusb/issues/3012
tulip sleet
@slender iron thanks. on a different topic, have you ever seen c6 or c3 builds where a build doesn't even come up? the bootloader just generates tons of "Invalid header: 0xffffff...". I am building NINA-FW just fine but it won't come up at all. Does CONFIG_BOOTLOADER_OFFSET_IN_FLASH value make any differene. Arduino IDE is fine and so is CircuitPython. I know the .bin is being loaded; I downloaded it and it's exactly what I expect.
partition table is not unusual
slender iron
<@252717193496756235> thanks. on a different topic, have you ever seen c6 or c3 ...
I have seen it. I think I added debug prints to the second stage bootloader to determine where it was reading
did you try a full erase beforehand?
tulip sleet
I have turned on logging there, as an initial step. yep, did an erase
slender iron
want me to try and fix the issue neradoc found that may break the next release?
tulip sleet
for sure, my thing i think I will figure out eventually
slender iron
yup, I'd print the address it is reading
tulip sleet
i turned on verbose logging but it said the bootloader was too big π
tulip sleet
thanks, I will do that:
ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x7 (TG0_WDT_HPSYS),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x400294a6
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
...
that looks like the rom bootloader
not the second stage one
I bet you are flashing the second stage bootloader to the wrong place
tulip sleet
right, I thought maybe the second stage was either not getting called at all or was failing really early
its offset is 0x1000 instead of 0x000, compared with an arduino blink program. ESP32 uses 0x1000. I have not found good documentation on how this offset is communicated to the first stage bootloader
slender iron
yup. I think its the second stage that looks at the partition table
willow totem
Dang, wish I'd spoken up now. I always check the esptool-js repo as they have the details one file per chip: https://github.com/espressif/esptool-js/blob/main/src/targets/esp32.ts
willow totem
The dreaded menuconfig
On another note who here is aware of what the situation with the library bundles ruff rules is?
We don't seem to have sane defaults, although I have no idea or opinion on this really, just noticing that I've had to add F821 Undefined Name to detect what feels like a basic error.
Justin suggested bring to discord and in-the-weeds, but I wondered about scoping out the situation in advance (and kind of thought might get lost in discord).
tulip sleet
On another note who here is aware of what the situation with the library bundles...
I don't know where the rules set came from. I think we could start over on that. micropython has been using ruff for a while, and we could look at theirs. I don't think there are a lot of people in the weekly meeting who have experience with this. We may well have a bad set of defaults. I'd go back to the initial commits and see if we can figure out where they came from. But I'd find out how to generate a sane set and then go from there. It's certainly not sacred.
slender iron
The kconfig files themselves can be helpful too
willow totem
The kconfig files themselves can be helpful too
good point!
tulip sleet
i have been reading those too. I think i just forgot to do idf.py set-target
willow totem
I don't know where the rules set came from. I think we could start over on that....
Thanks Dan, that does help clarify (particularly knowing no-ones precious about the current set/defaults). I'll scope out the micropython situation so I'm not coming to the meeting unprepared
tulip sleet
I'm sure it was tweaked to fix our style but I don't know what the starting point was. @lone axle may remember where it came from first
lone axle
On another note who here is aware of what the situation with the library bundles...
To the best of my recollection the set of rules that got put into cookiecutter and other libraries were built by looking at the prior used pylint rules and picking the closest matching ones for ruff.
I don't know all of the specifics, some of them may not apply the same, or it may still be nice to add others if they can be helpful. Beyond trying to match what we had I dont recall much other discussion around it.
willow totem
To the best of my recollection the set of rules that got put into cookiecutter a...
Got you, and were the default categories under "select" of F/E/I too restrictive, or not default back in v0.3.4? I've also seen they are using extend-select in micropython which would preserve the default categories https://github.com/micropython/micropython/blob/master/pyproject.toml#L41
Default config here: https://docs.astral.sh/ruff/configuration/
lone axle
I'm not sure about that.
willow totem
Cool, no worries. Makes my sweeping changes less of a concern π
lone axle
I do believe we started ruff in libraries before micropython started using. Matching them now that they've begun too does seem like a reasonable approach to me. Definitely worth some discussion in the weeds.
tulip sleet
do we have to do an all-library set of PR's each time we change the rules?
willow totem
That also concerns me yeah, but adabot can probably do it in one foul swoop
tulip sleet
I am not sure MicroPython is a good starting point -- they are very casual about some things we care about
willow totem
good to know
tulip sleet
can we point to a default set of rules and have modifications for each library?
lone axle
Hmm, it would be nice to centralize it somehow, but still be tweakable for each library.
Its probably possible somehow, but I'm not sure the best way to do it.
fetch ruff.toml from some central repo, and then merge it with a local one in the working repo?
tulip sleet
Definitely, which we have done for other common things. I can't remember what is common right now.
willow totem
looks like we can extend to a file, so ci would bring in the main config (specify on cmdline) and then link to optional repos config? https://docs.astral.sh/ruff/configuration/#config-file-discovery
tulip sleet
I thought it was stuff in circuitpython-build-tools? It's something that gets fetched in the CI, or maybe in pre-commit? pre-commit might get in the way
jaunty juniper
can it be defined in .pre-commit-config.yaml ?
lone axle
github actions are centralized like that. But they allow us to "point" to the central place within their own config file syntax. I'm not sure whether ruff has a similar ability to point to another place.
willow totem
lone axle
AFAIK each repo's pre-commit is independent and doesn't have a central location that updates it.
tulip sleet
--config <CONFIG_OPTION> Either a path to a TOML configuration file (pyproject.tomlorruff.toml), or a TOML <KEY> =
<VALUE>pair (such as you might find in aruff.tomlconfiguration file) overriding a specific configuration option. Overrides of individual settings using this option always take precedence over all configuration files, including configuration files that were also specified using--config
lone axle
cookiecutter is a central location they get created from, but nothing automatic keeps pre-commit in sync AFAIK.
tulip sleet
but could there be a pre-commit action that fetches the default settings from somewhere and then merges them with local? It doesn't look there can be a cascade of .toml files, though
lone axle
if it will let us specify two config files that would make it fairly easy
willow totem
cascading works, just a bit below config discovery it talks about extend for pyproject.toml or ruff.toml to parent folder as example
Maybe only two levels, but ci action has level one and project level two
cookie cutter just sets up action and pyproject/ruff.toml with empty ruff section
tulip sleet
Unlike ESLint, Ruff does not merge settings across configuration files; instead, the "closest" configuration file is used, and any parent configuration files are ignored. In lieu of this implicit cascade, Ruff supports an extend field, which allows you to inherit the settings from another config file, like so:
willow totem
yeah inherit from another. Needs testing, but sounds like a solution
tulip sleet
looking at the same page as you π
jaunty juniper
note that it has to work when running pre-commit run from a local cloned repo, not just in a CI environment, otherwise it's gonna be a world of bad surprises with every PR
tulip sleet
so the q is does pre-commit have any mechanisms for fetching files? Maybe you can specify a custom action that will do that.
willow totem
So the ci calls precommit, which uses the libraries local yaml as config. All libraries will need an initial tweak to that yaml, and the ruff/pyproject.toml, and the actions should be ok.
Maybe a cookiecutter update as it were.
The yaml contains the --fix option for ruff so we can add the --config there, alternatively we ask the projects config to extend from a central one, so if its offline the project config still works but not as well
tulip sleet
I think the pre-commit person hates that kind of thing, because it introduces a dynamic dependency in a repo
willow totem
I can't help but admit I don't run pre-commit, so that needs to work locally first I guess
willow totem
it's a good thing to run for sure, it just hates 66% of my computers
tulip sleet
macOS? sorry
willow totem
windows, probably broken python setups from yesteryear. I should try installing it again on the refreshed one
short tendon
@lone axle have time to release MiniMQTT today? Want to see if I got ALL the secrets
lone axle
<@382939733107408897> have time to release MiniMQTT today? Want to see if I got ...
yes, just made one π
short tendon
Thanks!
And secrets are gone from library code! And aio keys are all updated to ADAFRUIT_AIO_USERNAME and ADAFRUIT_AIO_KEY
There are 176 files in the learn guide that from secrets import secrets or import secrets
Not sure how you would like to tackle those. I can update all the code, but not sure about the learn guides themselves...
lone axle
@short tendon Thanks for all of the effort that you've put into it! For learn guide code you can submit a PR. If you have time and are so inclined you can search for the learn guide associated with the code as you change it and see if there are any instances outside of the main embeded code file that contain references to secrets.py, if so add a link to the relevant pages to a comment in the PR like: https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/2755#issuecomment-2026325982
If you don't have the time, or would rather not search through the learn guide pages you can just submit the PR with code changes and someone else will go through them.
willow totem
Not this week probably, but I can smash some out, or do the matching guide pages
willow totem
nevermind that pre-commit additional_dependencies talk, it tried to pip install my test file π€¦ Easier to use some python fetch script instead, but yuk
short tendon
<@1152454697614069811> Thanks for all of the effort that you've put into it! For...
Is there a direct correlation between what's in the library repo and the URL for a learn guide?
Also with that many changes, would you all want it in 1 or many PRs?
And it looks like there aren't any linting rules in the repo?
lone axle
Is there a direct correlation between what's in the library repo and the URL for...
For some guides there is, but for others its not direct unfortunately. No strict rule is in place on the naming. Feel free to skip any that don't pop up quickly, google can sometimes find them with a few keywords than the learn search but I've had good and bed luck both ways with different guides.
short tendon
Sounds good
lone axle
The linting is far less strict, but I do think there is some
although I'm not sure if the actions enforce it
short tendon
I can add some basic linting and not commit it to make sure I at least have imports and declared vars
short tendon
What about 1 PR vs many?
lone axle
What about 1 PR vs many?
for big sweeps like this in the learn repo I find it easiest to work through them as one big one, or perhaps a few PRs split into chunks if you pick up / put down the work on it.
both as reviewer and contributor personally.
short tendon
Sounds good. I'll see what I can do in a sitting and figure it out from there. In the end breaking it up won't be hard after the fact
Final question (and not sure if we need multiple opinions). In the examples I did:
from os import getenv
As it seemed most common (from a quick search) and Dan didn't have any issues in initial reviews.
Are we good using that in all the updates?
lone axle
Final question (and not sure if we need multiple opinions). In the examples I di...
I think that is fine.
short tendon
Also @lone axle do you want any help with the ruff migration?
lone axle
Also <@382939733107408897> do you want any help with the ruff migration?
I wouldn't turn down help. I basically just do the switchover for any libraries that I am working in for other reasons if I am not in a hurry. I would say though my preference is to keep them all on the same version of ruff, I noticed the versions was bumped on miniMQTT.
Keeping them the same accross libraries is ideal in my mind so that the rules for all libraries are the same, and because the adabot patching tool is less effective when the files it's patching contain differences. So if we want to update them all at once with a patch for instance having a smattering of different versions in different libraries makes that more difficult.
short tendon
Yeah, that's why I was asking. Cause if we get them all done, then we can globally make changes.
Do you know roughly what percentage of libraries have been updated?
lone axle
I do not really. my guess is that there are "a few dozen" or so completed, but it is definitely just a guess.
you did the first handful, and I've done a few chunks with other changes. I think a few others have been swapped in PRs by other community members.
short tendon
Gotcha. So still most need to be done. After I finish with the learn guide, I can start going after this. How many PRs in a pass feels good to you? For secrets I was doing 4-6
lone axle
That sounds fine to me, but I'm good with whatever rate you want to go at really. I will try to stay caught up on reviews, if I lag behind and you feel like slowing down you can, though I also don't see it as terrible if they stack to some degree as long as it's not getting out of hand.
If any do lag, and require changes I can commit them instead of having you circle back if you've moved on.
short tendon
Sounds good. I'm not a fan of PRs hanging out too long (mostly because of conflicts from other merges), so will keep an eye on open ones, and if it seems like it's a lot will check in with you.
willow totem
Sounds good. I'm not a fan of PRs hanging out too long (mostly because of confli...
Happy to be a spare pair of eyes if needed.
Last night updated my Todo from August for a third IO username variant π€¦ plan is tues-thurs next week [Google showed quite a few]
short tendon
Happy to be a spare pair of eyes if needed.
Last night updated my Todo from Augu...
a third one?
willow totem
a third one?
short tendon
π¦
@lone axle what do you think we should do here where it just looks for the existence to raise (since the MagTag library would have grabbed them from secrets, now does from settings)
try:
from secrets import secrets
except ImportError:
print(
"""WiFi settings are kept in secrets.py, please add them there!
the secrets dictionary must contain 'ssid' and 'password' at a minimum"""
)
raise
Do we check that getenv("ssid") is not None and raise?
lone axle
Do we check that `getenv("ssid") is not None` and raise?
yeah, I think that seems like a reasonable way to do it. It should catch or handle whatever happens if the settings.toml file doesn't exist as well
short tendon
so:
if getenv("ssid") is None:
raise Exception(
"WiFi settings are kept in settings.toml, please add them there."
"the settings file must contain 'CIRCUITPY_WIFI_SSID' and "
"'CIRCUITPY_WIFI_PASSWORD' at a minimum"
)
And a follow up. For ones like this learn guide where there's actually a secrets.py, what should we do?
short tendon
yeah, I think that seems like a reasonable way to do it. It should catch or hand...
Would it be better to put that in portalbase, so it just automatically happens everywhere, vs a bunch of c/p in all the guides?
lone axle
so:
```py
if getenv("ssid") is None:
raise Exception(
"WiFi settings...
is the second raise intentional?
short tendon
Bad copy/paste edit of the original. Fixed
lone axle
Would it be better to put that in portalbase, so it just automatically happens e...
if the majority of the code that is making use of it are portalbase projects I could see that being a good thing to put into the library. I thought there was some internal handling of secrets / settings in there already, but I'm not super familiar with them. It would be good to discuss portalbase changes with MakerkMelissa as well.
short tendon
so, there's two types. The ones that import secrets, just to raise an error (the ones using portalbase) and the ones that actually use secrets. I can easily add that exception for all of them and it will be similar
short tendon
@willow totem and @lone axle if there are aio keys, we don't specifically error, but should we?
# Get WiFi details and Adafruit IO keys, ensure these are setup in settings.toml
# (visit io.adafruit.com if you need to create an account, or if you need your Adafruit IO key.)
ssid = getenv("CIRCUITPY_WIFI_SSID")
password = getenv("CIRCUITPY_WIFI_PASSWORD")
aio_username = getenv("ADAFRUIT_AIO_USERNAME")
aio_key = getenv("ADAFRUIT_AIO_KEY")
if ssid is None:
raise Exception(
"WiFi settings are kept in settings.toml, please add them there."
"the settings file must contain 'CIRCUITPY_WIFI_SSID' and "
"'CIRCUITPY_WIFI_PASSWORD' at a minimum"
)
if aio_username is None:
raise Exception(
"Adafruit IO settings are kept in settings.toml, please add them there."
"the settings file must contain 'ADAFRUIT_AIO_USERNAME' and "
"'ADAFRUIT_AIO_KEY'"
)
or
# Get WiFi details and Adafruit IO keys, ensure these are setup in settings.toml
# (visit io.adafruit.com if you need to create an account, or if you need your Adafruit IO key.)
ssid = getenv("CIRCUITPY_WIFI_SSID")
password = getenv("CIRCUITPY_WIFI_PASSWORD")
aio_username = getenv("ADAFRUIT_AIO_USERNAME")
aio_key = getenv("ADAFRUIT_AIO_KEY")
if None in [ssid, aio_username]:
raise Exception(
"WiFi and Adafruit IO settings are kept in settings.toml,"
"please add them there. the settings file must contain "
"'CIRCUITPY_WIFI_SSID', 'CIRCUITPY_WIFI_PASSWORD', "
"'ADAFRUIT_AIO_USERNAME' and 'ADAFRUIT_AIO_KEY' at a minimum"
)
if the project code that uses both, I would combine the if statement like if ssid is None or aio_username is None: and then have the message say both.
yeah π
tbh with it refactored that way I would go ahead and toss in password and aio_key too
lone axle
A network can have no password, but I'm not sure if None vs "" would make a difference
short tendon
I'll test getenv and see what it does. one sec
lone axle
though I have never tested on a network without a password. I assume it works okay, but there could be issues I'm not sure. I never considered it, hopefully it's not really being done π¬
most networks without a password tend to be public hot spots that have some other login or accept mechanism that would block our code I think.
short tendon
that totally works. So we could tell people to set it to:
CIRCUITPY_WIFI_PASSWORD=""
This look good?
# Get WiFi details and Adafruit IO keys, ensure these are setup in settings.toml
# (visit io.adafruit.com if you need to create an account, or if you need your Adafruit IO key.)
ssid = getenv("CIRCUITPY_WIFI_SSID")
password = getenv("CIRCUITPY_WIFI_PASSWORD")
aio_username = getenv("ADAFRUIT_AIO_USERNAME")
aio_key = getenv("ADAFRUIT_AIO_KEY")
if None in [ssid, password, aio_username, aio_key]:
raise KeyError(
"WiFi and Adafruit IO settings are kept in settings.toml, "
"please add them there. The settings file must contain "
"'CIRCUITPY_WIFI_SSID', 'CIRCUITPY_WIFI_PASSWORD', "
"'ADAFRUIT_AIO_USERNAME' and 'ADAFRUIT_AIO_KEY' at a minimum."
)
I get this:
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
KeyError: WiFi and Adafruit IO settings are kept in settings.toml, please add them there. The settings file must contain 'CIRCUITPY_WIFI_SSID', 'CIRCUITPY_WIFI_PASSWORD', 'ADAFRUIT_AIO_USERNAME' and 'ADAFRUIT_AIO_KEY' at a minimum.
Universities sometimes use this, where the mac address is authorised at the router so their open network is "safe". We had one crop up in wippersnapper (not the captive portal ones that crop up regularly)
willow totem
that totally works. So we could tell people to set it to:
```
CIRCUITPY_WIFI_PAS...
That's the default for a new file (storage.erase_filesystem) anyway isn't it?
lone axle
This look good?
```py
# Get WiFi details and Adafruit IO keys, ensure these are...
I would be inclined to have it be a ValueError
but I've not read the real definition of either, and I think it's not a huge difference either way.
willow totem
I always wonder about Value vs Key vs Argument errors. Sometimes it's obvious, but othertimes the pedant in me is never satisfied
lone axle
both are an upgrade over ImportError
short tendon
so if it's None, it means it's not there, so the key is missing
short tendon
That's the default for a new file (storage.erase_filesystem) anyway isn't it?
Is it? It put's it in there with no value?
stuck elbow
there is also RuntimeError which is a superclass of ValueError and KeyError
short tendon
I just did storage.erase_filesystem() and the settings.toml is empty
short tendon
@lone axle what exception would you like? RuntimeError works for me
lone axle
RuntimeError sounds good to me too.
short tendon
Awesome. I have most the code updated. Will open up the first PR tonight (9 files, all the ones in a folder that start with A) and leave a bunch of comments, that will make future reviews easier. (I was also wrong on the count, there's only like 80 files)
copper linden
i think i might of posted this question before, but can i add micropython libraries to circuitpython?
i wanted to expand the bluetooth low energy library
manic glacierBOT
tulip sleet
i think i might of posted this question before, but can i add micropython librar...
The native BLE API (_bleio on CPy) is different, so they won't work without adaptation.
copper linden
gotcha, would be nice if there were a lot of examples using _bleio
jaunty juniper
@storm linden I would open an issue in the Circuitpython repo.
from the original PR it looks like it's enabled only on one RP2040 board, which has CIRCUITPY_USB_HOST disable, I don't know if that's relevant
https://github.com/adafruit/circuitpython/pull/9164
onyx hinge
Howdy <@&356864093652516868> ! Double check your clocks & calendars, for Daylight Saving Time has come to the Adafruit factory in Brooklyn and thus to the weekly meeting time! So it's a little over 2 hours from now. To see the meeting time in your local time zone, check out the online calendar https://open-web-calendar.hosted.quelltext.eu/calendar.html?url=https%3A%2F%2Fraw.githubusercontent.com%2Fadafruit%2Fadafruit-circuitpython-weekly-meeting%2Fmain%2Fmeeting.ical&title=CircuitPython Meeting Schedule&tab=agenda&tabs=month&tabs=agenda
onyx hinge
<@531578874039894048> I would open an issue in the Circuitpython repo.
from the ...
@storm linden I am pretty sure it turns out that only one kind of USB host controller can be configured in a given build. So, when the PIO-based one is enabled, the max3421-based one cannot be enabled.
If that's accurate, this issue cannot be resolved within circuitpython but would require changes in tinyusb to support multiple different host controllers in a single build.
candid sun
<@&356864093652516868> We'll have our weekly meeting in about 1 hour & 20 minutes from now in this text channel and in the circuitpython voice channel. Please take the time to add your notes in advance to the document: https://docs.google.com/document/d/14g8cgraUdNkIX4AiUpA_r2YfkXm_8MIflEEAMV8GrDM/edit?tab=t.0 -- I look forward to everyone's updates!
random junco
I can hear both Liz & jepler
onyx hinge
if necessary I can be the host today. Except I have this cough...
onyx hinge
@candid sun I can do "core" if you like
@candid sun I can also grab blinka if you want
candid sun
@onyx hinge thank you!
onyx hinge
π
lone axle
Thanks for hosting Liz. Have a great week everyone. π
candid sun
Here is the notes document for next Mondayβs CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youβll be attending the meeting - itβs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weβll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1Ko1sPKV5IYbYRw7ZtuqmnlXF6drwYaU91RZNFuMBK6o/edit?tab=t.0
short tendon
hey @lone axle wanted to check and see if you saw the learn guide PR?
lone axle
hey <@382939733107408897> wanted to check and see if you saw the learn guide PR?
I did see it in the list, buthave not taken a closer look yet. I will this afternoon or tomorrow.
short tendon
Awesome
jaunty juniper
there's a
#ifdef CIRCUITPY_STATUS_LED
here, and I believe it should be #if
https://github.com/adafruit/circuitpython/blob/64e87e272fb5c882e28ed7369d7c47aa9e33ffa6/supervisor/shared/safe_mode.c#L65-L79
manic glacierBOT
tulip sleet
gotcha, would be nice if there were a lot of examples using _bleio
_bleio is meant to be a low-level API. The adafruit_ble library is built on top of it, and is the one normally used. There are a number of examples in that library: https://github.com/adafruit/Adafruit_CircuitPython_BLE/tree/main/examples. But it could still use a better overall writeup.
spare jacinth
there's a
```C
#ifdef CIRCUITPY_STATUS_LED
```
here, and I believe it should be ...
If you made that, using "0" as a status led wouldnt work, and i would guess thats a possible value for a GPIO (at least on some port)
Rather than checking for a magic value (zero), checking whether the configuration flag exists seems easier
Or does it mean "there is a LED" and not "led is this one"?
jaunty juniper
If you made that, using "0" as a status led wouldnt work, and i would guess that...
CIRCUITPY_STATUS_LED is a boolean that says if there's a status LED defined
in fact in that same code both #if and #ifdef are used
spare jacinth
Yeah, just saw it
#define CIRCUITPY_STATUS_LED ((CIRCUITPY_DIGITALIO && defined(MICROPY_HW_LED_STATUS)) || defined(MICROPY_HW_NEOPIXEL) || (defined(MICROPY_HW_APA102_MOSI) && defined(MICROPY_HW_APA102_SCK)) || CIRCUITPY_PWM_RGB_LED)
So yeah, always defined as far as i can tell, should be #if
jaunty juniper
I don't think it causes errors since new_status_color would do nothing in all of its #ifdef MICROPY_HW_LED_STATUS and such sections, and I don't know that we even have much boards without an LED, I just don't want to do a PR just for that π¬
tulip sleet
I don't think it causes errors since `new_status_color` would do nothing in all ...
ok to do a PR for one thing. If you have something else, sure, include it.
manic glacierBOT
manic glacierBOT
short tendon
@lone axle the next batch I'm doing have a secrets.py in the folder. Like this one. Should I just delete it?
lone axle
<@382939733107408897> the next batch I'm doing have a `secrets.py` in the folder...
I think I'm in favor of replacing it with settings.toml that contains similar placeholder values with the appropriate names for any values needed by the code.py
# This file is where you keep secret settings, passwords, and tokens!
# If you put them in the code you risk committing that info or sharing it
CIRCUITPY_WIFI_SSID="your-wifi-ssid"
CIRCUITPY_WIFI_PASSWORD="your-wifi-password"
ADAFRUIT_AIO_USERNAME="your-aio-username"
ADAFRUIT_AIO_KEY="your-super-long-aio-key"
For now at least. Perhaps there is room for wider discussion about whether we want these files checked in to the repo. I can see some benefits and drawbacks of both ways and don't necessarily have a strong opinion, but lean towards keeping it as similar as possible as it was before at the moment.
short tendon
okay, will change. Easy to delete afterwards
short tendon
I had an idea, tell me if I'm crazy. This always comes up this time a year (and again later) with apps getting off time. People can use the AIO datetime methods, but those are heavy.
I have a few projects that have the next 5 years of offsets so when I get time via NTP, I can adjust.
I thought about a package that had all of them, but it would be big. But then I was thinking we have the fonts library that installs specific fonts and that I could build it like that, where you could install a certain TZ or a region.
Then you could call NTP with a timezone instead of an offset and it would correct it for you.
And on top of that the library would have a self updating script to have the previous, current and next x years so as the world changes it's always up to date.
Thoughts?
crimson ferry
Is there anything in the core that uses an RP2350 (with wifi) state machine by default? I can create 5 PIO UARTs, but then I get RuntimeError: All state machines in use. I should be able to get 6?
Also I notice that the PIO UART doesn't have a receiver_buffer_size arg, so I assume it won't be able to absorb as much data in the background as a busio UART with a large buffer (what is the upper limit)?
mortal kernel
Is there anything in the core that uses an RP2350 (with `wifi`) state machine by...
That error message is in error. What's actually happening is you've run out of PIO program space.
The "All state machines in use" error is thrown if state machines are exhausted or PIO program space is full.
crimson ferry
@mortal kernel Thanks for the explanation. I'm going to test the receive buffering.
mortal kernel
<@849815081251766292> Thanks for the explanation. I'm going to test the receive ...
WiFi also uses a PIO state machine to emulate the gSPI link to the CYW43 so it could be either or both conditions.
crimson ferry
looks like 8 bytes is the limit for the PIO receive buffer
mortal kernel
looks like 8 bytes is the limit for the PIO receive buffer
PIO_UART is using a PIO state machine's RX FIFO as the receive buffer, a 4x32-bit FIFO, so it should be 16 bytes? Maybe I'm misunderstanding.
crimson ferry
maybe my test is wrong```py
buffer
bytearray(b'usukbpmugboseyqdtvdqafsgtyxhtuukhwzvmmlueruljointalggueutzmluqeu')uart_pio.write(buffer)
uart_busio.in_waiting
64
uart_busio.read(64)
b'usukbpmugboseyqdtvdqafsgtyxhtuukhwzvmmlueruljointalggueutzmluqeu'uart_busio.write(buffer)
64
uart_pio.in_waiting
8
uart_pio.read(64)
bytearray(b'usukbpmug')
(hardware : a busio UART connected to a PIO UART)
oh, it's 9 received, not 8 o_O, even though in_waiting is 8
mortal kernel
There's something in the low-level PIO support code that's returning the 8 I'm chasing down.
crimson ferry
if I write <=8 bytes, in_waiting matches the number of bytes read
mortal kernel
uart_pio.in_waiting is returning the number of 32-bit words in the FIFO, not the number of bytes. uart_busio.in_waiting looks like it returns bytes. At least that's what I'm seeing reading the code, but it's getting late and it's all a bit blurry...
crimson ferry
it's late here too... thanks for looking into it
mortal kernel
Feel free to hit me up tomorrow. I'll give it another look in the morning.
mortal kernel
@crimson ferry In the fresh light of dawn I've looked at the two flavors of in_waiting again. uart_pio.in_waiting returns the number of 32-bit words in the UART's RX state machine's FIFO. This behavior is documented correctly. Each PIO state machine has a pair of RX/TX FIFOs, each 4x32-bits. Since PIO_UART uses separate state machines for RX and TX, each state machine is programmed to combine its FIFOs into a single FIFO of 8x32-bits. So, the 8 you're seeing means that there are actually 32 bytes in the FIFO.
There is a bug in uart_pio.readinto() which is called by uart_pio.read() where it treats the value of self.rx_pio.in_waiting as a byte count. This should be looked into.
For uart_busio.in_waiting a byte count is returned. This is also correctly documented.
crimson ferry
@mortal kernel thanks again for digging in, though Iβm still confused because for small byte counts (<=8), PIO in-waiting is accurate. In any case, Iβll file an issue.
mortal kernel
For my own info, I'd like to know how you set up your test so I can play along at home. I'm digging into UART emulation on PIO for the first time.
crimson ferry
>>> uart_busio = busio.UART(board.GP0, board.GP1)
>>> uart_pio = adafruit_pio_uart.UART(board.GP26, board.GP27)
``` where GP0 is connected to GP27, and GP1 is connected to GP26. Then the code above, and I play with the length of the bytearray sent.(this is a Pimoroni Pico Plus 2 W with CP 9.2.4)
mortal kernel
Try changing the line
waiting = min(len(buf) - count, self.rx_pio.in_waiting)
to
waiting = min(len(buf) - count, self.rx_pio.in_waiting * 4)
in uart_pio.readinto()
crimson ferry
but for 1-8 bytes sent, in_waiting correctly shows 1-8, and read correctly reads 1-8. sending anything 9 or over shows 8 in_waiting (e.g, sending 128 shows 8), but receives 9 bytes (e.g., 128 bytes sent only gets 9 bytes read).
mortal kernel
I think that's at least partly due to the bug in readinto(). Your loopback is easy enough to set up. I'll give it a shot.
crimson ferry
complete example comparing busio and PIO UARTs (RP2350, with loopback wires between the two UARTs)
tulip sleet
@crimson ferry @mortal kernel I suggest that having .in_waiting return a word count is a bug, even if it's documented. When I look at https://github.com/adafruit/Adafruit_CircuitPython_PIO_UART/blob/fa6496a4dc2d66493402cf6f52707901317b4df3/adafruit_pio_uart.py#L147 it says """Return whether the UART is waiting.""". .in_waiting in some libraries used to return a bool, which is what the description implies.
is https://github.com/adafruit/Adafruit_CircuitPython_PIO_UART/blob/fa6496a4dc2d66493402cf6f52707901317b4df3/adafruit_pio_uart.py#L168 right? It's using .in_waiting. Is the buffering by words or by bytes?
crimson ferry
busio returns the number of bytes accurately for in_waiting
@mortal kernel if I make the library change, the output is the same through buflen=10, but then it hangs up in the read on 10
PIO should behave as much like busio as possible?
mortal kernel
@danh The description is wrong in PIO_UART for in_waiting. What it actually does is call into the SDK function pio_sm_get_rx_fifo_level() via common_hal_rp2pio_statemachine_get_in_waiting() via rp2pio_statemachine_obj_get_in_waiting(). The SDK reads the 4-bit hardware level corresponding to the state machine, a count of 32-bit words in the FIFO. The FIFO acts as a SERDES, in this case taking bits from the SM and delivering them as 32-bit words via the FIFO.
tulip sleet
anything_UART should have an API like busio.UART and bitbangio, so they can be used interchangeably.
mortal kernel
OK, so if I'm understanding correctly we should be returning the raw value from the SDK multiplied by 4 to convert it to bytes.
tulip sleet
@danh The description is wrong in PIO_UART for `in_waiting`. What it actually do...
is it always in chunks of 4? What happens if there are only three bytes queued?
how can we tell if there is anythingto read? and how do we distinguish between three bytes received and four bytes received?
mortal kernel
good question. My assumption is that as soon as there is anything in FIFO it starts reporting 1 word. I think we need an experiment to be sure, the RP2350 datasheet doesn't make it clear.
tulip sleet
there must be some way of knowing how many bytes there are, unless it's that nulls are always discarded or something, but that's not a good impl of UART in that case
the PIO program itself keeps track??
I did not look at the PIO code
mortal kernel
The PIO program just looks for the "eye" and then clocks in 8 bits. Dead simple. No overall byte count.
mortal kernel
Yes, that's a limitation of the PIO FIFO.
tulip sleet
could it move on to the next 32-bit word after one byte, so that it's only one byte per word?
is this PIO program from pico-examples or similar?
mortal kernel
I think so, but again it deserves an experiment to know for sure. And yes, it looks like it came out of the datasheet.
tulip sleet
π π
mortal kernel
I'm going AWK for breakfast and a walk. Be back in an hour or so, hopefully with some fresh ideas of how proceed...
tulip sleet
@crimson ferry this should be an issue on the library, no? I can transfer it. I don't see it's a core issue
crimson ferry
Transferred.
I wonder if PIO UART should be in the core. There is no receiver_buffer_size argument in the init. My assumption is that the read buffer will be very limited in how many bytes it can hold in the background while user code is doing something else, so any PIO UART usage will have to be very carefully choreographed.
tulip sleet
I wonder if PIO UART should be in the core. There is no `receiver_buffer_size` a...
I think that could be fixed in the library.
sage violet
yes its limited to reading raw data i cant manage to read mouse scroll up and down its been a long time.
crimson ferry
I think that could be fixed in the library.
But the python library wouldnβt be in the background? And Iβm just guessing that PIO itself is too limited to hold a big buffer? busio can have a huge buffer, that can be filled while user code is doing something else.
unless PIO can push to a python buffer, but that sounds weird
tulip sleet
But the python library wouldnβt be in the background? And Iβm just guessing that...
The PIO program runs in the background. I think you could pass a buffer in to the PIO program that is as big as you want. https://docs.circuitpython.org/en/latest/shared-bindings/rp2pio/index.html#rp2pio.StateMachine.background_read could do it, I think
that is a recent addition
crimson ferry
I wasnβt aware of that one, that sounds pretty cool
mortal kernel
The PIO program runs in the background. I think you could pass a buffer in to th...
I got back from my walk thinking DMA might be the answer, but it looks like rp2pio is way ahead of me. Under the covers background_read() is doing just that plus some wildly creative things with byte-lane smearing. Looks like adafruit_pio_uart needs some re-work to take advantage of this fine machinery.
slender iron
why are you worried about pio uart?
crimson ferry
raspberrypi is limited to two busio UARTs, and there's no bitbangio UART
(and there's a bug and perhaps some other improvements, in the library)
slender iron
rp2 or broadcom chips?
mortal kernel
Digging into it has proven to be a great way to learn about rp2pio.
crimson ferry
rp2
slender iron
2040 or 2350?
crimson ferry
presumably both, I've been testing on RP2350
was thinking this morning to verify on RP2040
slender iron
looks like you are right. I thought it was more than two hardware uarts
crimson ferry
having up to 8 bidirectional UARTs on an RP2350 could be pretty powerful π
slender iron
looks to me like the library will need to be switched to the background pio stuff
otherwise you are capped by the PIO fifo length
busio also has a cap, it is just larger
crimson ferry
65535 iirc
slender iron
I think its the rx buffer size
crimson ferry
yeah, confirmed: busio receiver_buffer_size is 1-65535
crimson ferry
was thinking this morning to verify on RP2040
same PIO UART behavior on RP2040 as RP2035 (will update issue)
blissful pollen
Quick question: are all CP boards at least 32-bit? I think the answer is yes but just wanted to be sure.
crimson ferry
WiFi also uses a PIO state machine to emulate the gSPI link to the CYW43 so it c...
confirmed: RP2040 w/o wifi allows 4 bidirectional PIO UARTs instead of 3 on PicoW (non-wifi RP2350 should allow 6 bidirectional; wifi RP2350 allows 5)
onyx hinge
@blissful pollen yes, all have at least 32 bit addresses & 32 bit registers. it may be the case that the broadcom port has 64-bit addresses and/or 64-bit registers, I don't know for sure. But I'm also curious why you ask the question.
blissful pollen
<@228322543507865601> yes, all have at least 32 bit addresses & 32 bit registers...
Discussion with Cooper / idea on internal audio processing. I was thinking keeping samples 32-bit and then do the mix down right before going out (to 16 bit or 8 bit or some future format).
But if we used 32-bit on a 16-bit processor they could be a big performance hit.
onyx hinge
You can probably think of cortex-m0plus as kind of a baseline of CPUs for CircuitPython (even though there are some others like xtensa & risc-v in the mix now). Multiplying signed 16x16 bits, 16x32 bits & 32x32 bits to an output of 32 bits is all the same instruction (muls).
But when treating integer numbers as "fixed point", you're often interested in the upper bits of the multiplication. For instance, if you talk about "Q1.15" numbers and you want to get the product of two of them as another "Q1.15" number, you need the upper bits, just like if you multiply out "99 * 99" you get "9801", but when you multiply ".99 * .99" you need to get ".9801", the top 2 digits instead of the bottom two digits ...
so when you shift to doing multiplies on 32 bit quantities that are implicitly representing binary fractions with a fixed precision, you actually need to do a 64-bit multiply (and take the upper part), and that is less efficient than taking the upper part of the 32-bit part of a muls result.
int32_t mulshift32(int32_t a, int32_t b) {
return ((uint64_t)a * b) / (1ll << 31);
}```On cortex-m0plus this compiles to much more complex code than the 16-bit version, calling a function `__aeabi_lmul` to perform the actual multiplicatoin. On cortex-m3, there's a new instruction "smull" (signed multiply upper ll??). So, even though both the rp2040 and rp2350 are "32 bits", they will have very different performance characteristics when multiplying 32-bit fixed point numbers(similarly, rp2350 has a built in division instruction while on rp2040 it's a function call) You can see what each CPU generates here: https://godbolt.org/z/cKhET8vWK
I mis-spoke, rp2350 is cortex-m33 (not cortex-m3) but they seem to be the same when it comes to having sdiv & smull instructions available.
blissful pollen
Oh cool, thanks! That gives me a bunch of stuff to look into further.
The root issue I've been thinking about is how the audio pipeline could repeatedly saturate 16 bits and mix it down from stage to stage (synth->echo->reverb for example) and maybe it would make sense to keep it 32-bit to the end.
I haven't spent much time ever dealing with fixed point so will dive down that rabbit hole for a while too.
onyx hinge
*out_buffer32++ += (*tmp_buffer32 * loudness[0]) >> 16; this is an example of a fixed point multiplication, where some sample is being multiplied by loudness and then shifted down (from shared-module/synthio/__init__.c)
blissful pollen
I don't think I quite grasped the shifts I saw before but now it makes a lot more sense.
onyx hinge
I know you weren't angling for such a brain dump but there ya go π
(also that operation is a bit dubious now that I look at it, because the result of multiplying 32-bit tmp_buffer with 16-bit loudness could be 48 bits, but it's only 32-bit arithmetic that's being done there...)
blissful pollen
The brain dump is more then welcome. I've been spending some (too?) much time with ChatGPT and audio source code from other similar software to get ideas and learn. The fixed point part never jumped out at me.
onyx hinge
RP2350 datasheet sections 3.7.4.9 gives some info about how long operations take. For instance, a 32-bit multiplication result is available with a 1-cycle delay, while divisions take a variable amount of time related to the operands..
blissful pollen
(also that operation is a bit dubious now that I look at it, because the result ...
Hmm I have seen a weird audio glitch when I played loud multiple note audio but never got a chance to chase it. That could be a good starting point. It also was not easily repeatable.
onyx hinge
also see rp2350 datasheet section "3.7.4.9.10. Floating-point coprocessor operations." on cortex m33 32-bit float arithmetic is pretty fast too and it saves you from having to manually track scale factors. you can't forget a >>16, or a spot where you really needed a 48-bit multiply instead of a 32-bit one. honestly if moving beyond 16 bit integer stuff I'd prototype this first, and if it's good enough on rp2350 & some nicer esp32 say "yeah, we're doing [new] audio in floating point now". Stuff like biquad filter coefficients, which REALLY are resistant to reducing to 16-bit fixed point, would be much happier. (some specific things like note phase for direct digitital synthesis in synthio should stay integer though)
blissful pollen
So far this is in my long term idea bucket, but for sure needs a prototype to test it out. I am curious on saw a 2040 what speeds are still possible or alternatives. And at a minimum to not break audio on older processers π
slender iron
@lone axle you around still and want to talk fonts?
lone axle
<@382939733107408897> you around still and want to talk fonts?
Yes, give me 5-10 minutes to shoot a few photos that I'm all set up for and then I can.
slender iron
thanks
lone axle
@slender iron okay, ready any time.
onyx hinge
randomly ran across notes on rendering hangul (korean) without extremely large font sizes.. https://oberg.org/posts/hangul/
slender iron
randomly ran across notes on rendering hangul (korean) without extremely large f...
I glanced at this too: https://unifoundry.com/hangul/index.html
wheat siren
Would there be any opposition to adding Direction and Value to the DigitalInOut constructor? I've found myself wrapping it into a single function when initialising lots of I/O
# DigitalInOut
def __init__(
self,
pin : microcontroller.Pin,
direction: Optional[digitalio.Direction] = None,
value: Optional[bool] = None
): ...
This lets you do things like
led_pins = (board.D1, board.D2, board.D3)
led_io = (
DigitalInOut(
p,
Direction.OUTPUT,
False
) for p in led_pins
)
@wheat siren this has been discussed before (https://github.com/adafruit/circuitpython/issues/5124#issuecomment-896929174 and others) and the official word from @slender iron is as follows:
The reason we don't allow it from the constructor is that it's weird to have keyword arguments that are only valid depending on another (direction). Value and drive mode are for output and pull is for input. The class does default to input so we could add a pull kwarg. That'd simplify the input case. I'd push back against combining them.
wheat siren
Ah thank you!
tulip sleet
Ah thank you!
See https://github.com/adafruit/circuitpython/issues/9845 for a proposal for a different way of doing this that passes pin configurations to anything that currently takes a bare Pin. I am planning to implement this for CircuitPython 10
manic glacierBOT
lime mason
Adafruit Trinkey Proximity issues with version 7.2.1 and beyond not running code for more than a sec
mortal kernel
Curious about XIP performance, I created a benchmark: https://gist.github.com/eightycc/478033e458a2fd6b7da95a5c4c082679
(scroll down in gist for results on Adafruit RP2350 feather w/PSRAM)
mortal kernel
Following up on previous timing tests, I successfully overclocked the RP2350 feather to 240 MHz and increased the PSRAM QSPI clock from 75 MHz to 120 MHz: https://gist.github.com/eightycc/b61813c05899281ce7d2a2f86490be3b
Scroll down in the gist to see the timing results.
slender iron
<@&356864093652516868> Just a quick reminder that the community meeting is in 1 hour and 15 minutes. The US did our time change so we're in the weird shifted period. Talk with you soon! (Notes doc in the pinned messages.)
onyx hinge
yup the rp1 pio related repos like piomatter are now included in the reports
piomatter is n steps forward, (n^1) steps back right now
willow totem
omg yeah, chips challenge was really well done (surprised not more recognised by folks - wish they'd demo'd the challenging block types)
blissful pollen
Canβt speak now sorry
onyx hinge
(ie., if n=2, then it's 2 steps forward, 1 step back; but if n=1 then it's 1 step forward, 2 steps back. I'm a nerd)
@mortal kernel I think some of the clocking you're describing in your notes is similar to what dvhstx does. specifically, it reserves 1 PLL just for hstx and clocks everything else including CPU & USB from a 528MHz PLL.
I dunno what PSRAM boundary mode is though
can you select() or poll() all the open sockets to get the "data available" flag?
tulip sleet
can you select() or poll() all the open sockets to get the "data available" flag...
not exactly, but I could make a polling task that runs in the background. In the old way, it hooked in a routine on packet routine that set a flag, basically. I tried duplicating that but it crashed. I need to debug that.
there is a hook mechanism in lwip I could use, but it would require recompiling the arduino-esp32 libraries, I think.
mortal kernel
@onyx hinge Let's chat after the meeting.
onyx hinge
@mortal kernel depending when we finish I can stick around for a few minutes.
https://github.com/MichaelBell/dvhstx/blob/main/drivers/dvhstx/dvhstx.cpp#L433 <- the dvhstx clocking code I mentioned
A reminder of why we have frozen come before lib would be helpful @slender iron because I know you have a rationale
lone axle
Adding a section to our reports that checks frozen modules version against current releases does sound like it would be nice.
mortal kernel
@onyx hinge Thanks for the dvhstx link. That answers my question.
On PSRAM boundary crossing mode. The PSRAM parts refresh internally. If you promise the part that you'll pause at at "wrap" boundaries it can refresh then. This allows a faster SPI clock to be used.
There's a special 0xc0 op that toggles the control.
onyx hinge
@mortal kernel OK then I'll sign off when the meeting is through. source code is worth 100x as much as an explanation from someone who's merely read the source...
lone axle
Thanks for hosting Scott, have a great week everyone!
willow totem
Would it be too insane to have a different default path order for m0 (trinkeys) and tiny flash boards, i.e. keep frozen first for them, but move path order to have frozen last by default?
slender iron
I don't think its worth it. Any place that needs frozen also needs those libraries out of RAM.
Maybe we need a troubleshooting/FAQ entry about adjusting sys.path for version issues.
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/15NZc6nDGYZSXt41qXQ1whWKbiChyfmh00CQwtD_NlYY/edit?usp=sharing
slender iron
Here is the notes document for next Mondayβs CircuitPython Weekly Meeting. It is...
fleet hollow
@slender iron Quick typo on the youtube video of the meeting. Should be March 17th, not 27th. https://www.youtube.com/watch?v=0oO-b3eDTlo
slender iron
<@252717193496756235> Quick typo on the youtube video of the meeting. Should be ...
Fixed! Thanks
my audio isn't as easy as a fix
slender iron
FYI Dan and I are going over issues in prep for CP 10.
The LUN stuff is destabilizing enough to switch main to 10.
mortal kernel
The LUN stuff is destabilizing enough to switch main to 10.
If there's anything I can do to help, let me know.
midnight ember
This weeks meeting recording is kind of unwatchable. Sounds like some serious buffering issues. Hope you get it figured out. π¦
slender iron
This weeks meeting recording is kind of unwatchable. Sounds like some serious bu...
Sorry about that! I didn't realize it beforehand. I'd suggest skipping to hug reports and status updates. Other folks' audio is fine
slender iron
@lone axle is it quick for you to do a ruff update? bitmap_font is giving me trouble
lone axle
<@382939733107408897> is it quick for you to do a ruff update? bitmap_font is gi...
it depends on how many things get flagged within the library. I can give it a try in a moment on that library.
slender iron
thank you!
lone axle
thank you!
https://github.com/adafruit/Adafruit_CircuitPython_Bitmap_Font/pull/68 is submitted for converting to ruff.
tulip sleet
@lone axle did you make a backup recording?
lone axle
<@382939733107408897> did you make a backup recording?
I did, although it would need a little bit of touchup, I was early on the record button so there are several seconds at the front that could be clipped.
I also accidentally pressed stop recording after the library section of stats but started again quickly, I don't think much was missed but I have 2 files that need to be spliced.
I have been practicing ffmpeg some, I think both will be fairly easy. I'll attempt and share a link to the result
tulip sleet
I did, although it would need a little bit of touchup, I was early on the record...
@slender iron Thanks! π
lone axle
slender iron
<@252717193496756235> https://www.dropbox.com/scl/fi/bsbwf65wayxo633k8hjr9/meeti...
Thanks! I published it to youtube and updated the notes and newsletter with the new link.
lone axle
@slender iron in bitmapt_font I think the LVGL_HEADER_SIZE varible got lost somewhere, it's tested against but doesn't seem to be defined.
slender iron
# The LVGL file starts with the size of the 'head' section. It hasn't changed in five years so
# we can treat it like a magic number.
LVGL_HEADER_SIZE = b"\x30\x00\x00\x00"
not sure how it got lost
maybe I hit discard instead of stage
πΆ βοΈ
lone axle
@slender iron it's used in bitmap_font.py, so it needs imported over there. I added that in my local copy and it is working though π
ah, it is imported, but it's inside the the block that tried to check against it.
slender iron
ah, it is imported, but it's inside the the block that tried to check against it...
kk, will fix tomorrow
supple prairie
Am I a dummy or are there no examples for HSTX on the Adafruit website? I've been looking and can't find them (reportedly there are)
stuck elbow
Am I a dummy or are there no examples for HSTX on the Adafruit website? I've bee...
there seem to be a bunch, like https://learn.adafruit.com/breakout-game-on-metro-rp2350/code
supple prairie
there seem to be a bunch, like https://learn.adafruit.com/breakout-game-on-metro...
tyvm. I am quite clearly blind π
blissful pollen
@onyx hinge no rush on this question, but for the synth work does it assume Q15 for most of the math / processing?
Iβve been reading way more about fixed point and now wondering if we should target it as much as possible for effects too.
onyx hinge
<@426200547024961539> no rush on this question, but for the synth work does it a...
"More or less"
Its a bit more ad hoc but in general yes
blissful pollen
Thanks! I finally got my head around it all and it made sense
tulip sleet
@slender iron @onyx hinge @mortal kernel I'm seeing CI build errors on PR's due to URL's like https://files.nordicsemi.com/artifactory/swtools/external/nrfutil/index/x86_64-unknown-linux-gnu/nrfutil-nrf5sdk-tools no longer working. Not sure if this is temporary or they have moved things.
(β―Β°β‘Β°)β―οΈ΅ β»ββ»
I'm making up release notes for 9.2.5 and will investigate this afterwards.
onyx hinge
@tulip sleet that's terrible. argh.
manic glacierBOT
manic glacierBOT
tulip sleet
@slender iron @onyx hinge @mortal kernel CI fetch issue with the nordic URL's was transient. A re-run worked. When using the URL in a browser, the result is confusing, but wget works fine.
orchid basinBOT
mortal kernel
π
tulip sleet
https://blog.adafruit.com/2025/03/18/circuitpython-9-2-5-released/
Highlights of this release:
- Update frozen modules.
- Enable function attributes and reverse arithmetic operators on most boards.
- displayio:
- Add tilepalettemapper.
- Add VT100 escape code support for scrolling and colors.
- synthio and audiodelays additions.
- Add audioio on Espressif.
- Add spitarget on SAMx (enabled on most SAMx5x boards).
- Initial work on a Zephyr port.
- Bug fixes.
jaunty juniper
I'm adding the Waveshare-ESP32-S3-Touch-LCD-2 to CP and tinyUF2 and that board is a little weird as it doesn't go into ROM bootloader but tinyuf2 when resetting while holding BOOT, only when plugging while holding BOOT does it go into the bootloader. Now according to the schematics GPIO 0 is also used for the LCD reset pin, so maybe there's something there π€·
jaunty juniper
on the other hand it makes it easier to boot into UF2 mode π
manic glacierBOT
tulip sleet
@slender iron @onyx hinge @mortal kernel et al I just created a 9.2.x branch. So main is now for 10.0.0. Any bugfixes for 9.x.x would be PR's against 9.2.x. If we move on to a 9.3.0 we would create a 9.3.x branch off 9.2.x
slender iron
<@252717193496756235> <@426200547024961539> <@849815081251766292> et al I just c...
Please push a 10.0.0-alpha.0 tag to main too. (Do we have any newer commits yet?)
tulip sleet
not yet,
slender iron
kk, we should be able to merge some of @mortal kernel's changes and then tag them
tulip sleet
also I need to fix the readthedocs defaults
slender iron
ok, there we go!
tulip sleet
I tagged 9.2.5 also as 10.0.0-alpha.0, so #10144 is after that.
slender iron
does that confuse the version determination?
tulip sleet
hmm maybe so, I can move it
tulip sleet
ok, moved to the first commit after
slender iron
thanks!
tulip sleet
@slender iron @mortal kernel @onyx hinge This is the easiest way I've found to get new branches into your fork:
git fetch adafruit 9.2.x:9.2.x
also do a git fetch adafruit --tags to pick up the 10.0.0-alpha.0 tag
mortal kernel
<@252717193496756235> <@849815081251766292> <@426200547024961539> This is the ea...
Worked like a charm. β€οΈ
tidal kiln
this might be expected behavior? or might be indicating something? using a Metro M4 and loading 9.2.5 - it does not show any activity (dmesg) after UF2 is copied and reset.
it may be related to the Metro M4 being in a weird state (not sure what last usage was)
can load 9.2.4, and it will go into safemode and give a com port
which shows:
Auto-reload is off.
Running in safe mode! Not running saved code.
You are in safe mode because:
CIRCUITPY drive could not be found or created.
Press reset to exit safe mode.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 9.2.4 on 2025-01-28; Adafruit Metro M4 Express with samd51j19
>>>
so i'm thinking of doing a storage.erase() next, but posting here first in case this is worth looking at further?
UF2 Bootloader v3.15.0 SFHWRO
Model: Metro M4 Express
Board-ID: SAMD51J19A-Metro-v0
@tidal kiln I am not sure what could cause that issue, but I just loaded 9.2.5 on my metro M4 with no issues, it boots up and seems to behave normal under 9.2.5
tidal kiln
hmmm...my Metro M4 Express "BETA" board comes up fine
maybe this one not working is an even older variant
components are located different
left one works, right one is weird
different flash chips
lone axle
mine looks closer to the left, but not quite the same silkscreen at least
tidal kiln
yah. i think maybe it's just this board. been too long to remember, but i think i got one pre-beta for testing.
wraith crow
@tulip sleet I'm going to take another look at the multi-display issue, which tag/branch would you prefer I base my work on in case it results in a PR?
tulip sleet
<@329766224093249548> I'm going to take another look at the multi-display issue,...
If it's going to change an API, then main is preferable. Otherwise either is fine. We are going to merge changes from 9.2.x into main as needed.
ionic elk
I'm basing my ros circuitpython rclcpy module off rclpy, which has lots of features that will not be supported. Should I still include all unsupported arguments and give them NotImplemented errors?
solar whale
yah. i think maybe it's just this board. been too long to remember, but i think ...
IIRC there was a very early Metro M4 that was "abandoned"...
tulip sleet
maybe this one not working is an even older variant
That is a rev b proto that had different pin mappings and had some kind of bug. My sample is in a box of obsolete boards
The plain type "M4" and the B in a circle is the giveaway, I think.
solar whale
tidal kiln
That is a rev b proto that had different pin mappings and had some kind of bug. ...
thanks. gonna mark this one for next time i dig into this box-o-metros.
solar whale
Off the fantail with it! π When I used to work in Oceanography and would spend several weeks on research ships at sea, I had a "fantail rule" for dealing with defective 8" floppy discs and mag tapes. If they failed, they were to be taken to the ships fantail and thown overboard so that they could not find their way back to use. This was 45 years ago and we were not quite so conscious of the environmental impact, Probably could have just binned them, but it was fun to fling them off the fantail. The impact of having one get re-used was significant!
manic glacierBOT
onyx hinge
huh I must have just imagined that we had put the web workflow hostname in os.uname
mortal kernel
Didn't see it there, let me scan to see if it was in any of the ports...
Nope, not there.
onyx hinge
no, I don't see it either
mortal kernel
It would be handy to have os.uname().hostname. I'll open an issue and see what Scott thinks.
jaunty juniper
we don't want to do that, os.uname is a C python thing
it does define only 5 attributes and doesn't seem to allow for implementation-specific additions ?
but nodename should be the hostname
mortal kernel
I see that. CP is doing nodename incorrectly.
jaunty juniper
I mean, "implementation-defined" right ? π¬
the thing is i'm gonna bet nobody uses nodename on desktop python anyway, since as the docs mentions it's a poor substitute for a hostname, it might even be truncated
mortal kernel
Agree, probably not used. Would be nice to get it right, though?
jaunty juniper
yeah
mortal kernel
OK, I'll make an issue and throw it back in the hopper for now. All the other members of the tuple are static, so implementation will take a little more thought.
jaunty juniper
yeah, and the default mdns name cpy-1234-stuff is created dynamically deep into port implementations of the wifi module within common_hal_wifi_init, it could be moved into a dedicated supervisor thing or something
jaunty juniper
should I rebase a PR to add a board on 9.2.x rather than main ?
tulip sleet
should I rebase a PR to add a board on 9.2.x rather than main ?
You could try that, but for some reason it often doesn't seem to work.
jaunty juniper
ok, github didn't complain so far, it doesn't seem to redo the checks but that's fine
slender iron
manic glacierBOT
orchid basinBOT
short tendon
Is there a thought of adding CIRCUITPY_SAVES_PARTITION_SIZE on other boards? Even if it was just a few kb?
wraith crow
When I started my PR, I performed a git checkout remotes/circuitpython/9.2.5 (my fork is actually of micropython so I need to reference circuitpython as a remote) which I thought would end up allowing me to post the PR against that tag, however when I do a git compare against the 9.2.5 tag, I don't have an option to create a PR. How do (or can) I perform the PR post against 9.2.5. Not that it's critical, just trying to create as little work for Dan as possible
It does look like I can do a merge to the 9.2.x branch, is that the route I should go? I'll merge to 9.2.x, I can always resubmit it if there's a better choice π
manic glacierBOT
manic glacierBOT
manic glacierBOT
slender iron
@mortal kernel I've never done JTAG on ESP. I think Jeff did manage to. I usually do printf debugging. DEBUG=1 on the make command will start the ESP_LOGing
mortal kernel
<@849815081251766292> I've never done JTAG on ESP. I think Jeff did manage to. I...
I'm seeing an asynchronous failure that's triggered by CP calling IDF RMT code, but faulting a couple of seconds later. It's going to be tough to pinpoint. I'll look into ESP logging and also ping Jeff in the morning.
lone sandalBOT
zinc walrus
(btw if any CircuitPython dev wants a pico8enc PCB mailed to them, let me know)
@devout jolt Can the pico8enc PCB have the Pico temporarily attached via headers, or does it have to be directly castellated soldered permanently?
onyx hinge
I'm seeing an asynchronous failure that's triggered by CP calling IDF RMT code, ...
I don't have any specific recollection about jtag on espressif, other than that the board where it worked well enough was the Kaluga (ESP32-S2) that had a 2nd USB interface for UART & JTAG (ftdi chip)... and I found a script that started openocd like this: exec $HOME/.espressif/tools/openocd-esp32/v0.10.0-esp32-20200709/openocd-esp32/bin/openocd -f board/esp32s2-kaluga-1.cfg -c "gdb_port 2331"
bin/start-stub-metros2:exec $HOME/.espressif/tools/openocd-esp32/v0.10.0-esp32-20200709/openocd-esp32/bin/openocd -f $HOME/esp32s2-metro-jlink.cfg -c "gdb_port 2331" I may have also debugged the metro s2 with a jlink & openocd
mortal kernel
I don't have any specific recollection about jtag on espressif, other than that ...
Much appreciated. I'm going to give JTAG over the USB port a try for a limited amount of time. Espressif has some documentation too, so it's not completely hopeless.
One more quick question, which version of ESP-IDF are we using?
tulip sleet
One more quick question, which version of ESP-IDF are we using?
5.3.2
if you go into the esp-idf submodule, you should be able to see that tag in git log at the top
mortal kernel
5.3.2
I see. It looks like we're on branch circuitpython-v5.3.2 of Adafruit repo https://github.com/adafruit/esp-idf/ which includes 7 commits on top of the Espressif 5.3.2 release.
tulip sleet
I see. It looks like we're on branch `circuitpython-v5.3.2` of Adafruit repo htt...
yes, those are patches I think we have mostly submitted upstream but they haven't taken yet
mortal kernel
I'm having a touch of trouble building an Espressif board. Here's what I'm seeing:
(.venv) βͺ make BOARD=adafruit_feather_esp32s3_4mbflash_2mbpsram -j16
- Verbosity options: any combination of "steps commands rules", as `make V=...` or env var BUILD_VERBOSE
-- Building ESP-IDF components for target esp32s3
-- Checking Python dependencies...
Python requirements are satisfied.
Constraint file: /home/rabeles/.espressif/espidf.constraints.v5.3.txt
Requirement files:
- /home/rabeles/Development/cp-development/issue-10004/cp-repo-issue-10004/ports/espressif/esp-idf/tools/requirements/requirements.core.txt
Python being checked: /home/rabeles/.espressif/python_env/idf5.3_py3.11_env/bin/python
CMake Error at esp-idf/tools/cmake/build.cmake:552 (message):
/home/rabeles/Development/cp-development/issue-10004/cp-repo-issue-10004/.venv/bin/python:
Error while finding module specification for
'idf_component_manager.prepare_components' (ModuleNotFoundError: No module
named 'idf_component_manager')
Call Stack (most recent call first):
esp-idf/tools/cmake/project.cmake:710 (idf_build_process)
CMakeLists.txt:12 (project)
-- Configuring incomplete, errors occurred!
start with a fresh terminal. If you have an existing python venv, deactivate it. Then do source esp-idf/export.sh. Then remove the build directory. Or have you done this many times before??
export.sh sets up its own venv
also you need to do esp-idf/install.sh first
mortal kernel
I'm starting again with a fresh repo clone. It's been a while since I built for Espressif, and I see that I should not have used my own venv. Ooops.
tulip sleet
also don' forget make fetch-all-submodules at the top level or make fetch-port-submodules at ports/espressif
this is meant to covered in https://learn.adafruit.com/building-circuitpython/espressif-build but i may have left things out or wrong order
oh also install python packages...
mortal kernel
No worries. I'm toying with the idea of putting the entire Espressif process into a Docker container. It doesn't seem to play well with my installation.
mortal kernel
oh also install python packages...
Going over my notes from the last time I see that I needed to do the pip step twice. Once before and once after the export step.
Here's what I wrote the last time:
# There are version conflicts between the ESP-IDF and CP Python package
# requirements. We enter the ESP-IDF virtualenv, install CP requirements,
# and then re-run the install script to force version requirements to follow
# the ESP-IDF requirements. Effective while the ESP-IDF virtualenv is active.
For a Docker container it looks like this:
RUN cd ${CPBUILDENV_USER_HOME}/temp-cp-repo/ports/espressif && \
source esp-idf/export.sh && \
cd ../.. && \
pip install --upgrade -r requirements-dev.txt && \
pip install --upgrade -r requirements-doc.txt && \
cd ports/espressif && \
esp-idf/install.sh
It's all fine now. Thanks for the tips. If you like, I can send you notes for updating your espressif-build article.
tulip sleet
It's all fine now. Thanks for the tips. If you like, I can send you notes for up...
that would be great!
mortal kernel
that would be great!
Here's a gist with my CircuitPython for Espressif build instructions: https://gist.github.com/eightycc/197a12ffb747e21aa72bdedb2cade818
manic glacierBOT
jaunty juniper
@wraith crow is the SDIO error after a power cycle or after running the SPI code ? Can an SD card switch from SPI mode back to SDIO on the fly ?
mortal kernel
@danh Is there a mechanism for merging 9.2.x PRs into 10? I'm assuming it will get done manually.
manic glacierBOT
manic glacierBOT
manic glacierBOT
orchid basinBOT
tulip sleet
π€¦ I made 9.2.6 off of main instead of 9.2.x by mistake. It was early enough that I deleted the tag and stopped the release process, and re-did it properly. If it had been longer, I would have just skipped 9.2.6.
EDIT: This was not such a good idea, because the stubs had already been uploaded to PyPi, and PyPi doesn't let you replace a file.
manic glacierBOT
tulip sleet
https://blog.adafruit.com/2025/03/22/circuitpython-9-2-6-released/
Highlights of this release
- Fix
storage.remount("/", readonly=False)regression. - Fix RP2xxx WiFi mDNS limitations.
manic glacierBOT
manic glacierBOT
manic glacierBOT
mortal kernel
I'm attempting to build CP with DEBUG=1 for an Espressif ESP32-S3 and getting a "Too little flash!!!" message:
Memory region Used Size Region Size %age Used
iram0_0_seg: 107776 B 358144 B 30.09%
iram0_2_seg: 1203530 B 8388576 B 14.35%
dram0_0_seg: 169640 B 341760 B 49.64%
drom0_0_seg: 1585949 B 33554400 B 4.73%
rtc_iram_seg: 4360 B 8168 B 53.38%
rtc_reserved_seg: 24 B 24 B 100.00%
rtc_slow_seg: 0 GB 16 B 0.00%
extern_ram_seg: 1638368 B 33554400 B 4.88%
esptool.py v4.8.1
Creating esp32s3 image...
Merged 3 ELF sections
Successfully created esp32s3 image.
1669856 bytes used, -228064 bytes free in flash firmware space out of 1441792 bytes (1408.0kB).
4384 bytes used, 3808 bytes free in 'RTC Fast Memory' out of 8192 bytes (8.0kB).
0 bytes used, 8192 bytes free in 'RTC Slow Memory' out of 8192 bytes (8.0kB).
16383 bytes used, 16385 bytes free in 'Internal SRAM 0' out of 32768 bytes (32.0kB).
169640 bytes used, 256344 bytes free in 'Internal SRAM 1' out of 425984 bytes (416.0kB).
0 bytes used, 65536 bytes free in 'Internal SRAM 2' out of 65536 bytes (64.0kB).
Too little flash!!!
Any hints will be appreciatedπ
jaunty juniper
you gotta disable some modules to make space
I believe it fits with bigger flash if you can use that for debugging
like with 8MB+ flash the partition for CP is 2MB instead of 1.4
mortal kernel
Been using a Feather w/4MB. I've got a larger Metro around here somewhere...
mortal kernel
like with 8MB+ flash the partition for CP is 2MB instead of 1.4
Building for the Metro ESP32S3 did the trick. Thank you!
tulip sleet
I'm attempting to build CP with DEBUG=1 for an Espressif ESP32-S3 and getting a ...
also, disabling ulab is often a quick fix if you want to build for a particular smaller board
<@&356864093652516868> Reminder that our weekly meeting is in less than two hours, at US 2pm ET // 11 am Central time. The skew in Daylight Saving Time changes may affect the meeting starting time on your local clock. Add your hug reports and status updates here: https://docs.google.com/document/d/15NZc6nDGYZSXt41qXQ1whWKbiChyfmh00CQwtD_NlYY/edit?usp=sharing
onyx hinge
does that mean there are around 600 * 21 = 21600 build artifacts from each build?
tulip sleet
I think there are not 21 active languages, but there might be 18.
onyx hinge
oh that's a lot better π
π I'll be blushing during hug reports today
oooh thank you neradoc! that's a cool feature that I have wished for.
jaunty juniper
yeah me too π
onyx hinge
also y'all are all so smart
thorny jay
Thank you Danh.
mortal kernel
Thanks Dan!
manic glacierBOT
jaunty juniper
@tulip sleet I was looking at my CDC issue of not being able to read the buffer when nothing is connected, and realized that the fix that caused that checked if a client is connected, when it probably meant to check if USB is connected (tud_ready).
https://github.com/adafruit/circuitpython/pull/7100
But, when trying to revert the change to compare to the original issue, I believe the problem of accessing CDC before it's ready is now fixed in tinyUSB itself:
https://github.com/hathach/tinyusb/pull/2630
so I don't know if I should make a PR changing the test in CP using tud_ready or tud_cdc_n_ready (which includes tud_ready, so it seems to be a better one) or just revert 7100 since tinyusb takes care of it
tulip sleet
<@329766224093249548> I was looking at my CDC issue of not being able to read th...
bool tud_cdc_n_ready(uint8_t itf) {
return tud_ready() && _cdcd_itf[itf].ep_in != 0 && _cdcd_itf[itf].ep_out != 0;
}
bool tud_cdc_n_connected(uint8_t itf) {
// DTR (bit 0) active is considered as connected
return tud_ready() && tu_bit_test(_cdcd_itf[itf].line_state, 0);
}
it looked likes "ready" is less strict than "connected"?
I'd say you could try to revert #7100, but then test whether you can reproduce the bug reported in #6108.
jaunty juniper
I couldn't reproduce it so far, maybe be I could test an old version of CP where the issue happens to make sure I get it to happen with what I'm doing
orchid basinBOT
- [ ] Made with CircuitPython Badge is getting clipped
short tendon
@lone axle when you have a moment, I have another secrets.py question. For Macropad_2FA_TOTP the code has the user add multiple totp_keys to secrets - as a list, which os.getenv doesn't support. I see 2 options:
- do something like:
name|code|color,name|code|colorand then break it apart in code - create a
secrets.jsonthat we load instead.
Thoughts?
lone axle
<@382939733107408897> when you have a moment, I have another `secrets.py` questi...
For that one I think it's okay to just rename secrets.py to something specific to the project like totp_secrets.py, totp_secret_keys.py, or maybe even just totp_keys.py and adjust the import in it's code. We could change it to JSON, but it I view it as essentially the same, just requiring different/more boilerplate to load it.
As a longer term solution maybe some day we can support toml arrays or whatever this grouping syntax is from the wikipedia TOML example:
[servers]
[servers.alpha]
ip = "10.0.0.1"
dc = "eqdc10"
[servers.beta]
ip = "10.0.0.2"
dc = "eqdc10"
Sounds good, will do the rename! Thanks
wheat siren
I'm looking to add this as a Board (ESP32-WROOM-D) - would it be worth me making a PR? Or is it likely to be too niche (I can keep a fork and run the GitHub Action on there).
manic glacierBOT
tulip sleet
It's pretty niche, especially since you don't know the details of the board yet. By using a generic ESP32-WROOM board, you'll be able to reference all the pins, etc.
wheat siren
I need to check if the flash sizes are the same between the existing WROOM-E and this one
tulip sleet
I need to check if the flash sizes are the same between the existing WROOM-E and...
There is some automatic determination of flash size in ESP-IDF, and an incorrectly-specified flash size may still work anyway
wheat siren
Ah that's good to know.
Image with a smaller specified size than the actual flash should work, but not vice versa?
tulip sleet
Ah that's good to know.
Image with a smaller specified size than the actual flas...
the flash specs in the board defs mainly determine the partition layout and whether DIO/QIO, etc. is used for the flash. Also they specify args to esptool.py command-line args for flashing convenience
last condor
hiya, was hoping to hear from some contributors, how difficult is it to port a new board to circuitpython? i've seen (and come into possession of) these generic unbranded ESP32-C3 modules with a tiny 0.42inch OLED, and it seems through some tinkering that they don't differ much from the 01space esp32-c3 oled (mostly in the pinouts and the oled screen driver being sh1106 instead of ssd1306)
stuck elbow
hiya, was hoping to hear from some contributors, how difficult is it to port a n...
there is a detailed tutorial https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython
it's not hard at all if there is a similar board already
last condor
ah, fantastic! thank you very much. since there is no manufacturer listed... well, anywhere i assume the naming convention for this board would be something akin to generic_oled042_esp32c3 ?
stuck elbow
ah, fantastic! thank you very much. since there is no manufacturer listed... wel...
you will need to ask espressif for a unique usb vid/pid
last condor
ok, thank you very much for the information
actually, this board doesn't seem to support native usb, since everything has to go over the web workflow, would that mean i'd be using the creator/creation id system instead of a vid/pid?
jaunty juniper
actually, this board doesn't seem to support native usb, since everything has to...
yep
last condor
alright perfect. thanks for the help :)
jaunty juniper
https://github.com/creationid/creators
hmmm should there be a "generic" creator ID ?
last condor
the board seems near identical in functionality to the 01space 0.42inch lcd esp32c3, just with a slightly different pinout and display driver (although rather amusingly, the sh1106 and sd1306 drivers are similar enough that a small row of pixels does in fact render in the center) so it could possibly be a subset of that design? but then again it's not officially from them
jaunty juniper
@slender iron what do you think we should do to add a creation ID for a generic/unnamed board "creator" in there ? https://github.com/creationid/creators
last condor
it seems i've raised up a lil dilemma π
jaunty juniper
just a legitimate question
tulip sleet
These generic boards can vary slightly from one another, and we end up with an plethora of boards that can't be readily identified.
If there seems to be a trend among generic boards to be the same (e.g. the "yellow display") we could make up a generic definition, but minor variations blow up the board space.
This is my opinion, not necessarily policy
I do think we should define some explicitly generic boards and encourage people to use those. For boards with displays the issue is whether it's worth defining the display in board.c for ease of use
last condor
most if not all of these small integrated display boards ive found seem to be either ssd1306 or sh1106 (which are very similar regardless) so in this case it could be something like generic_oled042_esp32c3 and/or generic_oled042_sh1106_esp32c3 ? (as an example for the device name itself), it does seem a little long winded though
e.g., through digging around i found only one other generic variant that advertises itself as using an ssd1306 display and also has a pin to directly connect a 3.7v battery, but it does seem like these generic boards are a little difficult to pin down and define
jaunty juniper
that reminds me that I have the RP2040 and ESP32S3 variants of the 01space .42 inch board, but they don't have pull ups on the I2C and I can't make the display work in CP so I gave up on them
last condor
realistically it does seem that it is similar enough that i can simply re-define pins (e.g., real_SCL = board.IO5 wherever i need to open the display), so a whole new port might not entirely be necessary
in fact that's precisely what i'm doing since i'm using one of these in ""production"" (small plant soil moisture monitor)
maybe there could be a place to document little quirks of these generic boards and how to "map" some of them to existing ports?
last condor
that reminds me that I have the RP2040 and ESP32S3 variants of the 01space .42 i...
i actually had this exact issue with this board when i tried to just use board.I2C() with the correct i2c pins and i got around it by using bitbangio.I2C() instead
last condor
either way, i'd love to hear what the official consensus on these generic boards will be as i do have about 7 of this one laying around that i use for various wifi-connected projects, i'll keep an eye out on the creatorid/creations repo in case any discussions happen there
sterile anvil
The WIZnet W5500-EVB-Pico2 board doesn't currently have an official CircuitPython build, so I've been using a custom build based on the W5100s-EVB-Pico2. (It's virtually identical aside from the USB PID and the WIZnet ethernet chip itself.) Given that I don't work for WIZnet and I'm not the designer/developer of the board, can I still submit a pull request to get it added to CP?
onyx hinge
@sterile anvil yes, many people do that.
sterile anvil
Perfect, thanks - I'll submit a PR then!
onyx hinge
thank you!
manic glacierBOT
manic glacierBOT
orchid basinBOT
short tendon
@lone axle how have the sizes been for the library PRs? The next batch will be P which has a bunch for PyPortal. Want to make sure any given PR isn't too much to tackle
lone axle
@short tendon The previous one (I haven't looked at the new one yet) is probably almost to the biggest size that I'd want to do in one sitting. Much bigger than that and I'd want to probably take a break and do something different for while part way through the guide page updates, so it may split up into morning/afternoon or across two days depending on what else is on my plate.
short tendon
Okay. I think the next one might be a little bigger, but part of that is that it's almost all MagTag. I'll split the next one
onyx hinge
@mortal kernel do you have a firm handle on the PIO bug{,s} or is there any assistance I can offer?
mortal kernel
<@849815081251766292> do you have a firm handle on the PIO bug{,s} or is there a...
Got it. A small signedness bug.
onyx hinge
hah the mp3 bug was also a signedness bug.
maybe java was right to not have unsigned types at all
mortal kernel
π
stuck elbow
maybe java was right to not have unsigned types at all
it makes sense for the kind of hardware that java runs on