#circuitpython-dev
1 messages · Page 59 of 1
Let me look...
The MEMENTO has an unusual tinyuf2 load, which has one large "OTA" partition, 2.8MB, instead of two 1.4MB partitions. The user filesystem is 960kB, same as usual.
My current changes are in https://github.com/dhalbert/circuitpython/tree/memento-storage-crash
I've got Metro Rev B with ESP32-S3 N16R8
you could probably load the MEMENTO bootloader on that board. Or do you have a Feather ESP32-S3 TFT or 4/2 plain Feather ESP32-S3?
the bootloader might not have a status LED (due to pin differences), but I think it would still work
quick question, I'm getting a syntax error. Are you able to use else with try except blocks for when no error happens in circuit python?
That's all I've got besides some older VROOM boards.
Let me pull your code and I'll see if I can spot something without resorting to testing.
my first q is whether the 1024's in statvfs are actually right. I see the same thing on a Pico, for instance
Trinket has 512's. CPX has 1024's.
Adafruit CircuitPython 7.3.3 on 2022-08-29; Adafruit CircuitPlayground Express with samd21g18
>>>
>>> import os
>>> os.statvfs('/')
(1024, 1024, 2024, 2020, 2020, 0, 0, 0, 0, 255)
The best way to check that is to dump the VBR and compare.
2020 is right
I put the camera boot loader and the Camera CP uf2 on an ESP32-S3 TFT and the file system does seem to have issues (reporting 3.7M)
@mortal kernel on Metro ESP32-S3, df -h says 13984 1k-blocks, and statvfs says 2048-byte clusters and 6992 f_blocks. So that's right. So this may be limited to the unusual partition scheme on the MEMENTO. Metro has ota_0 and ota_1 each 2048kB, and user_fs 11968K, so it is going to extend CIRCUITPY into ota_1 to make 11968+2048, about, which seems right
my UF2, you mean? Yup, it's not particular to the board, but I think it's the partition. I want to test again putting firmware.bin from my onto a freshly erased module and see what size it reports
@tulip sleet you tried with CIRCUITPY_STORAGE_EXTEND disabled and it didn't fix anything?
(and you formatted the filesystem hopefully)
No, I was just confirming that the original issue showed up on the feather TFT, I burned the UF2 from circuitpython.org
EXTEND is turned off because DUALBANK is turned off. I even verified that with a print statement somewhere. It did fix the hard crash, but then the new "gets remounted as read-only" problem shows up. I think there are two bugs here. one is that DUALBANK should not be on if there's not an ota1 partition. The second is that the size is being reported wrong in statvfs
yes, I have been reformatting the filesystem
OK
I notice that esp_ota_get_next_update_partition will return ota0 if it's the only one
if (default_ota == NULL) {
/* Default to first OTA partition we find,
will be used if nothing else matches */
default_ota = p;
}
that's not so great, but I thought it was not being called
i can instrument that
Loading the .bin:
dafruit CircuitPython 9.0.0-beta.1-1-g3871899860-dirty on 2024-02-18; Adafruit Camera with ESP32S3
>>>
>>> import os
>>> os.statvfs('/')
(0, 0, 0, 0, 0, 0, 0, 0, 0, 96)
>>> os.listdir()
[]
hahah
i did do an erase_filesystem() after the first time I saw that
@mortal kernel I'm beginning to think there is no oofatfs or low-level issue, so feel free not to spend time on this. It's some peculiarity of the partition stuff on ESP, I think
i was mostly surprised by the two-sector clusters
going ice-skating ⛸️
NP, if you need me give me a ping.
I'm having an intermittent problem running make fetch-port-submodules. Here's a small sample:
what is your git version?
Cloning into '/home/rabeles/Development/circuitpython-issue-7693/circuitpython-memento/lib/mbedtls'...
error: 41 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
fatal: clone of 'https://github.com/ARMmbed/mbedtls.git' into submodule path '/home/rabeles/Development/circuitpython-issue-7693/circuitpython-memento/lib/mbedtls' failed
Failed to clone 'lib/mbedtls'. Retry scheduled
git version 2.43.2
do a make remove-all-submodules and see if that helps
No joy, problem just keeps moving around. I suspect github is having issues. I'll try again later.
@danh Poking around while waiting for github to settle down, I chased the path from f_mkfs that returns the raw filesystem size. Here's the code from ports\espressif\supervisor\internal_flash.c that does the heavy lifting:
uint32_t supervisor_flash_get_block_count(void) {
#if CIRCUITPY_STORAGE_EXTEND
return ((storage_extended) ? (_partition[0]->size + _partition[1]->size) : _partition[0]->size) / FILESYSTEM_BLOCK_SIZE;
#else
return _partition[0]->size / FILESYSTEM_BLOCK_SIZE;
#endif
}
Shouldn't the expression (_partition[0]->size + _partition[1]->size) be (_partition[0]->size + _partition[1]->size) / FILESYSTEM_BLOCK_SIZE?
it's confusing to read, but it looks correct due to parenthesis: return (extended ? (size_0 + size_1) : size_0) / block_size
Good eye, you're right.
btw, CIRCUITPY_STORAGE_EXTEND should be 0. I put in some print statements earlier and that was true. (A print statement in the #else arm was executed.)
I have been working more on this, and have leads on what is really going on. Once DUALBANK is turned off and the proper partition files are set up, that exercises some bug that causes nothing to be written to the filesystem. So even reformatting the filesystem doesn't work, though it appears to, and what I'm seeing is the old leftover larger filesystem. I'll say more tomorrow.
Hi! Can you please accept this pull request. Our team decided we'll not be using rgb status for this board. I also updated the name of the product from Maker UNO RP2040 to Maker Uno RP2040.
Let me know if there is any problem.
Thank you!
This PR add the board definition for M5Stack Dial
Thank you! Could you do a PR to circuitpython-org to add the board?
Done https://github.com/adafruit/circuitpython-org/pull/1329
@tulip sleet I just noticed ... ```c
#if CIRCUITPY_STORAGE_EXTEND
multi_partition_rw(_cache, sector_offset, SECTOR_SIZE, OP_WRITE);
#else
single_partition_rw(_partition[0], _cache, sector_offset, SECTOR_SIZE, OP_READ);
#endif
I bet that's the part that made the partition read only when !EXTEND
I am writing this up right now. Yes, that looks like a problem -- good catch. The host also only notices that it's read-only when it tries to do a write. And storage.erase_filesystem() when !EXTEND doesn't actually create the filesystem. You can see that if you erase all of flash, and then install one of my later builds with !EXTEND. It keeps going into safe mode saying it can't find (or, really, create) CIRCUITPY
I see several directions to go now to fix this:
- Turn off DUALBANK and EXTEND in beta.2 and tell everyone to do
storage.erase_filesystem()when they install it,
also I asked chatgpt to analyze that function to find the error. It noticed this was hinky:
supervisor_flash_read_blocks(_cache, sector_offset / FILESYSTEM_BLOCK_SIZE, blocks_per_sector);
_cache_lba = sector_offset;
}
```_cache_lba is compared to block_address but assigned sector_offset
- Redo the bootloader to remove the non-OTA-ness. The current firmware fits fine in a 1.4MB partition. That allows a larger CIRCUITPY for images, etc.
But then people have to install a new bootloader AND beta.2, which is a lot of support for all the Adaboxes already out htere
#2 does seem more disruptive
let's discuss at 1pm
Here's what I think is going on:
The MEMENTO *aka adafruit_esp32s3_camerawas set up using an unusual partition scheme. There is a single 2.8MB 2816kB) firmware partition, instead of two 1.4MB firmware partitions (one for OTA update of firmware). The user filesystem partition is 960KB like other boards. The TinyUF2 bootloader combined.bin sets up this partition scheme.
There was an incorrect FLASH_SDKCONFIG setting in the mpconfigboard.mk for the MEMENTO. That config name is obsole...
we should make sure !EXTEND case works right though.
<@&356864093652516868> a quick note, there's no meeting today (monday), as Adafruit observes the Presidents' Day holiday. We'll meet tomorrow, 24 hours after the usual time! You can add your notes to the doc anytime, of course, check the pinned messages for a link.
oh yes, sure, it's bad it's broken. I think we should error-out the build to ensure that DUALBANK should not be set without a second OTA partition, but not sure how to do that yet without a shell script or something that looks at the partition .csv file.
@onyx hinge the behavior was really confusing because it was two bugs, and fixing the first revealed the second, especially the persistence of the 3.7MB CIRCUITPY even after turning off DUALBANK/EXTEND
we can check if the "next ota partition" is the "running partition": ``` #if CIRCUITPY_STORAGE_EXTEND
_partition[1] = esp_ota_get_next_update_partition(NULL);
if (_partition[1] == esp_ota_get_running_partition()) {
_partition[1]->size = 0;
}
but this would prevent it from extending into the single OTA partition
@noqman, The purchase link from the circuitpython.org site goes to the Cytron Maker UNO. I can find a Cytron Maker PI RP2040 on Cytron's web site, but I can't find a Cytron Maker UNO RP2040.
Is this board name correct or should it be "Cytron Maker UNO"?
it would have to go into safe mode. Maybe that's a good idea: it would tell people to reformat.
I didn't test, but my gut told me that if I did a safe mode reset inside supervisor_flash_init I'd end up with a nasty reset loop
we have recursion prevention for some other safe mode, I think. It might be in main.c
if we prevent such a build from ever happening, that fixes the problem in the long run. It just doesn't make it obvious it needs to be fixed for current board owners. This is the kind of thing to discuss at 1pm
i was going to ask to chat with you about this earlier but it took a while to do other things and write this up
I was scratching my head over it all last night
I wonder how many board configs are affected by this problem. esp32s3-camera is the only "1ota" partition table user I see
I figured out the reason for the behavior just before i (tried to) go to sleep
There are 2MB boards with DUALBANK turned off. I wonder if they work at all
I think they might not be able to write/format CIRCUITPY
I know it's ugly and not ideal, but could you make a second board definition for the correct boot loader so the large file system was installable but leave the orginal boot loader version on the existing download to avoid the disruption for people that might not be aware of the issue?
maybe yes, we will ask "management" about the best way forward. @onyx hinge would you say that 1.4MB is enough, given that it fits now, and is a larger CIRCUITPY desirable as well for the camera? That means it can have some limited use without an SD card, I think.
@tulip sleet is this similar to the size you see? ```1285200 bytes used, 156592 bytes free in flash firmware space out of 1441792 bytes (1408.0kB).
yes, that's what I see
even the big languages should be OK, that's a lot of free space.
turning BLE back on someday will reduce the free space a lot, but I think it may still fit. I wonder why it didn't fit before, maybe -O2??
now it's -Os
This may be a dumb question, or a question with a hard-to-implement answer, but... now that (I think) we have TLS as a shared resource across ports, is it feasible to have TLS over (WIZnet) Ethernet?
maybe it's convoluted to have a library-accessed socket passed back into circuitpython core
yes, not sure that would work out
we do something like that in asyncio??
@crimson ferry shared-module/ssl "does things" by making C function calls into socketpool routines, e.g., ```c
STATIC int _mbedtls_ssl_send(void *ctx, const byte *buf, size_t len) {
mp_obj_t sock = *(mp_obj_t *)ctx;
// mp_uint_t out_sz = sock_stream->write(sock, buf, len, &err);
mp_int_t out_sz = socketpool_socket_send(sock, buf, len); …```
These would all have to be replaced with "something else" that would adapt to different kinds of underlying socket objects
(not sure why there's a commented out line there, probably me being untidy)
there are probably around 8 to a dozen places that would have to be modified to call back to Python code instead of making a C function call
so TLS for ethernet is more sensible as a Python library if that possible?
I could be wrong but I think TLS is usually port specific because it can be computationally heavy
I don't think you'd want to code TLS in Python, and I don't think we'd want 2 TLS implementations in the core (one for wiznet, one for wifi) so I'd tend to look at how to make the ssl module work with any object that obeys the socket "protocol" (in the python sense of a protocol or abstract bsae class). but that's just a gut reaction from me.
dest[2] = MP_OBJ_NEW_SMALL_INT(self->device_address);
dest[3] = write_buffer;
mp_call_method_n_kw(2, 0, dest);
```instead of a basic C function call you end up writing something like this, example from adafruit_bus_device which is designed to work with true core i2c, C bitbangio i2c, or python-coded bitbang i2c
@tulip sleet M5 Stack cardputer has a matrix keyboard with a 74HC138 decoder on the rows. Current keypad module don't support this case. I would like to try to write the module. What do you think about this?
it's ok to do that. I haven't thought about the API. I don't know how common using a demux like this is for keyboards, and whether there might be a case where both rows and columns are demuxed?
Does the use of a multiplexer cause rollover not to work right? I have not thought about that.
I don't know that we would turn it on in general, maybe just for this board. It will take up space on smaller boards.
m5 stack keyboard could be an interesting case for an ULP program. I have a retro keyboard with both row & column muxes and always meant to write its scanning code in the riscv ulp.
I don't think the use of a multiplexer affects rollover; this retro keyboard (atari something) doesn't have diodes, so it's limited to 2kro (+ some keys are specially placed on the matrix so nothing ghosts with them, iirc)
(but quite possibly ulp support isn't working at the moment so it'd be some uphill work to do)
This was something I was going to look at after ConnectionManager was fully released. Do you know what socket methods need to be fully implemented?
@short tendon just based on a little grepping, I see 8 call sites but imagine I missed something: ```SSLSocket.c: mp_int_t out_sz = socketpool_socket_send(sock, buf, len);
SSLSocket.c: mp_int_t out_sz = socketpool_socket_recv_into(sock, buf, len);
SSLSocket.c: return common_hal_socketpool_socket_bind(self->sock, host, hostlen, port);
SSLSocket.c: common_hal_socketpool_socket_close(self->sock);
SSLSocket.c: common_hal_socketpool_socket_connect(self->sock, host, hostlen, port);
SSLSocket.c: return common_hal_socketpool_socket_listen(self->sock, backlog);
SSLSocket.c: socketpool_socket_obj_t *sock = common_hal_socketpool_socket_accept(self->sock, ip, port);
SSLSocket.c: common_hal_socketpool_socket_settimeout(self->sock, timeout_ms);
I'd probably start by factoring those out to intermediate functions, then make the intermediate functions operate via mp_call_method*. once that's working, if the performance is detectable reduced on native objects add an "is native object" flag to skip the object layers and do direct function calls.
(well, first I'd factor it so that mp_load_method is called just once for each method, not once for each call; it's probably the most expensive part of overhead that is easily eliminated and then check if the overhead's still important)
Sorry for taking so long with this, been busy with other stuff.
stations_apnow returnsNoneif not in AP modestations_apnow returns a list of NamedTuples withmac_address,rssiandipv4_addresselementsipv4_addresswill now beNonerather than 0.0.0.0 if none has been assigned
This is solid with Espressif but I see erratic results from the Pi Pico's cyw43 SDK. You can see them in the screen cap - it sometimes reports 1 station connected despite 2 or 3 (confir...
Looking briefly both wiznet5k and esp32spi socket implementations support those.
@onyx hinge, I can submit my current MEMENTO things as a draft PR, if you think that makes sense. I'd probably stop the jobs from running at first, since it's still wrong.
@tulip sleet or you can just point me at your branch, either way
I am trying to figure out the best way to trigger safe mode if there's no OTA1 but EXPAND is enabled.
maybe we don't need to do this, instead prevent it from even building in that case
do you have ideas about how to do that? If so 💯
mpconfigport.mk can look at the chosen .csv and analyze the partition table with a short python script or even a shell command line. If the partition .csv's are uniform, can complain if EXTEND is on but ota_1 is not in the .csv. That's a simple grep or similar
i can work on that if you would be willing to test the single partition write fixes
do you think chatgpt was right about its conclusion?
If "ota_1" is not found in the csv, and DUALBANK is enabled, error
I agree with chatgpt that there's something funky about how the cached block is tracked
in case someone tries to test it separately. Or just test extend
as i mentioned somewhere I also stumbled upon some obsolete references to *SUPERVISOR_ALLOCATION that I removed, while looking through those files anyway
@tulip sleet let me work on the checking sdkconfig vs EXTEND/DUALBANK
you could look at the old code before the muti-partition write was added, but maybe that was wrong too
then we can look together at the flash cache bit
right now the naming scheme (after I renamed that one .csv file in my branch) is consistent that *no-ota*.csv are the ones without an ota_1 partition. sdkconfig itself doesn't have info about partititions, it is just in the filename setting
CONFIG_PARTITION_TABLE_CUSTOM_FILENAME="esp-idf-config/partitions-4MB-no-ota.csv"
CONFIG_PARTITION_TABLE_FILENAME="esp-idf-config/partitions-4MB-no-ota.csv"
but I think it's easier just to look for no-ota in FLASH_SIZE_SDKCONFIG. That value will be set in mpconfigport.mk or mpconfigboard.mk, so you can just test it in mpconfigport.mk
and do $(error ...)
@tulip sleet "FLASH_SDKCONFIG = esp-idf-config/sdkconfig-4MB-1ota.defaults" is this line just totally wrong? the variable never seems to be referenced
or am I missing how it gets used
I ended up with the "1ota" name because tinyuf2 used it: ```$ find | grep 1ota
./ports/espressif/partitions-8MB-1ota.csv
./ports/espressif/partitions-4MB-1ota.csv
./ports/espressif/partitions-16MB-1ota.csv
yes, i fixed that in my branch. I think it nay have been FLASH_SDKCONFIG in the past and got changed
well make them all one way or the other. All the others are no-ota in esp-idf-config
how many tiny little weird things have converged here? I'm losing count.
I like no-ota better, because it's a functional desription instead of a "name of the partition" description.
maybe do that same check on CIRCUITPY_DUALBANK, because it's useless with only one partition, and those options can be set independently
@tulip sleet I think this is ready for you to grab into your branch, if that's how you want to handle it. https://gist.github.com/jepler/a1eb2fb95c48ede5cb6035caa57de783
and if using "git am" is something you're familiar with
@onyx hinge
_cache_lba = sector_offset;
```
was also present before EXTEND was added: <https://github.com/adafruit/circuitpython/pull/7000/files>
i have used git patch, not git am
The OP_READ bug looks like copy pasta
git patch will work, git am is able to preserve the author info and commit message. you'd download the raw patch (https://gist.github.com/jepler/a1eb2fb95c48ede5cb6035caa57de783/raw/da8dd29c6d9e4d31b947500c90b5eea6207d6014/check-sdkconfig-ota.patch) and in a clean working tree apply it with "git am /path/to/check-sdkconfig-ota.patch" to create the commit locally
oh, it is something like "apply mail" or something, right? They email around patches. Linux kernel workflow looks like a nightmare to me
The fact that I make homonymic mistakes while typing says something about my mental processing...
you're not the only one who does that.
i think i subvocalize what I type, at least some of the time
i made some comments; I'll change your script a bit
it's funny, I only start doing that after speaking English for extended periods – for example on a conference – and it takes me several days to recover
@onyx hinge why did you skip duplicate definitions:
v = sdk_config.get(k, v)
@tulip sleet that's explained poorly by the line above, and is not needed anyway. Some defines expand into other defines and that line tries to handle it: ```
-
# ad-hoc handle lines like '#define CONFIG_TCP_MSL CONFIG_LWIP_TCP_MSL' -
v = sdk_config.get(k, v)```
but you can delete the line & comment, it's not needed for the defines we care about
i can leave that in. I made an int_or_string() function
OK
Thanks for diving into this, it will be quite handy.
I tried to track it down, but I'm not sure where ESP_WIFI_MAX_CONN_NUM comes from. From your tests, it appears to be 15 for some Espressif boards, 10 for others. I thought 10 used to be the max, but seems to be 15 now. However, the following seems to indicate that 10 is esp-idf default (and it trades off with number of ESP-NOW encrypted pairs):
https://docs.espressif.com/projects/esp-idf/en/release-v5.1/esp32s3/api-guides/wifi.html#ap...
(fwiw, ESP-NOW maximum number of encrypted peers is a build-time option, whereas maximum number of connections of SoftAP is a runtime option - link)
@onyx hinge out for a walk, need more testing. I am still confused about the caching: sectors vs blocks
was cleaning up some other things and got distracted
me too
I'm due to go out for walk as well, hopefully I'll come back less distractable
i switched your script to click
Does someone know about circup, if the output of "circup freeze" can be used to install a specific version later? I thought circup would only install from the latest bundle. https://github.com/ide/circuitpython-https-server/pull/2#issuecomment-1951412172
Is it frowned upon to try to add a board to CirPy that relies on community libs and a modified official lib in order to function?
do the libraries have to be added to the repo?
does it not function at all without those libraries (I suspect not)?
For reference, I'm working on the files for this board, ESP32-2424S012. It's an ESP32C3-Mini with a screen and touch module. Right now it needs the gc9a01 from the community bundle and adafruit_cst8xx with _CHIP_ID_CST826 edited
is there a sensible PR to adafruit_cst8xx to have it handle the superset?
Without those it'll technically work like a plain ESP32C3, but no screen
It's not frowned upon. do you want to propose an addition or change to the cst8xx library?
And I'm not sure, I do see inside the cst8xx lib some comments about subclassing it to allow more IDs to be accessed
you want to copy the init sequence from the driver and add it to board.c, look at the other boards with screens for an example
then it won't need that driver
Ah ok, that's neat. I had seen something about that when looking at projects for other screens but didn't realize that's what it was for
it will then start with the screen already working
Would I do that for both drivers, for the board and the touch chip? Because it's the touch driver that needs the ID edited
the touch is done in python only, so no built-in thing
Ok in that case it would be nice to have the ability with adafruit_cst8xx to include the chip ID as an argument, which is easy enough to find because it prints the current chip ID in the terminal on init already
Actually question, does the chip ID matching actually matter? I just tried disabling the check and it works when it doesn't force an error
I assume there's some edge cases where a different enough chip just wouldn't work at all, hence the enforcement?
or there could be subtle variations in algorithms... may need to look at datasheets
"works" as in doesn't get an exception, vs. "works" as in functions 100% correctly
Makes sense. Either way, I'll go poke with the init sequence thingie and be back when I've figured that out since I'll have no doubt bodged it up
correct @RetiredWizard, I got the mic/speaker crossed. Thanks for the reply and let me know if you give it a try.
- Fixes #8944
- Fix
supervisor_flash_write_blocks()to write instead of read when handling a single firmware partition (thanks @jepler). - Fix
adafruit_esp32s3_camera/mpconfigboard.mk(MEMENTO)to use proper setting name for partition file. - Rename partition files to have consistent names: no-ota` if only one firmware partition.
- Forbid
CIRCUITPY_DUALBANK = 1andCIRCUITPY_STORAGE_EXTEND = 1if there is only one firmware partition. Thanks @jepler for initial version of v...
Thank you -- excellent cleanups done along the way. However, can you double check this comment you added? It's the opposite of what I understood from the discussions.
isn't it designed for a larger firmware, not more filesystem?
yes, that is wrong, from an early misunderstanding of mine.
@onyx hinge afk for about 1.5 hours now
I tested a build from this branch successfully on the device. With this version the drive size reported to OS makes it so it will warn me that the file is too large to fit when I try pasting it if there is already other things on the drive.
I also have been able to successfully use this build with a modified version of the basic camera example from learn and been able to take a few photos successfully with it.
Is there a functional difference between
#define CIRCUITPY_BOARD_I2C_PIN {{.scl = &pin_GPIO5, .sda = &pin_GPIO4}}```
and
```#define DEFAULT_I2C_BUS_SCL (&pin_GPIO4)
#define DEFAULT_I2C_BUS_SDA (&pin_GPIO5)
Aside from the first method letting you use board.I2C when the second doesn't (I think)
@novel cairn I think the first style you showed is newer in circuitpython and is preferred.
Ok, wanted to verify since the second is what's in the new board guide
it probably was never updated, that happens more than we'd like.
I appreciate ESP-IDF's move to extremely modular components but sometimes things are scattered to the winds :)
I'd thought of get_max_stations_ap() as the upper limit of stations the firmware was configured to support, but I see the argument that it shouldn't report more than max_connections. I'd missed the part about sharing keys with ESP-NOW, good catch.
I don't think anybody asked for get_max_stations_ap(). I included it because it was easy and I thought it might help one or tw...
@onyx hinge I think I will go ahead and make a beta.2 now -- make sense to you?
@tulip sleet yes, or tomorrow would probably be fine
Agreed on the 17.
I can't actually find the 7 (ESP-Now) anywhere, perhaps it's in the esp-idf component and we just don't have it defined differently in our config files. I've never tested more than 2 encrypted pairs.
I don't have a strong opinion about get_max_stations_ap() either. Since there is an out of bounds exception in the espressif port for max-connections, maybe it's superfluous. raspberry afaik is fixed at 10.
Automated website update for release 9.0.0-beta.2 by Blinka.
Sounds like beta 2 will be an almost mandatory update for Memento owners. Would enjoy hearing in the meeting how someone figured out it thought it had more space than it actually did. Neat bug.
I wrote it up in https://github.com/adafruit/circuitpython/issues/8944#issuecomment-1952743218. And it was two cascading bugs.
https://blog.adafruit.com/2024/02/19/circuitpython-9-0-0-beta-2-released/
This release contains an important fix for Adafruit MEMENTO Camera Boards. See the release notes for details.
Incompatible changes with 8.x.x are also spelled out more clearly in these latest release notes.
I'm trying to build CP for Feather S3. Following the steps here (https://learn.adafruit.com/building-circuitpython/build-circuitpython), and using the 8.2.x branch, I get these errors:
cd ports/espressif
make BOARD=unexpectedmaker_feathers3
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
make: *** No rule to make target `lib/tinyusb/src/portable/espressif/esp32sx/dcd_esp32sx.c', needed by `build-unexpectedmaker_feathers3/genhdr/qstr.split'. Stop.
did you fetch the submodules?
yep!
and you did . esp-idf/export.sh or the equivalent?
Thank you
Well, my circuitpython/ports/espressif/esp-idf/ is empty (no install.sh as called for in those docs)
There is one in esp32s2 but not in esspresif
CircuitPython/circuitpython/ % find . -name install.sh
./ports/esp32s2/esp-idf/install.sh
I just now tried make fetch-port-submodules , which did a ton of work, including:
Entering 'esp-idf'
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (1/1), 808 bytes | 808.00 KiB/s, done.
remote: Enumerating objects: 16528, done.
remote: Counting objects: 100% (13912/13912), done.
remote: Compressing objects: 100% (6317/6317), done.
remote: Total 8770 (delta 4400), reused 4902 (delta 1746), pack-reused 0
Receiving objects: 100% (8770/8770), 1.28 MiB | 4.68 MiB/s, done.
Resolving deltas: 100% (4400/4400), completed with 760 local objects.
But there’s still nothing in that directory.
Delete your circuitpython folder and start again. There has not been a ports/esp32s2 folder in almost 2 years.
I also pointed you to the "Espressif Builds" section on that guide as well.
Yeah it complained about not being able to delete a few folders because they weren't empty, but that shouldn't preven this from working. I did update from git.
but okay, I'll start over
make remove-all-submodules might work too
It's not just a submodule issue - the main directory structure is wrong, and git was unable to update the repo properly.
ok
make BOARD=unexpectedmaker_feathers3 is finally doing work. Yet more submodule cloning lol
All of this is for me to try to port PDMIn.c to esp32s3. Is that something on-topic for this channel?
I'm trying to use the Adafruit PDM mic with the Feather S3
I believe that is on topic here, I haven't looked at the audiobusio core routines myself, but I suspect you'll find answers to your questions here. Coincidentally PDMin just came up in a PR for the M5 Cardputer (https://github.com/adafruit/circuitpython/pull/8816). The PR author has an initial non-working attempt on github at (https://github.com/jamesjnadeau/circuitpython/blob/esp32-I2s-PDMIn/ports/espressif/common-hal/audiobusio/PDMIn.c). Maybe a chance to collaborate?
Oh that's good news! I decided to try to get this working in Arduino first, I think that'll be a much faster build-test cycle. But I'll ping the author and see what I can do. Thanks!
@jamesjnadeau I happen to try to connect a PDM mic to a Feather S3 today, only to discover PDMIn hadn't been implemented yet. As I started looking into doing so, I was directed to this PR and to your fork of CP. Is there anything I can do to help get PDM working?
@jamesjnadeau Currently in the source code two spi busses are defined but only one is exposed in pins.c. How do you suggest to fix this? The code change proposed above? Something else?
From the CP 9.0 beta.2 release notes. Incompatible change: Require explicit socket port reuse. Use socket.setsockopt(pool.SOL_SOCKET, pool.SO_REUSEADDR, 1), as in CPython. Where are we likely to have to make a change to deal with this. I don't see it in adafrutit_requests.py . I'm just curious where it has an impact and if what libraries might have been updated to deal with this.
Ah looks like it impacts adafruit_httpserver https://github.com/adafruit/circuitpython/pull/8940
Hi https://github.com/silabs-ChatNguyen Would it be possible to get a response for this issue and help work out a solution? Thanks so much.
@MHVUT I'm wondering, which version of Java are you using? I have
$ java --version
openjdk 11.0.21 2023-10-17
OpenJDK Runtime Environment (build 11.0.21+9-post-Ubuntu-0ubuntu122.04)
OpenJDK 64-Bit Server VM (build 11.0.21+9-post-Ubuntu-0ubuntu122.04, mixed mode, sharing)
I alerted the HTTPServer maintainers about this. Michał Pokusa has PR for httpserver: https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer/pull/84
Can someone remind me why not have a method or property on the Radio object to return its socketpool singleton. I feel like I raised this in the past and there was a reason. pool = wifi.radio.pool or pool = wifi.radio.pool() vs pool = socketpool.Pool()
I was just thinking about this two days ago. Makes sense to me too. I think it's a q for @slender iron
@MHVUT I'm wondering, which version of Java are you using? I have
$ java --version openjdk 11.0.21 2023-10-17 OpenJDK Runtime Environment (build 11.0.21+9-post-Ubuntu-0ubuntu122.04) OpenJDK 64-Bit Server VM (build 11.0.21+9-post-Ubuntu-0ubuntu122.04, mixed mode, sharing)
Sorry for the late reply. I was just wrapping up the Lunar New Year holiday.
I think this issue due to wrong java version. Code generation tool are using java 11.
Thanks guys for the support.
The SiLabs UG520 app note states in section 2.1 for requirements…

I actually had installed this version based on the UG520 app note of requiring version 17 or higher...
openjdk 21.0.2 2024-01-16 LTS
OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode, sharing)
Per the comments I used sdkman to install and set the following version as the default…

No...
adding itsybitsy esp32 (https://www.adafruit.com/product/5889)
added creation ID here: https://github.com/adafruit/adafruit-creations/pull/4
tested web workflow, i2c, neopixel, basic i/o, wifi
This button is on GPIO13. Looking at the product photo, I can't see if it has a silkscreen name. Could you change the SW38 button to something else?
Do make translate and then push again
I am using default-jdk of ubuntu 22.04
openjdk version "11.0.21" 2023-10-17
OpenJDK Runtime Environment (build 11.0.21+9-post-Ubuntu-0ubuntu122.04)
OpenJDK 64-Bit Server VM (build 11.0.21+9-post-Ubuntu-0ubuntu122.04, mixed mode, sharing)
Could you help to run below cmd in your side:
cd /port/silabs/
make BOARD=devkit_xg24_brd2601b clean
make BOARD=devkit_xg24_brd2601b slc-generate
I am probably overlooking something silly in my change, can someone spot the problem with my attempt to add the type property to socket objects? s.get_type() (nonstandard) works, but s.type doesn't.
my change: https://gist.github.com/jepler/219145b531657e957d59b980b3b437ed
Adafruit CircuitPython 9.0.0-beta.2-2-g3a06f87e31-dirty on 2024-02-20; Adafruit Camera with ESP32S3
>>> import socketpool, wifi
>>> socket = socketpool.SocketPool(wifi.radio)
>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.type
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'Socket' object has no attribute 'type'
>>> s.get_type()
get type
1
iirc for properties to work you need a flag on the class
ah! I bet that's it
MP_TYPE_FLAG_HAS_SPECIAL_ACCESSORS
thank you @stuck elbow !
yep that was exactly it.
@anecdata pointed out that moving ssl to shared-module might pave the way to using ssl with wiznet.
I mentioned that for this to be possible, ssl would have to make Python calls for various methods (connect, send, recv, etc) instead of calling the common_hal socket routines.
I went ahead and implemented this. I very lightly tested it: it can do the standard socket test and fetch from https pages like https://www.adafruit.com/api/quotes.php on an esp32s3 device. I didn't test servi...
<@&356864093652516868> Due to yesterday's holiday the weekly meeting is occuring today (Tuesday) starting about 90 minutes from now here on discord. Feel free to fill in hug reports, status updates, or in the weeds topics to the shared document prior to the beginning of the meeting if you'd like. Look forward to speaking with everyone then! https://docs.google.com/document/d/1x3O7daDGGkd0NgEyHz0p9OKz8tCtKB4gli7iCisYtmI/edit?usp=sharing
I'm seeing "Hard fault: memory access or instruction error." with 8.2.10 on a Matrix Portal S3.
It's running a long running large complicated application that's obviously using the LED matrix but also has a lot of network activity (MQTT) and writes every so often to flash. Didn't see this with 8.2.9.
It'll be difficult to isolate the problem. I've moved it to 9.0.0-beta2 (which took exactly zero changes to the application, very nice :)).
Is it even worth filing an issue on the 8.2.10 crash at this point? If I see it with 9 I'll file it against that and see if I can come up with a small program that reproduces the problem.
Update tools/convert_release_notes.py to use mistune v3, the current version, which has a lot of internal API changes from v2. Also added code block support.
This is used to generate release notes for the blog and the forums from the GitHub Markdown release notes.
I've removed get_max_stations_ap(). Might as well save the bytes and potential confusion until someone actually asks for it. It's probably better suited to documentation anyway. Thanks for catching the max_connections stuff!
I'm still using ESP_WIFI_MAX_CONN_NUM internally as an upper bound for temporary storage while querying about connected stations, but that should be a safe use.
that all looks plausible!
I did test it :slightly_smiling_face:
@onyx hinge mind approving #8955? I don't think Scott needs to review.
I confirmed cHemingway's findings for the CLUE Morse Code Chat example.
BL 0.8.0 and 0.8.2
CP 8.x and CP 9.x beta
CP Lib 8.x and CP 9.x beta
Morse Code Example Bundle 8.x and 9.x
The only way to get this example to work is to modify the scan_and_connect function to perform scanning if the
CLUE is to be the central and to perform advertising if the CLUE is to be the peripheral.
`MY_NAME = "CENTRAL"
FRIENDS_NAME = "PERIPHERAL"
#MY_NAME = "PERIPHERAL"
#FRIENDS_NAME = "CENTRAL"
...
This code looks about the same as https://github.com/ide/circuitpython-https-server which I used (with modifications, see https://github.com/ide/circuitpython-https-server/pull/2) when testing https://github.com/adafruit/circuitpython/pull/8932
#8954 will not further increase compatibility with anything that uses socketpool sockets.
whoops , meant to click approve 😉
i did think that 🙂
could be something wasn't quite right in #8940.
Can you test with these two specific uf2 files: https://adafruit-circuit-python.s3.amazonaws.com/bin/adafruit_matrixportal_s3/en_US/adafruit-circuitpython-adafruit_matrixportal_s3-en_US-20240217-main-PR8808-d0fec0c.uf2 and https://adafruit-circuit-python.s3.amazonaws.com/bin/adafruit_matrixportal_s3/en_US/adafruit-circuitpython-adafruit_matrixportal_s3-en_US-20240217-main-PR8940-6c1e34e.uf2 on the matrixportal? "PR8808" is from immediately be...
I was just bisecting when you posted @jepler ...
Adafruit CircuitPython 9.0.0-beta.0-51-gd0fec0c8b6 on 2024-02-17; Adafruit QT Py ESP32-S3 4MB Flash 2MB PSRAM with ESP32S3
works as HTTPS server,
Adafruit CircuitPython 9.0.0-beta.0-52-g6c1e34e957 on 2024-02-17; Adafruit QT Py ESP32-S3 4MB Flash 2MB PSRAM with ESP32S3 fails on server.start:
Traceback (most recent call last):
File "code.py", line 56, in <module>
File "adafruit_httpserver/server.py", line 226, in start
...
I don't remember considering this. Seems ok to me.
@tannewt can you take a look? I didn't immediately spot how your change introduced this problem, maybe you'll see it though.
No reason. We're close to getting 9.0 stable and redid the rgbmatrix code in 9.0 to make it (hopefully) more stable anyway.
CircuitPython version
9.0.0-beta
Code/REPL
>>> s = pool.socket() # or socket.socket
>>> b = bytearray(b'0.0.0.0')
>>> s.connect((b, 443))
Traceback (most recent call last):
File "", line 1, in
TypeError: can't convert 'bytearray' object to str implicitly
Behavior
In standard Python, the bytearray is accepted (and the connection fails, because there's no listener):
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
...
While working on this it might be nice to make the empty hostname function the same as '0.0.0.0', again for compatibility with standard python.
hmm, should the library only be calling
self._sock.setsockopt(
self._socket_source.SOL_SOCKET, self._socket_source.SO_REUSEADDR, 1
)
when not CircuitPython?
if implementation.name != "circuitpython":
self._set_socket_level_to_reuse_address()
But calling it always yields:
AttributeError: 'SSLSocket' object has no attribute 'setsockopt'
so maybe the custom TLSServerSocketPool class needs extending?
I believe you should set reuse before wraping socket with context.
https://github.com/adafruit/circuitpython/issues/8947
In this issue I posted a all-in-one example with current adafruit_httpserver, before the compatibility with 9.0.0 PR that is still in progress.
Ah, thanks @michalpokusa that works, and it's back to ValueError: Error: Failure to bind
Ah, thanks @michalpokusa that works, and it's back to
ValueError: Error: Failure to bind
Thanks for testing.
I just realized in previous response I linked to this exact issue 😅, happens when you jump between multiple issues/PRs. Nevertheless the class sets reuse before wraping.
Add new senseBox MCU-S2 with ESP32S2. Successfully build it locally and tested some things. More infos about the board: https://github.com/sensebox/senseBox-MCU-S2-ESP32S2
@gilded cradle it was michalpokusa, not me, who did the search performance improvement on circuitpython.org. I edited your hug report
Thanks @tulip sleet
Oh that sounds neat, I'd like to see that.
sql json flat file sounds cool. lots of progress for http server stuff lately.
That's awesome CGrover. Maybe people will start collecting wave tables like they used to.
I am still waiting for the full socket SSL support for 9.0.0, then it will also be able to host HTTPS 🙂
Sharing synth voices would be pretty cool. I mostly like to emulate existing musical sounds, but there are some pretty inventive creators out there that take it to the next level. Would love to learn from their creativity.
The Sonoma fix went backwards? :/
jepler: you're welcome for side-tracking you 😉 , and thank you 🙂
Nice to have you back Jepler. Hope you had a nice vacation.
around something I said?
or generally?
Just in general. I'd like a break from _bleio for a day or two.
It now uses ST7735 display and physical buttons.
https://github.com/adafruit/circuitpython/issues/8643 is unclaimed but may be tricky to reproduce
@short tendon https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/sharing-in-the-community-bundle (Community bundle and Adafruit bundle mostly the same process.)
ah this is the issue with reset and deinit() you found while streaming. you didn't seem to keen on all the work that would be involved with switching everything to deinit instead of using a blanket reset.
that makes a lot of sense
pulsein>pulseout>pwm>rabbithole
Thank you Devs for looking into the low level hard stuff so others like me can focus on making pretty graphics.
@lone axle Thanks for hosting!
thanks @lone axle !
Thanks everyone
Thank you for hosting @lone axle
Thanks!
(Adafruit CircuitPython 9.0.0-beta.0-52-g6c1e34e957 on 2024-02-17; Adafruit QT Py ESP32-S3 4MB Flash 2MB PSRAM with ESP32S3 works with non-SSL HTTP Server, so it does appear to be ssl-specific)
@plucky tulip is there an issue yet (or are you already working on one) for the PicoW HTTPS server regression? if not I'd be happy to bisect and make an issue
If think I do not follow, what about PicoW?
Oh, I see. I didn't create a separate issue about MemoryError, as right now it is not what pops up when running the HTTPS server, so it is hard to reproduce. Now the problems is that there is a "Failure to bind" which seems to be more general problems as it applies to all ESP boards (maybe to PicoW too, I didn't test), where a MemoryError only happened on ESP32-S2 and Pico, or at least it seems so.
yes I got espidf MemoryError on S2 also... I'll do some testing
Great. If you find anything I would appreciate ping/tag. I can also help.
presumably the PicoW and ESp32-S3 'bind' issue is the same, and you're right it's masking the memory issue, so we may be stuck for now, but I'll play around some more to confirm
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/1fKV2aLWrm9ooTyiFA41vlT5zMu4KBs1E2QbcvIaBK5Y/edit?usp=sharing
@onyx hinge Is there an example of using the OV5640 autofocus with espcamera, that is, not via pycamera. I am curious about using it with the OV5640 breakout on an esp32s3 (metro or feather) If nothing exists, I'll be happy to see if I can adapt pycamera to a more generic "mycamera" for use with the breakout. I just did not want to re-invent the wheel if somthing existed already and I was just not seeing it.
Not trying to make any work you you -- I was just curious if I had missed something and there was already a library out there. I'll look into adapting pycamara to my own use.
no, there's not. you can take a look at the autofocus related routines and just copy them though
Thanks - I just saw that they looked to be easy to extract.
While investigating #8726 I realized the crash was due to a conflict between "bulk" reset such as "pulsein_reset()" and "deinit()" based reset that is triggered by deiniting the heap. With early ports, we relied heavily on "bulk" reset so that we knew exactly the state of peripherals at the start of every run. However, we also implemented deinit() so that user code can deinit peripherals at a precise time. (del and finalizers are called at collect time or vm end.) If deinit() wasn't cal...
Make sure you are working from main. The ESP-IDF has been upgraded to 5.1 and we won't want to update your code. Just do main.
Good to know!
There are a few tweaks in the awesome circuitpython repo this week.
Pico W HTTPS Server seems to have broken with the MemoryError somewhere between 8.0.0 and 8.1.0.
Right now busio.SPI() doesn't allow it. What value do they suggest for Rpu?
I think the real question is whether there is a bug causing the problems with espcamera on the esp32s2 or if esp32s2 simply can’t handle espcamera. If that is the case, do we just document that and move on or is it worth trying to revert to something lime imagecapture. There does not appear to have been a great demand for it so I expect there are more important issues to resolve at this time.
I'm not super interested in getting things going on the S2 if we don't have a project that uses ...
The wifi chip is similar to the one on the Pico W but the code we use for it is licensed for RP2040 use only. So, we'd need to get a broader license or replace the code. (Not important for adafruit-funded dev.)
This is also related to https://github.com/adafruit/circuitpython/issues/1270#issuecomment-1711991127 which we consider splitting out Pad properties from DigitalInOut.
The easiest thing by far is to add the pull to your circuit. Internal resistors are often not the right value anyway.
I have used the espcamera on an esp32-s2 without problems a while back, so I'm confident it's possible: https://hackaday.io/project/182342-camera-shield-for-s2-mini
It would be cool if the support for the T-Deck keyboard was present in the terminal. It would add the ability to use the T-Deck as a standalone python device.
How is the keyboard connected? You'd need a C implementation of scanning the keyboard and then connect it up to serial_read(). See https://github.com/adafruit/circuitpython/blob/main/supervisor/shared/serial.c#L241 for how USB host keyboard is connected in.
This isn't an Adafruit-funded priority because it isn't an Adafruit bo...
Are you running WiFi? I think all ports use our bitbanged OneWire implementation. Any idea how it would be done with ESP-IDF?
Yeah, it looks like the directory listing response was the main issue. In order to trigger the password prompt, a listing is requested on connection, which is why it wouldn't connect.
I'm about to use Homebrew to re-install the ARM toolchain on my M1 mac. Ideally I'd like to build the 8.x latest version for now. Can I use 13.2.rel1, or will that only work with CP 9.x ?
Use 9.0.0/main we're very close to stable
Sweet, thanks!
8.2.x dev should be only for bad bugs
@tulip sleet #8820 is ready for your rereview too.
What is the advantage of allowing bytearray ASCII? This seems to go against the idea that strings are for bytes + encoding.
Please open a PR to main. The ESP-IDF upgrade has slightly changed how boards are defined and it should be tested there. 8.2.x is going to be legacy soon. We're really pushing to get 9.0 stable in the next few weeks.
Why not make a new board def? That way folks with the old one will have new versions of CP.
See output log for ‘clean’ and ’slc-generate’ commands as requested. I have posted the full output log here in case it provides more information that may be useful to understand the problem.
@.***:~/circuitpython/ports/silabs$ make BOARD=devkit_xg24_brd2601b clean
- Verbosity options: any combination of "steps commands rules", as
make V=...or env var BUILD_VERBOSE
rm -rf build-devkit_xg24_brd2601b
@.***:~/circuitpython/ports/silabs$ make BOARD=devkit_xg24_brd2601b slc-ge...
I'm not sure. Adafruit's breakout board uses a 47kΩ resistor. Espressif has some documentation that suggests a 10k resistor.
iirc S2 has 320KB SRAM, and S3 has ~540KB~ 512KB SRAM, with various claims to that memory from esp-idf/rtos/etc, and maybe some things from CP core too. I don't fully understand the new CP 9 memory model.
CP will try to allocate to PSRAM first now in beta.1+. (Not exactly sure when I changed it.) The IDF can allocate to PSRAM now too by default but needs to request it explicitly. Without an explicit request, then internal memory will be used first.
@tannewt if you remember this code, could you take a look? But this code was present before CIRCUITPY_DUALBANK and CIRCUITPY_STORAGE_EXTEND were present.
It doesn't look right to me and it looks like RP2040 has the same bug. I've always meant to factor out this cache code but never have...
In https://github.com/adafruit/circuitpython/pull/8952#issue-2143285908 it was pointed out that this code looked funny:
https://github.com/adafruit/circuitpython/blob/499cc0158b65fe8c483ff179d99510c3f7d46812/ports/espressif/supervisor/internal_flash.c#L154-L157
Specifically the value _cache_lba is set to sector_offset doesn't match the comparison value block_address. This likely causes excess sector reads when writing to the file system. I think the data written is still write. The ...
@tannewt can you take a look? I didn't immediately spot how your change introduced this problem, maybe you'll see it though.
Yup. My brain went straight to "hey, I removed that error message". Looks like ssl socket is implicitly converting the new error number returned to a bool and then throwing the error message. Will fix today or tomorrow. It should be identical to the non-ssl socket change.
@tulip sleet release notes should also call out removal of show()
I can edit them.
next time is fine too
mostly want us to have a central place for "things that may be in your code and need to change"
I use the previous notes as the starting point for the next notes, so done locally. Also I2CPeripheral is now I2CTarget.
We can wait until https://github.com/micropython/micropython/pull/13682 is released to make this simpler.
Non-ssl sockets now return size_t error numbers, not bool.
Fixes #8947
@anecdata or @michalpokusa please test this.
[low priority] @lone axle - thx for reviewing https://github.com/adafruit/Adafruit_CircuitPython_IterTools/pull/20 - one question for your thoughts: I found it helpful to locally add a tests/ directory where I could both confirm library behavior at least in cpython + run mypy to ensure concrete types in the tests passed muster. I however removed it from the PR as it wasn't directly related to type annotations. Do you think it (i.e., a tests/ set of basic checks) be something that makes sense to include in one of the upcoming PRs regardless?
@lone axle or @slender iron does ConnectionManager need to be added to the bundle before a release to pypi can be made?
I don't think so
Can we do a release?
pypi release happens when the library repo is released as long as the actions succeed. It's seperate from the bundle.
Yes, I'll make an initial release.
Actually it looks like I can release... Not sure if I should be able to
But since I know nothing about that, I won't
and found the docs for adding to the bundle
PyPi release succeeded: https://pypi.org/project/adafruit-circuitpython-connectionmanager/. The Github release actions which run mpy-cross and upload the results to the GH release page failed with a 403 error: https://github.com/adafruit/Adafruit_CircuitPython_ConnectionManager/actions/runs/7982007459/job/21794769235. I think this means that the repo does not have proper permissions set up in it's settings, but I do not have access for this repo and I don't recall the exact setting that resolves it.
Maybe write access under Actions -> General
Yes, that fixes ESP32-S3 HTTPS server. Pico W is back to the MemoryError, should probably open a separate issue for that.
okay, I don't have access to the settings either
I fixed: Librarians had Read access
Also, what pushes it to docs.circuitpython.org? So I can make sure the URL is right?
I started I re-run already sorry. Thank you for fixing the permissions.
It still shows a similar 403 on the GH actions release.
This error feels very familiar from a different library I set up recently. I think this was the setting I ended up having to change.
Also is there a way to re-run tests? I pushed a commit to Requests before I should of (changing the requirements.txt)
it was new to me when I did it though. I don't know when github added that as a necessary step or if there is some way to do it at a higher level in the org for the repos.
if it's in an action job you can usually re-run it with a button near the top right of the failed actions page.
It's not there (either for me or at all....): https://github.com/adafruit/Adafruit_CircuitPython_Requests/actions/runs/7981907962
i need to add you as a collaborator
Ahhh, I can also just push some other changes
you already are a collaborator, so just ask us for re-runs, etc. I can do it with my org privs
If it's easy to re-run the failed test job on this: https://github.com/adafruit/Adafruit_CircuitPython_Requests/pull/151 it would be great
@lone axle re-run did not work by either you or me, hmm
OK, ths requests test re-ran with no errors.
check on this setting if you can#circuitpython-dev message that was the solution for a different library for me recently I think.
yes, it was read-only, running again. Mysteriously this project is not showin up in the readthedocs subprojects list of projects we can add. I have to remember how to add it or refresh that list
I wonder if there is some way to apply that setting at a higher level so it happens automatically at the repo level. I think it will pop up for each new library from now on.
macOS Sonoma 14.4 beta 4 is out and still exhibits this behavior
@tulip sleet no rush, but if/when you get CM on RTD let me know
still looking at that
^^ this is me seeing if any builds fail adding ConnectionManager
@lone axle it's all documented here: https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/sharing-our-docs-on-readthedocs. I forgot we may have to add the project manually. I did a refresh in "My Projects" in RTD, but it didn't show up.
also I got the alias case wrong. Originally was ConnectionManager, should have been connectionmanager
I tested the updated code on S3 and PicoW. LGTM! I'll leave code review to core devs.
Rather than depend on esp_sta_list.num being limited to no more than ESP_WIFI_MAX_CONN_NUM, you can use a dynamic stack array:
mp_obj_t common_hal_wifi_radio_get_stations_ap(wifi_radio_obj_t *self) {
wifi_sta_list_t esp_sta_list;
esp_err_t result;
result = esp_wifi_ap_get_sta_list(&esp_sta_list);
if (result != ESP_OK) {
return mp_const_none;
}
esp_netif_pair_mac_ip_t mac_ip_pair[esp_sta_list.num];
for (int i = 0; i < esp_st...
I don't see that pullup in this older breakout: https://learn.adafruit.com/adafruit-micro-sd-breakout-board-card-tutorial/download, or on, say the Feather M0 Datalogger. These boards do work, hmm.
@ladyada Have you heard about this desired pullup on MISO on SD cards?
just select different color constants, like 0x7f7f7f or (127,127,127) instead of 0xffffff or WHITE or (255,255,255)
FYI, this approach doesn't seem to work on the MatrixPortal S3 with CircuitPython. The actual brightness of 0x7f7f7f is exactly the same as 0xffffff. :-(.
I was hoping this would be a solution, but no dice. I'm getting complaints about the LED being so bright it's hurting people's eyes, so I'm hoping a workaround will show up somehow.
never heard of it before. traditionally we only need a pullup on the CS line. however, we should initialize the SD card first!
I haven’t used the S3 version of the MatrixPortal yet, but suspect that the default color bit depth is set to two bits, just four levels of color brightness, limiting the granularity of intensity.
When instantiating the display in CircuitPython, the bit depth can be set to 6-bits which increases the brightness granularity — at a price of needing more memory to hold the display buffer.
If you are using CircuitPython displayio objects, you could apply something like PaletteFader to help. http...
@tulip sleet ~~I assume I'm making a silly mistake, but why are these failing on the frozen modules: https://github.com/adafruit/circuitpython/actions/runs/7982902724/job/21797383821?pr=8963~~
never mind. I made a stupid mistake
oh wait, no, I'm still stuck
the commit in frozen/ for each library needs to have a tag that is a version number
now that ConnectionManager has a release, use that commit
oh, then how can we test, since the Request one won't have a version?
the only way to test would be to make branch with a tag and check out that commit for Requests
the q is what are we testing: just that it fits, or that it works?
Both technically, but that it fits
I'm not too worried about testing that it works, since if it works non-frozen it should work frozen
is Requests bigger when it uses ConnectionManager?
No, it's smaller but together it's a little bigger
so just use the old incompatible release of Requests to test whether it fits. It won't work, but it will tell us if it fits. Keep it a draft PR. Then when we release a Requests that uses CM, you can update the PR
Ahh, that makes sense
When doing the add to the bundle, does it need to be a version?
generally, yes, but ConnectionManager has a version now
maybe always yes, not sure we considered otherwise
the bundle updates itself when new versions are released. There is a nightly run that updates to the latest released version of everything
if there are no new versions, then it doesn't build a new bundle that night
Okay, will try in a bit
So, I have a RGBMatrix brightness workaround... you can even use a brightness control to adjust the brightness values of all text/vectorio shapes and displayed BMP images. I'm defining all color values in HLS instead of Hex, which makes it super simple to change the brightness without changing the color value (just adjust L/level). For BMPs, feed the pixel_shader into a function that converts the integer colors to HSL, then adjusts their level and inserts the new value back into the pixel...
I am using wifi in this application. I see that you are disabling interrupts as the first line of that function. For the ESP controllers, I think that leads here. It has been a while since I have messed with freeRTOS, but I thought that portENTER_CRITICAL should prevent the scheduler from interrupting those lines, but I don't know where that is defined for the ESP boards. I also ...
Hmm, I would have to stare at it a lot more, but there is a driver here that implements the 1-wire protocol using the RMT peripheral in the ESP32 CPU. If that module operates independent of the CPU once the data is loaded, that might be a solution?
@dhalbert and @tannewt as an FYI, all builds pass with adding ConnectionManager and keeping the current Requests which is larger
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; Raspberry Pi Pico W with rp2040
Adafruit CircuitPython 8.2.10 on 2024-02-14; Raspberry Pi Pico W with rp2040
Code/REPL
import time
import wifi, ipaddress, socketpool
import select
ssid="ssid"
password="anything"
#Connect to WLAN ...
Is there a technical reason for selecting exactly these SPI-pins? Waveshare claims that this board is useful for the Pico oecosphere, but the SPI-pins don't map:
ESP32-S3 Pico Function
GPIO36 -> GP11 TX (MOSI)
GPIO35 -> GP10 SCK
GPIO37 -> GP12 RX (MISO)
So swapping GPIO36 and GPIO35 would align functions and make it possible to swap the Waveshare for the Pico in existing designs.
thanks for the review. I really had not consider that possibilities.
Yes, I explicitly bought that board to replace the Pico with the more powerful ESP32-S3-Pico. I do know how to build my own version with a different pin mapping, but I thought other users would also profit if swapping these two pins is possible. BTW: the I2C pins map perfectly to I2C1 on GP6/GP7.
Add new senseBox MCU-S2 with ESP32S2. Successfully build it locally and tested some things. More infos about the board: https://github.com/sensebox/senseBox-MCU-S2-ESP32S2
I haven’t used the S3 version of the MatrixPortal yet, but suspect that the default color bit depth is set to two bits, just four levels of color brightness, limiting the granularity of intensity. When instantiating the display in CircuitPython, the bit depth can be set to 6-bits which increases the brightness granularity — at a price of needing more memory to hold the display buffer. If you are using CircuitPython displayio objects, you could apply something like PaletteFader to help. http...
I am not sure about your build environment.
Can you setup and build with docker ubuntu:22.04?
I will try build a docker environment and provide to you.
OK I think I have docker build setup. I am way out of my comfort zone here 8-)). I am new to Linux just because that appears to be the only way to build Circuit Python. So not really sure what I am going at this stage.
Please send the docker environment and I’ll try to use it.
Thanks,
On Feb 21, 2024, at 7:01 AM, Nguyen Van Chat @.***> wrote:
I am not sure about your build environment.
Can you setup and build with docker ubuntu:22.04?
I will try build a docke...
@slender iron do we want to keep this section in requests?
This was originally what set_socket used, but that's gone. I changed it to be create_default_session, which then you could do:
import adafruit_requests as requests
requests.get(...)
In another file, but not sure if that's worth it, vs just creating a new adafruit_requests .Session (since it's now all tracked anyways).
Personally this feels harder to troubleshoot if we keep it
I think the reason I added it at the start was because I had used requests that way to start
Will both methods be allowed until 10.x so there's a 9.x transition like with some displayio methods?
Might not be possible to have both and I'm ok with that if there's going to be a hard cutoff in 9.x. For the sake of consistency across libraries I think it's a good thing either way.
requests changes won't be tied to a CP version. it'll be versioned by the library
ohh interesting 👍
And I know that's how CPython works, but it's all automatic. Happy to leave it if you want it there. Just trying to see what isn't well tested and add some tests
ya, I know there's this weird difference
The page states According to SDC/MMC specs, from 50k to 100k ohms is recommended to the value of pull-up registers.
My gut is that this should be the board's job. Not a use for internal pulls.
I also have no idea how this is implemented on dual core CPUs. Is it possible that the
portENTER_CRITICALfunction is not working as intended?
Running CP on the second core should insulate it from this.
My understanding is that onewire's bits are timing sensitive but not the inter-bit timing. Is that true? It is possible a Python garbage collect is causing a delay between bits.
Definitely try on the latest 9.x builds as well. A lot has changed under the hood for ESP.
add new senseBox MCU-S2 with ESP32S2. Added to v9.x only see here: https://github.com/adafruit/circuitpython/pull/8965
I've typically been creating requests and connecting to WiFi in a connections.py and then importing that requests in other files. Again happy to leave it, but anyone using set_socket will already need to change code and getting everyone to use the same thing fells like a support win
Also, do you want CM in the bundle when requests is merged, or now?
^^ also responded on GH for that one
Great! Please un-draft and we'll merge it in so that a blanket frozen update that includes the requests changes works.
Done. Would appreciate a double check to make sure I didn't miss any boards. I just did a search for frozen/Adafruit_CircuitPython_Requests
So I decided to try something completely different rather than trying to fix the current Ubuntu 22.04.2 (x86_64 emulation) with Parallels on my Mac. I started a completely new VM but this time using Ubuntu 22.04.2 ARM64 to see if that makes any difference.
I followed the Adafruit notes as defined here…
https://learn.adafruit.com/building-circuitpython/linux
Building CircuitPython
learn.adafruit.com
and here…
https://docs.circuitpython.org/en/latest/ports/silabs/README.html#prer...
When it happens on ESP32-S2 (QT Py; N4R2),
gc.mem_free()is 2001968 andespidf.heap_caps_get_largest_free_block()is 1933312.
Neither of these metrics capture the internal memory free. SSL only uses internal memory so secrets aren't on external memory.
Done. Would appreciate a double check to make sure I didn't miss any boards. I just did a search for
frozen/Adafruit_CircuitPython_Requests
That's what I would do.
Fixes #8726 which was caused by a mix of bulk reset and finaliser use.
Work towards #8960.
@hathach Mind looking at this?
@gilded cradle do you remember what setting you used to improve https://github.com/adafruit/circuitpython/issues/8692?
Not off hand, but I'll see if I can find it...
Thanks! I figure we can change the default value to match
I don't have that touch setup
@slender iron I used CIRCUITPY_HEAP_START_SIZE=2048000
that's all the PSRAM I think...
That's on CircuitPython 9.0.0-alpha.5
do you have it setup?
yes
I was thinking more like 128k or 512k
That may have been the multiplier issue version
So it may have actually used 1/8 of that
or 1/4. I can't remember.
I can try beta 2 and see how that performs
@slender iron 512000 seems to work fine. I also tried 128000 and 256000 and both still showed the issue.
Tested this on latest CP 9 version and 512K seemed to work better than 128K or 256K.
The larger number may have been when I was figuring out where the issue popped up and was testing on alpha 4, but can't remember for certain.
Thanks! I’m a bit torn because the higher number may slow down execution of small programs. It may be ok to just say the override is needed in these cases
Yeah, overriding is fine. The paint program may use a bit more memory than usual.
It may be more that there are too many garbage collections early
It did seem to start instantly with 512k, though the delay was noticeable with the 2M setting.
Thanks for retesting
No worries. I already had everything hooked up, so it was easy.
Various build failures in atmel-samd and raspberrypi due to now-missing routines.
@onyx hinge The PyCamera library is currently at version 0.0.9. Is there a reason not to make it a 1.0.0 release? I am about to release with the filesystem check.
@tulip sleet go for it!
emoji pun
State of ConnectionManager for anyone that's curious:
- v1 code is merged into
Adafruit_CircuitPython_ConnectionManager, on pypi and RTD - v1 code has been frozen to the 13 boards that also have
Adafruit_CircuitPython_Requests - PR open to add it to the bundle
Adafruit_CircuitPython_RequestsPR updated to use the released CM and updated all examples to useadafruit_requests.Sessionandos.getenv- Have one last question if we want to keep the methods like
getthat are directly onadafruit_requests(the ones that worked based on the oldset_socket
is the PR to the bundle non-draft?
Yup. Fixed it earlier
kk, I'm not sure I get an email when one is moved out of draft
Probably not. I fight with that at work and our automation all the time...
Thanks for the update! I've moved this to 9.x.x. I'd like to see if any other uses like this crop up before we change the default heap size. Having it in stable should make it clearer.
this issue is still open, but just checking if there's still no work around for BLE scanning while advertising?
https://github.com/adafruit/circuitpython/issues/6012
if not, will need to restructure some old guide code along these lines:
https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/2738
basically just don't do both
The after number after the exception is a red herring because gc.mem_free() does not ensure that gc.collect() is run first. gc.collect() is run after a successful import.
I'm looking into why the import process doesn't have enough memory.
I can't reproduce this now. I was originally testing with a proto Metro 1011 board which seems to have a bunch of problems.
Currently our ports directories are disjunct from MicroPython except for unix and nrf. Renaming the nrf directory would make merging from upstream a little easier in the future, so let's do it before the next merge.
I would suggest nordic, nrf52, or nrf-sd. The last is because the port is based on the older SoftDevice, not zephyr. Suggestions welcome.
I wouldn't do nrf52 because I expect we'll want to add nrf54 support when we can get our hands on one. nordic is fine with me.
So, I think the addition of USB host in 9.x is the main cause of this regression (not the split heap stuff). It takes ~12k extra static RAM. At least 5k of that is code that needs to run even when the flash is being accessed.
CIRCUITPY_USB_HOST=0:
RAM: 91956 B 256 KB 35.08%
CIRCUITPY_USB_HOST=1:
RAM: 104392 B 256 KB 39.82%
LWIP and picodvi also have large RAM footprints even when they aren't in use as well.
I think that using mpy ...
I tried this with #8736 and didn't see much change. I agree that the computation is an improvement but don't think we need to track it separately. We'll get it automatically when we update MP next.
Builds are fixed @dhalbert
@mortal kernel heres a 9.0.0 issue that you may be able to repro on mac: https://github.com/adafruit/circuitpython/issues/8824
Thanks! I will do some hw testing a little later.
File "code.py", line 123, in <module>
File "adafruit_httpserver/server.py", line 186, in serve_forever
File "adafruit_httpserver/server.py", line 226, in start
OSError: [Errno 112] EADDRINUSE
```I got this today with newly installed adafruit_httpserver via circup. I guess the SO_REUSEADDR change is not released yet?
I see #83 / #84 in that repo are still in progress. OK.
I'll give it a try.
thanks!
Easy to reproduce. I'm setting up SWD to troubleshoot the problem.
yeah sorry, haven’t gotten around to obtaining a RP2040 board with exposed SWD yet
NP. It's a call to panic() in __tusb_irq_path_func.
that suggests that my hypothesis about back-to-back control transfers, some of which are aborted, might be part of it
Could be. It's calling panic because of an attempt to set USB_BUF_CTRL_AVAIL when it's already set in the endpoint's buffer_control. Now for SWD and a backtrace.
standard Python accepts a bytearray here, even if it's surprising. if we can accept a bytearray without (say) code bloat, I don't see why not to.
Tested on an RP2040, creating some PWMOuts and then restarting the VM. Things seem fine. I'm impressed the code has gotten smaller!
We were going to have hathach look at the bug too. If you add a comment to the issue about what you found out so far, I'm sure he'll appreciate it.
Crash is readily reproducible using tio when disconnecting by ctrl-T Q.
So far, I've found the crash is due to panic() being called under one or the other of these conditions:
rp2040_usb.c:_hw_endpoint_buffer_control_update32()whenUSB_BUF_CTRL_AVAILis already set in the endpoint'sbuffer_control,rp2040_usb.c:hw_endpoint_xfer_continue()when!ep->active.
Made one other small change and removed a superfluous check if we're in AP mode. The ESP-IDF functions will return an error if we're not, which will lead to the correct behavior. Tested to confirm.
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; Waveshare ESP32-S2-Pico with ESP32S2
Code/REPL
### Starting the Server
mdns_server = mdns.Server(wifi.radio)
mdns_server.hostname = MDNS_HOSTNAME
mdns_server.advertise_service(service_type="_http", protocol="_tcp", port=80)
pool = socketpool.SocketPool(wifi.radio)
server = HTTPServer(pool, "/static", debug=True)
@server.route("/")
def base(request: Request):
return Re...
CircuitPython version
Adafruit CircuitPython 8.2.9 on 2023-12-06; VCC-GND YD-ESP32-S3 (N16R8) with ESP32S3
Code/REPL
import synthio
import board
import audiobusio
import usb_midi
import adafruit_midi
from adafruit_midi.control_change import ControlChange
from adafruit_midi.note_on import NoteOn
from adafruit_midi.note_off import NoteOff
import audiomixer
import ulab.numpy as np
import time
import asyncio
import analogio
import keypad
### Ini...
Just a heads up: The board you have doesn't support I2S, and you're attempting to use I2S to run the speaker. I ran into this problem and figured I'd leave this here in case anyone else runs into this issue.
I never distributed the old one to anyone, I only made a few prototypes for myself, and I really doubt anyone but me made any. It also has hardware problems, so I wouldn't recommend making it to anyone.
I wouldn't want to litter CircuitPython with boards that only I have, especially since each new board needs its own VID/PID, and that's a limited resource.
On the other hand, I already plan to do a couple of workshops with the new one, so I'm confident it will actually be used by people.
Makes sense. It was basically a proto.
Why not make a new board def? That way folks with the old one will have new versions of CP.
Did I miss something on my Bundle PR for CM? I don't see it here: https://docs.circuitpython.org/projects/bundle/en/latest/drivers.html
GPIO48 is used for the RGB LED input and is also SPICLK_N (not clear how that is used). If you set a pin other than GPIO48 here, does it crash? Does it crash if creating a keypad with GPIO48 in a simple program that doesn't use synthio at all?
The rtd build for the bundle is failing, and has been for three weeks. I'll investigate
Fixed, thanks for noticing. It was actually three months, and we were not getting notifications it was failing, which I corrected.
I'm building CP with
make BOARD=raspberry_pi_pico_w CIRCUITPY_DEBUG_TINYUSB=3 V=commands DEBUG=1 -j16
but I'm not getting any USB debug messages on my UART. I've defined CIRCUITPY_CONSOLE_UART_RX and CIRCUITPY_CONSOLE_UART_TX and I am getting REPL on the UART.
CIRCUITPY_DEBUG_TINYUSB is not a make variable; it's only a C preprocessor macro. So you'll need to set it in mpconfig<something>.h
that could be fixed
Thank you! I'll fix it if you like.
probably would save another person some time later :). But you can keep it in your pocket for some PR
Any and all feedback welcome on: https://github.com/adafruit/Adafruit_CircuitPython_Requests/pull/151
Update adafruit_requests to use Adafruit_CircuitPython_ConnectionManager for socket handling. As well as clean up examples
@tidal kiln do you know who is planning on doing the INA228 library?
i do not (or forgot). i know guide is in works - i think liz.
(you must have read same forum post...i was also double checking for it this morning)
@short tendon for WIZnet Ethernet (and I think ESP32SPI too), it should be valid (for now) to have None for context instead of FakeSSLContext?
You can try with docker environment with below guide:
Extract
dev-machine:~$ unzip build_cp.zip
dev-machine:~$ cd build_cp
Build docker image
dev-machine:~/build_cp$ docker build -t docker_cp .
Run docker image & build
dev-machine:~/build_cp$ docker run -it -v $PWD:/build docker_cp
root@docker:/# cd ./build/
root@docker:/build/# git clone https://github.com/adafruit/circuitpython.git
root@docker:/build/# cd ./circuitpython
root@docker:/...
Where does the bytearray come from? It should be a string. We don't do many things that CPython allows. Only the reverse needs to be true. (That CPython is ok with what we do.)
Please try with the latest 9.0.0 build as well. Much of the underlying implementation has been updated.
(re-asking since original may have gotten lost in noise)
this issue is still open, but just checking if there's still no work around for BLE scanning while advertising?
https://github.com/adafruit/circuitpython/issues/6012
if not, will need to restructure some old guide code along these lines:
https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/2738
basically just don't do both
I guess it worked at one time, because of the rock-paper-scissor example. I don't know why it stopped working. It should be fixed but is not high priority. PR 2738 could be accepted: does it make the example less functional?
@onyx hinge any reason not to merge https://github.com/adafruit/Adafruit_CircuitPython_PyCamera/pull/28 "Overlay feature and exmaple"
@tulip sleet I don't know why not
i will make a new release with the renamed ipcam too, then
I think it was a change I did that prevented both from happening concurrently
being able to do both helps make the initial syncing connecting easier. but not a show stopper. but will need to change code and update guide, etc. so if the core issue was going to be fixed anytime soon-ish, that work wouldn't be needed.
the changes would be along the lines of PR2378 with minor mods. i've tested that PR and it needs some tweaks.
If rock/paper/scissors works for, say, CPy 6, we could add a note to the guide. I can move the issue to 9.x.x
I'm trying to remember why I stopped it from working
i didn't realize it was deliberate
it sounds like this issue is going to be deferred. i'll work on updating the code/guide.
I think it was the identities stuff with ble workflow: https://github.com/adafruit/circuitpython/pull/4918/files
Only one device identity list can be used at a time and the list is shared between the BLE roles. The device identity list cannot be set if a BLE role is using the list.
maybe not
maybe it was a resource thing
Apropos #8824: I'm unable to attach MacOS USB with CIRCUITPY_DEBUG_TINYUSB set to 3. With Linux, USB attaches normally with exact same build. Any clues appreciated. ❤️
Here's the trace:
Version: 7.95.49 (2271bb6 CY) CRC: b7a28ef3 Date: Mon 2021-11-29 22:50:27 PST Ucode Ver: 1043.2162 FWID 01-c51d9400
cyw43 loaded ok, mac 28:cd:c1:00:d3:a5
Adafruit CircuitPython 9.0.0-beta.2-6-g89437cf031-dirty on 2024-02-22; Raspberry Pi Pico W with rp2040
Board ID:raspberry_pi_pico_w
UID:E6614C775B4D5335
MAC:28:CD:C1:00:D3:A5
USBD init on controller 0
sizeof(usbd_device_t) = 83
sizeof(tu_fifo_t) = 20
sizeof(tu_edpt_stream_t) = 40
CDC init
MSC init
HID init
VIDEO init
MIDI init
sizeof(hw_endpoint_t) = 32
0;🐍Wi-Fi: off | Done | 9.0.0-beta.2-6-g89437cf031-dirty
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
0;🐍Wi-Fi: off | code.py | 9.0.0-beta.2-6-g89437cf031-dirtyHello World!
0;🐍Wi-Fi: off | Done | 9.0.0-beta.2-6-g89437cf031-dirty
Code done running.
Press any key to enter the REPL. Use CTRL-D to reload.
BUS RESET
USBD Bus Reset : Full Speed
USBD Setup Received 00 05 01 00 00 00 00 00
Set Address
Prepare BufCtrl: [0] = 0xf400 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 0 bytes
BUS RESET
USBD Bus Reset : Full Speed
BUS RESET
USBD Bus Reset : Full Speed
[repeats a few times, then:]
USBD Setup Received 00 05 01 00 00 00 00 00
Set Address
Prepare BufCtrl: [0] = 0xf400 [1] = 0x0000
buf_status = 0x00000001
Sync BufCtrl: [0] = 0x6000 [1] = 0x0000
Short packet on buffer 0 with 0 bytes
Completed transfer of 0 bytes on ep 0 in
USBD Xfer Complete on EP 80 with 0 bytes
is this a manifestation of the bug you're trying to debug?
I think filing an issue to TinyUSB with the simple pico-sdk example given in the CPy issue would get Thach's attention
he is in Vietnam, so expect him to be online around 9pm PT
I don't think so. MacOS USB seems to be flaky and fragile.
@slender iron i can just re-work code. this seems like a non-trivial fix for the core.
it was done deliberately for 7
I think I'm seeing a timing problem, i.e., debug messages are slowing things down enough to induce it.
yah. the code is much older. one other question - did terminalio.FONT change at some point?
the size? or how so?
size, shape, etc. - it's not lining up in the UI as it used to - for the CLUE morse thing
easily fixable by tweaking positioning
maybe....
i guess it could be a change in the display_text library also...some minor change in positioning
I feel like there was some padding fix
yah. it's like that. padding changed or something.
nothing recently though
code isn't recent 🙂
meh. no worries. will fix at same time as updating for the BLE connect stuff.
gonna update now too - had the same problem
CircuitPython version
Adafruit CircuitPython 8.2.9 on 2023-12-06; Adafruit QT Py RP2040 with rp2040
Board ID:adafruit_qtpy_rp2040 UID:DF611CF78F5F3D32
I got this message:
Hard fault: memory access of instuction error.
Please file and issue with your program here (github.com etc.)
Press reset to exit safe mode.
I have a SSD1306 display and a 24lc32 eeprom over stemma i2c
Code/REPL
""
This is code to write and read from an eeprom
"""
import gc
impor...
Could you try with CircuitPython 9.0.0-beta.2?
Yes, if you aren't using SSL (which wiznet doesn't support).
Although if you don't, then this isn't called: https://github.com/adafruit/Adafruit_CircuitPython_ConnectionManager/blob/a37193847e3c7e9a4e5b9b3f893f0147df30cbad/adafruit_connection_manager.py#L96
Which may cause issues if other code depends on that
If you use get_radio_socketpool, it creates the fake context, and just stores it
I discovered this on 9.0.0 while using adafruit_ble_eddystone to debug something else. It works in 8.2.x. This is a MicroPython regression between v1.20.0 and v1.21.0. Filed https://github.com/micropython/micropython/issues/13733.
>>> memoryview(b'x') + b'y'
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported types for __add__: 'memoryview', 'bytes'
Thanks for the docker file and instructions. Looks to be exactly the same problem that I posted about yesterday when trying a clean new Ubuntu VM.
@.***:/build/circuitpython/ports/silabs# make BOARD=devkit_xg24_brd2601b V=2 clean
rm -rf build-devkit_xg24_brd2601b
@.***:/build/circuitpython/ports/silabs# make BOARD=devkit_xg24_brd2601b V=2
SLC generates project
Traceback (most recent call last):
File "/build/circuitpython/ports/silabs/tools/slc_cli_linux/slc", line 23,...
yeah, I guess that’s why I was asking… whether fake context is needed when not using native SSL, or if None is sufficient. But if that’s the mechanism to invoke connection manager, then sounds like it’s needed.
It's not what invokes CM, just that the software based pool isn't aware of the radio (like it is when it's native)
That's one of the things set_socket did (tied the radio and pool together)
One of the next additions I am hoping to get is passing the radio to things like requests and minimqtt. And that way the pool and context can be grabbed there
so if, for example, we had a device with ESP 32 SPI and Wiz net… Sessions encapsulates that and we could run both at the same time?
And if you are doing something specific, you can still pass them in
You would need to manually create 2 ConnectionManagers, but yes
How does socket allocation happen when there’s more than one connection manager?
My goal: simple for those that just need it to work, and options for those that are doing something extra
They would both track sockets separately. At that point it would fully be limited by device memory
makes sense, the socket sources are different, so there’s not really any contention other than overall memory
one pool per radio,, one connection manager per pool, one or more socket-using applications per connection manager
Yup. That's what I'm working towards
My UM S3 can have 7 native sockets open. Going to work with adding an esp32spi and wiznet5k and see what happens
cool, that will be a fun one
there is probably optimizations you can do to make more than 7 fit
Oh really, what??
Are their docs on how to do that? Would be curious to play with it
FYI -- This worked out great. I now have an AF OV5640 working with a feather esp32s3 using a PIR sensor to capture images and send them to AIO. Thanks for the great examples to start with! It's nice to be able to play with the breakouts this way and to use AutoFocus.
Not really. I'd start by chasing down the error source from the 8th socket.
to determine if it is a hard limit setting vs ram unavailable
Well I am trying CircuitPython 9.0.0-beta.2 and it seemed to take care of the hard fault but there are alot of changes from 8.2.9 in the display area that need to be fix before I know if I have a solid fix.
thanks,
ken
Mainly just change display.show(splash) to display.root_group = splash.
I did that change but continued to have other changes to my code. It became a never ending battle. All the imbeded modules related to displays i2c seemed to have changed. Now I have another HARD failure. Is there an adafruit learn or some tutorial. That's what I followed in the past but they seemed to be all outdated.
GPIO48 is used for the RGB LED input and is also SPICLK_N (not clear how that is used). If you set a pin other than GPIO48 here, does it crash? Does it crash if creating a
keypadwith GPIO48 in a simple program that doesn't usesynthioat all?
I tried other pins, like 21, same situation. Plus, as mentionned in the comments, using sensors or using any prepheral on top of synthio was causing crashes.
Please try with the latest 9.0.0 build as well. Much of the underlying implementation has been updated.
Indeed, with CP9, no more crashes. Synthio becames stable on esp32-s3 !
Thanks, Melissa. The /code/ interface seems to be working, but the /fs/ entry still shows "ℹ️ USB is using the storage. Only allowing reads. Try ejecting the CIRCUITPY drive. See Getting Started with Web Workflow for details." even though the device is not connected through USB. I assume this is a related issue.
ok, found one problem, when I original changed from display. show(splash) , I changed it to display.root_group(splash). that seemed to cause the crash/HARD failure. Fixed that to what you showed and found in documentation "display.root_group = splash
I'd say take out all the eeprom code temporarily until you get it working. It would be useful to know if the eeprom is causing you to go into safe mode.
@noqman, The purchase link from the circuitpython.org site goes to the Cytron Maker UNO. I can find a Cytron Maker PI RP2040 on Cytron's web site, but I can't find a Cytron Maker UNO RP2040.
Is this board name correct or should it be "Cytron Maker UNO"?
Hi, I'm very sorry I missed your question, and I apologize for the late reply. Actually, we planned to launch this product at the end of this month, which is why you can't find the product on our website. The product page is curren...
@hktklsh Could you give me a small test program or a sample advertisement to try? If you have a piece of an example that is not in CircuitPython, that is fine too.
I have now got everything working, display and eeprom code together and displaying eeprom data to display.
I do get a bunch of FutureWarning messages at start, see below.
FutureWarning: Display moved from displayio to busdisplay
FutureWarning: Display renamed BusDisplay
FutureWarning: EPaperDisplay moved from displayio to epaperdisplay
FutureWarning: FourWire moved from displayio to fourwire
FutureWarning: I2CDisplay moved from displayio to i2cdisplaybus
FutureWarning: I2CDisplay ren...
Yes, those changes are in 9.0.0, but there is still backward-compatible code there. In 10.0.0, the old names will be gone.
@jerryneedell Do you have an opinion about this? I am pretty reluctant to add aliases to the M0 boards, because they are so tight on space. Maybe we should just make up some guidelines going forward for the best pin names. If you have suggestions for that, I'd be interested as well.
It would be nice if effects could be added to the voices on the audio mixer. For example: pitch (playback rate and/or time-stretch), reverb and EQ maybe?
This can't be done near-realtime in Python, so it is better suited to a compiled library. Most effects would require buffering but should be achievable on something like a Pico.
How much space does an alias add to the M0 build? I like the generic RFM_* names used on the RP2040 and I think it is unlikely that multiple modules will be present on the same board. Even if they were, then that would warrant some alternative naming for that case. Using RFM_* would make it a lot easier to migrate between boards and to write guides and examples for multiple boards. It is more like the way displays are handled with TFT_*. Changing the M0 names will break a lot of existin...
Good morning @slender iron realized that Adafruit_CircuitPython_PortalBase also uses requests and that there is a call to set_socket in there we need to update before we merge in requests. I looked in GitHub and need to make a similar change in both adafruit_esp32spi_wifimanager and adafruit_espatcontrol_wifimanager. I see 2 options:
- in
adafruit_portalbase/wifi_coprocessor.py
import adafruit_connection_manager
...
pool = adafruit_connection_manager.get_radio_socketpool(esp)
ssl_context = adafruit_connection_manager.get_radio_ssl_context(esp)
requests = adafruit_requests.Session(pool, ssl_context)
import adafruit_connection_manager
import adafruit_esp32spi.adafruit_esp32spi_socket as pool
...
ssl_context = adafruit_connection_manager.create_fake_ssl_context(pool, esp)
requests = adafruit_requests.Session(pool, ssl_context)
Do you have a preference? I'd make the same changes in the other ones. Personally I like the adafruit_connection_manager.get_radio_* methods and it moves in a way to minimize imports and standardize user code.
@short tendon I did a little full text searching and found that library code in drivers/esp-atcontrol drivers/esp32spi and helpers/azure also use requests.set_socket. There are also 33 requests.set_socket calls in examples (+ more MQTT.set_socket(), not sure of the status of that)
I like alternative #1 fwiw.
is drivers/esp32spi different then Adafruit_CircuitPython_ESP32SPI? which is where adafruit_esp32spi_wifimanager is? Realize I didn't give full path info... Sorry
My plan would be to update libraries (since those would plain out break), then get all the examples and learn guides after.
libraries/drivers/esp-atcontrol/adafruit_espatcontrol/adafruit_espatcontrol_wifimanager.py:56:9: requests.set_socket(socket, esp)
libraries/drivers/esp-atcontrol/adafruit_espatcontrol/adafruit_espatcontrol_wifimanager.py:123:9: requests.set_socket(socket, self._esp)
libraries/drivers/esp-atcontrol/adafruit_espatcontrol/adafruit_espatcontrol_wifimanager.py:148:9: requests.set_socket(socket, self._esp)
libraries/drivers/esp-atcontrol/adafruit_espatcontrol/adafruit_espatcontrol_wifimanager.py:170:9: requests.set_socket(socket, self._esp)
libraries/drivers/esp-atcontrol/adafruit_espatcontrol/adafruit_espatcontrol_wifimanager.py:191:9: requests.set_socket(socket, self._esp)
libraries/drivers/esp-atcontrol/adafruit_espatcontrol/adafruit_espatcontrol_wifimanager.py:212:9: requests.set_socket(socket, self._esp)
libraries/drivers/esp32spi/adafruit_esp32spi/adafruit_esp32spi_wifimanager.py:64:9: requests.set_socket(socket, esp)
libraries/drivers/wiznet5k/README.rst:83:5: requests.set_socket(socket, eth)
```these are the non-example locations I see within the adafruit bundle
When trying to figure out these sorts of "I have to change all uses of ..." a fully populated clone of https://github.com/adafruit/Adafruit_CircuitPython_Bundle/ is useful. community bundle is worth looking in too but not adafruit's responsibility to fix
Okay, those are the same ones I found. Where is the azure one?
FYI It may not be worthwhile worrying about supporting the ESP_ATcontrol library. It was tagged as unsupported long ago https://github.com/adafruit/Adafruit_CircuitPython_ESP_ATcontrol?tab=readme-ov-file#this-library-is-no-longer-supported-the-library-is-being-left-available-for-continued-usage-however-adafruit-is-no-longer-supporting-it
It's a tiny fix. And will help to get rid of all the unsupported calls
@onyx hinge Other than wasting some time, is there any "down-side" to executing the Autofocus code on an OV5640 camera that does not have the AF motor. It is not clear that there is any way to tell if it is supported or not and it seems to "do no harm". It goes through the motions and seems happy to "try" to focus it. I was just curious if I was missing something and needed to worry about executing it on a board with no motor.
No problem -- I'll let you know if I find any reason. I'll leave it in for all the breakouts I am trying. Adafruit and Waveshare, with/without AF. So far, no problems.
@onyx hinge didn't want this to get lost. Where is the azure one?
@short tendon my mistake, the azure ones are MQTT.set_socket
libraries/helpers/azure/adafruit_azureiot/iot_mqtt.py:123:13: MQTT.set_socket(self._socket, self._iface)
Ahhh. Thank you. Will need to get those too
Just need to get Scott's opinion on the alternatives
@VPTechOps the message may a bit misleading. Essentially, you can either have a writeable file system via USB or with web workflow, but not both at the same time. You'll want to disable Mass Storage to make it writeable. See https://learn.adafruit.com/getting-started-with-web-workflow-using-the-code-editor/device-setup#disabling-usb-mass-storage-3125964 for more info.
I agree #1 is good
I'm currently travelling and only have my UM S3 with me. Do you have access to a PyPortal or Portal M4 to test with?
I do
@Vindictive Pigeon in discord [reports](#help-with-circuitpython message) alarm, including time alarms, doesn't seem to work on the Swan R5, an STM32L4R5 board.
@m-mcgowan: may be of interest to you.
@slender iron when ever you have time: https://github.com/adafruit/Adafruit_CircuitPython_PortalBase/pull/100 and https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/pull/188
done
Do we want to release them now, or with requests?
I was thinking they'd get released next time foamyguy does a sweep
👍
@slender iron Requests PR updated. Got test coverage up to 85%
After that's in, I'll finish attacking MiniMQTT
I think we should wait until next week to merge it
just to ensure no one hits an issue over the weekend
Totally agree with you there. But if you have time to review I can work to fix anything else up before then
I'm already through my reviews for the day. debugging usb now
Sounds good. Enjoy your weekend
thanks! you too
Is there an Adafruit owner for Adafruit_CircuitPython_AzureIoT? It's totally broken for wiznet5k and esp32spi because it directly imports ssl and uses ssl.create_default_context(). And also uses MQTT.set_socket which also creates a fake ssl context. This change was over 2 years ago...
I see 2 paths forwards:
- fully remove support for anything without on-board/native wifi
- add support for
esp32spiand update docs to state that thewiznet5kis not supported (it doesn't say that it is, just being specific)
it does state:
Board Compatibility: The following built-in modules must be available: gc, json, ssl, time
But then does listESP32 AirLift Networkingright under that
I think it was done by someone at microsoft. and they just annouced it is going away I think
So that sounds like I should do #1? Otherwise it will break when we merge in the MiniMQTT changes...
Adding the RFM aliases takes 84 bytes extra on Feather M0 RFM69. We recently gained a lot of space by switching to shorter error messages on these smallest builds.
{ MP_ROM_QSTR(MP_QSTR_RFM_D0), MP_ROM_PTR(&pin_PA09) },
{ MP_ROM_QSTR(MP_QSTR_RFM69_D0), MP_ROM_PTR(&pin_PA09) },
{ MP_ROM_QSTR(MP_QSTR_RFM_RST), MP_ROM_PTR(&pin_PA08) },
{ MP_ROM_QSTR(MP_QSTR_RFM69_RST), MP_ROM_PTR(&pin_PA08) },
{ MP_ROM_QSTR(MP_QSTR_RFM_CS), MP_ROM_PTR(&pin_PA06) },
I suppose the other way to look at this is to say that leaving it as is only means adding a few lines to be commented in/out of any examples. Perhaps that is the better way to go to avoid the inevitable issues with running out of space for every change to 9.x.x builds. 84 bytes is not trivial....
As noted, going forward standardized names should be used but it may not be worth losing back at the M0 boards.
Regarding the examples, we still will likely include examples of how to use them wi...
The older names would be dropped in 10.0.0. But we'd need to change several guides and examples.
Another change I see is to name the I/O pins DI0, DIO1, etc. uniformly. Those are the names used on both the SXnnn datasheets and the RFMnn module datasheets. Then they don't get confused with the regular D0, etc. pins.
For any future boards, I'll try to make sure the names are consistent with the guidelines described so far:
RFM_*RFM_DIO*
Also the Arduino pin names ...
maybe ask in an issue on the repo. that way someone who worked on it can give insight
I managed to hit "Hard fault: memory access or instruction error." after only a few minutes playing with the httpserver examples. I dont have more details at this time, just that I was using the pico w.
@hathach How do we initialize the USB host stuff so that we can see devices that are already attached? Do we need to toggle power or is there a TinyUSB bug here?
@hathach The second read issue is due to the endpoint being claimed already by an internal HID read. Should I add a blanket abort transfer call or have the HID library manage the abort?
This improves #8885 but doesn't fix the read error.
https://github.com/mydana/CircuitPython_DMX_Transmitter Would love feedback.
Just wanted to say thanks @mydana, I just found your library from this thread and was able to set it up and get it working without any issues using an RP2040 and CircuitPython 9.0.0 beta 2. Your wiring diagram in the README was also very helpful. Thank you! I hope that it can be added to the community bundle soon.
Issue opened. I also did some digging, and it appears the shutdown message for Azure IoT was a mistake and it isn't.
The message just started to appear on CP9. I have been using web workflow for quite some time using the same procedures. This is new, and as I pointed out, the USB on the device is not connected to anything other than a power supply. The circuitpy drive does not appear because there is no USB connection. Am I missing something?
CircuitPython version
Adafruit CircuitPython 8.2.9 on 2023-12-06; Swan R5 with STM32L4R5ZIY6
Code/REPL
def work():
led.value = 1
time.sleep(LED_TIME)
led.value = 0
while True:
# do some work
work()
# sleep
if MODE == SPIN:
next = time.monotonic() + INT_TIME
while time.monotonic() < next:
continue
elif MODE == SLEEP:
print(f"(normal) sleep for {INT_TIME}s")
time.sleep(INT_TIME)
elif MODE == LIGHT_SLE...
@hathach How do we initialize the USB host stuff so that we can see devices that are already attached? Do we need to toggle power or is there a TinyUSB bug here?
when initializing usb host, it should reset controller, any current attached device should go to enumeration process as newly plugged. Otherwise, it is a bug with controller, in this case is the pio-usb controller. Let me try to reproduc this first, @FoamyGuy do you have any quick code.py to test with.
@tannewt let me try it out first on Monday since I don't follow how usb host is managed in cpy.
@hathach during this test I was not using any specific code. I think just the default print("hello world") file that comes from a storage format.
The code itself wasn't trying to interact with the keyboard. I was trying to use the keyboard to interact with the REPL after the code finished executing.
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0-24-g6022b94cf6-dirty on 2024-02-11; Seeed XIAO nRF52840 Sense with nRF52840
Code/REPL
import time
import gc
MEM_CUTOFF = 16000
time.sleep(4)
a = []
print("Eating memory:...")
while True:
gc.collect()
mem_free = gc.mem_free()
if mem_free < MEM_CUTOFF:
print(f"mem_free: {mem_free}")
print("opening file")
time.sleep(0.5)
f = open("mem_test.txt", "...
This might be releated to #8961. Could you also retest with 9.0.0 beta.2? I don't expect a change but let's make sure.
This is starting to look like a possible hardware erratum where the device controller doesn't clear USB_BUF_CTRL_AVAIL on EP0 when a SETUP packet arrives before the OUT packet from a preceding control write. In the first case, there's a panic because TinyUSB finds the flag already set. In the second case, TinyUSB gets a completion interrupt from the OUT packet arriving before it configures EP0 to receive the data stage, because the device controller accepts the OUT DATA due to the flag alre...
@eightycc thanks for the debugging! Could you possibly get full stack traces for those?
I've retested with 9.0.0 beta.2 Same results (although different cutoff for remaining memory before crash occurs).
I don't think its related to #8961 as this is running on nrf, and I can't see the suspect code in that port.
@tame creek I'm getting the backtraces you asked for now. @danh suggested that I try reproducing this with blink as you'd mentioned earlier in the issue. Could you give me the descriptors that you used for the ACM endpoint?
i just changed this in pico-examples; no special ACM descriptors
diff --git a/blink/CMakeLists.txt b/blink/CMakeLists.txt
index 63ffbd3..d953b9f 100644
--- a/blink/CMakeLists.txt
+++ b/blink/CMakeLists.txt
@@ -5,6 +5,10 @@ add_executable(blink
# pull in common dependencies
target_link_libraries(blink pico_stdlib)
+# enable usb output, disable uart output
+pico_enable_stdio_usb(blink 1)
+pico_enable_stdio_uart(blink 0)
+
# create map/bin/hex file etc.
pico_add_extra_outputs(blink)
diff --git a/blink/blink.c b/blink/blink.c
index d478d78..8fa2f49 100644
--- a/blink/blink.c
+++ b/blink/blink.c
@@ -13,6 +13,7 @@ int main() {
const uint LED_PIN = PICO_DEFAULT_LED_PIN;
gpio_init(LED_PIN);
gpio_set_dir(LED_PIN, GPIO_OUT);
+ stdio_init_all();
while (true) {
gpio_put(LED_PIN, 1);
sleep_ms(250);
Got it, thanks!
but yeah hello_world/usb also exhibits the hard fault
One other thing, since the problem is only reproducible with an RP2040/MacOS host combination, I don't understand how it could be an RP2040 hardware bug?
because the macOS CDC host driver sometimes aborts control write transactions, which is technically permitted by the USB spec, but i haven't observed other OSes doing. the RP2040 hardware might have a bug that makes it difficult or impossible for firmware to recover from that
Understood.
@tulip sleet topic pinned message hasn't been updated with this weeks notes doc yet.
fixed -thanks
Here is a backtrace from a breakpoint at panic():
Thread 1 hit Breakpoint 1, panic (fmt=0x0) at sdk/src/rp2_common/pico_runtime/runtime.c:307
307 void __attribute__((noreturn)) __printflike(1, 0) panic(const char *fmt, ...) {
(gdb) bt
#0 panic (fmt=0x0) at sdk/src/rp2_common/pico_runtime/runtime.c:307
#1 0x20000ba2 in _hw_endpoint_buffer_control_update32 (ep=ep@entry=0x2000d0cc <hw_endpoints+32>, and_mask=and_mask@entry=0,
or_mask=or_mask@entry=54272) at ../../lib/tinyus...
@tlyu The reason that the trace is light is that full level 3 tracing in TinyUSB affects timing to the extent that MacOS cannot enumerate the device. If you'd like more tracing, let me know what you'd like and I'll add it.
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; Adafruit Camera with ESP32S3
Code/REPL
import os
import storage
storage.remount("/", readonly=False)
try:
os.mkdir("/sd")
except OSError:
pass # It's probably 'file exists', OK to ignore
storage.remount("/", readonly=True)
Behavior
Above Code is in boot.py. When going to http://cpy-da7e84.local/fs/#/sd/, I get the following error in the console:
V...
@tame creek I've also captured a USB trace with a Beagle. I can send you a CSV if you'd like.
@eightycc thanks! That is helpful, even if the trace is missing the control request details. It looks like in this instance, there are back-to-back control writes with no data, so they're answered with a ZLP IN transaction (control status stage). The one that panics is because the AVAILABLE flag set by the previous status stage wasn't cleared by the device controller hardware when the transfer was aborted with a new SETUP packet.
from the same event that you posted the stack trace of? i'd prefer the actual Data Center capture file, if you have it
Not the same event. I'll re-run it to get you traces of the same event with the Data Center capture file.
thanks! yeah, if you could get the TinyUSB trace logging, the stack trace, and Beagle capture all from the same event, that would be very helpful
You bet. Give me a few minutes...
@tlyu Here are the traces of single failure event. The Control Center capture is the zip file at the end.
Thread 1 hit Breakpoint 1, panic (fmt=0x0) at sdk/src/rp2_common/pico_runtime/runtime.c:307
307 void __attribute__((noreturn)) __printflike(1, 0) panic(const char *fmt, ...) {
(gdb) bt
#0 panic (fmt=0x0) at sdk/src/rp2_common/pico_runtime/runtime.c:307
#1 0x20000ba2 in _hw_endpoint_buffer_control_update32 (ep=ep@entry=0x2000d0cc <hw_endpoints+32>, and_mask=and_mask@entry=0, ...
@eightycc thanks so much for the coordinated traces! The Beagle trace confirms what I've seen before in a previous context: some CDC control requests sent by macOS are aborted. It also confirms that my suspicions are likely correct, that the RP2040 hardware doesn't clear some state for a SETUP packet that it probably should.
There are 4 OUT control transfers of length 7, which are CDC Set Line Coding, followed by 3 no-data control transfers, which are CDC Set Control Line State.
The fir...
@tlyu Have you discussed these possible issues with the RP2040 folks? I think https://github.com/raspberrypi/pico-feedback is the right place. There are some USB hw issues there already.
I'm guessing that they licensed IP for the peripherals and did not design them themselves. But I might be wrong. @hathach would probably know.
Well, I switched to:
Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM with ESP32S3
And it seems to have improved the situation. The bus is still getting interrupted sometimes, but the CRC errors are very uncommon.
(interrupted on receiving data bytes.)
Every capture that I have done has shown a delay like that somewhere in the tr...
@dhalbert not yet; thanks for the pointer! It only occurred to me that it might be a hardware erratum after seeing the stack traces and doing a close read of the TinyUSB code.
So I was adding some unit tests with a fake i2c device for adafruit_bitbangio - and saw something that I couldn't understand how it's working 🙂 : https://github.com/adafruit/Adafruit_CircuitPython_BitbangIO/blob/2410e85a2faaa0c408aa6bb91b5817617cf23540/adafruit_bitbangio.py#L404-L408
E.g.: with spi mode 1 (polarity=0, phase=1) wikipedia thinks data should be written on the rising clock edge. https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#:~:text=the original specification.-,Mode numbers,-[edit]
But the code is updating mosi value on the falling clock - e.g. when polarity = 0, it's getting set here when the clock is also going from 1->0
I was initially thinking that maybe the read code got copy-pasted without flipping the logic for the write, but second-guessed myself as I'd imagine this would have caused issues before. (Maybe because the mosi value is getting set right before the clock, there's just enough time for the values to update by the time the peripheral reads the data on the falling edge? Not sure..)
I dumped some of the net values from the simulation here: https://ibb.co/7CLJ4xm - the decoder is still able to get the right bits (for mode=1) but it also seems like it's because the data is getting pushed out just before the falling edge.
@dhalbert just wanted to update you that I tried the latest Circuit Python version 9 and the matrix worked with the sample 2 line scrolling but when I used my code I ended getting memory allocation errors and an issue with sdcardio, understanding that its in beta, will check back in other revisions.
Hi Guys,
Just want to give an update on progress rebuilding the CircuitPython .bin file for the SiLabs EFR32MG24 Dev Kit. I finally got it to work. Here’s how…
I have an old Intel i5 based Mac on which I re-installed the mac OS, specifically Big Sur 11.7.10, so it was completely clean. Then I installed the Parallels VM tools, then used the Parallels tools to install Ubuntu 22.04. Following that I installed the Docker build tools, and then followed the instructions for building and runni...
Hi Good day, here I updated the details and images for the Maker Uno RP2040 board.
Please let me know if there is any problem or questions.
Thank you!
@eightycc please try hathach/tinyusb#2492 to see if that helps?
@tlyu Your patch fixes the WARN: starting new transfer on already active ep 0 in failure mode, but the ep 0 in was already available remains. I'll follow up with traces shortly.
Thread 1 hit Breakpoint 1, panic (fmt=0x0) at sdk/src/rp2_common/pico_runtime/runtime.c:307
307 void __attribute__((noreturn)) __printflike(1, 0) panic(const char *fmt, ...) {
(gdb) bt
#0 panic (fmt=0x0) at sdk/src/rp2_common/pico_runtime/runtime.c:307
#1 0x20000bc6 in _hw_endpoint_buffer_control_update32 (ep=ep@entry=0x2000d0ec <hw_endpoints+32>, and_mask=and_mask@entry=0,
or_mask=or_mask@entry=54272) at ../../lib/tinyusb/src/portable/raspberrypi/rp2040/rp2040_usb.c:115
#2 ...
@argonblue Looks like progress and I think you are on the right track. Let me know if there's anything I can do to help.
@eightycc thanks! Which RP2040 board are you using, and what is its CPU clock speed? I guess it could also be down to a host-side timing issue as to why I'm not longer seeing failures and you are.
There's some TinyUSB-side state that I needed to reset as well, which explains the "already active ep 0". There's also a delay missing from the buffer control setting, which might be necessary to ensure that the AVAILABLE flag is already clear before proceeding with the rest of the request handling.
@eightycc I updated the patch in the TinyUSB PR; please try it when you get the chance?
@tlyu Now fails 10 out of 10 attempts.
Thanks, please try again? I had a precedence oops previously with bitwise operators.
@mortal kernel if you put the parens around the bitwise-and, and it went back to 10/10 failures, that's kind of odd. it definitely fixes the failures for me on the macropad, even with circuitpython
i wonder if the Pico W is running on both cores due to the WiFi support, and maybe that's running into race conditions between the cores?
My understanding is that the second Pico core remains idle with WiFi.
I can test with a plain Pico if you'd like.
sure, that would be a good comparision
@mortal kernel how are you getting the REPL and the TinyUSB trace in the same window? is the REPL outputting to UART? or are you sending TinyUSB traces to CDC?
I've activated CIRCUITPY_CONSOLE_UART_xX, so REPL is going to a UART. The trace calls from TU_LOG get routed to only the UART, CDC is quiet except for the usual startup messages from the VM.
Still failing on the Pico W. I'm setting up a Pico now. It'll take me a few minutes to solder the headers...
I just got my Video Game Module for Flipper Zero which is a RP2040. Thought I might try my hand at adding a port. Would it be worth it to add this one?
the question is do you need it?
No, I don't. It has some interesting things (video out, and 6-dof), but that isn't really my project style for what I use CP for
@tame creek Sorry for the delay. Got a bad (my first) Pico. Let me solder up another...
also try deleting your extra TinyUSB tracing. i have a hunch it might be throwing off the timing enough to break my workaround
Good point. I'll do that too.
i was getting enumeration errors at log level 2
Me too, at level 3.
log level 2 at 230400 bps enumerates, but panics on tio disconnect, even with my patch, so there's definitely a race condition in my workaround and almost certainly a hardware erratum
I've removed my tracing. With your patch, the Pico will not enumerate.
that's the one with this fix?
while ((usb_hw->abort_done & 0x3) != 0x3)
Yes.
huh, works for me on the kb2040, unless i have too much tracing turned on
to confirm, you're using commit dc8cb27048240fe91015b01480eea77f707aa784 or a cherry pick of it?
Yes, dc8cb27048240fe91015b01480eea77f707aa784. I need to be AWK for the next 2 hours.
interesting. ok, thanks for all your help!
I might need to add an explicit clear of the ABORT_DONE register. I'm not sure when I'll get to it yet.
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.2-10-g54e78c89fc on 2024-02-22; Seeeduino Wio Terminal with samd51p19
Code/REPL
import displayio
displayio.*tab*
Behavior
>>> displayio.FutureWarning: Display moved from displayio to busdisplay
FutureWarning: Display renamed BusDisplay
FutureWarning: EPaperDisplay moved from displayio to epaperdisplay
FutureWarning: FourWire moved from displayio to fourwire
FutureWarning: I2CDisp...
@domdfcoding I ran into that problem using the adafruit_sdcard package, using the built in sdcardio package instead works fine and is easier since there's nothing extra to install. This was on 8.2.10 by the way
@eightycc what chip revisions do you have? Apparently revisions earlier than RP2040B2 have an erratum (RP2040-E2) that causes endpoint aborts to NAK the endpoint forever.
@tlyu The Pico W I've been testing with is B2, the Pico that fails to enumerate with your patch is a B1.
I just gave it a shot with beta 2 and it works perfect 👍
I just gave the recommendation because I thought it would be something that would be good to document.
Thanks!
A very simple suggestion to use the naming that is used by Python.
When trying to access info about a generator fuction, repr simply returng `` without name of the function.
The idea is to change it to ``.
CircuitPython:
Python:
Note that hw_endpoint_lock_update() is null, so calls to hw_endpoint_start_next_buffer() are unprotected against concurrent calls from user and IRQ level routines.
Probably the same as #8977? I added some graphs there (using time-alarms).
I have been doing a lot of testing between CP8 and CP9. When I do similar testing in CPython, I have different virtual envs that I activate to test code on. Since CircuitPython has a lib path order, it would be awesome to make it (for CP9):
- current dir
- root
- frozen
- lib9
- lib
This way when 10 comes out, lib9 would become lib10 and when you switched versions back and forth, back and forth you wouldn't need to re-copy files (or download source, which is why I am doing curre...
I will likely be missing the meeting today. Added a picture in the notes for the TFT BFF.
Maybe the bring-up code on your custom board does not work, so Thonny can't connect to your custom board.
The board communicate with Thonny via EUSART0. You can try build & flash firmware to print something to VCOM first.
In addition, you should use Ozone-Segger tool to debug your bring-up code.
I think that I might have to accept a larger race condition window on B1 hardware and earlier, by only doing the ABORT for the chip versions where it works.
@eightycc updated the PR to only use ABORT on hardware B2 and later. This means the workaround should work in some cases on B1 and earlier, if the firmware wins the race condition. Please give it a try when you have a chance.
(The failure to enumerate on B1 is consistent with the description of the erratum RP2040-E2.)
Does anyone happen to know more specifically what "Mismatched versions in .pre-commit-config.yaml " on the circuitpython.org library infrastructure issues page means?
Or alternatively if it's possible / how to run this report locally so I can try to add some print statements to the code to understand what specific versions it's believing are problematic.
I noticed ConnectionManager is in that list, which was very recently cookie cutter'd I believe. If there is something mismatched in there it's perhaps an indication that an update to the cookie cutter templates are in order.
I am not in favor of adding a board just because it exists. If you want to use it, great, or if you think there's a good use case, ok.
I did make some updates to black and added isort. Didn't know anything was looking at that. I can revert if needed. (Personally I love isort)
I don't personally have much of a preference on the specific versions we use. But I think it should be consistent across all libraries so we don't end up with inconsistencies, and I'd still like to understand if there is some way to glean more info from the report or the libraries it identified issues with.
Swapping GPIO36 and GPIO35 would align functions and make it possible to swap the Waveshare esp32 s3 pico for the RPi Pico in existing designs.
ESP32-S3 Pico Function
GPIO36 -> GP11 TX (MOSI)
GPIO35 -> GP10 SCK
GPIO37 -> GP12 RX (MISO)
Suggested by @bablokb in here https://github.com/adafruit/circuitpython/commit/448b8cb271ebc7bce2dd25f3f3b4887af8968884
Gotcha. Let me know if you want to revert (I made the same changes in requests). Also, someday I would love to talk about tox, testing and coverage - if anybody wants to listen
And not sure if I can have access to the report, to see if I can help get more information
I'd say go ahead and revert it for now and we can see if that was indeed the cause of it appearing in the report.
If that does turn out to be the case, I'm not opposed to using the newer versions but we should do it in cookie-cutter and run a patch to update the existing libraries.
I can get that done tonight when I'm at my desk. I'll ping you here so you can release and see if it fixes it (on your schedule)
Have you all talked about isort before?
So this just aligns 8.2.x with what has now been merged into main, is that right?
I've seen the name pop-up before, I'm not sure if it was in a disscussion here on discord or just usage in some place. I'm not really sure what it does tbh. I don't think there have been any substantial discussion around it.
actually coincidentally I think I just found the place where I am remembering seeing it from https://github.com/adafruit/cookiecutter-adafruit-circuitpython/pull/224
It sorts imports, so it just helps keep code clean
@summer boughnblue Good morning! I'll be setting up and testing your latest patch once I've had my coffee. A couple of quick questions: Why does your pull set USB_BUF_CTRL_DATA1_PID? What is the race condition you're correcting?
that race condition is that the EP0 data toggles might not be set correctly after an aborted control transfer. arguably, it's redundant as long as AVAILABLE is cleared, because the next transaction setup should set it to the correct value before re-enabling AVAILABLE
<@&356864093652516868> We'll have our weekly meeting in about 90 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/1fKV2aLWrm9ooTyiFA41vlT5zMu4KBs1E2QbcvIaBK5Y/edit -- I look forward to everyone's updates!
It is possible to run locally via adabot, though I don't remember if you need to run ALL of adabot to get it
You can modify sys.path yourself to do the same thing. I don't think we want to make the lib dir version dependent, because it would require a lot of new explanation. But the other day I thought we might suggest to MicroPython that .mpy files encode the mpy version in the filename: .mpy8, etc. The .mpy version does not correspond to the CircuitPython or MicroPython major version number, so that's a bit confusing. MicroPython has not adopted a semver style of version numbering, either.
Mismatched versions is an adabot-generated flag for repos whose pre-commit revisions don't match the pre-commit-config file in the cookiecutter
BUT based on how it works, it'll also trigger if the hooks don't match up as well (e.g. new hooks not in the cookiecutter)
I am not sure there is a name always available, but this would be clearer, I agree. It is something that is in the MicroPython core, and might be proposed upstream.
@lone axle you should be able to run it via adabot locally with the --validator validate_contents flag but you may not need that now that I'm catching up
Thanks. I have not used Ozone Segger and I will need to learn how to use those tools as well. Before going down that route I would like your comments on what I have tried. I will also check what options are available to build a simple Tx/Rx interface with EUSART0.
• With the EFR32MG24 Dev Kit I can…
-
Use SS5 to build and load the BGAPI bootloader and use the bare metal ‘Blinky’ to flash the blue LED on the Dev Kit. No issues.
-
Use Simplicity Commander to load and run the official...
@tlyu I've done some testing with your PR and find that it works with B2 but B1 still has problems.
I believe that the root cause is the race condition in hw_endpoint_start_next_buffer() noted earlier. Saving the interrupt state and disabling interrupts at the start of hw_endpoint_start_next_buffer() and then restoring interrupt state at its exit resolves the problem for both B1 and B2. I am able to build with -Og and TinyUSB level-3 tracing with no difficulties.
@dhalbert my goal wasn't to replace the lib folder, but to add an additional one. Specifically for testing purposes.
I'm suggesting since you can modify sys.path yourself, you can set this up without it being a permanent feature that we have to document. I think the number of people who have this use case will be low.
@eightycc thanks for the additional testing! I think you might be right about the user/interrupt context race condition being a component, and that fixing that race can mitigate the problem on B1. I think that without the endpoint aborts, an incorrect transaction can still get dispatched under a different scenario.
In the particular instance we're seeing with macOS and closing of CDC serial devices, the transactions queued for the aborted CDC control transfer are still valid for the duplic...
Forgot to attach this:
<img width="878" alt="Screenshot 2024-02-24 at 2 40 28 PM" src="https://github.com/adafruit/circuitpython/assets/2681417/2ce13bac-8677-4068-ba94-775c2a19976a">
In the particular instance we're seeing with macOS and closing of CDC serial devices, the transactions queued for the aborted CDC control transfer are still valid for the duplicated one that follows, but that might always not be the case for other instances of this problem.
Good point. I think the final PR should incorporate both of our patches.
MIDI Finger Piano w/ Raspberry Pi Pico project
Capacitive touch, custom PCB for MIDI interface
ToC:
0:00 - Intro
1:02 - Machining mini kalimba
1:49 - Solder on components
3:30 - Multimeter testing
4:20 - Trying it out - world's first MIDI kalimba?
5:12 - Huge kalimba mod
6:02 - Custom PCB & assembly - PCBWay
7:08 - PCB working without Kalimba
8...
I may just integrate into an existing library repo
Thanks everyone
Thanks for hosting Liz. Hope everyone has a nice week!
Thanks Liz/All 😄
Thank you all!
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/1NxTW_z8Ewhjbh9voOGli4Jt0PIRy9slbp2u51NzX02s/edit
Hey @lone axle, do you think for the .pre-commit-config.yaml that it's the whole file that needs to match? I also added some pylint things in the test files like invalid-name that almost every test needs since then have long names.
I'm not sure. @proven garnet do you happen to know if the mismatched versions precommit check will get tripped by pylint differences as well? Or is it specifically for versions and whether the tasks exist or not?
In general though I would say I am in favor of .pre-commit-config.yaml being the identical in all libraries to whatever extent is possible, and ideally keep cookiecutter matching whatever that is.
The more that common infrastructure files like that diverge across the libraries it makes it harder to use the patching mechanism in some cases I believe. Keeping those files in sync accross the libraries makes maintenence easier.
Fair and don't disagree. How hard is it to update the pylint rules and patch them everywhere? Happy to update and add all the ignores, just seems like they would be good changes
the patching process uses adabot. The readme contains a brief documentation on how it works https://github.com/adafruit/adabot?tab=readme-ov-file#applying-patches-to-all-circuitpython-libraries
@lone axle what would you like me to do:
- Revert all the changes in that pre-commit file (and fix any linting issues)
- Wait a day or so to see if people want to merge in the isort change (made a comment) since it seemed like it was good and just needed 1 fix (if they are good with it I'd try to get my other ones in too)
you can wait and see about the change
just a random note: I had trouble with HUSB238 and QT Py ESP32-S3 PSRAM in 8.2.10. It seemed to communicate properly but read impossible data. With 9.0.0-beta, it was perfect.
@makermelissa What code.py are you running? It needs to mount the SD card using the native classes. We don't auto-mount SD cards yet. On reload, the SD card won't be available while the VM is stopped and restarted. The reload won't happen while a file is being uploaded.
I filed and issue for auto-mounting here: https://github.com/adafruit/circuitpython/issues/8678
Are you seeing the LEDs blink like CircuitPython is running? They should blink during start up. A debugger will make it much easier to get it going. My process doesn't use Segger Ozone but GDB: https://learn.adafruit.com/debugging-the-samd21-with-gdb (Applies pretty well to all cortex-m cpus.)
It appears that the first bit in a byte sent can have inconsistent timing.
This might correspond to loading code off of the flash chip because it isn't in RAM. You could try capturing the flash's CS line as well.
Looking at the flash code, it looks like a scratch flash sector is used as a buffer when memory is low - could this be the issue?
Ya, I suspect that is the issue or something similar.
@hathach CircuitPython 9 will automatically use a connected keyboard as input. This is done by the supervisor using the TinyUSB host HID driver. So, no specific code.py is needed on the RP2040 USB host feather because the board_init() starts up the USB host port.
@makermelissa, the message just started to appear on CP9. I have been using web workflow for quite some time using the same procedures on CP8. This is new, and as I pointed out, the USB on the device is not connected to anything other than a power supply. The circuitpy drive does not appear because there is no USB connection. Am I missing something?
Please file a new issue and let us know what board you are using.
I imagine it makes less sense to restrict frequency, as other countries have very different restrictions. The other thing is you can often use other frequency bands with less power (like FM radio), especially if you have a Ham radio license (more power allowed). Presumably the libraries could default to a US frequency? Having to do it by country is a pain (we can't see channels 12 + 13 based 2.4ghz WiFi networks in the UK unless we select GB on some devices/toolchains, and routers auto-select channel)
I dont think we have amazon sidewalk here, but that's really interesting to know
@midnight ember you might want to record that in some form in the issue: https://github.com/adafruit/Adafruit_CircuitPython_RFM9x/issues/92
we're not supposed to see channels 12 & 13 in the U.S, but some commercial devices regularly use at least channel 12
will do and will delete the comment here so it's not crossposted. didn't know there was something open for it already. will do.
Thanks for the message, I’ll take a look at the GBD debugging notes.
My custom board has a single RGB LED just like the SiLabs EFR32MG24 Dev Kit. That RGB LED doesn’t blink during CP start up on either the Dev Kit or the custom board, even with the official 8.2.10 release. CP works fine on the SiLabs Dev kit.
While I was trying to get the CP build environment working over the past month I also tried out non-CP code, mostly using the examples in SiLabs Simplicity Studio. One issue that I...
moved my posts to the issue, further discussion can be done there. Thank you for the link @tulip sleet
That RGB LED doesn’t blink during CP start up on either the Dev Kit or the custom board, even with the official 8.2.10 release.
Switch to 9.x. I think I added it there. 9.0.0 is almost stable and has many fixes.
Adafruit Requests 3.0.0 released thanks to @short tendon for Connection Manager. I did the release notes and version myself to note the changes. I also poked RTD to get the docs build updated.
@BlitzCityDIY Have you had a chance to use web workflow recently? Is this still an issue?
This is related to: https://github.com/adafruit/circuitpython/issues/2179
The warning check things the properties are being loaded (because they are internally.)
We could enhance this code to do map lookups on native types since they rarely have superclasses.
I have the same changes in Requests that is now merged. If you run the report does that one also error?
I'm not set up to run it locally. I found ConnectionManager listed here: https://circuitpython.org/contributing/library-infrastructure-issues I'm not sure what time it runs the report to refresh the live page, I assume some time over night.
@tlyu I've been testing with both patches in place on both B1 and B2 RP2040s and cannot get it to fail.
You can find my patch here: https://github.com/eightycc/tinyusb/tree/issue_8824. You can add it to your PR.
Cool. Will see what happens with Requests, and also fix the other few things it has issues with
@slender iron do you think it's worth posting something on #help-with-circuitpython about the change with Requests (that for onboard WiFi, no changes are needed except for the inclusion of CM, and for others they will need to make code changes) and pin it for ease of use? Or does this happen regularly enough that most people will figure it out?
This please! I don't always have a network I can connect to, so being able to do this would be really handy for working from anywhere away from home.
i tried again tonight. i erased the flash and installed 9.0beta 2. it has not been erasing chunks of code but it has been going into safe mode inconsistently (not a very helpful data point). it's happened 2/5 times on saving and then randomly while running the code. i'll be connected to the serial monitor on web workflow and it stops, doesn't show disconnect and i see the neopixel flashing yellow 3x. might be time for the debug build?
I'm finished up with my ST7796S display project. Now have many displays at my disposal and can start running some CM tests. Where do you suggest I start? Most recent beta?
actually the safe mode issue seems to be separate from web workflow. i power cycled and didn't try to get back into it and it went into safe mode on its own after a while. i'll try to get more info tomorrow
I am not sure I understand. Is there a separate flash chip that is loading the code before it executes it? Do I have access to the CS line to scope that? I thought the memory was inside the ESP32 module?
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; Adafruit Camera with ESP32S3
Code/REPL
import pycamera
pycam = adafruit_pycamera.PyCamera()
pycam.tone(440, 0.1)
Behavior
File "adafruit_pycamera/__init__.py", line 807, in tone
RuntimeError: Internal resource(s) in use
Description
No response
Additional information
No response
talked w @dhalbert who suggested I try ctrl-C and ctrl-D to see if tone causes error using the version linked above, and it does have this problem. 9.0.0 beta.2 does not have this problem.
For precedence, maybe have it try to connect to the outside network first, and if that fails make AP mode the fallback? For my uses, that would be ideal. When I'm at home, it could just connect to my home network, and when I'm out it would go to AP mode, making it so that I don't have to change settings.toml to get the correct behavior wherever I am. (Also, this would give anyone using these devices an easy to way to get in and change settings.toml if they suddenly can no longer use the wi...
Don't want to rush this, but I'm wondering if there's anything I can do as a workaround to get bluetooth working on my esp32-s3 in any capacity. I'm an esp32 and circuitpython noob, so if I'm missing something obvious or if it cannot currently be done with circuitpython please let me know. Ideally, I want to set up my esp32 to act as a BLE peripheral, but can't seem to get that working due to this missing bleio library.
@nrgbistro There is no workaround. Now that ESP-IDF 5.1.2 has added dynamic service support to the nimble base, we are no longer blocked in terms of implementation. But we still have to write quite a bit of code.
Understood, thanks for the quick update.
More discussion along those lines in 8405.
It should be the latter. I think the actual yaml is parsed.
I can help run a patch if needed. This one should be a good fit for adabot to apply if almost all of the libraries currently match.
CircuitPython version
9.0.0-beta.2-10-g54e78c89fc
9.0.0-beta.0
Code/REPL
Any, even Hello World.
Behavior
Web workflow to http://192.168.0.66/fs/ results in file list with message "ℹ️ USB is using the storage. Only allowing reads. Try ejecting the CIRCUITPY drive. See Getting Started with Web Workflow for details." at the top of the list **even though the device is...
So for anything that has onboard WiFi, I would just update the libs and make sure everything still works. So either 8x or 9x. Maybe try circup if you use that
@short tendon I just ran a few quick tests on existing code. Updating requests and adding connection_manager worked fine.
I do expect you will be seeing a lot of questions....
8.x? I thought ConnectionManager was only for 9.x?
I think the real question is whether there is a bug causing the problems with espcamera on the esp32s2 or if esp32s2 simply can’t handle espcamera. If that is the case, do we just document that and move on or is it worth trying to revert to something lime imagecapture. There does not appear to have been a great demand for it so I expect there are more important issues to resolve at this time.
I'm not super interested in getting things going on the S2 if we don't have a project ...
It works for both. Won't be frozen in 8
I have used the espcamera on an esp32-s2 without problems a while back, so I'm confident it's possible: https://hackaday.io/project/182342-camera-shield-for-s2-mini
Have you tried this with espcamera and CP9? I'm just curious if you will have the same issues with memory.
@tulip sleet I saw some more commits to 8x. Are you doing another release? And if so, should we add CM to frozen?
I wouldn't plan to update frozen on 8.x -- bug fixes only. The latest commit fixes a pin error on an existing board.
Sounds good. Just thought I'd check
I figured I'd wait the week with the new requests in the bundle, and then open a PR to update frozen on main. Sound good? Do you have plans for another beta soon?
I update all of frozen before each release. Don't bother with a separate PR. As long as the versions are all in the bundle in a consistent way, it will get updated. Not sure when we will have a beta or even RC, but not too long.
When working through updating MiniMQTT, I noticed that in esp32spi the ESPSPI_WiFiManager takes in secrets.
To remove that, would it be better to:
- Pass in
ssidandpasswordinstead - Remove the param and have it pull from
os.getenv
Is this expected in web workflow (9.0.0-beta.2) if connected to a USB power bank, but not to a host:
ℹ️ USB is using the storage. Only allowing reads. Try ejecting the CIRCUITPY drive.
The check is done in Javascript, with .writable. The drive might be corrupted. See if it's writable when plugged in to USB.
yes, it's writable... the power bank is doing something unexpected?
I'll see if I can try it again later with a board I can put a LiPo on
I loaded 9.0.0-beta.2 on both the SiLabs EFR32MG24 Dev Kit and my custom board, and the RGB LED does indeed flash periodically on both. Which is great, it means my custom board is running CP. I was also able to successfully rebuild 9.0.0-beta.2 as well and verified it works the same on my custom board. Again, all good.
But Thonny won’t connect. Connecting a serial terminal to the VCOM Tx/Rx signals there are text strings transmitted out from CP at boot, but all the characters are scrambled...
that's a little strange, not sure why the power bank would show up as a host
more likely a board issue... I'll start with a clean board next time
if you double-click on a UF2 board like atmel-samd, do you get a fast pulse or slow pulse. Slow indicates the UF2 bootloader thinks it is connected to a host
try an AC adapter instead of the power bank
fast pulse with a Feather M4 on the power bank, but it's the board... same on an AC adapter, I had even wiped the filesystem and reloaded the UF2 (QT Py S3 nopsram)
try a different CPy version. Is this beta.2?
beta.2, yes ...tried it with a Feather S3 TFT, read-only on LiPo, AC adapter, and power bank. I'll try an older CP
(no errors or warnings in the browser console; same read-only in various browsers
8.2.10 is OK....writable when not on host
@VPTechOps I was not able to reproduce this however I did notice that the default behavior of CircuitPython is for WebWorkflow to be read-only.
In order to use WebWorkflow without getting the message you are indicating you must create/edit a boot.py file on the device that contains the following:
import storage
storage.remount("/",False)
That is obviously a problem if you don't have the device connected to a computer.
oh, there's an issue for this already
I am able to reproduce this. QT Py S3 and Feather S3 TFT both get read-only when not connected to host when using 9.0.0-beta.2. But I tried the Feather on 8.2.10, and it behaves as expected: when not connected to host, web workflow file editor files are writable, with no storage.remount necessary.
I have the feeling that earlier versions of CP were not strictly enforcing the "writing from one source only" requirement which may have resulted in some web workflow file corruption issues.
@anecdata Can you confirm the contents of boot.py on the boards you tested?
But if it's not connected to host, web workflow is the one source.
I believe CP can't currently dynamically change the boot mode and you could plug the device in to a computer while CP is running so CP has to assume if the boot mode is not configured with the FALSE option you might write from two sources.
I removed code.py, boot.py, safemode.py, and repl.py. Same behavior: works (writable) on 8.2.10, but not on 9.0.0-beta.2 when not on host.
That is the behavior I expected, that is without the existence of a boot.py containing storage.remount("/",False) neither code running on the device or web workflow would have write access to the flash on the device.
Maybe my expectation is wrong though :grin:
Passing secrets was left in for backward compatibility, it may be time to take that out but you might want to look this over https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/pull/182
I tried with 8.2.10, first using web workflow unconnected to host with files writable. Then I plugged it into a computer without resetting the board and tried to edit and couldn't (timeout). Refreshing the file editor page showed that it recognized the host and was read-only.
I have no boot.py files in any of this testing. I'll also point out that when everything in /fs/ is read-only, the full editor /code/ still allows read-write.
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.2 on 2024-02-20; Adafruit MatrixPortal S3 with ESP32S3 # also on beta.1
Code/REPL
# SPDX-FileCopyrightText: 2023 Liz Clark for Adafruit Industries
#
# SPDX-License-Identifier: MIT
import os
import gc
import ssl
import time
import wifi
import socketpool
import adafruit_requests
import adafruit_display_text.label
import board
import terminalio
import displayio
import framebufferio
import...
@hktklsh Could you give me a small test program or a sample advertisement to try? If you have a piece of an example that is not in CircuitPython, that is fine too.
I use one 52840 to send and another 52840 to receive, and found that some data will be lost.
send:
receive:
S...
I did not realize you were using this for adafruit_ble_radio.
The lost data is not surprising. Advertising is not a reliable way to deliver data. It's like UDP. But it can be used as a best-effort way.
My understanding is that the motivation for high-speed advertising is mainly to speed up reconnections, not to deliver data quickly.
It took a while to track this down, but it appears that the reason for the leak is that CharacteristicBuffer.deinit() is not being called when the CharacteristicBuffer used for one direction of the UARTService is no longer in use. I have a fix for this in the adafruit_ble library.
It's possible we may be able to detect in _bleio when to call deinit(), but I am not at all sure. If we could, we might not need that exposed routine.
I'll discuss this with @tannewt, and maybe mov...
In the file adafruit_ble_radio.py, set AD_DURATION = 0.12 and interval = 0.02, it's possible not to lose data, I think if the interval can be smaller, AD_DURATION can be set smaller too。
Can we please get a board configuration to compile Circuitpython for the Waveshare RP2040-One? Or rather, is there a documentation about how to write one?
Nice! Thanks. There are now so many Circuitpython guides, that it's sometimes hard to find the right one.
Is there an easy way to guarantee a timeout on a socket call? Seeing some strange things and trying to find a way to reproduce
@candid sun sorry for the direct ping. When you tested my Azure PR, what board and CP version were you using?
all good! feather s3 tft with 9.0 beta 2
and did you get timeouts (which should be expected on the loops)?
On 9.0.beta.0 I got valid errors of [Errno 116] ETIMEDOUT which is 116
to 9.0.beta.2 and timeouts errors of -116 which causes MiniMQTT to raise
The negative errno rings a bell about a recent change. Could you file an issue?
I can. Not sure what to put in the steps, because all I have is the Azure test code. I was able to pin it to a merge on the 16th
just give the two error messages, I think that will be enough context. And list the merge
👍
@slender iron When you're available, got two things to discuss with you:
- deinit()-ing Characteristic Buffers to prevent leaks
- Finalizers not running (also present in 1, but maybe not interesting for that).
thanks
CircuitPython version
works: adafruit-circuitpython-unexpectedmaker_feathers3-en_US-20240215-no-branch-8291467.uf2
_note there are a few merges between these two_
doesn't work: adafruit-circuitpython-unexpectedmaker_feathers3-en_US-20240216-main-PR8935-696aa83.uf2
Code/REPL
# Found the issue re-testing my code for this PR: https://github.com/adafruit/Adafruit_CircuitPython_AzureIoT/pull/63
Behavior
Updated adafruit_minimqtt to tring the error...
I’m home again with Ari (after a doctors appointment). I’ll ping you when we can video chat
@slender iron https://github.com/micropython/micropython/issues/1878 py: del special method not implemented for user-defined classes
By default on Windows HID device is seen as CircuitPython HID, see also #5445
This PR adds new method usb_hid.set_interface_name that provides means to change the name of USB HID interface.
Example:
usb_hid.set_interface_name("My HID device")
$ sudo lsusb -vd 239A:80F4 | grep iInterface
iInterface 4 CircuitPython CDC control
iInterface 5 CircuitPython CDC data
iInterface 6 CircuitPython Mass Sto...
I would also like to have this feature.
I actually spent some time and implemented it here #8989
Sorry about missing the readme in ESP32SPI. I assume we need to do that in Adafruit_CircuitPython_PortalBase as well based on https://github.com/adafruit/Adafruit_CircuitPython_PortalBase/pull/100/?
@slender iron and I discussed this briefly this morning. If you can find all such cases, that would be great. Clone Adafruit_CircuitPython_Bundle and then you can grep over all the libraries to find those with adafruit requests in their README. Then check which don't also have ConnectionManager.
there might be some in the community bundle; I don't know
grepping through the bundle repo is a great way to check what's going on in all the libraries
I can do that. I'll also check MiniMQTT, since that PR is open too
Thank you for this! It's been asked for several times.
I've added some comments, especially about storage management.
Instead of reserving 128 bytes of RAM all the time for this, use the technique used in supervisor.set_usb_identification(), https://github.com/adafruit/circuitpython/blob/54e78c89fc9e0d2b31544dfd03c30a159e8540a4/shared-bindings/supervisor/__init__.c#L297-L298. It allocates space for the user-set string(s) only if they are specified. It uses port_malloc(), which allocates outside the Python heap (so no gc issues). port_malloc() is new in 9.0.0.
//| `interface_name` must be an ASCII string (or buffer) of at most 126.
Do not call this _obj; that nomenclature is reserved for Python objects.
Will need to grep a few things... For example Adafruit_CircuitPython_OAuth2 depends on requests, but it isn't listed in the README
that's a README bug too 🙂
you can just open an issue if you don't want to make a bunch of PR's
looks like 13 libraries. I'm happy to work through them all