Oops! Thanks for fixing it up. I was just firing up my ubuntu VM again to run the pre-commit script. I guess my Notepad++ settings disagree with the linter.
#circuitpython-dev
1 messages · Page 74 of 1
Question: is there a mechanism allowing one to compile-in a code.py and libraries, kind of like Micropython's manifest files? (https://docs.micropython.org/en/latest/reference/manifest.html ) I know that CircuitPython's "/frozen" libraries are the equivalent, but I have two questions on that:
- Is there a way to add a frozen code.py?
- Can single-use frozen libraries / code.py live in the board directory instead of polluting "/frozen", with an appropriate define in "mpconfigboard.mk"?
yes, here are some boards with their own frozen code:
ports/nordic/boards/challenger_840/mpconfigboard.mk:11:FROZEN_MPY_DIRS += $(TOP)/ports/nordic/boards/challenger_840
ports/raspberrypi/boards/solderparty_rp2350_stamp_xl/mpconfigboard.mk:14:FROZEN_MPY_DIRS += $(TOP)/ports/raspberrypi/boards/solderparty_rp2040_stamp
ports/raspberrypi/boards/solderparty_rp2350_stamp/mpconfigboard.mk:14:FROZEN_MPY_DIRS += $(TOP)/ports/raspberrypi/boards/solderparty_rp2040_stamp
ports/raspberrypi/boards/solderparty_rp2040_stamp/mpconfigboard.mk:14:FROZEN_MPY_DIRS += $(TOP)/ports/raspberrypi/boards/solderparty_rp2040_stamp
You could change the default code.py print("Hello World") to instead import some frozen module
.
Thanks!
The sensor may be cooked. I had a 2640 do the same to me recently.
Try switching to another camera.
The Arduino version of the library has reached version 1.1.0 3 months ago, are the required changes implemented yet? Or is there an issue to keep track on the progress?
It works fine on older builds, so it's not the sensor. This is mysterious. I am still narrowing down the problem. It's not the autofocus loading -- I removed that from both and it still works.
CircuitPython version
Adafruit CircuitPython 9.1.4 on 2024-09-17; M5Stack Dial with ESP32S3
Code/REPL
import time
import board
import displayio
import vectorio
display = board.DISPLAY
def show_and_count_loops_per_second(num_reads: int) -> None:
time_ms = time.monotonic_ns() // 1e6
next_lps_time = time_ms + 1000
lps_counter = 0
while num_reads > 0:
lps_counter += 1
time_ms = time.monotonic_ns() // 1e6
...
Description
Add support for 2 boards: MAX32690EVKIT and AD-APARD32690-SL.
Status
At the moment, this port only includes digitalio in addition to the supervisor and USB workflow required to get CircuitPython functioning. Pinouts listed are currently just...
Hey @slender iron , I'm getting the PR in but seeing some CI fails because it looks like my local pre-commit installation wasn't catching format issues for some reason. I'll try to get the CI steps passing today.
Nice! I'm around to help if you need extra eyes
Is there something I should add the name of my port to to get this CI scheduler run to pass?
I suspected this was the palette being marked dirty and then never cleared. BUT it looks like it should be cleared. There may be a bug further upstream that is preventing the palette dirty bit from being cleared.
Thanks! This is only ~30 commits or so. I don't expect to have any issues with it.
Thanks for the new port! I'm excited to try it. I've added a few comments. Nothing major.
You should be able to remove this now that digitalio is implemented. CircuitPython has "status led" code that will blink on startup and every 5 seconds when code.py isn't running.
This would be more universal:
clean-all:
This needs updating.
make BOARD=apard32690
These names should match the silkscreen. You can have additional aliases for "standard" pin naming such as an arduino A#/D# numbering too.
I ran into some build issues at some point when these weren't defined. I will remove them and test.
Hi! I'm struggling to get a custom C module to show up in circuitpython. It was working ok in CP7.x, but now that I'm updating everything to CP9, it's not showing/registering, and I'm hoping someone can help me out. The module is _lightshow, and it's here: https://github.com/buildwithpiper/circuitpython/tree/piperCP9.0.0/shared-bindings/_lightshow.
I used MP_REGISTER_MODULE and cleaned the build, but it's not showing when I call help("modules")
Are you seeing the files in shared-bindings/_lightshow being compiled? I suspect not. I think you also need to add _lightshow to /py/circuitpy_defns.mk
okay, I'll give that a try, thank you!
And it doesn't look like there' s a way to have a board-specific code.py that gets frozen in, beyond doing Makefile hacking like:
DUMMY_VAR=$(shell sed 's/\print(\\"Hello World!\\")/import myfrozenlib/' filesystem.c > filesystem.c.new && mv filesystem.c.new filesystem.c)
okay. I'm stuck again. I think I'm getting closer, but I'm getting this error now that it's picking up the files and trying to build them:
In file included from ../../shared-module/_lightshow/__init__.c:48:
../../shared-module/_lightshow/__init__.c: In function 'lightshow_tick':
../../py/mpstate.h:337:40: error: 'mp_state_vm_t' {aka 'struct _mp_state_vm_t'} has no member named 'lightshow_singleton'
337 | #define MP_STATE_VM(x) (mp_state_ctx.vm.x)
| ^
../../shared-module/_lightshow/__init__.c:112:34: note: in expansion of macro 'MP_STATE_VM'
112 | lightshow_obj_t *lightshow = MP_STATE_VM(lightshow_singleton);
| ^~~~~~~~~~~
I'm not sure where I should be defining lightshow_singleton beyond what I've already done - so I don't know why I'm getting this error.
there is a struct that this macro expands out to maybe mp_state_vm?
Like this?
lightshow_obj_t *lightshow = MP_STATE_VM(lightshow_singleton);
if (!lightshow) {
lightshow = m_new_obj(lightshow_obj_t);
lightshow->base.type = &lightshow_type;
lightshow = gc_make_long_lived(lightshow);
MP_STATE_VM(lightshow_singleton) = lightshow;
}
Source: https://github.com/buildwithpiper/circuitpython/blob/piperCP9.0.0/shared-bindings/_lightshow/LIGHTSHOW.c
For background, this is for a 8x8RGB matrix that is driven using shift registers and closely modeled after the _pew module. Admittedly, I'm a little out of my depth being this deep into it, but it's a requirement for our base firmware.
lemme find it
Looks like the new way to get it into there is with MP_REGISTER_ROOT_POINTER. Search for an example of that
okay, I added MP_REGISTER_ROOT_POINTER(mp_obj_t lightshow_singleton); to the end of shared-bindings/_lightshow/LIGHTSHOW.c, but that didn't seem to have any effect - should I be somewhere else?
😦 Same error unfortunately - I ran make clean at the top directory, then make -C mpy-cross and make clean BOARD=... in the port directory.
Looks like enabling this caused me to hit a snag with my RTC somehow due to the call to interrupt_after_ticks. I will let you know here when it's fixed and pushed.
I think that's right
In my situation this doesn't seem to be an issue. I just can't seem to get it to register the singleton into MP_STATE_VM
At least I think that's what the issue is currently.
sorry, I was responding to someone else!
oh, sorry!
There is a pre-compilation step that looks for all the `MP_REGISTER_ROOT_POINTER() definitions. If that source file is not getting scanned, then it won't go into the MP_STATE_VM
i don't remember where the list of files is specified, but the _lightshow directory needs to be listed somewhere to get that to work.
I don't think it's a special list, but if you haven't added it to the right .mk file yet, then it won't be preprocessed to find the registration
Okay - that's helpful - maybe the file needs to be listed explicitly in /py/circuitpy_defns.mk?
I think I added init.c there, but not LIGHTSHOW.c
make it be set up like all the other shared-bindings stuff
right, it needs to be compiled. Look at some other things that use MP_REGISTER_ROOT_POINTER, like, say, keypad
Okay, I really appreciate the lead. I'll start trying to plug it in.
in general don't use ALLCAPS for a filename, btw
@slender iron https://forums.adafruit.com/viewtopic.php?t=213823 user installed PSRAM on RP2350 board and I2C started to fail. is PSRAM orientation correct? Do they need a new build?
physical orientation looks correct, going by the Eagle board file and PSRAM datasheet
@tulip sleet replied. not sure why it'd impact i2c
me neither. Is there built-in support or does blakebr have to make a new build?
it should detect it automatically
These match the silkscreen but not the standard feather pin naming D12 and D13 are left so code is compatible.
Brought up on the forums:
https://forums.adafruit.com/viewtopic.php?p=1030324
Would Bluetooth support on Pico W be likely to reduce the available RAM again?
@tulip sleet I recently soldered a psram to my feather 2350 and it worked. Fwiw
Gpio8 (psram cs) is not shared with anything so it should be fine
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0-16-gec5cca6983 on 2024-09-27; TinyS3 with ESP32S3
Code/REPL
# SPDX-FileCopyrightText: 2020 ladyada for Adafruit Industries
# SPDX-License-Identifier: MIT
"""
This example acts as a keyboard to peer devices.
"""
# import board
import sys
import time
from adafruit_hid.keyboard import Keyboard
from adafruit_hid.keyboard_layout_us import KeyboardLayoutUS
import adafruit_ble
from adafru...
With firmware CYW43 bluetooth firmware blobs, BTstack, and a skeleton implementation of _bleio in place flash grows from 85.7% to 88.14% and RAM from 40.14% to 44.35%. This includes both BLE and Wifi support.
From a post above in this now rather long thread.
@eightycc: is it possible that you publish the current state of your work somewhere so others might step in and continue on this project?
Does not fail in 9.2.0-alpha.2351, so the change is recent.
Is there a way I can download a 9.2.0-alpha build?
Try https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/unexpectedmaker_tinys3/en_US/, and pick the release with PR9597. #9597 fixed some things that prevent BLE HID from working. I was just seeing if it was the same error.
Cool looks like it is working there! Thank you so much for your help @dhalbert. Looking forward to the 9.2 release
I'm reopening this because the latest builds, past #9597, cause the error you found. So there was a regression we need to fix.
RAM from 40.14% to 44.35%
That's 11K, which could put it back into breaking projects that were broken by the 9.0 update and fixed again by disabling DVI and USB host recently.
I think I found a potential race condition + null pointer dereference in usb.core.Device.
I've been looking at shared-module/usb/core/Device.c with an eye towards improving error handling for quirky USB devices (PR in progress). Along the way, I found this code in _open_endpoint(...):
if (self->configuration_descriptor == NULL) {
mp_raise_usb_...
- Fixes #9535
- Fixes #9561
Update to use new ESP-IDF I2C driver. @tannewt did most of this work in https://github.com/tannewt/circuitpython/commit/8a4ad54fe71b78011050f962f8a5eb7f37ffc6b5 (https://github.com/tannewt/circuitpython/tree/idf5.2_i2c). I started with that, fixed a few things, and fixed some issues with the esp32-camera library, which recently had a PR to use the new driver.
I retested the problems reported in #9535 and #9561 amd they seem to be fixed.
A few builds overflowed. I turned off some unused pins. I also did CIRCUITPY_CODEOP = 0 on one or two boards. That could be done on more if necessary later.
locally, git thinks this a (probably unintended) rewind of the tinyusb submodule
Submodule lib/tinyusb 5217cee5de..4349e99fb2 (rewind):
< Merge pull request #2801 from hathach/release-0.17.0
< Merge pull request #2799 from hathach/add-pico2
< Merge pull request #2794 from hathach/fix-circleci
< Merge pull request #2450 from HiFiPhile/vendor_fifo
< Merge pull request #2788 from dp111/cppcheck
< Merge pull request #2789 from hathach/enhance-disconect-connect-esp32
.enable_internal_pullup = CIRCUITPY_I2C_ALLOW_INTERNAL_PULL_UP ?
something here is redundant. maybe the two pin assignments here should be removed altogether?
did the equivalent of this code get added elsewhere? is it needed?
try_lock could be used from displayio. I think it was recently changed to relying on this returning failure if the bus was deinited. so, I don't think this can be removed.
thanks for working on this!
@tannewt I had no idea what was going on here, and just left it alone.
Yes, in the old version, using the old driver, it was:
#if CIRCUITPY_I2C_ALLOW_INTERNAL_PULL_UP
.sda_pullup_en = GPIO_PULLUP_ENABLE, /*!< Internal GPIO pull mode for I2C sda signal*/
.scl_pullup_en = GPIO_PULLUP_ENABLE, /*!< Internal GPIO pull mode for I2C scl signal*/
#else
.sda_pullup_en = GPIO_PULLUP_DISABLE, /*!< Internal GPIO pull mode for I2C sda signal*/
.scl_pullup_en = GPIO_PULLUP_DISABLE, /*!< Internal GPIO pull mode for ...
Good catch, should be 10, because the arg is ms now.
It's because the fields in camera_config are ints. NO_PIN is defined as -1, and the camera driver checks for the pin being >= 0. However, common_hal_mcu_pin_number() returns a uint8_t, so the -1 turns into 255, and that makes it still >= 0. I will put in a explicating comment.
I noticed that there were GPIO errors being printed in the debug log -- that's why I fixed this.
oops, yes, git is bad at merging submodule updates
Fixed all of these, and also added
// Ensure the object starts in its deinit state.
common_hal_busio_i2c_mark_deinit(self);
at the top of each constructor. Strictly speaking, this is only necessary for NO_PIN deinit markers, which are -1, not 0, but for safety and consistency I did them all.
I'm not sure why this disappeared. The others were fine. Thanks for noticing this.
This PR includes a fix for the null pointer dereference from issue #9670 and adds short error message strings to help distinguish between different types of usb.core.USBError exceptions.
I understand that adding unique strings to the core is generally problematic, but I don't know how to avoid it in this case. For writing USB device drivers, it's very helpful to be able to identify the specific causes of the different types of exceptions that get grouped together under USBError. If there w...
[adafruit/circuitpython] Pull request opened: #9673 support setups with all modules in src-directory
In larger libraries with multiple modules it makes more sense to put all modules into a src-directory and don't scatter them in the top-level directory. Python setuptools explicitly supports this setup as a default (in this case, pyproject.toml does not have to specify the modules explicitly, but this is only a side note and not relevant here).
This PR changes tools/preprocess_frozen_modules.py to support this setup. The change is backward compatible.
Failure was with one board: timeout during upload of artifact. I don't think this has anything to do with my change.
are you contributing patches elsewhere for this? e.g., I don't think a circuitpython library organized this way will work with circuitpython-build-tools, so it wouldn't be possible to organize a library like this and place it in the community bundle.
(I don't think there's a written rule for this but my gut tells me that to submodule something into frozen modules in the core we would want it to be in a bundle as well)
Thanks. I think this addresses all the issues I raised. I would like @tannewt 's review still on the broadcom stuff, as it looks to me like protection against resetting the HDMI outputs might have been lost.
are you contributing patches elsewhere for this?
Not yet, but this is planned. Before I can contribute the library, I need to make sure it can be added as frozen.
e.g., I don't think a circuitpython library organized this way will work with circuitpython-build-tools, so it wouldn't be possible to organize a library like this and place it in the community bundle.
A patch for the community-bundle/circup would certainly be next step if necessary.
(I don't think there's a writt...
I added a fix for the failing pre-commit check (translation file needed changes). I'm not convinced that my approach here of adding error strings and updating the translation file is the right way to solve the problem of distinguishing types of USB errors. If there were a way to set USBError.errno, I would prefer to do that. But, I don't know if or how that would be possible.
@samblenny Did you just do make translate at the top level? That updates circuitpython.pot programmatically. You should not need to edit circuitpython.pot by hand.
I'm new to this. When I looked around for possible ways of invoking the translation pre-commit hook (skipped normally), the best looking documentation option I found was to run pre-commit run --all-files as mentioned in https://learn.adafruit.com/improve-your-code-with-pylint/check-your-code-with-pre-commit. So, that's what I did.
I tried running make translate just now, and it didn't appear to make any additional changes.
I tried running
make translatejust now, and it didn't appear to make any additional changes.
Probably what you did was equivalent. But when pre-commit complains, just run make translate and commit those changes. We should put that in a message somewhere (though I thought that was somwhere already).
CircuitPython version
Adafruit CircuitPython 9.1.4 on 2024-09-17; Adafruit Matrix Portal M4 with samd51j19
Code/REPL
from adafruit_matrixportal.matrix import Matrix
# default pinout:
# R1 - G1
# B1 - GND
# R2 - G2
# B2 - B
# A - D
# C - E
# CLK - LAT
# /OE - E
matrix = Matrix(width=64, height=32)
# alternate pinout:
# R1 - G1
# B1 - GND
# R2 - G2
# B2 - E
# A - B
# C - D
# CLK - LAT
# /OE - GND
addr_pins = [board.MTX_ADDRA, board.MTX...
I worked a while on trying to get this to work with mp_obj_t/Q_STR variables but wasn't making much progress so I thought I could get some help if I posted this as a proof of concept :grin:
I was concerned that if someone set the hostname using wifi.radio.hostname that this default code would replace it when the interface was reset.
I'm haven't figured out if there is a way to reset the network interface in code yet, but I did some quick testing and it seems that wifi.radio.hostname survives a ctrl-d reset without being set back to this new default value. I haven't seen the host name set by wifi.radio.hostname show up on my router yet, but I'm thinking there's some sort of dh...
I'm not sure what level of reset or reinit would clear the hostname, or if CircuitPython has such a path invokable by the user.
I do see the wifi.radio.hostname = blahblah to show up in the router right away once there's a new wifi connection...
Please note that when the hostname is altered after interface started/connected the changes would only be reflected once the interface restarts/reconnects
<https://docs.espressif.com/projects/esp-idf/en/v5.3.1/esp32/api-reference/network/...
Neither wifi.radio.enabled = False nor wifi.radio.stop_station() clear the custom hostname.
<details>
<summary>In 9.1.4, supervisor.reload() will clear the custom hostname back to CONFIG_LWIP_LOCAL_HOSTNAME...</summary>
Adafruit CircuitPython 9.1.4 on 2024-09-17; Adafruit QT Py ESP32-S3 4MB Flash 2MB PSRAM with ESP32S3
>>> import microcontroller ; microcontroller.on_next_reset(microcontroller.RunMode.NORMAL) ; microcontroller.reset()
[11:25:41.279] Disconnected
[11:...
two entries/comments, the first I tried everything but strace:
-
journalctl -b | grep mount returns:
Sep 30 08:29:41 nebula udisksd[1751]: mountpoint /media/rps/CIRCUITPY is invalid, cannot recover the canonical path
Sep 30 08:29:41 nebula udisksd[1751]: Cleaning up mount point /media/rps/CIRCUITPY (device 8:1 is not mounted) -
pmount -w -s /dev/sda1 CIRCUITPY
no errrors but mounted read only -
fstab
I was unsupervised and put my laptop into a state where IT had to fix my...
strace pmount -w -s /dev/sda1 CIRCUITPY
execve("/usr/bin/pmount", ["pmount", "-w", "-s", "/dev/sda1", "CIRCUITPY"], 0x7fff91b69410 /* 30 vars /) = 0
access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory)
brk(NULL) = 0x562c720ef000
arch_prctl(0x3001 / ARCH_??? */, 0x7fffee359e70) = -1 EINVAL (Invalid argument)
fcntl(0, F_GETFD) = 0
fcntl(1, F_GETFD) = 0
fcntl(2, F_GETFD) ...
Ok, the pmount problem is evident from the end of the trace: pmount must be able to run as root (at least part-time), so it needs the suid bit set. Normally, the installation should take care of that.
But let's look at the very first error:
- journalctl -b | grep mount returns:
Sep 30 08:29:41 nebula udisksd[1751]: mountpoint /media/rps/CIRCUITPY is invalid, cannot recover the canonical path
Do you know which command triggered this log-entry? AFAIK, mounts below `/media/...
<@&356864093652516868> Our community meeting will be in 10 minutes in the CircuitPython voice channel. Talk with you soon!
my first guess is on power cycle of my laptop root is following some script that sends a command to the udisksd daemon
my second guess is the startup script has a timing issue, trying to mount the raspberru before the raspberry pi board has connected via the usb (this might be the real problem)
my new problem is something I ran on my laptop now connects to the raspberry pi twice (or thinks it does), I have two different CIRCUITPY drives on /media/rps/ CIRCUITPY and /media/rps/ CIRCUITP...
not sure how we'd silence cats anyway 😼
Thanks for hosting Scott. Have a great week everyone.
thanks Scott. Short & sweet
Latest updates:
- Simplified the processing code, hopefully making it easier for others to follow
- Tested again 16-bit signed and 8-bit unsigned sources. So far Synth, RawSample and WaveFile. MP3 still is not working.
- Added in dynamic range compression like in Synth for 16 bit echos.
- Added a lot of comments to the code
Things are close now. I still want to see if I can tell why MP3s are not working (they should be don't think it is a processing limit).
I do have to clean up the d...
Does anyone have experience or insight with Github rate limiting? Digging into this adabot tests issue I'm finding that the X-RateLimit-Remaining header is inexplicably not containing a value, which gets defaulted to 0 and leads to logic in adabot looking for the X-RateLimit-Reset header, but that one also has no value. The code is currently written to assume that it will have a value in this scenario so when it's missing a KeyError is raised.
Strangely the request imediately preceeding the one that fails does contain the X-RateLimit-Remaining header and it still has a large value 4952 remaining out of 5000 limit. But for some reason on the following request the headers exist in the response but don't seem to have a value. Link to actions output: https://github.com/adafruit/adabot/actions/runs/11112781607/job/30875604335#step:7:47
The request where they have no value gets a 200 status code and it's content looks like what is expected for the response, just the headers seem to be "messed up" in this way where the keys exist without values.
clarification, the 2nd CIRCUITPY was a co-worker with a 2nd board connected to my laptop (my laptop has so many usb cables going in, I missed this) I unplugged that board's power and am back to just not being able to ssh and mount.
The docs here https://docs.github.com/en/rest/using-the-rest-api/troubleshooting-the-rest-api?apiVersion=2022-11-28#rate-limit-errors make mention of the retry-after header, which similarly has a key in the headers dict but no value. I don't see any information about what it means if the header exist but without a value.
If you just connect one device, and then restart that device a few times, do you see the same or a similar issue? I am interested in knowing if we need to test with two "paws" or not.
@lone axle I looked at the output of the actions and am scratching my head over it
@lone axle it looks like this line is only hit once you're already having an exception .. I can't find any evidence that the quiet= parameter ever existed to logger.error()... I would remove quiet=
E TypeError: _log() got an unexpected keyword argument 'quiet'
@lone axle tests/unit/test_common_funcs.py patches some get function or method, see mock_github_get inside test_is_new_or_updated.
If it's this get that's being used, the expected headers won't be there. You could try adding them (result.headers['key'] = 'value') and see if it fixes CI
scratching my head how this ever worked though
but I don't see this mock being used in the other tests so it still doesn't feel like a full explanation
(for anybody not familiar with the terminology, in this case a mock is a replacement for a function or method that makes it do something different during testing)
- remaining = int(response.headers.get("X-RateLimit-Remaining", 0))
+ remaining = int(response.headers.get("X-RateLimit-Remaining", 99))
```(in github_requests.py) you could also try defaulting the number of requests remaining to 99 and cross your fingers. then it wouldn't enter the part where it tries to get the time until rate limit reset
(I lurk for tidbits just like this 🙂)
I ended up making a test branch to work on and I have removed the quiet argument in that branch https://github.com/adafruit/adabot/tree/testing_fixes. It is a mystery to me why it was there or how it ever worked in the past as well. I also could not find any documentation that made reference to quiet. I will try giving it a larger default. If nothing else I'm curious if subsequent requests start having numerical values for those headers again after the one where they are seemingly blank.
I did a bisect and 03b077dd912d9fd7faf9fb167fb7d8f48af300ab is the first "bad" commit.
I think you should preserve this. These I2C peripherals are used by the GPU I think. Setting them in use prevents us from trying to use them too.
Images automagically compressed by Calibre's image-actions ✨
Compression reduced images by 31.3%, saving 228.97 KB.
| Filename | Before | After | Improvement |
|---|---|---|---|
| assets/images/boards/large/esp32-wrover-dev-cam.jpg | 87.41 KB | 52.80 KB | -39.6% |
| assets/images/boards/large/pimoroni_tinyfx.jpg | 139.43 KB | 98.60 KB | -29.3% |
| assets/images/boards/large/vidi_x.jpg... |
Thanks. I think this addresses all the issues I raised. I would like @tannewt 's review still on the broadcom stuff, as it looks to me like protection against resetting the HDMI outputs might have been lost.
@tannewt I restored the broadcom reset_i2c() and its call, but could you check that this is the way you want it to be? Thanks.
This is very weird! I'd expect audio stuff to run in between VM byte codes. I'd appreciate it if you could dig into why it isn't working.
Took a look, seemed between two channels of 44.1Khz audio and constantly checking a rotary encoder I hit the processing limit as close as I can tell. Or the rotary encoder blocked long enough (and I was checking it often enough) to slow the audio down. So at this point seems to be a non-issue.
Things are close now. I still want to see if I can tell why MP3s are not working (they should be don't think it is a processing limit).
MP3Decoder as a source works now. Was a bug I just hadn't ran into. Also samples of unusual lengths work now (wasn't update the remaining sample buffer correctly, and most samples use values that just happened to work).
A little bit more info about the adabot / github rate limit issue discussed above: I actually mis-read a detail the headers print out yesterday. It's not the case that the headers contain keys without values as I stated before. What's actually the case is there is a Access-Control-Expose-Headers header which contains a long string of comma seperated strings which are a list of other Headers that are presumably meant to be present in the response. I was seeing X-RateLimit-Remaining and X-RateLimit-Reset in that list without a colon and a value and mis-interpreting it.
So those X-RateLimit headers seem to be not present in the response, but are listed in the. They don't have keys or values, which does make sense as the exception that bubbles up is a KeyError.
Another small difference I just noticed in the headers: For the pen-ultimate request (that succeeds and contains all expected headers) one of the headers present is this: 'X-Accepted-OAuth-Scopes': '', But in the following request which succeeds but seems to be missing those headers the value is different: 'X-Accepted-OAuth-Scopes': 'repo' I'm not sure if it's really related or not though. Perhaps it's just due to the different resources being requested.
Maybe this is a wider spread issue with github. Just found this discussion: https://github.com/orgs/community/discussions/140079 which appears to be about the same symtoms.
I am thinking one option to resolve it is to keep local variables storing the value of the relevant headers. Then if we find they are missing from the response just refer back to the ones we stored from the previous request and "manually" decrement the remaining value to account for the requests we send that don't contain the response header. Based on the discussion and which request it's failing for us on, it seems like requests to /releases endpoints are the ones with this issue currently.
You could open a ticket with GitHub about this. We do pay them.
base don the discussions link, it sounds like a change
I'd be happy to do that, but I'm not sure where or how to do so. Although helpfully it does appear they've documented it here: https://docs.github.com/en/support/contacting-github-support/creating-a-support-ticket
Would it be worth trying to create a small reproducer before opening the ticket? It's buried rather deep within the Adabot code.
If the problem can be gleaned from logs, that's often enough for them. But if you can show the problem with a URL you put in the browser or via curl or whatever, that would be better
Okay, I was able to distill it down to this reproducer:
import os
import requests
no_token_resp = requests.get("https://api.github.com/repos/adafruit/Adafruit_NeoPixel/releases/latest")
print(no_token_resp.headers['X-RateLimit-Remaining'])
auth_headers = {'Authorization': 'token ' + os.getenv('GITHUB_TOKEN')}
with_token_resp = requests.get("https://api.github.com/repos/adafruit/Adafruit_NeoPixel/releases/latest", headers=auth_headers)
print(with_token_resp.headers['X-RateLimit-Remaining'])
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/1-hJPXRQZXHs7SzZVYPoi8s2IM_5xo_gtMdRPCf_IZC0/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for October 7th, 2024 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...
@lone axle are you working on fixing adabot's bundle update?
How do you specify what state machine for the PIO's on the 2040?
yes, I think https://github.com/adafruit/adabot/pull/378 will fix the issue we saw last week with the community bundle. However there seems to be something strange going on with some responses from the Github API now that are causing the tests to fail. It's unclear at the moment if it's a bug or intentional change from Github (albeit undocumented if so).
I have in mind a way to change the logic in Adabot to hopefully be able to work around the issue of the missing headers in the responses. I've have not attempted it yet, but do intend to.
Oh, actually I hadn't noticed the build job failed today too
Ok, I'll let you keep fixing it. Let me know if you need me to help
it's failed the last few days apparently
KeyError: 'x-ratelimit-reset' this is the same root cause of the test failing though
So hopefully if/when the logic in there is changed it will resolve it for anywhere that this specific issue may pop-up.
You don't. It determines it automatically
are you changing it or should I?
Either way is fine with me. I am eating lunch and need to take care of a few other things afterward before I can work on it. If you are able and want to take a shot sooner you can.
kk, will do shortly
I think we can close this one. I see no room for improvement for the Pico-W (and Pico). Also, with the upcoming 2nd generation of these boards there are now (or soon) more powerful alternatives available.
@lone axle in case it might be relevant to your rate limit thing... I noticed that when I created a PR against adafruit/circuitpython a couple days ago, and when I pushed an additional commit to that branch, GitHub kicked off 500+ workflow actions that ran for about 45 minutes each time. Perhaps that has nothing to do with the problem you are discussing.
... but, it does seem like the kind of thing that might put stress on rate limit quotas.
I think the error might be that it no longer includes that header
Thank you, it's something to look into. But my initial instinct is that they're unrelated. AFAIK the core repo actions don't make requests the Github API for anything, though they do a lot of other building and testing work. I don't think that adabot is actually hitting the rate limit because there are still 4900+ left in the last request that does show a value.
I believe it's specific to /releases endpoints. Those are not returning any of the X-RateLimit headers. My idea to resolve was keep local variables with the values when we do receive them and then if they're missing just keep track with local variables. Then update them as needed for requests that we do recieve values on.
If there are tasks that need to request only /releases endpoints that won't work though because we won't ever receive the values. The tests which I have looked most closely into so far have a mix of lots of non /releases and a few that are /releases so I think that approach can work for them.
Thinking about the build process though I'm now questioning whether that really does ask for anything other than /releases endpoints.
FWIW, poking around in circuitpython/.github/{actions,workflows}, I see several instances of uses: actions/upload-artifact@v4, which might be hitting the github API? Perhaps multiple times per port * board build?
I might be totally wrong about that though. This just caught my eye because one of the checks for a commit I pushed yesterday failed in a way that looked kinda mysterious. Like, maybe it had to do with some kind of rate limit or availability thing. IIRC, the check log said something about an error when attempting to upload a build to S3, so maybe it's unrelated.
the S3 thing happens every so often. usually a retry fixes it
Ahh, I just realized, when I tested with the reproducer code posted above I used my own private API token and saw the same behavior with the missing headers. Mine is definitely not used by anything with the core repo actions so I think the RateLimit header thing isn't tied to the core workflows.
hey @lone axle , you got the adabot problem, with API rate limit headers missing. I've caught up on above (skimmed though), and I know the circuitpython library checking code works a bit differently...
Did anyone submit a support issue yet, I'm about to otherwise?
I'm just running it today for ardu libs, have patched github_requests.py to ignore if no rate info and continue on.
I play in this branch: https://github.com/tyeth/adabot/tree/arduino-ci-ver-bump
or this commit:
https://github.com/adafruit/adabot/commit/64e1b06d6090147c61c6d52ad29ea000d61be227
Also left a trail here: https://github.com/orgs/community/discussions/24760#discussioncomment-10812653
I'm changing the code to assume we have requests left if the header is missing
maybe they removed the limit on that endpoint
I did create a support ticket for it https://support.github.com/ticket/personal/0/3029134 (I'm not sure if it lets other org members see it?)
(I can't see it)
sorry sound on mute, I got distracted 🙂
You might be right about opting that endpoint out of the limit. It doesn't appear to be counting a usage for that endpoint any more with a quick test locally. I'm getting response data and upon checking remaining count with another request elsewhere it isn't subtracting one for the /releases request.
interesting
I wanted to make it clearer that the parameters are buffers not flags, as loop is used for instance in https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/audio_dma.c
I didn't really think this was ready, it does work but the following code segment isn't optimized for Micropython/Circuitpython in terms of variable/memory use:
char cpy_default_hostname[80];
uint8_t mac[6];
esp_wifi_get_mac(ESP_IF_WIFI_STA, mac);
sprintf(cpy_default_hostname, "cpy_%s_%x", CIRCUITPY_BOARD_ID, (unsigned int)mac);
const char *default_lwip_local_hostname = cpy_default_hostname;
ESP_ERROR_CHECK(esp_netif_set_hostname(self->netif, default_lwi...
Not-ready code should be in a draft PR then. I think that's fine because esp_netif_set_hostname will copy the string input.
Sorry, I should have drafted it.... I'll see if there's anything I can do to optimize it and if so, submit another PR.
merged!
i am behind on email
CircuitPython version
Adafruit CircuitPython 9.1.4 on 2024-09-17; Raspberry Pi Pico with rp2040
Code/REPL
a = b'A' * 32
print(a.count(b'A'))
print(a.count(65)) #A is ascii character 65
Behavior
The count function works with the byte string but not the integer. See:
32
Traceback (most recent call last):
File "code.py", line 3, in
TypeError: can't convert 'int' object to str implicitly```
### Description
In contrast, with cPython 3....
This behavior also exists in MicroPython, from which we take a lot of this kind of core functionality.
- Fixes #9669
Characteristic was using self->current_value == NULL to indicate that the Characteristic was deinit-ed. However,
the current_value storage in a Characteristic can be the NULL pointer if the Characteristic is initialized with an initial value of None.
Change to using self->handle = BLEIO_HANDLE_INVALID as the deinit flag (similar to what nordic does), and handle an empty initial value more carefully. For instance, don't try to allocate a zero-length chun...
This PR updates the cpy_default_hostname variable length to exactly what's needed rather than 80 characters.
If there's any value in using an mp_obj_ type variable rather than a char array to store cpy_default_hostname let me know and I can try to get that to work in another PR.
The sunton_esp32_8048S050 was added after the PR which removed all the CONFIG_LWIP_LOCAL_HOSTNAME statements from sdkconfig was based. I added an update for that board to this PR as well.
Delay, Mix and Decay are all BlockInputs now. I'll resolve this change and if an issue is with the BlockInputs is found a new change can be raised.
more information, I did an strace udisksctl mount and although there's too much information to copy and paste
but the relevant information is that /dev/sda1 is mounted RD_ONLY, i.e. mounted readonly by default,
and googling seems to find others with similar issues but no solution.
$ strace udisksctl mount -b /dev/sda1 -t vfat
I am going to investigate the udisk command
I think an unpower/repower the rp2040 board also plays a part, but there are so many permutations to try
logging in causes something to change
I have to be (by not logging in first) missing a parameter to udisksd or to systemd
Here's logging in first, then running journalctl
$ journalctl -b | grep CIRCUITPY
Oct 02 09:27:09 nebula udisksd[1734]: mountpoint /media/rps/CIRCUITPY is invalid, cannot recover the canonical path
Oct 02 09:27:09 nebula udisksd[1734]: Cleaning up mount point /media/rps/CIRCUITPY (device 8:1 is not mounted)
Oct 02 09:28:08 nebula systemd[1]: Finished Clean the ...
Please post your Ask an Engineer questions beforehand in #1280611628081221785 channel.
solved
after udisksctl mount I need to cycle power on the rp2040 and then it will change from read only to read/write
thank you all for your pointers/hints, the strace is a new tool in my toolbox
Glad you got it working. I'm still not sure why it's an issue on your particular setup but not on most others. But maybe this issue will help others in the future.
dhalbert, I hope so too, again thank you for giving me the forum to work through issues publicly
[adafruit/circuitpython] New comment on issue #9173: Hard fault: memory access or instruction error.
Could any of you be more precise about the "two days" interval? Is it literally 48 hours, or somewhat less? I am interested in whether it is a power-of-two number of milliseconds or something like that. 2**27 milliseconds is 1.55 days, for instance.
sigh, adafruit playground seems to have eaten a bunch of my work this morning 😕
I'd written a whole code-explaining section on https://adafruit-playground.com/u/jepler/pages/e-ink-countdown-in-circuitpython-with-custom-stand and .. poof!
I wonder if it's related to having had multiple tabs open on the editor; I thought this was correctly managed but maybe that's only on learn.
bummer! have you talked to internal folks about it?
no, I haven't. I decided that it was a good moment to take a break.
@heady bolt I can help you here since you are compiling circuitpython yourself
you can do a DEBUG=1 build of circuitpython and esp builds will log to UART all of IDF logging
you mean make BOARD=x DEBUG=1?
correct
i wish i could figure out how to get into bootloader mode on the esp32 s3 consistently. i have a boot and reset button . ive tried pressing boot, pressing boot and reset at the same time, double clicking reset, unplugging holding boot and plugging in. none seem to work
ive gotten it in boot loader mode plenty of times, it just doesnt work consistently it seems. its a custom PCB
holding boot while pressing reset should get you into the rom bootloader
just tried that, still nothing
probably worth checking the board design then
holding boot while pressing reset does get me access to the drive
but not into where i can copy a new uf2 file
usually it creates a volume called BOOTESP32 or something to that effect
what pin is your boot button connected to? the rom bootloader shouldn't show as usb drive at all
Hi, moving this question over from #help-with-circuitpython :
I’m attempting to build circuitpython from source because I have some minor modifications I want to test out. However, it takes around half an hour to even get to the point where the compiler complains about my silly syntax errors on my fairly old laptop. Is there a simple way to tell the build system to reduce the amount of code it attempts to compile? I’m already building only for the specific board I want to use for testing, and I’m building from the raspberrypi port directory.
I’ve been able to compile an unmodified version of the repo by the way. But that took just as long, or probably longer.
It should be fast after the first run. What command are you running to build it?
what CPU is in your laptop?
does your laptop have a spinning hard drive or a solid state drive?
I've set up a task in vscode to build via wsl, like so:
{
"version": "2.0.0",
"tasks": [
{
"label": "Build",
"type": "shell",
"command": "c:\\Windows\\System32\\wsl.exe --cd \\\"/mnt/c/path/to/circuitpython/ports/raspberrypi/\\\" make -j12 BOARD=seeeduino_xiao_rp2040 V=1",
// "command": "make -j12",
"group": {
"kind": "build",
"isDefault": true
},
"presentation": {
"reveal": "silent"
},
"problemMatcher": "$gcc",
"options": {
"env": {
"TARGET": "${workspaceFolderBasename}"
}
}
}
]
}
I'm on a gen 8 i5, so I don't expect it to be fast, but this was a bit slower than I was hoping for.
I have an SSD (but it isn't new either), and both it and the CPU are at 100% resource utilization for a long time while building.
WSL has slow disk access particularly older WSL
a gen 8 i5 should be fine. I do builds all the time on a gen 8 i7, and they take much less time than that (like 1/30)
I reinstalled and set up a completely new WSL2 image specifically for this, so the version shouldn't be a problem. But the disk access speed could of course still be an issue.
how much RAM is allocated for WSL?
Hmm, that's a good question. I'll try to figure it out
I can't remember if you can specify how many cores and how much RAM
cat /proc/meminfo
It has access to all cores at least. The CPU is at 100% for a very long time
also cat /proc/cpuinfo
cat /proc/meminfo
MemTotal: 3948580 kB
MemFree: 2794812 kB
MemAvailable: 3213336 kB
Buffers: 44036 kB
Cached: 528624 kB
SwapCached: 0 kB
Active: 496388 kB
Inactive: 260628 kB
Active(anon): 2328 kB
Inactive(anon): 185152 kB
Active(file): 494060 kB
Inactive(file): 75476 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 1048576 kB
SwapFree: 1048576 kB
Dirty: 7380 kB
Writeback: 0 kB
AnonPages: 182540 kB
Mapped: 137996 kB
Shmem: 3124 kB
KReclaimable: 102084 kB
Slab: 156684 kB
SReclaimable: 102084 kB
SUnreclaim: 54600 kB
KernelStack: 4004 kB
PageTables: 5012 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 3022864 kB
Committed_AS: 759812 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 25712 kB
VmallocChunk: 0 kB
Percpu: 3744 kB
AnonHugePages: 71680 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 117760 kB
DirectMap2M: 4009984 kB
DirectMap1G: 8388608 kB
on my 8th gen i7, to compile raspberry_pi_pico:
real 0m28.957s
user 1m51.553s
sys 0m39.243s
so meminfo says 4GB
lscpu | awk -F ":" '/Core/ { c=$2; }; /Socket/ { print c*$2 }' will tell you how many cores
I haven't tried WSL for a while, but it was more like 3-4x slower, not 30x slower
and it was due to slower disk access
Any idea as to why this program only works for pin 5. The other pins 6 and 9 do not generate a square wave. I want to use mltiple state machines.
import time
import rp2pio
import board
import adafruit_pioasm
squarewave = """
.program squarewave
set pins 1 ; Drive pin high and then delay for one cycle
set pins 0 ; Drive pin low
"""
assembled = adafruit_pioasm.assemble(squarewave)
sm1 = rp2pio.StateMachine(
assembled,
frequency=1000 * 1 * 4000,
first_set_pin=board.D5,
)
sm2 = rp2pio.StateMachine(
assembled,
frequency=1000 * 1 * 24000,
first_set_pin=board.D6,
)
sm3 = rp2pio.StateMachine(
assembled,
frequency=1000 * 1 * 1000,
first_set_pin=board.D9,
)
print(dir(sm1))
print("real frequency", sm1.frequency)
print(assembled)
time.sleep(100000)
Does it work if you use the same frequency on all three? This is better to ask in #help-with-circuitpython first.
Even when set at the same frequency it fails on the pins 6 and 9.
you don't get an error but it doesn't work? what board are you using? (moving to #help-with-circuitpython )
Sorry my setup was wrong. It works as expected.
@slender iron im still getting sporadic resets on the board and i have deployed the debug version of the custom cirtcuitpython build. I will run the code a few times and then eventually it stops responding and i get this "Unable to connect to COM18: could not open port 'COM18': PermissionError(13, 'Access is denied.', None, 5)"
the only way to get it back is to reset the board, but this hasnt really happened before. just strange
@heady bolt you'll want to monitor the debug uart output to see what is happening
where/how would i do that?
do you have a USB/serial adapter?
I think this is the same as #9626. There were some changes in the BLE workflow logic. I'm closing this in favor of #9626.
im connected to the pcb by usb
I finally got around to testing out your audio_effects fork and playing around with audiodelays.Echo. I was hoping to recreate some form of chorus effect with this module, but I don't think that's possible with the current implementation. The decay parameter directly affects the level of the first repeat of the delay. Generally, I would assume that decay/feedback would only apply to additional repeats of the audio signal and the level of the initial copy would be controlled independently us...
I've created a pull request on your fork for your consideration, @gamblor21. https://github.com/gamblor21/circuitpython/pull/1
I've created a pull request on your fork for your consideration, @gamblor21. gamblor21#1
I will take a look but probably not until tomorrow. What you were saying makes sense.
One thing I do plan to do is create more effects then just this echo. This really is a proof-of-concept still. I was looking a chorus briefly last night, and want to consider others (reverb) as well.
If you are playing with it another thing you can try is ch...
Though the delay_ms parameter has been set up as a BlockInput object, it is not recalculating echo_buffer_len and subsequent read/write positions within audiodelays_echo_get_buffer. As a result, using a BlockInput parameter for delay_ms has no discernible affect beyond the initial value.
lfo1 = synthio.LFO(scale=250, offset=500, rate=0.5)
synth.blocks.append(lfo1)
echo1 = audiodelays.Echo(delay_ms=lfo1, decay=0.5, mix=1.0, buffer_size=4096, channel_count=CHANNELS, samp...
Though the
delay_msparameter has been set up as aBlockInputobject, it is not recalculatingecho_buffer_lenand subsequent read/write positions withinaudiodelays_echo_get_buffer. As a result, using aBlockInputparameter fordelay_mshas no discernible affect beyond the initial value.
Oh good catch! Thanks, I'll have a fix for that soon I know what is wrong.
@slender iron ah I think this feather (esp32s3 with 4MB flash + 2 MB PSRAM) doesn't have bleio enabled so I wouldn't be hitting the BLE / deep sleep bug with my project.
ah! that'd explain it
Are there humans who understand the template language of circuitpython.org? I noticed the list of built in modules is showing wrong, with extra spaces and a trailing comma
this fixes it but .. what ???
diff --git a/_includes/download/board.html b/_includes/download/board.html
index a497f0d18..7a5ed7b74 100644
--- a/_includes/download/board.html
+++ b/_includes/download/board.html
@@ -146,7 +146,7 @@
{% if version.modules %}
<p>
Built-in modules available:
- <span class="download-modules {% if version.stable %}stable{% else %}unstable{% endif %}">{{ version.modules | join: ', ' }}</span>
+ <span class="download-modules {% if version.stable %}stable{% else %}unstable{% endif %}">{{ version.modules | join: " " | split: " " | join: ', ' }}</span>
</p>
{% endif %}
{% if version.frozen_libraries and version.frozen_libraries.size != 0 %}
scratch that .. the diff does nothing. my local version builds right without change while the current version is different
it's also back from 9.0.4 days and the ruby bundler hasn't been updated, so maybe it's version churn or something
yes it was a bug introduced somewhere along the line...
is it jinja?
it's liquid
i found the bug but I haven't figured out how to fix it yet. there are two problems, one is that the "don't add comma after last item" logic is wrong; the other is that the template language is inserting a whitespace that shouldn't be there.
Hello, may I take this one? thanks!
@tannewt is @eightycc active on discord?
@ItsTerm1n4l Your interest in this feature is understandable, but pinging someone on Discord is not going to make it happen any faster.
@jepler I know, I wanted to know if he was active because if he is, then I might have a look on the discord server to see if there are any updates there and if I could help in any way
@tulip sleet can you point me to how i can monitor the uart output to capture why this board keeps disconnecting?
are you using circuitpython? what board?
haha, I asked you yesterday 🙂
it is custom
do a debug build and then monitor the TXD pin
for uart0
@slender iron I think it makes sense to take effects out of draft now. I'm not sure how many extra effects I can get done now but those can be other PRs easily enough and gives a guideline to others. Does that make sense?
I think it's safe to say that eightycc isn't available and that pinging them isn't helpful. If they were online, then they would have replied here by now. This happens from time to time as volunteers get busy.
I'm happy to guide anyone who wants to take on this work (though I'll soon be out as well for paternity leave.) Otherwise, there are plenty of other nRF52840 and ESP* boards that can already be used for BLE from CircuitPython.
Sure! I was just reading the comments on that PR now
I'll do a review too
Hello, may I take this one? thanks!
Sure! We're here to guide you on Discord: https://adafru.it/discord in the #circuitpython-dev channel.
CircuitPython version
Adafruit CircuitPython 9.1.4 on 2024-09-17; Adafruit Metro RP2040 with rp2040
Board ID:adafruit_metro_rp2040
UID:DF6260785F3B3E2B
Code/REPL
# SPDX-FileCopyrightText: 2022 Jeff Epler, written for Adafruit Industries
#
# SPDX-License-Identifier: MIT
import array
import board
import supervisor
from rp2pio import StateMachine
from adafruit_pioasm import Program
# Pixel stream is very similar to NeoPixel WS2812B, but inverted....
Doing a single non-looping background write first may be a workaround for the problem:
sm.background_write(data)
time.sleep(.01)
sm.background_write(loop=data)
@ladyada for the TM1814 program you can also try with this workaround
def _transmit(self, buf):
self._buf = buf
## WORKAROUND FOR https://github.com/adafruit/circuitpython/issues/9678
self._sm.background_write(memoryview(buf).cast("L"), swap=True)
time.sleep(.01)
## END WORKAROUND
self._sm.background_write(loop=memoryview(buf).cast("L"), swap=True)
I have a fix - will be doing a PR soon.
- Fixes #9626.
ble_serial_connected() was checking _tx_packet_buffer.conn_handle as an indicator of whether BLE was connected. But that value was not initialized when BLE hadn't started up at all, and so ble_serial_connected() was returning true incorrectly in that case. The check should have also included a check for deinited. I added that and refactored it into a common-hal routine.
While debugging, I found that on RP2040 the first looped background write on a StateMachine would be garbled: It the first few outputs would be as expected, but then the data would go back to the start of the buffer.
I realized that this could be due to there already being a pending interrupt on this DMA channel that had occurred previously but never been acknowledged. In fact, by printing the value of dma_hw->intr before this, I could see that it was the case.
After this change, both...
CircuitPython version
CircuitPython 9.2.0-beta.0 on 2024-09-17; Raspberry Pi Pico 2 with rp2350a
CircuitPython 9.2.0-beta.0-15-gca25c602a8 on 2024-09-27; Raspberry Pi Pico 2 with rp2350a
CircuitPython 9.2.0-beta.0-16-gec5cca6983 on 2024-09-27; Raspberry Pi Pico 2 with rp2350a
Code/REPL
import rotaryio
import board
encoder = rotaryio.IncrementalEncoder(board.GP15, board.GP14)
last_position = None
while True:
position = encoder.position
if l...
This was already reported & fixed upstream, but the fix will not be in a released SDK until 2.0.1. It's easy enough to use our own workaround.
Testing: without this bug fix, rotaryencoder did not work on a pico 2
Note: the cut&paste code was reindented by uncrustify, giving it a slightly different style than the upstream sdk code.
Closes: #9681
I thought I had PRd this two weeks ago, but apparently I didn't. The problem was independently rediscovered by @d3fq, thanks for the report.
If you can test with a build artifact from #9682 (should be ready in an hour or less), it'd be appreciated! I had also encountered the bug & fixed it, but apparently neglected to make a PR. Thanks for the report!
@Sola85 @dy0x Would you be able to test an artifact from here? https://github.com/adafruit/circuitpython/actions/runs/11169629161?pr=9679
@Sola85 @dy0x Would you be able to test an artifact from here? https://github.com/adafruit/circuitpython/actions/runs/11169629161?pr=9679
This seems to have fixed the issue on my boards.
For instance, if you wanted to create a strong "slapback" style delay, this is what I would expect to work in that scenario (I'm excluding
buffer_size,channel_count, andsample_rateas they aren't relevant):The expected outcome would be a full volume repeat of the audio after 500ms and then no additional feedback/decay of that audio. Instead, there is no effect on the audio output because the
decayparameter silences out all delayed audio including the first repeat.
Firs...
https://forums.adafruit.com/viewtopic.php?t=213955 by blakebr notes that os.uname().sysname and .nodename say rp2040 even for rp2350boards. Fix this by usingMICROPY_HW_MCU_NAMEinstead. Note that it would berp2350aandrp2350b`.
Note that on some ports, the name is more generic, such as samd21 and samd51 for atmel-samd. But espressif and broadcom use MICROPY_HW_MCU_NAME. In the long run, maybe that is better, since it's more informative, instead of using a generi...
This seems to have fixed the issue on my boards.
Great, thank you for testing.
Here's my initial PR for this issue #9660, thanks!
@dhalbert Thanks for working on this!
Unfortunately I can only try out the fix next week. But given the problem description, I'm pretty confident that @dy0x and me experienced the same issue, so if it's fixed for him it's probably fixed for me.
If not, I'll let you know next week.
I will admit that the example I provided was an extreme use-case and not a good representation of the problem at hand. I still think this is an issue that should be addressed regardless of our interpretation of "echo" vs "delay". I will do my best to demonstrate the issue here.
echo = audiodelays.Echo(delay_ms=250, decay=x, mix=y)
| Desired Outcome | T=0ms | T=250ms | T=500ms | Current decay (x) | Current mix (y) | Proposed decay (x) | Proposed mix (y) |
| --- | --- | --- | -...
CircuitPython lacks support for object.__set_name__, a dunder method added in 3.6 which allows descriptors to know the name they were assigned to in their owning class. This makes descriptor implementations have needless redundancy:
class FooDescriptor:
def __init__(self, name):
self.name = name
# def __set_name__(self, owner, name):
# self.name = name
class Foo:
thing = FooDes...
The X-RateLimit headers have re-appeared in the responses from /releases endpoints from Github API.
and they are subtracting API requests from limit now. I guess it was unintentional that they were opted out of that for a few days.
There is work going on upstream in MicroPython to add __set_name__. When this is merged into MicroPython, we'll merge it into CircuitPython in one of our periodic merges from upstream.
https://github.com/micropython/micropython/issues/15501
https://github.com/micropython/micropython/pull/15503
Looks like pico-sdk 2.0.1 might be next week, if I am interpreting this correctly: https://github.com/raspberrypi/pico-sdk/issues/1877#issuecomment-2390511245
I tested with an RP2350 and also an RP2040 (to check for any regression). Both work with the test program. Thanks!
If you can test with a build artifact from #9682 (should be ready in an hour or less), it'd be appreciated! I had also encountered the bug & fixed it, but apparently neglected to make a PR. Thanks for the report!
Yes, I've just tested 9.2.0-beta.0-23-g11d4bce481 and can confirm it's work fine on RP2350.
@jepler @dhalbert Many thanks!
Thanks for working on this! Just a few API comments.
Would 1.0 require a buffer of infinite size? How should you handle a case where the buffer is too small? Maybe mention how max_delay_ms impacts the internal echo buffer.
I'd be clearer here that it only dictates the playback buffer, not the temporary storage of the echo.
//| self, sample: circuitpython_typing.AudioSample, *, loop: bool = False
For ease of use and consistency across ports, use MICROPY_HW_MCU_NAME for os.uname().sysname and .nodename. See https://github.com/adafruit/circuitpython/pull/9683 for background on this. This will not be an upward-compatible change.
@onyx hinge @slender iron for the remaining 9.2.0 bugs, could I assign some to you two? e.g picodvi and usb host bugs to Scott, MP3 bug to jeff, etc. I can take the BLE and Matrixportal bug.
yes but I might punt them
I would understand that, if they are not blockers
@danielmader There are actually two problems going on here:
- You are specifying a matrix of height 32, but you're specifying 5 address lines. That is one too many. See the documentation here about how many address lines are used: https://docs.circuitpython.org/en/latest/shared-bindings/rgbmatrix/index.html#rgbmatrix.RGBMatrix
- A ValueError is thrown to tell you about that problem. However, when the VM restarts, there is a hard memory error, and, it goes into safe mode. The memory error ...
A decay of 1.0 will cause an infinite repeat of the audio signal. It shouldn't have any effect on buffer size. I think it's better to allow for this value rather than prevent it. There are some situation where infinite repeat is desired (imagine a momentary "infinite" button). Some analog delay effects actually allow for a feedback/decay value greater than 1.0 to cause self-oscillation. That's something we want to avoid here, but just a bit of context.
You're welcome, and thanks again for the report.
tannewt, I know you're pressed for time at the moment and probably don't have much bandwidth to discuss this. If you have any concerns about the error messages, I'd be happy to add a commit putting them back like they were before (leaving the just the changes to fix the null pointer dereferences).
@todbot A question came up about the mix parameter and how it should work. If we speed things up at value 0 and pass the sample straight through, with an effect like echo the sample will not be placed into the echo buffer so if mix is then increased the echo is lost. Is this what you intended?
Versus if mix is 0 you pass the sample straight through but still inject into into the echo buffer, but never hear that play, unless mix is increased?
Any thoughts? I also realize this functiona...
Can anyone point me to what may be wrong for this error when I am building the docs.
audiodelays/__init__.pyi:17: error: Name "BlockInput" is not defined [name-defined]
For an area like:
//| self,
//| max_delay_ms: int = 500,
//| delay_ms: BlockInput = 250.0,
...```
The stubs build locally for me, I know other modules (synthio) use BlockInput as a type. I cannot see what I need to include so it builds.
there should be an import for it at the top of the file, inside a try block?
This is in the core though, that's what I cannot figure out.
Ah think I have it. wifi uses ipaddress and just has ipaddress.IPv4Address prefacing it with the module it is defined in.
Really liking this one.
Doesn't seem to suffer from the C3 wifi issues.
@tannewt which board(s) should I enable this for? Right now I only have it for the Pico2. I could for an 2350 board. I haven't tried it against any others yet.
In displayio screens, when moving an object we should use or try to use the display's scroll functionality whenever possible.
An example of a good situation to do this in is when scrolling happens on the terminalio terminal (the text goes off the screen on the vertical axis)
@dhalbert Thank you for giving this issue attention!
I understand issue 1. However, I am still clueless how I can specify the different pinouts from the male plug of the MatrixPortal M4 board to the female socket of the WaveShare RGB matrix. I thought, the only way to do so is to pass the full list of address lines in the order of the pins.
CircuitPython version
documentation
Code/REPL
none
Behavior
The description of the displayio.Display class is missing from the 9.1.x branch ReadtheDocs pages, but is present in earlier versions: e.g. https://docs.circuitpython.org/en/8.2.x/shared-bindings/displayio/index.html
Perhaps it was lost during the reorganization of displayio for version 9.
Description
No response
Additional information
No response
displayio.Display, .EPaperDisplay, .FourWire, and .I2CDisplay are deprecated in 9.x.x and will be removed in 10.0.0. That is why they were removed from the documentation. Perhaps displayio should contain cross-references to the new top-level modules: epaperdisplay, fourwire, i2cdisplaybus, and paralleldisplaybus, and busdisplay.
I thought, the only way to do so is to pass the full list of address lines in the order of the pins.
You should only list as many address pins as are needed -- in this case, four pins. The alt address pins are just substituted for the ones that would be chosen by the library. With an Adafruit matrix the pins used would be [board.MTX_ADDRA, board.MTX_ADDRB, board.MTX_ADDRC, board.MTX_ADDRD]. That is the default chosen by adafruit_matrixportal based on the given parameters.
The scree...
Adafruit CircuitPython 9.1.4 on 2024-09-17; Adafruit QT Py ESP32-S3 4MB Flash 2MB PSRAM with ESP32S3
I tried the "lowering tx_power" trick and could not connect at all.
If I hard-reset, I will usually get a connection on the first try. Interestingly, the "Unknown failure -2" alternates sometimes with "No network with that ssid".
I'm wondering if (in my case) since the connection isn't used for a long period of time, the socket appears to go "stale" (the connection is dropped a...
Thanks again, and yes, you were fully right about me posting a wrong pinout. I've taken it for this post only from an older version of the wiki without checking, please excuse.
Unfortunately, your suggestion still yields a broken display, at least when I use the higher-level class adafruit_matrixportal.matrix.Matrix instead of your suggested
rgbmatrix.RGBMatrix:
from adafruit_matrixportal.matrix import Matrix
[...]
addr_pins = [
board.MTX_ADDRA,
board.MTX_ADDRD,
...
Thanks Dan -and on a weekend too...
I think cross-references are essential -there is a tremendous amount of documentation that references the depreciated way of doing things. Knowing now to look for the busdisplay docs helps to put the pieces together. Much of this complexity is hidden on boards with integral displays, but when adding displays to other boards, it's essential.
Old syntax:
display_bus = displayio.FourWire(spi, command=tft_dc, chip_select=tft_cs, reset=tft_rst)
displa...
Maybe the discussion should be continued there: https://forums.adafruit.com/viewtopic.php?t=213775
I"ll follow up there for the pin order.
@EAGrahamJr Could you try the "Absolute Newest" builds past beta.0, which have some further fixes: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/adafruit_qtpy_esp32s3_4mbflash_2mbpsram/
CircuitPython version
Adafruit CircuitPython 9.1.4 on 2024-09-17; Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM with ESP32S3
Code/REPL
# full context: https://github.com/skjdghsdjgsdj/babypod-software/blob/main/power_control.py#L65
alarm.exit_and_deep_sleep_until_alarms(pin_alarm, time_alarm, preserve_dios = [i2c_power])
Behavior
The board resets into safe mode and requires a reset. The console output shows:
Enabled interrupt for center b...
Could you retest with the absolute latest build, which is past 9.2.0-beta.0?
https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/adafruit_feather_esp32s3_4mbflash_2mbpsram/
@EAGrahamJr Could you try the "Absolute Newest" builds past beta.0, which have some further fixes: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/adafruit_qtpy_esp32s3_4mbflash_2mbpsram/
I was just going to reply that the newest seems absolutely rock solid for 60 minutes (that's 4 HTTP requests spread out over 1 hour)...
Interesting....
Over 2 hours, so I buttoned up the PLA enclosure I had printed with an enclosed SH1106 display and the error resurfaced not long after. On a hunch, I popped open it back open, and the WiFi properly reconnected and everything went back to working. So, that's a little bit of a bummer.
Same problem and same output with the latest snapshot:
dafruit CircuitPython 9.2.0-beta.0-25-g7f14b9c49a on 2024-10-04; Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM with ESP32S3
I believe this is related to: https://github.com/adafruit/circuitpython/issues/7447
I have a global exception handler in my code.py. This commit makes deep sleep perform as expected when connected to USB: https://github.com/skjdghsdjgsdj/babypod-software/commit/061031acb539283232860684e88eaaf88ca12ee4
Output is now:
Enabled interrupt for center button
Cleared encoder read queue
Waiting a few seconds for deep sleep
Creating time alarm
Preserved I2C_POWER
Created pin alarm
...
As mentioned in #7447, internally, requesting deep sleep raises DeepSleepRequest, which is a subclass of BaseException. It should not crash, but as you found, catching Exception instead is a work-around.
Confirmed it's specifically something to do with printing a DeepSleep exception.
some random old FW on a board I grabbed:
Adafruit CircuitPython 9.1.0-beta.3-50-g9b85fe5766-dirty on 2024-07-09; Adafruit MagTag with ESP32S2
>>> import alarm
>>> try:
... alarm.exit_and_deep_sleep_until_alarms()
... except BaseException as e:
... ee = e
...
...
...
>>> id(ee)
1065359200
>>> type(ee)
<class 'DeepSleepRequest'>
>>> print(ee)
[08:31:34.335] Disconnect...
Before, this would crash trying to print a NULL object. mp_raise_type is the correct way to raise an exception without an associated object or message.
>>> import alarm
>>> try:
... alarm.exit_and_deep_sleep_until_alarms()
... except BaseException as e:
... ee = e
...
>>> ee
DeepSleepRequest()
I also looked at including the deep sleep arguments in the args, but it was confusing because it would seem to print the TimeAlarm rather than the DeepSleepRequest:
...
@tulip sleet I don't know why the doc build is failing in that PR. Whether it is more readthedocs churn? There are multiple things in the log that say "warning". But I think this one is new:
WARNING: Calling get_html_theme_path is deprecated. If you are calling it to define html_theme_path, you are safe to remove that code.
Heh, I was just coming to mention that looks like it's going to be an issue across all the libraries. https://github.com/adafruit/Adafruit_CircuitPython_Display_Text/actions/runs/11217110767/job/31177912073#step:2:1002
yeah https://pypi.org/project/sphinx-rtd-theme/ was updated a major version just a few hours ago
There is something that just changed in rtd, I think. I am afk but will find the email from rtd about it
I think they sent us a warning but it was not clear it was applicable
I will look into it and see if I can find the fix unless one of you is already on it?
I just forwarded you an email
that seems to be something else, not 100% sure though
here's the announcement on their blog, covers the same info: https://about.readthedocs.com/blog/2024/07/addons-by-default/
Removing that line does appear to work in a library as well. I'll prepare a patch that adabot can run to get it fixed in the libraries.
CircuitPython version
Adafruit CircuitPython 8.1.0-beta.1-48-g98a1083d6-dirty on 2023-08-22; ESP32-S3-DevKitC-1-N32R8 with ESP32S3
Code/REPL
import time
LOOP=200
acc = 0
for i in range(LOOP):
t = time.monotonic_ns()
time.sleep(0.01)
t2 = time.monotonic_ns()
diff_us = (t2-t) // 1000
acc += diff_us
avg = acc / LOOP
print(f'expected 10000 us, got {avg} us')
Behavior
The result shows:
expected 10000 us, got 9799.07 us...
Started a "how long will this run" test this morning. Reference code is at https://github.com/EAGrahamJr/ispy-deskie (basically it's asyncio and checks for wifi.radio.connected every 5 seconds, then goes into a re-connect loop if necessary).
<@&356864093652516868> The weekly CircuitPython meeting is in less than two hours: 2pm US ET / 11am US PT. Ttyl! Add your notes: https://docs.google.com/document/d/1-hJPXRQZXHs7SzZVYPoi8s2IM_5xo_gtMdRPCf_IZC0/edit?usp=sharing
You should try that on CircuitPython 9.1 or better.
There have been many updates to the ESP32 internals since 8.1.
Ohai, could someone please help me understanding why this fails? https://github.com/adafruit/Adafruit_CircuitPython_GPS/pull/113
Besides having the number 13 in it, I can't figure it out 😅
I believe you've run into an issue that is being worked on #circuitpython-dev message
Ah, I see ... I guess I should have scrolled up in the channel, lolz
So there is nothing I have to do about it? It's getting fixed ?
You may be able to simply remove this line "html_theme_path = [sphinx_rtd_theme.get_html_theme_path(), "."]" from docs/conf.py as I think that's what foamyguy is planning on doing across all the libraries but I'm sure it will be solved pretty soon anyway.
Got it, thank you!
There is a patch PR in to adabot now with the fix for it: https://github.com/adafruit/adabot/pull/381
For the moment it's fine that PRs are failing th actions due to that change in sphinx-rtd-theme. It should get resolved once this patch is run.
Sorry for not getting back to you! Yes, I'd prefer to back out the error changes. The new messages aren't very actionable for users. It's fine for debugging but I wouldn't leave them. The cost of leaving them is translation and firmware size.
... I'd prefer to back out the error changes...
ok. sounds good. will try to get you a new commit soon.
I filed #1170 long ago to do this. I think the tricky bit is tracking the static portions that will need to be moved during a scroll.
@tannewt which board(s) should I enable this for? Right now I only have it for the Pico2. I could for an 2350 board. I haven't tried it against any others yet.
At least all RP2350. Then folks can enable it for other chips after they test it.
Just pushed a commit to remove the error message changes. Now the remaining changes are limited exclusively to avoiding null pointer dereferences.
and in fact news of its release just came out on the Python discord
Similar in 9.1.4. A sliver of the loss (<8us) is from the time it takes to call time.monotonic_ns(). There also seems to be a tinier sliver lost to the float division. Without any division::
expected = 2_000_000_000
actual = 1_961_395_269 (avg 9806.98 us)
Re @todbot, if you followed the linked forum discussion you'll see that bug was reproduced on 9.1.1 as well
and thanks to Foamyguy for taking on that same readthedocs problem across the libraries!
Thank you! I can run the patch this afternoon.
Thanks for hosting Dan, have a great week everyone.
yw, and thanks everyone for attending!
@slender iron did you ever run into this? in a pico-sdk project I am generating video on core1. Something in there is doing a modulo, which calls into __aeabi_uidivmod through veneer, which I think means it goes into the slow flash .... ? anyway, I am getting video tearing because of that, I think.
what's weird is it was working until I made some changes in my CMakefile
I have CP setup to crash if the flash is accessed. That'll tell you exactly where it is happening
this is why I want the compiler to be smarter
the veneer would be used if your main code is in ram
well I guess my question is, do you know how to move __aeabi_udivmod into RAM?
the code is just doing a % modulo operation but I guess that is a function call
I don't know if pico-sdk has a flag for it. you can check the map file to see where it is placed
it might be in ROM instead of flash
maybe this is an accidental cache-line-boundary change?
Right, thanks I see that now. Also, thanks @anecdata. In my experience trying to do tight-timing on CircuitPython this isn't very surprising. CircuitPython has no concept of atomic or critical sections so who knows what happens during those three function calls: USB handling and garbage collection come to mind as tasks that eat up several milliseconds.
Perhaps a similar test that was disconnected from USB, does a gc.disable() before starting, and then logs the final results to a file ...
What I think is odd here is that the time is less that the requested time. I'd expect overhead to make it longer. So I'm suspecting a ticks-vs-msec issue: a tick is 1/1024 of a second vs the msec 1/1000 of a second.
@todbot A question came up about the
mixparameter and how it should work. If we speed things up at value 0 and pass the sample straight through, with an effect like echo the sample will not be placed into the echo buffer so if mix is then increased the echo is lost. Is this what you intended?Versus if mix is 0 you pass the sample straight through but still inject into into the echo buffer, but never hear that play, unless mix is increased?
Any thoughts? I also realize this...
Oh yes, under the requested value. You are correct. I need more coffee.
@slender iron ```#include "src/rp2040/hardware_structs/include/hardware/structs/mpu.h"
#include "src/rp2_common/cmsis/stub/CMSIS/Device/RP2040/Include/RP2040.h"
OK got it 🙂
Some of the libraries have a different chunk in their docs/conf.py file that configures the theme: https://github.com/adafruit/Adafruit_CircuitPython_AMG88xx/blob/main/docs/conf.py#L152-L162 it will need a separate patch to target those ones due to the surrounding code being different enough to not apply.
Test run of the patch finished with 343 successful, 9 skipped for that different conf.py file, and 8 failed seemingly they're missing the docs conf file.
I'm going to start the real run in a moment and I'll check into the remaining failures, I think some may be newer minimal repo's without their cookiecutter files yet and no releases / not in bundle.
A handful of the ones that successfully commited then had this very generic actions failure.
I'm going to try re-running to see if maybe it was just a transient issue caused by having committed to so many repo's in a relatively short time window.
Look at the other framebuf impl for rp2350
maybe I omitted it there
This patch should cover the 9 with the alternative config files. https://github.com/adafruit/adabot/pull/382 though I think the tests take a while to complete so it won't be green for a bit.
Thanks for the pointer to ../contributing. I As a retired engineer who spent far too much time in unfocused meetings at big companies, your focused & efficient meeting is a breath of fresh air. (even though the baby-project statu should have been first item. 😄 ❤️
(I hope to get around to contributing in a couple months)
Glad you appreciated it! This is the place to get help when diving in.
I would say it's generally stable. After about 3 hours or so, started getting more of these:
26532.219: INFO - Connecting to WiFi
26535.633: ERROR - Error connecting wifi - Unknown failure 2
26535.641: WARNING - Attempting to re-connect
26537.641: INFO - Connecting to WiFi
26540.055: ERROR - Error connecting wifi - No network with that ssid
26540.055: WARNING - Attempting to re-connect
26540.297: WARNING - Weather waiting on connection
26542.055: INFO - Connecting to WiFi
2...
@tannewt which board(s) should I enable this for? Right now I only have it for the Pico2. I could for an 2350 board. I haven't tried it against any others yet.
At least all RP2350. Then folks can enable it for other chips after they test it.
I've tested this board on the original Raspberry Pi Pico (RP2040) with an I2S DAC (PCM5102). It can run through the examples at stereo 44.1k without any issue.
But when I tried adding audiodelays.Echo to a bigger audio project of mine, ...
This library seems to have some issue with the github release action. https://github.com/adafruit/Adafruit_CircuitPython_CST8XX Both of it's releases failed that action. The error for the recent release is:
Error: Error: unexpected status code: 403
{"message":"Resource not accessible by integration","request_id":"9940:38FE6F:12BA518:145FF8A:6704567A","documentation_url":"https://docs.github.com/rest"}
It seems like maybe there is something different in the permissions or setup of the token that gets used inside of actions perhaps?
This library has the same issue where the gh releases have all failed. https://github.com/adafruit/Adafruit_CircuitPython_PCA9554
The rest of the first group of 343 have all been released after the patched docs config.
@lone axle the VEML7700 library has some kind of sphinx issue on a PR,... is it the same thing?
Yes, I think if you merge main to your PR branch and then push, it should make it pass the actions.
OK, I'll see if I can figure out how to do that, this was an in-place patch edit on github.com (I thought it would be easy. Narrator: It's never easy.)
That worked.
Almost all of my boards (including S3, Pico-W) need more than a single attempt to connect to my AP. wifi.radio.connect() does have a timeout-parameter, but I don't think this is implemented in the way you expect it to work (if implemented at all). So I also use a retry loop for connecting.
Otherwise my S3 board is very stable. Running for days, connecting every 15 minutes to an URL fetching data.
If possible, you should check the logs of your AP to see if the AP actively stops the con...
When playing around with custom LUT waveforms on an epaperdisplay, I needed two_byte_sequence_length=True, in order to be able to send more than 128 bytes of start_sequence data. However, I noticed that the delays between commands were read incorrectly in this case.
When two_byte_sequence_length=True, the adress of the delay (if present) is shifted back by 1 byte as compared to when two_byte_sequence_length=False, but prior to this PR the delay was always read from the same adress....
Thanks -- I think I understand why the existing code is wrong, but maybe you want to have it as delay_length_ms = *(data + data_size) so that it always refers to the next byte after the end of data. I think that's clearer overall, and might even result in smaller generated code.
@dkulinski you added support for two byte sequence lengths back in #5874 -- if you have a chance you might want to make sure this change is compatible with your displays & their control sequences.
I can't comment directly on this line of code because it's not touched by the change .. anyway, the position within the init sequence is advanced by i += 2 + data_size; and then an additional byte in the case of 2-byte lengths. This doesn't seem to take into account the presence of a delay value at all. I'm probably overlooking something, but just in case it jiggles someone's brain I wanted to mention it.
We can do *(data+datasize), but then I think we have to move the increment of data_size to after reading delay_length_ms. I can try this out this evening and update the PR.
I can't comment directly on this line of code because it's not touched by the change .. anyway, the position within the init sequence is advanced by
i += 2 + data_size;and then an additional byte in the case of 2-byte lengths. This doesn't seem to take into account the presence of a delay value at all. I'm probably overlooking something, but just in case it jiggles someone's brain I wanted to mention it.
data_size in incremented half-way through the loop to include the delay byte co...
Thanks, I missed that.
If you'd prefer not to tinker further with the code and call it good, I'm OK with that as well.
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0 on 2024-09-17; Raspberry Pi Pico 2 with rp2350a
Code/REPL
import rotaryio
import time
import board
enc = rotaryio.IncrementalEncoder(board.GP16, board.GP17)
last_position = None
while True:
position = enc.position
if last_position == None or position != last_position:
print(position)
last_position = position
Behavior
Print initial 0 and then no changes to `...
This was fixed already: see #9681 and the fix #9682. This will be in the next beta, or you can get an "Absolute Newest" build.
Ah, my bad. Thank you for pointing this out!
Eh, my EP logs are pretty limited -- all I can see is when the S3 gets a MAC address, which only means the AP sees a connection. I need to put a timestamp on my logs so I can correlate instead of trying to "count seconds since I plugged it in". :grinning:
@slender iron I have draft release notes for 9.2.0-beta.1 and can wait for any imminent PR's.
@onyx hinge 👆 too - I see some PR's by or of interest to you.
I won't be able to review PRs until this afternoon. I wouldn't wait
we can always do another release
I intend on doing the picodvi bugs this afternoon too
i was just wondering whether you think the picodvi bugs will be easy. I could wait until tonight for the release.
but sure, I could do another beta soon anyway
Remove wrong features, fix typos and name.
I'll test on a MagTag, just to check for regression.
Thanks, I missed that.
If you'd prefer not to tinker further with the code and call it good, I'm OK with that as well.
If you're ok with it and Dan's test is ok, then let's just leave it as it is for now.
I tend to view freezing a module in as the last step, after it's able to be built with circuitpython-build-tools and installed with circup & the adafruit internal bundlefly tool. Once it's showing its usefulness within the circuitpython ecosystem then it might make sense to freeze it in on a board for a specific reason. But, maybe that is incorrect.
There's also not a lot of motivation given within this PR for requiring a different repo organization than the one standardized by the ada...
@tinylabs any plans to get back to this PR?
@tulip sleet did you have other PRs in mind as ones I might be interested in?
nope, I think I mistakenly thought one was open when it was already closed
... ok, I realize I meant issues instead of PR's
9644 and 9662
9644 I need to look at for sure
9662, no idea what to do. I don't think it's a code problem since my setup ran fine for days.
i'm not sure either if you can't reproduce
"needs retest" 🙂
thanks
The pins here don't match board.SCK etc in pins.c, and the MOSI choice is for SPI1, not SPI0. Did you mean:
#define DEFAULT_SPI_BUS_SCK (&pin_GPIO6)
#define DEFAULT_SPI_BUS_MOSI (&pin_GPIO3)
#define DEFAULT_SPI_BUS_MISO (&pin_GPIO4)
Hi,
I'd like to see support for USB host dual role in CircuitPython, something that was mentioned on the Feather product page is already supported in Arduino. Arduino seems to be using TinyUSB for this, the same as CircuitPython.
My specific use-case is this; I use CircuitPython to drive a keyboard, and I'd like to extend this keyboard with one or two USB host ports. I'd connect a mouse to one port, and a more generic HID device to the 2nd port (like a USB flash drive or a yubikey).
...
I think they will be easy but haven't done it yet so I don't know
I can just wait.
👍
Thanks! I poked the CI so it'll retry.
Could you give more detail about what you tried, what worked, and what didn't work? Maybe with some sample code?
On the side of CircuitPython acting as USB host, were you trying to use to use usb.core.find(), usb.core.Device.set_configuration() and [usb.core.Device.read()](https://docs...
Could you give more detail about what you tried, what worked, and what didn't work? Maybe with some sample code?
I was just running the tests found here: https://github.com/adafruit/circuitpython/tree/main/tests/circuitpython-manual/usb
With device_info.py I was able to detect the devices no problem. With basic_keyboard.py I was able to read the OTP event from the yubikey. With basic_mouse.py I could read the vectors from the mouse.
On the side of CircuitPython acting as USB host...
So, is it the case that you just need a way to send usb_hid keystrokes? Can you just buffer what you get from the yubikey, then send it to the host computer using adafruit_hid.keyboard?
Are you saying that you've tried doing that and adafruit_hid.keyboard does not work?
Or, if you just want literal pass through with no changes at all, could you just include a hub in your keyboard build (perhaps [...
So, is it the case that you just need a way to send usb_hid keystrokes? Can you just buffer what you get from the yubikey, then send it to the host computer using adafruit_hid.keyboard?
No, I'd need full generic USB passthrough, or at the very least CDC, for the yubikey FIDO2/U2F to work.
Can you just buffer what you get from the yubikey, then send it to the host computer using [adafruit_hid....
oh... okay, so by passthrough for HID CDC, do you mean you want to bridge a serial port connection between the RP2040's USB Host port and its upstream connection to the computer? In that case, I have no idea if that's possible, or how to go about it. I've never tried to make a USB serial port connection over a CircuitPython USB host port. You could try #help-with-circuitpython on Adafruit Discord to see if anybody there knows about doing that.
Or do you suggest that I rather do this?: ....
oh... okay, so by passthrough for HID CDC, do you mean you want to bridge a serial port connection between the RP2040's USB Host port and its upstream connection to the computer? In that case, I have no idea if that's possible, or how to go about it. I've never tried to make a USB serial port connection over a CircuitPython USB host port. You could try #help-with-circuitpython on Adafruit Discord to see if anybody there knows about doing that.
Not specifically, but it'd be one of the thi...
I got a reply today on the Github ticket about the X-RateLimit headers, confirming the change we saw to the headers and the resolution a few days later:
Sorry for the delayed response—we're currently handling a high volume of support inquiries, which has impacted our response times.
I wanted to follow up on your concern. There was indeed a change in the behavior of the Releases endpoint around the time you mentioned, and it was resolved on October 3rd.
If you have any more questions or need further assistance, feel free to reach out. Happy coding! 🚀👨💻
Cheers,
Rocky
does "it was resolved" mean they reverted it?
does it work the old way now?
That is my understanding of what they mean, and yes it's back to behaving the old way.
The core issue here to address is that exception failures in the RGBMatrix constructor do not clean up properly, and cause crashes. Moving this forward to 9.x.x.
Thanks! I poked the CI so it'll retry.
The only build failure was readthedocs. I removed get_html_theme_path() from conf.py, which is the same fix we just had to do to all the libraries.
This fixes picodvi and will speed up division too.
Fixes #9628
Don't change the framebuffer dimensions but do set the rotation. Then it works like you want.
Fixed by #9672. Thanks @samblenny!
Tested on Pico/DVI Sock and the Pimoroni pico dv Base. DVI is working now. Thanks!
[adafruit/circuitpython] Pull request opened: #9699 MDNS hostname match DHCP. Fix collision mangling
MDNS defaults to the hostname used by DHCP/LWIP since it is now unique. This makes it the same either way.
This also updates esp-protocols (used for mdns) with a patch to ensure that mangled names are the ones that collide. (circuitpython.local collides but was causing cpy- to be mangled.)
Fixes #6869 again.
@retiredwizard this changes the hostname slightly because it hit an assert when over 32 characters. cpy, board and mac are now dash separated too. That way the board's _ don't co...
@wraith crow just pinged you on github
@tulip sleet just sent out a PR for the MDNS fix. picodvi is all looked at too
Yup, looking good. I think I will go ahead and make a beta release.
thanks for the quick fixes and diagnoses
np! I want to get 9.2 stable
Scanned the code quickly, looks good to me, I'll give it some light testing tonight just for fun 😁
This looks fine to me but we can await testing by @anecdata and @RetiredWizard as well.
It should be fine in a beta too. I tested that MDNS still works.
@slender iron ok sure -- i'll merge and make a beta
Merging and can be tested in the beta.
I am marking this as an "incompatible change" because the hostnames can be somewhat different. Or is that an unusual case? I'm not sure.
ya, it'll change the mdns hostnames
should we wait for 10? I assume these names are usually discovered instead of hard coded
I think it's ok. The removal of all those LWIP board-specific names is also an incompatible change.
maybe a more surprising one.
Running out of flash on the c3s?
could turn off keypad_demux
This looks fine to me but we can await testing by @anecdata and @RetiredWizard as well.
still failing on large translations. What got so much bigger?
mdns I presume
these have dualbank turned on, does that make sense in the long run? Also ps2io is on, but they dont' have full USB, so maybe not very useful
no, I think we'll want dualbank off for these with 10 too
I'm changing some mdns config to see if it helps size
i have a guitar class in a few minutes, until 6pm PT, so not chomping at the bit for a release.
kk, I'm about to leave too
I'm getting the same hostname / mdns hostname for all four devices I set up: cpy-t_qtpy_esp32s2-3ffe2e90, despite unique MAC addresses.
My original code to convert the MAC address doesn't work, we should use something closer to your original code in server.c:
snprintf(cpy_default_hostname, sizeof(cpy_default_hostname), "cpy-%s-%02x%02x%02x%02x%02x%02x", CIRCUITPY_BOARD_ID + board_trim, mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
I wondered where that t came from... it's the end of Adafruit_.... Would be nice to split it at a _, but probably not worth the code.
I'm sorta glad the C3's didn't fit, I'll be much happier with working hostname/MAC addresses in the beta release
the good news is... I haven't seen any mdns hostname mangling 🙂
(well, other than the -2, -3, etc. b/c the hostnames are the same - and, oh my, the hostnames and instance names increment differently, e.g., Adafruit QT Py ESP32S2-2 (cpy-t_qtpy_esp32s2-3ffe2e90-4))
I assume the goal of the unique MAC addresses in the host name is to avoid all the mangling issues 🤞 I built Scott's PR with fixed MAC address conversion:
cpy-bpi_picow_s3-7cdfa1f23d14 MAC Address:7c:df:a1:f2:3d:14
cpy-8r8_hacktablet-7cdfa1e15694 MAC Address:7c:df:a1:e1:56:94
last three octets should be sufficient
there will be a lot of overlap in the first three (espressif owns 208 OUI ranges, raspberry pi only 7 ...out of 16+ million)
Mixed results early on today, but after I moved the I2C display cable off of the chip within the enclosure, I've had 12 hours of nonstop service, which is :+1: from me.
I was thinking that also, but figured I'd let Scott decide, if he drops three of the octets he also has the option to add three more characters to the board name so your t_ would turn into ruit_ 😁 The practice of using the last three octets is what allowed my coding mistake to slip through, I converted part of the hex encoded mac address into an unsigned integer and then back to a hex value which just happened to turn out to be 6 didgets (hexets?) long ☹️
Mixed results early on today, but after I moved the I2C display cable off of the chip within the enclosure, I've had 12 hours of nonstop service, which is 👍 from me.
This is very interesting. Do you just mean it was close to the ESP32-S3 chip or do you mean you unplugged (or disconnected) the I2C display?
Mixed results early on today, but after I moved the I2C display cable off of the chip within the enclosure, I've had 12 hours of nonstop service, which is 👍 from me.
This is very interesting. Do you just mean it was close to the ESP32-S3 chip or do you mean you unplugged (or disconnected) the I2C display?
Part of it was laying "over" the board and I managed to coil it all under the display, next to the STEMMA port. It's a bit easier to explain in relation to this picture:
!...
Might it be due to the fact that resolvable addresses haven't been implemented yet?
This is something I don't have the expertise to implement.
@lone axle soooo it looks like adabot added some files it shouldn't have, due to testing before pushing. 🤯 ``` build_deps/mpy-cross-8.x | Bin 0 -> 1427128 bytes
build_deps/mpy-cross-9.x | Bin 0 -> 354520 bytes
and that made the build in the actual bundle repo fail 😠
the overnight release does actually have files so that's good I guess, but there's more work to be done.
@lone axle I tagged you for review on some PRs to fix this. Thank you for working on the adabot, everybody understands it's hard to get right on the first try!
Thanks for the fix. Review is in. I do not have rights to merge in adabot the repo.
@lone axle I can click merge on that PR in a bit. can you do https://github.com/adafruit/Adafruit_CircuitPython_Bundle/pull/476 too?
Yep, done.
hi! I've been trying to get CircuitPython building for the ESP32-S3 (specifically for the Memento board) with ustack enabled so I can check how heavy my resource usage is, but enabling it in py/circuitpy_mpconfig.h causes linking to fail. is it not supported on Espressif platforms? the documentation doesn't include a supported-boards list for either it or uheap
It looks like uheap is definitely broken due to incompatible changes in the core. However, I can successfully compile for adafruit_magtag_2.9_grayscale with ustack enabled, so you may have done the procedure incorrectly.
CircuitPython almost always enables modules by editing a .mk file, not a .h file. It's necessary to manually make BOARD=... clean after changing mk files.
So I added the line CIRCUITPY_USTACK = 1 at the end of ports/espressif/mpconfigport.mk, then did make BOARD=adafruit_magtag_2.9_grayscale clean and finally make BOARD=adafruit_magtag_2.9_grayscale.
I'll load it on my board in just a second and see if it imports/works.
I'll investigate uheap a little more too and file an issue if it is for sure not working. It is likely due to the "split heap" code that @slender iron switched us over to in the last months...
interesting, thank you! is this information in the docs, perchance? :p
I had to guess how to enable it since I'm not much of a C developer
When it comes to how-to documents they are often on the Adafruit Learn system. There's this (though it doesn't cover the need to make clean so it could be improved)
https://learn.adafruit.com/building-circuitpython/customizing-included-modules
You may want to include a particular module that is not included by default for the board for your board. You can customize which modules to include in your CircuitPython build by adding or changing settings in the mpconfigboard.mk file for your board.
alright
>>> import ustack
>>> ustack.stack_size()
15360
>>> ustack.stack_usage()
948
```ustack does work on my board so hopefully you can get it going too
let me see if it'll work
where would I find a list of the allowed options for port makefiles?
the closest to that is the source file py/circpy_mpconfig.mk which provides defaults and often small comment blocks about what can be enabled/disabled
CIRCUITPY_UHEAP ?= 0
CFLAGS += -DCIRCUITPY_UHEAP=$(CIRCUITPY_UHEAP)
```for instance from this plus my experience, I inferred that I could enable the `uheap` module by setting `CIRCUITPY_UHEAP` in the right `.mk` file. but without experience you wouldn't just guess it.
CircuitPython version
9.2.0-beta.0-72-g5b771569d8
Code/REPL
diff --git a/ports/raspberrypi/mpconfigport.mk b/ports/raspberrypi/mpconfigport.mk
index 81913bde01..28ef3c5eb7 100644
--- a/ports/raspberrypi/mpconfigport.mk
+++ b/ports/raspberrypi/mpconfigport.mk
@@ -81,3 +81,5 @@ CIRCUITPY_MESSAGE_COMPRESSION_LEVEL ?= 1
# (ssl is selectively enabled but it's always the mbedtls implementation)
CIRCUITPY_SSL_MBEDTLS = 1
+
+CIRCUITPY_UHEAP = 1
#...
I have to step away for now. If you're a github user you can track the uheap build problems on that issue. You can always ask more questions here or in #help-with-circuitpython and hopefully someone else can step in to answer.
mhm, thank you for your help!
👋
it works, hooray
although the reported values don't actually seem to... change? weird
and max_stack_usage() just doesn't exist
MICROPY_MAX_STACK_USAGE is a separate flag
@ladyada and team, it looks like DAC DMA is now supported in Espressif: https://github.com/espressif/esp-idf/blob/master/components/esp_driver_dac/esp32s2/dac_dma.c.
If you could provide some guidance, I’d be happy to work on adding this support to CircuitPython.
calling it os feels like a bit of a misnomer really, since most of what it actually does is filesystem stuff; it's not even under the Standard Libraries section with the rest of the CPython analogues
note that PYSTACK is enabled, so python stack frames are on a separate stack
what's the distinction? the reason I'm interested at all is because I had to increase the max size of pystack, but I don't really get what it does
THe python stack frames could be on the C stack, but with PYSTACK enabled, they are on a separate stack.
As part of work on the PicoADK V2 and initial CircuitPython support, I was wondering if SDIO support is coming?
This works really well https://github.com/earlephilhower/arduino-pico/discussions/1560#discussioncomment-10681395
I tend to view freezing a module in as the last step, after it's able to be built with circuitpython-build-tools and installed with circup & the adafruit internal bundlefly tool. Once it's showing its usefulness within the circuitpython ecosystem then it might make sense to freeze it in on a board for a specific reason. But, maybe that is incorrect.
I think freezing of modules is a way to add (software-) features to a board, necessary for the operation of the given hardware. Mainly to ma...
It turns out this diagram has several errors:
I am going to get that fixed!
The schematic is correct, of course:
The pin-out of the Waveshare panel is the same as the Adafruit panels. Pinouts of our panels are discussed here: https://learn.adafruit.com/32x16-32x32-rgb-led-matrix/new-wiring. Note you hav...
without pystack, large python frames get allocated to the heap instead of the c stack. so pystack prevents them from using the heap
takes the cats to the vet
Hi - this is a dupe of #8160.
I recommend to look at the repo I have referenced. The SDIO is much faster than the one in pico-extra.
This is working for me now. I probably had a truncated MP3 file and hit #9653, which was kindly fixed by a community member.
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0-25-g7f14b9c49a on 2024-10-04; Raspberry Pi Pico 2 with rp2350a
Code/REPL
import time, board, busio, adafruit_ssd1306
from digitalio import DigitalInOut
i2c = busio.I2C(board.GP17, board.GP16)
display = adafruit_ssd1306.SSD1306_I2C(128, 64, i2c)
Behavior
SSD1306 display properly attached
First time works, then if we reload and run it again:
ValueError: I2C peripheral in use
Desc...
From #9702 (dupe):
@DatanoiseTV
As part of work on the PicoADK V2 and initial CircuitPython support, I was wondering if SDIO support is coming?
This works really well https://github.com/earlephilhower/arduino-pico/discussions/1560#discussioncomment-10681395
I don't think this is a bug. We keep I2C around when used by a display so that it can be used internally. Do displayio.release_displays() to release it.
It's not a displayio display. I just met the bug with it.
It can be repro'ed with just import board, busio; busio.I2C(board.GP17, board.GP16), reloading and running it again.
giving it emulated-native wifi support.
I worry that emulating the native API will be confusing because it won't be able to do everything that an actual native implementation can do. Specifically, it won't be able to do the web workflow. So I'd suggest a full AirLift-style library that could be frozen in or an actual native C implementation that web workflow can use.
@jepler Do you have a WIP branch somewhere that @tmkasun could start with?
Otherwise @tmkasun I'd suggest looking at how I2SOut is implemented and convert it into audioio.
@tannewt no I don't think I have any WIP branch related to this
The esp-idf docs make it sound like we would want to use continuous dma mode with asynchronous writing: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/dac.html#continuous-wave-output-continuous-dma-mode
the on_convert_done callback would be comparable to the function i2s_event_interrupt providing the ...
Does anyone use aesio? It takes about 3k on ESP32-C3. We'll likely add a new crypto API for Matter support. (Currently it uses a small part of cryptography and ecdsa modules.)
aesio was added by #2823. It implies it might have been used for some Covid tracking functionality. @xobs Are you using aesio for anything now? You were the PR author.
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0-3-g3a189e75d9-dirty on 2024-09-23; Raspberry Pi Pico 2 with rp2350a
Code/REPL
# https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/main/circuitpython-audio-fx/polyphonic/code.py
Behavior
Install the project and hook up a button to GP4. When pressed and held, this says "track 4 hold loop".
Repeatedly press and release the button. Press for about 1 second at a time, trying t...
Tested on BPI PIcow S3 and Hacktablet, the Web workflow page and my DHCP server both show the expected hostname with the correct :blush: MAC address.
You can also hear this if you use GP4 to trigger "track 4 hold loop", release mid-sample, and then press GP3 to trigger "track 3". However, you don't hear anything when going from GP3 to GP4, i.e., it's either only affecting looping samples OR samples that are stopped mid-playback. This also shows it's likely not a special case error of playing the same sample twice in a row.
I looked at going to the next _ but in some cases you do lose something helpful. In some cases the remainder is the chip number (such as 6 from esp32c6) for example.
Looks good, no mangling observed. mdns hostname correctly shows each MAC address. WW pages load with curl or browser by IP, mdns hostname, or circuitpython.local[.]
Links to other devices on the WW pages are correct.
could drop to 3 octets of MAC, to free up more of the board name
I looked what dropping one octet would do and it didn't seem too helpful. I thought about xoring the three octets together to ensure all bits are included.
ping also to @bobricius and @isacben who have also previously contributed fixes or improvements to this module
I tried latest main with a SAMD21 board, and I2C cleanup is acting flaky, though I haven't got a reproducer yet. I think this may be due to #9671, which removed i2c_reset() on various ports.
@slender iron in the circuitmatter README, if I do python -m circuitmatter test_data/recorded_packets.jsonl, I get
FileNotFoundError: [Errno 2] No such file or directory: '../esp-matter/connectedhomeip/connectedhomeip/credentials/test/attestation/Chip-Test-DAC-FFF1-8000-0000-Key.der'
it looks like I need to clone esp-matter next to circuitmatter?
I haven't yet done anything with esp-matter
yup! sorry about that
np, just wanted to make sure you knew
it is documented under the chip-tool section
please update the readme as you find these things
@slender iron did you have any trouble with cffi during the esp-matter install.sh? It's complaining it wants it to build wheels but it's not installed. from pip's point of view it is installed
- Fixes #9703
busio.I2C() became a class with a finaliser in #9671, but it also needed __del__() to be defined for the finaliser to work properly.
Tested on a Metro RP2040, a PyPortal, and a Pico 2.
I have 2 items unchecked but I think it is worth merging this now if it is ready. More PRs can add more features as we go.
I think the build failures are something with the build system but not 100% sure.
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0-35-g6f6b8b03a6 on 2024-10-09; ESP32-S3-DevKitC-1-N8R8-with-HACKTABLET with ESP32S3
Adafruit CircuitPython 9.2.0-beta.0-31-g14d3f2e839 on 2024-10-08; Raspberry Pi Pico 2 with rp2350a (using dvi sock)
Code/REPL
import displayio
databytes = bytearray(64)
for i in range(64):
databytes[i] = i+1
for i in range(2,64):
bitmap = displayio.Bitmap(i,i,255)
mem = memoryview(bitmap)
me...
Modifying the Matrix dump routine so it performs all the copies first and then dumps the matrix, results in the following:
Memoryview copies into bitmap of width 10
1:2:3:4:5:6:7:8:9:10:
13:14:15:16:17:18:19:20:21:22:
25:26:27:28:29:30:31:32:33:34:
37:38:39:40:41:42:43:44:45:46:
49:50:51:52:53:54:55:56:57:58:
61:62:63:64:65:66:67:68:69:70:
73:74:75:76:77:78:79:80:81:82:
85:86:87:88:89:90:91:92:93:94:
97:98:99:100:0:0:0:0:0:0:
0:0:0:0:0:0:0:0:0:0:
I don't agree. With this emulation, libraries like adafruit_connectionmanager, adafruit_requests, adafruit_httpserver (actually every library and program that uses wifi) just work. If you look at the adafruit libs and how much additional code they need to support adafruit_esp32spi then you know how unattractive it would be to add another incompatible api/implementation.
Yes, web-workflow does not work, but you can expect users that add an external co-processor to know that there are di...
I think tracked down my issue. It looks like Displayio fills each bitmap row to end at an even 4 byte boundary. So when using memoryview to copy data into the bitmap, you need to adjust the destination after each row by any filler space.
There still seems to be an issue using memoryview for bitmaps with a color depth of 4 or less. If I can't figure that out it may warrant a separate issue.
Please add images too.
Thank you for the hint. Done.
doesn anybody know where common_hal_displayio_bitmap_load_row is implemeted? it's defined in shared-bindings/displayio/Bitmap.h but I can't find the implementation
@stuck elbow looks like there's a declaration in Bitmap.h but no definition & no uses.
the implementation was removed a very long time ago in 2019
would there happen to be a way to interrogate a CircuitPython microcontroller about its capabilities that isn't "send Python over the raw REPL?" I'm considering remaking the vscode extension because it's pretty broken right now
a machine-readable list of USB vendor/device IDs would also be cool
If the CIRCUITPY drive is available, you can look at boot_out.txt to identify the device.
right
I suspect the problem will be finding the serial port corresponding with a USB drive
See https://github.com/adafruit/Adafruit_Board_Toolkit and https://github.com/neradoc/discotool for identifying serial ports
the serial ports have certain names. If you have multiple devices connected, that is a bit more of a problem, but for one device, it's easy
using that library or that tool (they use the same techniques)
cool, thanks
both of these use platform APIs, unfortunately; I'm not sure if I can easily do that from JS
looking for something...
https://github.com/circuitpython/web-editor is what runs https://code.circuitpython.org, which asks the user to choose the serial port, using webserial on chrome-based browsers. Is that good enough/
that code is all js, running in the browser
Node isn't quite the same as Chrome, though :p
let me see if I can find my code
the current one uses https://serialport.io/ I think
Talk to your Serial devices with JavaScript
okay, I can get a vendor and product id from that
now I just need to find a node USB library that isn't broken
@tannewt I use aesio to secure LoRa packets
@tulip sleet I didn't have cffi trouble but esp-matter is a pain.
i will check their issues, etc.
If I were to make a "very similar board" to an existing CircuitPython board but use 4MB flash in place of the original board's 2MB flash, will CircuitPython still load and work? or is CircuitPython expecting an exact match for the flash chip?
You shouldn't need to pip install everything to run the replay
with what micro? some ports expect exact match
Ah. Sorry about that.
@tulip sleet - I am working with the SAMD21 and used a 4MB flash rather than the 2MB. I did try to use the same vendor/manufacturer for the flash and stay in the same family of chip. (aka I used a W25Q32JVSS vs the W25Q16JVxQ for the itsy bitsy M0).
I wasn't sure if my problem is the flash size or if it's not close enough to the same model
Yeah. I was trying to cheat and reuse the itsy bitsy M0 since there will only ever be about 100 of this board in the wild.
I'll go ahead and build a new board.
Hi @jepler
Thanks for checking! I am no using it.
If you look at the adafruit libs and how much additional code they need to support adafruit_esp32spi then you know how unattractive it would be to add another incompatible api/implementation.
I thought the intent of ConnectionManager was to centralize this so it didn't need to go in many places. The adafruit examples likely predate connection manager.
I think this is too confusing. It isn't a native implementation. Why not do a native implementation so that web workflow works?
Minor changes to have CIRCUITPY_AUDIOEFFECTS enable a bunch of future modules and have CIRCUITPY_AUDIODELAYS explicitly.
ifeq ($(CIRCUITPY_AUDIODELAYS),1)
SRC_PATTERNS += audiodelays/%
endif
CIRCUITPY_AUDIOEFFECTS ?= 0
CIRCUITPY_AUDIODELAYS ?= $(CIRCUITPY_AUDIOEFFECTS)
I don't understand the reasoning. There are currently 326 py-files distributed by circup that do an "import wifi". They will only work if they find a module called wifi. And this is not only because they predate the connection manager, but because the connection manager does not provide any support for the many methods of wifi.radio that deal with starting/stopping AP, stations, setting IPs, DNS and so on.
Currently, I can add an ESP32Cx to whatever board provides a free UART simply by ins...
Thanks @anecdata and @RetiredWizard for testing!
There is some build problem with the latex pdf doc build. I am going to ignore that for now and debug it separately. I will go ahead and merge this.
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0-33-g52602caae4-dirty on 2024-10-10; Adafruit Camera with ESP32S3
Code/REPL
# See https://gist.github.com/gingershaped/d0336649c3da9f89775b22fcb78ea451
Behavior
Under specific conditions, connecting to the Memento board over Bluetooth Low Energy causes CircuitPython to hard fault and enter safe mode. Usually it happens after doing some variation on these steps:
- put this code in `c...
make latexpdf worked with Sphinx 7.4.7. Then I updated did pip install --upgrade -r requirements-doc.txt, and Sphinx got upgraded to 8.1.0. Then make latexpdf failed. Checking further.
[adafruit/circuitpython] Pull request opened: #9709 pin sphinx temporarily while debugging doc build
Sphinx 8.1.0 just came out today. It breaks the latexpdf build, and also causes new messages like:
checking consistency... /home/halbert/repos/circuitpython/BUILDING.md: document is referenced in multiple toctrees: ['docs/index', 'docs/pdf'], selecting: docs/pdf <- BUILDING
/home/halbert/repos/circuitpython/CODE_OF_CONDUCT.md: document is referenced in multiple toctrees: ['docs/index', 'docs/pdf'], selecting: docs/pdf <- CODE_OF_CONDUCT
/home/halbert/repos/circuitpython/CONTRIBUTING...
I think adafruit_support_bill got it right way back in August: here. Plus, any short sleep will be accentuated by the floored division diff_us = (t2-t) // 1000 which rounds decimal remainders down to the nearest integer, e.g., 1.999999 -> 1 (per the docs). See also [this](https://docs.python.org/3/tutorial/floatingpoint.html#floating-point-arit...
@slender iron @onyx hinge if you can approve https://github.com/adafruit/circuitpython/pull/9709, I will do the 9.1.0-beta.1 release
Thank you for debugging this!
thanks!
caught me right before I left 🙂
whew 🙂
thank you! so excited to be at "beta" 💜
Automated website update for release 9.2.0-beta.1 by Blinka.
New boards:
- datanoise_picoadk_v2
- espressif_esp32s3_lcd_ev_v1.5
- makerdiary_imxrt1011_nanokit
- makergo_esp32c6_supermini
- sunton_esp32_8048S050
I think adafruit_support_bill got it right way back in August: here. Plus, any short sleep will be accentuated by the floored division [...]
Ah yes, I have experienced this. In #9237 I was convinced it was a problem with floats in CircuitPython because 0.004 seconds / 1000 != 4 milliseconds.
Howdy folks 🙂
I've had reports from 2 different people in the last week or so stating similar to this...
Is there a known bug with wifi on feathers2 with circuitpython 9.1.x? I've been trying to get some of my older code working on 9.1.4 and realized that as soon as 'import wifi' runs things lock up. Can easily replicate it in the REPL, just import wifi. I tracked it down to the 9.1.0 release. Previous version 9.0.5 works, 9.1.0 locks up. To make things worse after power cycling the flash comes up empty and possibly corrupted.
Have there been any other reports of anything like this since 9.1x shipped?
I'm, flashing 9.1.3 on all of my boards on my test jigs, and I am not experiencing any wifi issues or flash corruption issues, but that's all in a controlled environment.
Ah yes, I have experienced this. In #9237 I was convinced it was a problem with floats in CircuitPython because 0.004 seconds / 1000 != 4 milliseconds.
My favorite quote from the discussion:
"Note that this is in the very nature of binary floating point: this is not a bug in Python, and it is not a bug in your code either. You’ll see the same kind of thing in all languages that support your hardware’s floating-point arithmetic" (emphasis mine)
I can repo this on a FeatherS2 running 9.1.3... simply go to the repl and import wifi
and it hangs... doesn't come back. If I reset it, I don't get flash corruption, but I've only done this twice.
I'm not using it. It was originally part of a Contact Tracing implementation that has since languished.
There was something that was fixed https://github.com/adafruit/circuitpython/issues/9486 rather more specific, but was provoked by import wifi. Please try 9.1.4, and also I am in the process of releasing 9.2.0-beta.1. Try that also.
Oh, ok, I'll try that out and report back, thanks!
OK, the 9.2.0-beta.1 links are up on circuitpython.org now
Plus, any short sleep will be accentuated by the floored division
diff_us = (t2-t) // 1000which rounds decimal remainders down to the nearest integer, e.g., 1.999999 -> 1 (per the docs).
I think this is still something to follow up on. We might round instead of truncating. And I am still suspicious of 1024 vs 1000. 9.7 vs 10 is not a few least-significant bits of difference.
I think this is still something to follow up on. We might round instead of truncating. And I am still suspicious of 1024 vs 1000. 9.7 vs 10 is not a few least-significant bits of difference.
I had played around with altering the value given time.sleep; the handful of substitute values tried were enough to suggest that expressions are perhaps being evaluated according to The Price is Right rules, which is to say what it returns is as near as possible the specified value without going ov...
What (or where) is the process for requesting a USB PID for a new SAMD21 (M0) board?
@stuck elbow - all the hardware will be published. I use the MIT license for my stuff.
When I did a search on "SAMD21", I found references to PID requests within CircuitPython but they were from a few years back. Hence, my question.
Thanks.
https://blog.adafruit.com/2024/10/10/circuitpython-9-2-0-beta-1-released/
Highlights of this release
- New
busio.I2C.probe()andbitbangio.I2C.probe()methods to check for a single device address. - Use new ESP-IDF I2C driver.
- ESP32-S3: implement
sdioio. - Incompatible change: Change default hostname for all Espressif boards to the ESP-IDF default, which is
espressif. Previous board-specific names were not applied consistently. Usewifi.radio.hostnameto set a custom hostname. - Incompatible change: Use default hostname for mDNS. Fix mDNS collision mangling.
then the website I linked should work for you
For the Spirit Board that I am working on I created a helper class AnchoredTileGrid that extends TileGrid and adds the anchor_point and anchored_position behavior from Display_Text and a few other widget libraries.
I think it has the potential to be useful more generally than just for the Spirit Board. I'm curious if there is any interest in having those properties added directly to TileGrid within the core? Or creating a library to hold the AnchoredTileGrid class so that it's easy to re-use outside of this specific project.
This discussion has somehow deteriorated, we should instead discuss this PR.
To sum up:
- the script
tools/preprocess_frozen_modules.pyis small and has a very limited functionality - it uses heuristics to autodect py-files from library-projects for freezing
- this heuristics uses some seemingly random choices about which directories are valid and which are not, e.g.
docsvs.docortoolsvs.utils - the PR adds three lines of code that optionally enables library developers t...
I agree this has gotten off topic. I think it is OK to add the src detection; it is optional and won't break our existing frozen libraries. Whether that library is available for use in the bundle or not is a separate question.
I think this is a workaround? But maybe not having to do that is the whole point.
FROZEN_MPY_DIRS += $(TOP)/frozen/Some_Library/src
Yes, I used that workaround already. But having it the the script is more explicit.
It is OK with me to merge this, for private use by whomever has libraries with src/. The disadvantage is that libraries with src/ are not going to work in a bundle. But that's a problem for the library writer. We can have a separate discussion about making src/ optional and possible in the bundle world or even the default in general.
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0 on 2024-09-17; Raspberry Pi Pico 2 with rp2350a
Code/REPL
# boot.py
import usb_cdc
usb_cdc.disable()
Behavior
After power-cycling the Raspberry Pi Pico 2, as instructed in https://github.com/adafruit/circuitpython/issues/990#issuecomment-444643691, the boot.py still runs.
Description
I was expecting a REPL prompt similar to this, but more applicable to the actual situation:
...
I have reproduced this. I'm thinking that the magic word that detects repeated resets is not being saved for some reason (does reset on the RP2350 clear RAM)?
I have reproduced this. I'm thinking that the magic word that detects repeated resets is not being saved for some reason (does reset on the RP2350 clear RAM)?
If that's actually the situation, maybe safe mode could be entered by pressing BOOTSEL during the initial 700ms timeframe. At least on the original Pico, the BOOTSEL button could be read, albeit slowly: https://arduino-pico.readthedocs.io/en/stable/bootsel.html
@tannewt and I talked about this. The src/ thing is fine. We have some ideas about an AirLift wifi substitute library but can talk about that elsewhere.
Do you have a sense of how that might impact runtime performance, memory allocations, and flash size? I've been experimenting recently with using TileGrid for relatively high frame rate animations, and I've been impressed with how well that works. It's nice to have the implementation be pretty fast.
If it were a library it would be no impact unless you choose to use it instead of the standard TileGrid. If you did choose to use it I'm not sure of the impact it would have, I wouldn't expect it to be drastic but I haven't done any measurements.
If it were implemented in the core directly on TileGrid I would expect it to increase flash size, and memory usage slightly due to the code to support the new properties, and the values those properties hold. But the code needed won't be that much I think, the python implementation is here: https://github.com/FoamyGuy/Adafruit_Learning_System_Guides/blob/tft_spirit_board/TFT_Spirit_Board/shared/lib/anchored_tilegrid.py In the core it would probably expand a bit further due to handling of the tuples, but still shouldn't be that big.
I would not expect it to impact the rendering framerate of cycling through tiles in the TileGrid if the TileGrid is not moving also. If the TileGrid were moving, and you choose to move it with the new properties I would expect it to be ever so slightly slower than moving it with the x and y properties directly because it has to do a bit of math to calculate the position and then set the x and y properties.
interesting... for the Pumpkins vs. Skeletons game I just finished, I animated the x, y coordinate of the flying pumpkins. That let me use an 8x8 tile for the sprite, but, because I didn't have to stay tied to the 8x8 grid, the trajectory could look very smooth.
The frame rate I managed to get on an ESP32-S3 was mostly plenty fast enough, but with the occasional glitch once in a while. I don't really have a sense of how much of that was due to garbage collection pauses, time spent on data transfers over the SPI bus, or whatever else. But, my impression was that I was pushing the system close to the limit of what it could animate smoothly.
Is your code published anywhere? I could try tweaking it to use the python version of AnchoredTileGrid and see if it makes a noticable difference. I don't have a core implementation to test, but am willing to make it if there is interest.
https://github.com/samblenny/pumpkin-toss-game
also, guide at https://adafruit-playground.com/u/SamBlenny/pages/pumpkins-vs-skeletons-game-for-circuitpython describes the hardware setup which includes a USB gamepad
I'd be very curious to hear how it goes if you try it.
I don't think I have a USB gamepad to try it with. I'll poke around and see if one comes up though. It looks like the way you've got the code factored out should make it easy enough to mock the controller inputs if I don't find one. Although it perhaps lessens the meaningfulness of the test outcome for your use-case since I'd be removing the USB Host operations from the equation.
you might be able to make do with a USB numpad or keyboard. like, just read 8 bytes or whatever from endpoint 0x81 and look for anything that's not 0
anyhow... hope the spirit board thing goes well. I'm headed afk.
CircuitPython version
Adafruit CircuitPython 9.1.3 on 2024-08-30; Seeed Xiao ESP32-C6 4MB Flash 512KB SRAM with ESP32-C6FH4
Code/REPL
socketpool = socketpool.SocketPool(wifi.radio)
addressInfoTupple = socketpool.getaddrinfo("cats.com", 80)
for individual_addressInfo in addressInfoTupple:
print(f"individual_addressInfo: {individual_addressInfo}")
Behavior
individual_addressInfo: (2, 1, 0, '', ('172.67.39.47', 80))
Description
I ca...
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.1 on 2024-10-11; Adafruit MagTag with ESP32S2
Code/REPL
>>> wifi.radio.addresses
('10.0.3.28',)
>>> wifi.radio.dns
('FD5F:3F5C:FE50::1',)
>>> wifi.radio.ipv4_dns
>>> wifi.radio.ipv4_dns = ipaddress.ip_address("1.1.1.1")
>>> wifi.radio.ipv4_dns
>>> wifi.radio.dns = ('1.1.1.1',)
>>> wifi.radio.dns
('FD5F:3F5C:FE50::1',)
Behavior
I was trying to reproduce #9771 and I grabbed this recen...
Actually it appears that the address is being continuously overwritten ...
>>> wifi.radio.dns = ('10.0.2.76',); wifi.radio.dns
('10.0.2.76',)
>>> # Wait 10 seconds
>>> wifi.radio.dns
('FD5F:3F5C:FE50::1',)
This is due to the IPv6 "neighbor discovery"; my router sends a RNDSS (recursive DNS server) announcement. lwip unconditionally overwrites the DNS server list with this. IPv6 neighbor discovery cannot be runtime disabled, so it runs even if IPv6 DHCP is not enabled and the...
This is a limitation of lwip, the socket library that is used by Espressif devices (and RP2040 wifi devices, when it comes to that). Their source code .../lwip/src/api/netdb.c states:
* Due to a limitation in dns_gethostbyname, only the first address of a
* host is returned.
* Also, service names are not supported (only port numbers)!
CircuitPython's implementation of getaddrinfo is prepared to return multiple addresses when you call socket.getaddrinfo but the underlying ...
Recursive DNS Server (RDNSS) is an extension of IPv6 Neighbor Discovery. It is one of several ways (in addition to DHCPv6) to inform a network node of a usable DNS server.
In LWIP, it appears any RDNSS DNS server will overwrite a DNS server from DHCPv4 or manual configuration, whether or not CircuitPython has an IPv6 address configured.
In the (default) case where DHCPv6 is disabled in CircuitPython, but the (apparently rare) case where a RDNSS advertisement is broadast, this means that...
Just based on some grepping around it looks like micropython takes the default value of 0 for CONFIG_LWIP_IPV6_RDNSS_MAX_DNS_SERVERS which if correct makes me feel better about taking this change.
CircuitPython's implementation of getaddrinfo is prepared to return multiple addresses when you call
socket.getaddrinfobut the underlying library doesn't provide multiple addresses yet.
Good to know! I'll keep my for loop that tires connecting the mqtt client to each address so when this is implemented its waiting to work.
@tiny peak is the YT video of your game here: https://www.youtube.com/watch?v=QStcSDSYKOE a realtime representation of how it looks when you play it? Or is that slowed down any?
I was able to get a modified version of the game working using a joy featherwing (connected via I2C) for input instead of a USB gamepad device.
I have the host featherwing connected and initialized and I have a device plugged in, but I think that device is presenting as a keyboard, not a gamepad and I don't think it would be sending much data.
In mine the pumpkin flying seems to render a fair bit faster. I'm guessing due to not really having to share the SPI bus between the gamepad and the display, but I'm not certain.
@tiny peak I've done a bit more testing now with pythom implementation of AnchoredTileGrid swapped in for the pumpkin tilegrid in your project.
I do not see any appreciable different in the rendering framerate when using AnchoredTileGrid vs. normal TileGrid. I did not measure scientifically though, just by eye.
I also tried changing the code that moves the pumpkin to use anchored_position instead of x and y To my eye, I still do not really perceive a difference in framerate rendering it looks visually the same as the normal TileGrid version to me.
All of the ones I've gotten running do seem faster to me than the one depicted in your YT video. If you're interested in seeing the difference let me know and I can get you some timestamped links to my stream this morning to where I ran the different versions.
the video is playing at normal realtime speed
interesting... I'm watching through the start of your stream now
I struggled for a bit on a USB solution that didn't pan out. The back half contains all of the bits relavent to displayio and tilegrid.
yeah, the USB protocol for Xbox 360 gamepads is a bit of a head-scratcher until you get used to it
Running it on a USB Battery instead of plugged into the Hub / PC actually seem sto make the pumpkin fly a bit slower strangely. It looks closer to the speed of your video this way, but still maybe a tad bit faster.
I think USB IO has a big impact on overall system timing
Ahh, actually I was wrong. Changed too many variables at once.
I had unplugged the gamepad that I tried to use. (I left it plugged in to so that the game would detect it and let me start). It turns out if I unplug that after the game lets me start the pumpkins fly a bit slower than if I have it plugged in.
I guess unplugged it's spending a tad more time "looking" for that device or trying to read from it than doing the same when it remains plugged in (even though I'm not actually using it for the game)
battery doesn't make any difference, only whether or not I leave the gamepad plugged in.
I was looking into using keypad.ShiftRegisterKeys and found the documentation confusing. I had to check the source code to understand how it works.
Says:
//| Create a `Keys` object that will scan keys attached to a parallel-in serial-out shift register
//| like the 74HC165 or CD4021.
//| Note that you may chain shift registers to load in as many values as you need.
//| Furthermore, you can put multiple shift registers in parallel and share clock ...
OK retested with just one connection. Still crashing once a message is sent from the peripheral.
Adafruit CircuitPython 9.2.0-beta.0 on 2024-09-17; FeatherS3 with ESP32S3
>>>
soft reboot
Auto-reload is off.
Running in safe mode! Not running saved code.
You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Hard fault: memory access or instruction error.
also tried the latest beta and same behavior
Adafruit CircuitPython 9.2.0-beta.1-1-...
I know the port is super-duper pre-alpha, but would be great to get a customized .bin every time there's a release :)
Also added some missing pin definitions.
Could you post or point to the code for the LEFTPAW and RIGHTPAW devices? Confirming that these are CPB's.
Missed keeping audioeffects around the first time but pushed and updated correctly now.
<@&356864093652516868> A gentle reminder that there is no meeting today, as Adafruit observes Indigenous Peoples' Day. The meeting is 24 hours later than usual, at 2PM ET / 11AM PT. See you tomorrow!
I created https://github.com/FoamyGuy/Adafruit_CircuitPython_Anchored_TileGrid to hold the class utilized by my spirit board project. If anyone has a moment can you create a repo by the same name under adafruit org. I can move the code over to there and then get it added to bundle.
CircuitPython version
Adafruit CircuitPython 9.1.2 on 2024-08-22; Raspberry Pi Pico W with rp2040
Board ID:raspberry_pi_pico_w
Code/REPL
import board
import keypad
keys = keypad.ShiftRegisterKeys(
data = board.GP0,
clock = board.GP1,
latch = board.GP2,
key_count = 8,
value_when_pressed = True,
value_to_latch = True,
)
print(f"There are a total of {keys.key_count}...
For what it's worth, this test also fails the same way:
import board
import keypad
keys = keypad.ShiftRegisterKeys(
- data = board.GP0,
+ data = (board.GP0),
clock = board.GP1,
latch = board.GP2,
- key_count = 8,
+ key_count = (8),
value_when_pressed = True,
value_to_latch = True,
)
I was able to reproduce the firmware error: 2 easily. I have not yet tried to reproduce the crash in earnest.
Some observations on the code:
Error2 is EALREADY, that is, pairing is already in progress. You do not need to call .pair() yourself, because pairing is being initiated by the Android central, when it brings up the "Pair?" dialog box. If I run the same program on an nRF board with CircuitPython, I get an "invalid state" error, which I think is trying to indicate the same t...
+ key_count = (8),
Try (board.GP0,) and (8,) to make these actual tuples. Just putting them in parentheses without the comma does not make a tuple (a syntactic trap of Python's).
I think you can request a transfer of the repo.
It disables the choice for me. I also tried "specify by organization name" instead of the dropdown with "adafruit" but it returned a similarly worded error that I am not allowed to request it.
Thanks! I confirmed the workaround works.
An aside: (8) is not a tuple; (8,) is a tuple; (8,8) without a trailing comma is also a tuple; (8, 8,) is also a tuple. The trailing comma is ignored, but it convenient when you have tuple members on multiple lines:
t = (
8,
9,
10,
)
- Fixes #9718
When keypad.ShiftRegisterKeys(..., key_count=some_integer, ...) had an integer argument, the argument was not correctly converted to an integer. This error was inadvertently introduced by #8143.
Testing:
import board
import keypad
keys = keypad.ShiftRegisterKeys(
data = board.GP0,
clock = board.GP1,
latch = board.GP2,
key_count = 8,
value_when_pressed = True,
value_to_latch = True,...
I have a fix for this in #9719. If you are interested in testing, the build artifacts are here:
https://github.com/adafruit/circuitpython/actions/runs/11337244998?pr=9719
The fix looks good.
- I went to https://github.com/adafruit/circuitpython/actions/runs/11337244998/artifacts/2055704506 and installed the UF2 for my pico_w.
- I confirmed the
boot_out.txtwas `Adafruit CircuitPython 9.2.0-beta.1-3-gfa7573d9b2 on 2024-10-15; Raspberry Pi Pico W with rp2040 - The
print(f"There are a total of {keys.key_count} keys.")now reflects thekey_countparameter - The logic analyzer trace shows the right number of clock pulses
`
@aseanwatson, the reporter in #9718, has tested and confirms it's a fix.
macos-12 is deprecated as a runner for GitHub actions and will be subject to brownouts in November. Update to macos-13.
Also try updating all the ubuntu-22.04 to ubuntu-24.04 and see what breaks, in a separate commit.
Hello everyone
I'm just starting out in circuitpython
I am currently making this project : here is the link:
https://learn.adafruit.com/matrix-portal-scoreboard/code-the-scoreboard?embeds=allow
I installed everything, I'm at: Adafruit IO Setup
But I don't understand where to install or copy the secrets.py file
Thank you for the help sorry for the translation I am French
Bonjour a tous
Je debute juste dans circuitpython
je suis en train de faire ce proget : voici le lien:
https://learn.adafruit.com/matrix-portal-scoreboard/code-the-scoreboard?embeds=allow
J'ai tout installer j'en suis a: Adafruit IO Setup
Mais je ne comprend pas ou il faut installer ou copier le fichier secrets.py
Merci pour l'aide desoler pour la traduction je suis francais
Hi! Welcome to CircuitPython - can you please ask for help in the #help-with-circuitpython channel? That would be the correct channel as this channel is for the development of CircuitPython itself. You'll probably get help faster there. 🙂
sorry thank you I will do it
desoler merci je vais le faire
I think everything is good now but cannot see why the last readthedocs task is failing on a warning. None of the warnings in the file match any changes I did. Was there a change to the doc building system between my branch and PR maybe?
thanks for keeping us up to date!
do we need to do this in 9.x too?
I think this is the warning you mean:
WARNING: Calling get_html_theme_path is deprecated. If you are calling it to define html_theme_path, you are safe to remove that code.
Yes, this is something that changed in the meantime, not due to your changes.
This warning should be resolved if you merge the Adafruit main branch into your PR branch, if you're comfortable doing that.
@onyx hinge to merge main into my PR is it just fetch adafruit/main and then merge adafruit/main? I have a less then stellar track record with not breaking my PRs with merges 🙂 If you don't have it off the top of your head don't worry I'll look into it more today.
If you're not comfortable with merging then probably just don't worry about it
It seems that RTD is unhappy with ubuntu-latest as the value for build.os in our readthedocs config file now.
Error
Config validation error in build.os. Expected one of (ubuntu-20.04, ubuntu-22.04, ubuntu-24.04, ubuntu-lts-latest), got type str (ubuntu-latest). Double check the type of the value. A string may be required (e.g. "3.10" instead of 3.10)
I assume it had worked in the past but it looks like they've changed to ubuntu-lts-latest I'm going to try it out on one and if it builds with no issues I could work on a patch for it this week. Though I think some of the libraries are still set to older hardcoded versions as well so it may take a few passes to get them all updated and back into alignment.
@lone axle do you think this is a recent change on their part?
I would guess that it's somewhat recent. our cookiecutter and newest libraries that I could find are using the value ubuntu-latest
Hmm a few months at least. I tried to search their changelog for related keywords. I didn't find the specific change that added "lts" but I did quickly find this PR from june where it looks like the lts was already in place at that time https://github.com/readthedocs/readthedocs.org/pull/11421/files
Welp another moment of poking into the git history and I'm fairly confused about how it was working in the past. It looks to me like the last change to the "latest" build version was 2/5/24 which appears to be when it was added as an option, however at that time it already seems to have the value ubuntu-lts-latest. So maybe ubuntu-latest never worked. I'm not sure how widespread that value is in our libraries. I've only checked a few but have seen mostly ubuntu-20.04.
<@&356864093652516868> here is the notes doc for today's meeting: https://docs.google.com/document/d/1UY8EJC4OuO3upz7Wcdu8zkrxFtqC0utJWgaZ2GLybkA/edit
We'll have our weekly meeting in about 2 hours 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 -- I look forward to everyone's updates!
Google Docs
CircuitPython Weekly Meeting for October 15, 2024 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...
I think it's most likely that the cookie cutter was updated erroneously to ubuntu-latest I made that change back in july, I assumed RTD version constants were the same as github actions one, but they differ in this case. Scanning the bundle it appears there are only a few libraries that have the incorrect value. The vast majority have ubuntu-20.04 so they could stand to be updated still.
do we need to do this in 9.x too?
I think it's not so likely we'll have another 9.1.x release. We are relatively close to 9.2.0.
Thanks for figuring this out!
Thank you! I'll override the failure since it is fixed on main.
@fleet hollow if you have cycles to help someone on the forum https://forums.adafruit.com/viewtopic.php?p=1032165#p1032165
maybe because all the libraries were updated
- Total Library Stats
- 1304306 PyPI downloads over 334 libraries
no that's what it says in the report
Ahh, yeah that could be. The actions install some of them I think.
there must be many mirrors
Thank you 👻
thanks liz!
Thanks Liz! Have a great week everyone
Thanks for hosting Liz, have a great week everyone!
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/1sFQK8Cn37B9dAOMinQ33eyYkPvlUz7M3em01pG8sxYI/edit
Google Docs
CircuitPython Weekly Meeting for October 21, 2024 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...
The first PR to add a basic echo effect was added to the core. Some of the effects mentioned here (EQ, pitch) are not in yet so I am not sure we want to close this issue. But if anyone is trying to add a new effect feel free to reach out to me on how I did it.
@tulip sleet have time later to figure out my next step for circuitmatter?
(after I get lunch)
sure
kk, will ping you when I'm ready
@tulip sleet I'm back now and free whenever
I tested this locally and the new board page looks good to me.
Thank you @CircuitART!
@tulip sleet https://github.com/adafruit/circuitmatter/issues
Thanks! I read them in my emails.
Error2 is
EALREADY, that is, pairing is already in progress.
I think this should have a more useful error message than "unknown system firmware error", if it's so easily triggerable.
@tannewt I plan to simplify and add a new version to the community bundle. I'm using the library myself to drive some DMX strip lights, and I have some lessons learned that I will incorporate, but will change the interface a bit thereby making it more compatible with the Adafruit animations.
@maxaitel if you haven't done it already, please create a folder called dmx_transmitter into your microcontoller's lib folder, and copy all the .py files from dmx_transmitter folder in the GitHub repo...
Driver code style question: For a device like this: https://www.adafruit.com/product/6062 with 3 channels that it can read from. I know generally we prefer properties for accessing data in the drivers. Would it be preferrable to have 3 properties (one for each channel), or to have 1 function which accepts the channel as an argument?
Generally we do one object per channel
each object looks like one sensor
Okay I think I see, so the final code will end up something like:
reading = ina.channel1.bus_voltage
ina.channel1.shunt_resistence = 0.1
other_reading = ina.channel2.shunt_voltage
I'd do channel[0] probably
or you can do ina[0]
both of those would allow you to iterate over the channels
Thanks @wtuemura and @andibing!
@aseanwatson Is it OK to take this out of draft state, or do you want to make further updates?
@dhalbert, ready to merge (as long as you're OK with it). Thanks.
Is RP2040-only library suitable for for bundle? Or do you have a fall-back like @Tasm-Devil's for others?
Some of my code:
import busio
import time
import digitalio
def delay_us(us):
w = time.monotonic_ns() + us * 1000
while time.monotonic_ns() < w:
pass
class DMXSerial:
def __init__(self, txpin):
self._start = bytearray(1)
self._txpin = txpin
def send(self, data):
with digitalio.DigitalInOut(self._txpin) as dio:
...
We want to control mouse and keyboard on tablets connected via USB to an ESP32 S3 Box (or similar).
adafruit_hid supports keyboard and relative mouse. As in another issue mentioned, sometimes the need arrises to move to absolute positions to know where the mouse really is.
Work-arounds, like moving relative to (-5000;-5000) all the way top left to get to a fixed point, some...
Non functional change: the field wifi.Network.authmode has a different type than currently documented.
Check out https://circuitpython-absolute-mouse.readthedocs.io/en/latest/ and see if it's useful for your needs.
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.1 on 2024-10-11; Raspberry Pi Pico W with rp2040
Code/REPL
#import helpers
#helpers.connect() connect to AP with wifi.radio.connect
import wifi
wifi.radio.dns
wifi.radio.dns = ('8.8.8.8',)
Behavior
>>> import helpers
>>> helpers.connect()
connecting to AP wlan-xxx ...
connected: False
Unbekannter Fehler 205
connected: True
>>> import wifi
>>> wifi.radio.dns
('10.1.2.1',...
The reason wifi.radio.dns is different is that it can support IPv6 addresses, and is even prepared to support multiple DNS servers when the underlying IP stack supports it as well. That said, it's clearly a bug when setting the property causes a crash.
It would be useful to know if setting the ipv4_dns property, which does have to be an IPV4Address, is also crashing; and it might serve as a workaround for you in your code.
Looks like maybe a conversion to "char *" is missing, and not caught by the compiler. If you're able to build circuitpython please try with:
diff --git a/ports/raspberrypi/common-hal/wifi/Radio.c b/ports/raspberrypi/common-hal/wifi/Radio.c
index 3250ed4d7c..b34a7670b8 100644
--- a/ports/raspberrypi/common-hal/wifi/Radio.c
+++ b/ports/raspberrypi/common-hal/wifi/Radio.c
@@ -574,7 +574,7 @@ void common_hal_wifi_radio_set_dns(wifi_radio_obj_t *self, mp_obj_t dns_addrs_ob
...
Thank you @mydana!
Is RP2040-only library suitable for for bundle?
RP2040-only is totally fine for the bundle. It'd be helpful to note the restriction in the README for it.
@slender iron I have a BLE MTU/NUS change I would like to bounce off you, when you have time.
now works for me
You can also test with an artifact from the actions on #9727 if you have time
@tulip sleet this may be a good overview of matter https://www.youtube.com/live/zn9wyo6woU8?si=mbs2N63W7yy08l9j&t=2214
tnx!
has anybody done any previous work on building gamma correction into displayio? I'm particularly interested in ST7789, but also generally interested in anything that goes from 24-bit rgb displayio.Palette colors to RGB565 using busdisplay.BusDisplay under the hood. I see lots of stuff in old guides about gamma correction for arduino with NeoPixels, but haven't found that much related to CircuitPython.
None that I know of. Probably something colorconverter can do