Apologies, I wasn't very clear. I was assuming the touchio API needs to stay consistent with the many existing guides (and, selfishly, the 100+ already-assembled PCBs I sell). Thus, to support pull-ups and pull-downs at run time, touchio would need an optional new argument to TouchIn() or a new class. This would make shared-module/touchio change, which would impact all implementations of touchio, not just RP2.
#circuitpython-dev
1 messages · Page 73 of 1
HI, I see the links are updated but there is no https://github.com/adafruit/tinyuf2/releases/download/0.20.1/tinyuf2-lolin_s3_pro-0.20.1.zip file (the s3 mini works correctly)
Adding Barduino PID's.
Barduino is a development board created by Fablab Barcelona as a tool for it's educational programs.
ESP32-S3 (ESP32-S3-WROOM-1)
It needs a custom PID to have the opportunity to show it officialy in the CircuitPython website and to create an Arduino core for it.
It's done under Fablab Barcelona, part of IAAC.
This is (will be because it's a WIP) the documentation for the board https://fablabbcn-projects.gitlab.io/electronics/barduino-docs/
and this is Fa...
Adding Barduino PID's.
Barduino is a development board created by Fablab Barcelona as a tool for it's educational programs.
ESP32-S3 (ESP32-S3-WROOM-1)
It needs a custom PID to have the opportunity to show it officialy in the CircuitPython website and to create an Arduino core for it.
It's done under Fablab Barcelona, part of IAAC.
This is (will be because it's a WIP) the documentation for the board https://fablabbcn-projects.gitlab.io/electronics/barduino-docs/
and this is Fa...
Hi - just some pins.c questions and requests.
[adafruit/circuitpython] New review comment on pull request #9603: Adding support for Barduino Board
Could you group aliases for a pin together, and put the preferred name first, with a blank line between groups. For example:
{ MP_ROM_QSTR(MP_QSTR_BUTTON), MP_ROM_PTR(&pin_GPIO0) },
{ MP_ROM_QSTR(MP_QSTR_IO0), MP_ROM_PTR(&pin_GPIO0) },
and remove BUTTON from the end of the list. This makes it easier to check to and to find the pin names.
[adafruit/circuitpython] New review comment on pull request #9603: Adding support for Barduino Board
You gave default names for I2C and SPI for these pins, but didn't define board.I2C() and board.SPI(), only board.UART(). Normally if you have default pins for these devices, they'd have a board attribute.
[adafruit/circuitpython] New review comment on pull request #9603: Adding support for Barduino Board
Hi! Yes, sorry, I've just upload te new version, hope it's ok like that
[adafruit/circuitpython] New review comment on pull request #9603: Adding support for Barduino Board
Done, I've also added I2C and SPI definitions, thank you!
[adafruit/circuitpython] New review comment on pull request #9603: Adding support for Barduino Board
It's a Phototransistor, I've added a comment also.
One more suggestion: PT -> LIGHT
[adafruit/circuitpython] New review comment on pull request #9603: Adding support for Barduino Board
The standard name on other boards for this is LIGHT, short for "light sensor"
{ MP_ROM_QSTR(MP_QSTR_LIGHT), MP_ROM_PTR(&pin_GPIO3) }, // PT = phototransistor
The RP2350 datasheet has been updated: the RP2350-E9 erratum has been rewritten and includes a lot more information. I'll study it to see what we need to do in DigitalInOut and TouchIn. No word yet on any workaround support in pico-sdk.
I don't see a lolin_s3_pro under the release assets at https://github.com/adafruit/tinyuf2/releases. Either the bootloader on that board is incorrect or it hasn't been added to tinyuf2. Is it possible it just uses the lolin_s3 bootloader?
I have flashed a "lolin s3 pro" from the "lolin s3" download page with the web installer. I got circuitpython working this way.
I am not sure what does the bootloader need to access, anyway the RGB LED is on gpio 38 in both boards.
I have flashed a "lolin s3 pro" from the "lolin s3" download page with the web installer. I got circuitpython working this way. I am not sure what does the bootloader need to access, anyway the RGB LED is on gpio 38 in both boards.
Ok, we should just point to that bootloader for now then. I'll create a PR to fix it.
Extend the bitfields of these instructions: BitmapHandle, ClearTag, Tag, BitmapSource, PaletteSource
Add instructions: BitmapSourceH PaletteSourceH
All the new bits and opcodes are ignored by earlier hardware, so this change is backwards-compatible.
Passes tests on all EVE hardware.
Fixes #1450. There is no lolin_s3_pro, but @marcobrianza has successfully used the lolin_s3 bootloader.
Is it possible to save some disk space by deleting unused ports in a local CP build?
In your boots i'd just make remove-all-submodules or whatever it's called (press tab to autofill) from the top of the repo, to clean all submodules and then fetch what's needed again later.
Also, maybe clean unused build_ folders.
Putting some ideas down both for others to critique and to organize my own thoughts:
This is basic code to play a note:
audio = audiobusio.I2SOut(...)
mixer = audiomixer.Mixer(voice_count=1, channel_count=1,...)
audio.play(mixer)
synth = synthio.Synthesizer(channel_count=1, sample_rate=44100)
mixer.voice[0].play(synth)
note = synthio.Note(261)
synth.play(note)
There are two potential ways to add effects. The first as tannewt suggested:
# ... similar to...
First, this is very cool!
I like the .addeffect() technique a bit more, for the reasons @gamblor21 mentions, but I'd rather have it add to Mixer instead of Synthesizer, so that other items played with the mixer can get the benefit of the effects. (Many physical mixers do this, having effects busses you feed channels into)
So that would I guess look like:
echo = audioeffects.EffectEcho(delay=50, decay=0.7) # define an echo effect
mixer.voice[0].play(synth)
mixer.addeffect(...
Apologies, I wasn't very clear. I was assuming the touchio API needs to stay consistent with the many existing guides (and, selfishly, the 100+ already-assembled PCBs I sell). Thus, to support pull-ups and pull-downs at run time, touchio would need an optional new argument to TouchIn() or a new class. This would make shared-module/touchio change, which would impact all implementations of touchio, not just RP2.
@todbot The plan I had in mind was to switch at compile-time, for RP2350 only, to supporting a weak pull-up rather than a weak pull-down. That would be documented, so any RP2350 hardware would need to use it that way. It would not be an option to switch at run-time between the two methods. I just was testing it on RP2040 to see if the idea worked.
We might support an informational TouchIn.pull_needed read-only parameter, which would return digitalio.DigitalInOut.Pull.DOWN, .UP, or `N...
Which board(s) of yours are affected by the RP2350 issue?
- https://github.com/todbot/picotouch
- https://github.com/todbot/picotouch_synth
- https://github.com/todbot/pico_test_synth
- https://github.com/todbot/picoslidertoy
- https://github.com/todbot/picotouch_drumcard
- https://github.com/todbot/picotouch_bizcard
- https://github.com/todbot/touchwheels
All of these I've sold, currently sell, or are planning to sell. As Raspberry Pi has advertised the Pico2 as a drop-in replac...
That's a lot of boards to respin. I don't see any way around it :frowning_face: if you want to support RP2350. I can make the software side easier for you, like .pull_needed, but the E9 issue is certainly a showstopper for a certain class of use cases.
If touchio behaves differently between RP2040 and RP2350, none of these PCBs can work for both cases. I sell these as kits, with all SMD parts soldered except for the Pico, to give people the option of installing one of the nice 16MB USB-C Pico clones. I'm updating product pages to let people know to not try a Pico2 on them, but I'm sure someone will try
let me know if you think of anything i could do to help out.
do you have recommendations on "getting started on bluetooth firmware troubleshooting" reading? i have experience writing C and have written simple firmware for stepper motors and sonar sensors. any pointers would be greatly appreciated.
Could you try 9.2.0-alpha.2351 for this board?
Fixed by #9579 and merged into main in #9580.
good news! it has yet to crash! thanks for the update!
more details
with this code:
from adafruit_ble import BLERadio
ble = BLERadio()
ble.name
i see this output:
code.py output:
CIRCUITPY2262ba
with this code:
from adafruit_ble import BLERadio
from adafruit_ble.advertising.standard import ProvideServicesAdvertisement
from adafruit_ble.services.nordic import UARTService
ble = BLERadio()
uart = UARTService()
advertisement = ProvideS...
CircuitPython version
Adafruit CircuitPython 9.1.3 on 2024-08-29; Adafruit Feather RP2040 with rp2040 Board ID:adafruit_feather_rp2040
Code/REPL
import time
import board
import neopixel
import microcontroller
pixel = neopixel.NeoPixel(board.NEOPIXEL, 1)
pixel.brightness = 0.3
print('reset reason: ' + str(microcontroller.cpu.reset_reason))
while True:
pixel.fill((255, 0, 0))
time.sleep(0.5)
pixel.fill((0, 255, 0))
time.slee...
From discord:
@ ozzloy: when i upload a directory via the web interface, i navigate away before the whole directory is done uploading. could the page do one of these popups instead? "18 of 20 files still need to be uploaded. are you sure you want to navigate away?"
@tannewt I had to make room on Feather M4 and Metro M4. I turned off aesio, but should we turn off something else instead? @jamesbowman Are these boards used with eve hardware?
@tannewt @jamesbowman I was able to remove microcontroller.pin.<somepin> for a few pins that were not connected on Feather M4 and Metro M4, and so left aesio alone. This is good for a short while. Probably eventually we'll need to turn off something larger.
Now that this builds for all boards we can merge it.
I tested with CircuitPython 9.1.3 but still got the same error.
Adafruit CircuitPython 9.1.3 on 2024-08-30; M5Stack CoreS3 with ESP32S3
import board
import espcamera
cam = espcamera.Camera(
data_pins=board.CAMERA_DATA,
external_clock_pin=board.CAMERA_XCLK,
pixel_clock_pin=board.CAMERA_PCLK,
vsync_pin=board.CAMERA_VSYNC,
href_pin=board.CAMERA_HREF,
pixel_format=espcamera.PixelFormat.JPEG,
frame_size=espcamera.FrameSize.SVGA,
i2c=board.I...
Thanks, Dan! And thanks for all your work here, it's a great project!
When will it be possible to download the firmware from the download page? What are the next steps?
When will it be possible to download the firmware from the download page? What are the next steps?
The builds are already in AWS: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/seeed_xiao_esp32_s3_sense/. When we make make another 9.2.0-alpha release, then the circuitpython.org page will get updated.
<@&356864093652516868> We'll have our weekly meeting in about 70 minutes from now in this text channel and in the circuitpython voice channel. Please take the time to add your notes in advance to the document: https://docs.google.com/document/d/13FWJDCzuchjYlYK_5Q_3zCgKl5-x6oX0YLFo-AkJMJM/edit -- I look forward to everyone's updates!
Google Docs
CircuitPython Weekly Meeting for MONTH DAY, YEAR 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 t...
This is an HTML/JavaScript task in these files: https://github.com/adafruit/circuitpython/tree/main/supervisor/shared/web_workflow/static
In directory.* I think.
BUILD2GETHER 2.0 - Mobility Challenge
I'd been in those actions weeds before
YAY!
🎉
Thanks Liz!
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/1OdykHdAWueM-8HIBMdyglJB5GbroRYyOEWehC3dNPhs/edit
Google Docs
CircuitPython Weekly Meeting for September 16, 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 unabl...
Anyone have any thoughts? Are dynamically changing effects a good idea? Would we want effects on a per channel basis in the synth?
I think it's important to think about how you'd remove an effect as well. I do think we want to change them dynamically.
I don't think we need them on a synth channel basis. Instead, you can have two synths.
I don't think we need them on a synth channel basis. Instead, you can have two synths.
So no audio effects for audiocore.WaveFile and audiocore.RawSample?
I don't think we need them on a synth channel basis. Instead, you can have two synths.
So no audio effects for
audiocore.WaveFileandaudiocore.RawSample?
That's not what I meant. I was responding to "Would we want effects on a per channel basis in the synth?".
I still think the best way is through separate intermediate objects that get played.
echo = audioeffects.EffectEcho(delay=50, decay=0.7) # define an echo effect
echo.play(synth)
# with echo
mixer.v...
Anyone have a windows 10 computer they can test this with?
Anyone know the parameters to use with the new API?
After playing around with the code all weekend the first way @tannewt suggested I think makes the most sense. Looking at how the Teensy audio library works it seems similar.
# give the synth and echo effect
echo = audioeffects.EffectEcho(delay=50, decay=0.7) # define an echo effect
echo.play(synth)
# give a wave file a chorus effect
wavesound = audiocore.WaveFile("wave.wav")
chorus = audioeffects.Chorus(voices=5)
chorus.play(wavesound)
# combine them in a mixer
mixer...
reverb = audioeffects.EffectReverb() reverb.play(mixer)
Normally mixer is fed into the actually audio player, providing the much-needed audio buffer to the whole system, so I'm not sure how the above would work. Is this a typo?
Would representing the signal chain in code, rather than as a data structure, create glitches when the chain is changed? Let me think through this with an example. e.g. let's set up a synth playing through chorus & reverb, then remo...
And update I2C timeouts to be tick agnostic
Could you say why you removed this? Thanks.
Is this new in 5.3.1, or does it fix some existing issue?
@slender iron micropython merge status: at least one board from each port compiles without error. Tomorrow I'll check the tests.
reverb = audioeffects.EffectReverb() reverb.play(mixer)Normally
mixeris fed into the actual audio player, providing the much-needed audio buffer to the whole system, so I'm not sure how the above would work. Is this a typo?
This was more an example of "you could do this", then any practical or good idea.
Would representing the signal chain in code, rather than as a data structure, create glitches when the chain is changed? Let me think through t...
I think 5.3 switched the default for USB_SERIAL_JTAG to true. I've been setting this manually for debug builds before.
I was seeing extra logging that this was failing. I think init/deinit code does this correctly.
Awesome! Good work
@dhalbert...
I'm not sure if I'm seeing this same bug. I don't believe my program is using ADC (yet).
I've been experiencing infrequent but repeated watchdog timer resets on my ESP32-S3 Reverse TFT board running CircuitPython 9.1.1. By infrequent, I mean my program typically runs for one or more days before a watchdog reset halts it.
Although my program initializes an ADC AnalogIn on board.A5, it never actually reads it (I will be using it eventually).
I am read...
I just noticed that in the previous comment I haven't posted the comera initialization code therefore it wasn't obvious where was the problem. The error is caused by the pixel_format parameter, GC0308 camera don't support the JPEG output. If you change the pixel_format to RGB565 it works:
import board
import espcamera
cam = espcamera.Camera(
data_pins=board.CAMERA_DATA,
external_clock_pin=board.CAMERA_XCLK,
pixel_clock_pin=board.CAMERA_PCLK,
vsync_p...
@steveputz A few comments:
- I seem to remember other reports of watchdog timeouts unrelated to ADC.
- If you remove the
AnalogInobject creation, does it make any difference? It might take days to find out. - We will have a 9.2.0-alpha.2352 release soon, which upgrades a few things, including ESP-IDF. That would be worth. trying.
Hi there,
Espressif release v1.5 variety of ESP32-S3-LCD-EV-Board with hardware revision.
more details here
+1 on @tannewt 's suggestion of running audio buffer sources through the effect and then to the final mixer object before the output. In a way, I think it is reminiscent of guitar pedals as to how you'd chain them together. Though I know the naming scheme we're playing around with isn't final, I think audioeffects.EffectReverb is somewhat redundant and should be more like audioeffects.Reverb. There could be some minor conflict issues when using from audioeffects import Reverb, but I fin...
@dhalbert ...
- After the previous restart, it has run for 22 hours without a reset, but that's not unusual.
- I just commented out the
AnalogInobject creation and restarted. - Are there any relevant changes between 9.1.1 and 9.1.3 suggesting I should upgrade to 9.1.3, or should I wait for CircuitPython 9.2?
- Any suggestions of what might be triggering the infrequent watchdog timeouts? I could artificially increase frequency of, something (e.g. WiFi operations, display updates, etc...
@steveputz When 9.1.3 came out because it has an updated ESP-IDF, I tested the ADC functionality but still crashed for me when reading ADC values. So might be best to wait for 9.2.0-alpha.2352 if it is going to include another ESP-IDF update. However I don't know of any good reason not to upgrade from 9.1.1 to 9.1.3. I tend to always install the latest stable version whenever I am working with a board and sometimes the latest development release when the mood strikes me. So far so good.
The changes between 9.1.1 and 9.1.3 are slight, and mostly unrelated to Espressif in general. However, it's always good to update, because that narrows the space of where to look for a problem. 9.1.0 did an ESP-IDF update. 9.1.1 and later did not and won't (not on a bug-fix point release).
I like the direction of this. I want to point out we probably want more specific module names instead of audioeffects. That way we can have more or less on different chips.
CircuitPython version
Adafruit CircuitPython 9.1.3 on 2024-08-29; Adafruit Feather RP2040 USB Host with rp2040
Code/REPL
import time
import usb_cdc
serial = usb_cdc.data
# serial.reset_input_buffer() # ensure a clean initial state during testing
while True:
in_waiting = serial.in_waiting
if in_waiting > 0:
print(f'time={time.time()} connected={serial.connected} in_waiting={in_waiting} data={serial.readline()}')
time.sleep(1)
``...
Thanks for the updates! Just a couple small things.
[adafruit/circuitpython] New review comment on pull request #9608: Add Espressif esp32s3 lcd ev v1.5
You shouldn't need any of this.
On Monday we discussed internally what to do about the E9 workaround for CircuitPython.
Without adding additional API specifically to support the RP2350, there is no way to inform CircuitPython in various use cases, "well, yes, this is a weak input signal, so do the workaround". The only hint would be if you enabled the internal pulldown, but there are other cases as well. We do not right now want to make a special-case API for the RP2350.
So our conclusion is to not implement the worka...
This is needed to fully support the .mov_status and .fifo directives, as well as checking for PIO version compatibility between program & runtime hardware.
In this merge, I did further CIRCUITPY-CHANGE annotations, to try to use that marker almost everywhere.
This was straightforward.
frozen/Adafuit_CircuitPython_asyncio right now is pointing to branch, not a release, in that library. https://github.com/adafruit/Adafruit_CircuitPython_asyncio/tree/v1.22-merge. I need to test the changes in the branch to make sure they work with 9.1.x before I make a library release.
USB doesn't currently work. TinyUSB changes need to be upstreamed.
Reference code is linked to (and discussed) in this issue: https://github.com/raspberrypi/pico-examples/issues/530
It seems to be going OK. And I did get my pico 2 boards over the weekend. Next up I think is going through all the modules and making sure they work, and doing ps2io for rp2.
Thanks for doing this! I really appreciate you joining the object allocations with setting their type.
Two small things. Otherwise it looks good!
I think you may be able to use a link syntax in terminals. https://github.com/Alhadis/OSC8-Adoption/
I added this test. I think we want to keep it.
@slender iron I"m confused by this doc build error locally (it doesn't prevent it from building successfully):
WARNING setuptools_scm.pyproject_reading toml section missing 'pyproject.toml does not contain a tool.setuptools_scm section'
Traceback (most recent call last):
File "/tmp/build-env-s1ph4e6s/lib/python3.12/site-packages/setuptools_scm/_integration/pyproject_reading.py", line 36, in read_pyproject
section = defn.get("tool", {})[tool_name]
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'setuptools_scm'
WARNING setuptools_scm.pyproject_reading toml section missing 'pyproject.toml does not contain a tool.setuptools_scm section'
Traceback (most recent call last):
File "/tmp/build-env-16py28oi/lib/python3.12/site-packages/setuptools_scm/_integration/pyproject_reading.py", line 36, in read_pyproject
section = defn.get("tool", {})[tool_name]
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'setuptools_scm'
ERROR setuptools_scm._file_finders.git listing git files failed - pretending there aren't any
the last ERROR I know is innocuous. But the first two are confusing, because there is a top-level tool.setuptools_scm section in ./pyproject.toml
me too, I thought you fixed that.
lemme try building docs in adafruit/circuitpython
ok, when I try to build in tip of main locally, I get the same thing! Maybe some requirements-doc.txt is out of date?!
i updated my python reqs, didn't fix, but it doesn't break the build. definitely :shrug"
I didn't include it just because it was longer. I can put it back.
I deleted all the tests/unix by accident. Restored!
I think
audioeffects.EffectReverbis somewhat redundant and should be more likeaudioeffects.Reverb. There could be some minor conflict issues when usingfrom audioeffects import Reverb, but I find that unlikely.
I actually had realized the same thing and in my proof-of-concept code changed it already.
Some of the effects that I'd potentially like to see:
...
For now I'm trying to get a base framework up, and willing to look at other effect but I'm not an expert so prob...
I like the direction of this. I want to point out we probably want more specific module names instead of
audioeffects. That way we can have more or less on different chips.
Would more modules be preferrable over having flags to turn on/off individual effects within one module? I would think we would still want some broad categories and not one module/one effect? New modules aren't hard so no real preference from me. Something that doesn't have to be decided this moment still at least.
For now I'm trying to get a base framework up, and willing to look at other effect but I'm not an expert so probably need some guide on what/how they work. But I like the ideas!
Once we have the framework set up, I'd love to contribute where needed.
I like the direction of this. I want to point out we probably want more specific module names instead of
audioeffects. That way we can have more or less on different chips.
Personally, I'd like to see it all compiled into one module...
Are these now moot never-resets due to something else?
Hi!
In this pull request, I would like to specify that this firmware is intended for the VIDI X V1.1 revision. Since new revisions of the board are expected in the future, I renamed the board and updated the MICROPY_HW_BOARD_NAME accordingly.
There is a corresponding PR in the circuitpython-org repo which updates the board_id to address this change and it also updates the description and images. After this PR gets merged, please merge that one:
Thank you!
Hi!
In this PR, I would like to change the description, images and resolve the board_id change from a corresponding PR which specifies that this firmware is for HW revision V1.1 of VIDI X board:
https://github.com/adafruit/circuitpython/pull/9613
Thank you!
CircuitPython version
Adafruit CircuitPython 9.2.0-alpha.2350-17-g422eb7eff2-dirty on 2024-08-18; Seeed Xiao ESP32-S3 Sense with ESP32S3
Code/REPL
import _bleio
# dummy address bytes here, but also happens with valid addresses
someAddress = _bleio.Address(b'\x00\x00\x00\x00\x00\x00', 2)
_bleio.adapter.connect(someAddress, timeout=10)
Behavior
Running the code immediately results in an error.
Traceback (most recent call last):
File "...
Please use vidi_x for the filename as before so it matches the board ID in CircuitPython (see https://github.com/adafruit/circuitpython/tree/main/ports/espressif/boards). Otherwise it will show up as 2 boards.
Hi, it should be ok now. Thank you!
If you are using the github cli (gh) on Linux, and you see a message about an expired key when trying to update, see this: https://github.com/cli/cli/issues/9569
Out of curiosity, what version of gdb do you guys use with the Python scripts under tools/ meant to be sourced by GDB? ARM GDB doesn't normally come with Python support. Do you guys build your own GDB to use with these or am I missing something? For example, I'm interested in messing with the cortex-m-fault-gdb.py script.
@wanton dirge I know that the last person who edited that file, @slender iron , has often used the version of the ARM toolchain available in Arch Linux
I think I successfully used the Ubuntu/Debian package gdb-multiarch when I ran into this problem, but what I was doing was simple.
Ran into an article from MemFault on this topic (like all good workdays): https://interrupt.memfault.com/blog/installing-gdb. I think I'll probably try installing the xPack they mention as an alternative to the binaries provided by ARM. They have a nice support table in this article which mentions the Python support is a bit better.
thanks - I have bookmarked that
The directory board name is still vidi_x. Do you want to include the revision in there too? Are you expecting incompatible changes as the board is revised?
@BlitzCityDIY do you mind testing this out 🙏 only if you have time (my laptop is win11)
Hi, I was instructed to use vidi_x for the circuitpython-org PR and that's why I reverted the name change here. If some breaking changes occur in the future, then the new board will have a HW revision in the name from the beginning, and this one will stay like this. Do you agree or have any other suggestions?
This is the PR I mentioned:
https://github.com/adafruit/circuitpython-org/pull/1471#pullrequestreview-2294831278
OK, we can leave the directory name alone for now. It's not critical.
Thanks for the quick work and thanks to @bwhitman also!
I think newer gdb does come with python by default.
The 13.3 toolchain does not as far as I can tell, specifically the one from here: https://developer.arm.com/Tools and Software/GNU Toolchain
Use new features from recent Arm Architecture and from open-source projects GCC, Binutils, glibc, Newlib, and GDB.
hrmmm. lemme look
I think there used to be a -python version too
(I use the arch built version though)
the linux version has a -py version
Personally, I'd like to see it all compiled into one module and then disabled on an individual effect basis. I feel that would provide more cohesion in the implementation, but I'd really like to see what you might have in mind, @tannewt .
I prefer separate modules because import errors normally happen early on startup. If you have optional portions of the module then you'll find its missing later.
It'd be ok if related effects are in the same module, especially if they share code unde...
I just saw your PR! great work! I'm traveling and my P4 is far away, but i'll be back with it next week and will boot it with your PR, thanks!
Thanks for getting it going! You did most of the work. TinyUSB has an open issue for support. Right now it is just UART
@wanton dirge I don't see a windows version with python
Ah okay, got it. I will pursue alternate solutions 😈
The xPack method I mentioned from the Memfault article above worked...there is a "-py3" gdb inside that xPack. Have to install Node.js / xpm as dependencies, but works for me.
great!
Switching to 10.0. We should make all implementations of bus locking ensure that it is unlocked before deinit. For now, DotStar does the right thing.
@willow totem can you retest https://github.com/adafruit/circuitpython/issues/9496 when you have a chance?
yeah sorry, kind of not using one arm at the moment so didn't want to lsat week, will get to it this week in theory
This works ok for me with the latest main. Can you reproduce it with an absolute newest build?
Sorry for spam, but leaving this tip here in case anyone in the future comes along...the gdb-multiarch package is a fairly simple solution for Windows as well. This comes with the TUI and Python so it's decently full-featured, and even detected the armv7e-m target architecture when I loaded my .elf. Can be installed in MSYS2 with pacman -S mingw-w64-x86_64-gdb-multiarch.
i just tested with absolute newest (Adafruit CircuitPython 9.2.0-alpha.2351-32-g28b593341c on 2024-09-11; Adafruit Feather ESP32-C6 4MB Flash No PSRAM with ESP32C6) and had the same safe mode error occur on https://code-beta.circuitpython.org/
In case anyone else runs into this, my current workaround is to write something back from the device (serial.write(b'ok\n')) after read, and make the sender wait until it receives the response:
python -c 'import serial; import time; ser = serial.Serial("/dev/ttyACM1"); ser.write(b"hi\n"); print(ser.readline()); ser.close();'
Oh Great and All Knowing CircuitPython guru's:
is there a way to stop a property being evaluated when I press tab in the repl on the parent class object.
The crickit sets up everything when the repl evaluates it, including a stepper motor on the motor pins when the stepper_motor property is evaluated, i.e. pressing tab on crickit object to see whats available. It has undesired consequences, but if there's not a solution that's okay.
I tried some lazy-loading-like shenanigans but failed to achieve the goal of have it (stepper_motor) not run when evaluating crickit's children, while still work as expected when assigned to a variable or directly evaluated to see it's children/used in the repl (rather than as a child property of crickit). https://github.com/adafruit/Adafruit_CircuitPython_Crickit/issues/39
@willow totem no, this is a limitation of micropython
@willow totem see e.g., https://github.com/micropython/micropython/issues/4546
tab completion is "a lot like dir()"
perfect, that answered my follow up question, thanks @onyx hinge
i tested with a qt py esp32-s3 running absolute newest and this seems to be fixed.
@slender iron fyi, I'm working on test failures: there's some async bug having to do with precompiled .mpy's vs in-RAM compilation. Also there are the weird failures here: https://github.com/adafruit/circuitpython/actions/runs/10801512411/job/29961849332?pr=9611, in "test native modules", which may be some problem introduced by the merge with native .mpy's -- I haven't diagnosed that yet.
I also have a list of contributions back to mpy I am working on for tonight
@tulip sleet I'm two esp bugs deep atm but can help look after
thanks, we can discuss when you're freed up
It takes fewer resources than the RP2040 version so it should be ok to have on by default.
Ok, this was an intentional change in the IDF: https://github.com/espressif/esp-idf/commit/8e3bc160bc7e31c59a48eb5d6d95ccf8aaff2612
CP 8 (IDF 4.4) is using REF_TICK to provide the clock for this. In IDF 5 this is no longer possible because of the commit. So, this is working as intended.
The BLE workflow is leaking data every reset. #9599 also crashes due to this.
Thanks for tracking it down. It's disappointing since for years we've been able to have low-frequency PWM. I use it especially when I have a blocking activity that won't let me manually toggle the LED regularly.
IDF 5.3.1 fixes this. I hope, I pray.
I have been running while True: adc.value for 15' now with wifi connected, it hasn't crashed.
The weird random 0 values are also gone, the adc values seem a lot more uniform.
Oh and I flashed the latest artifact on my watch, so it'll get uptime-tested.
Update: Left overnight.
This issue is resolved on the latest artifact.
IDF 5.3.1 fixes this. I hope, I pray.
Was that hope based on reading something in the release notes? The only explicit ADC thing mentioned is:
https://github.com/espressif/esp-idf/issues/14124.
Was that hope based on reading something in the release notes?
No, just on testing.
I retest everything i'm concerned about after idf / micropy updates.
The idf release notes are incredibly long.
I physically don't have the time to read them.
The wording "I hope" was chosen because of the bluetooth workaround, which patched it, till enabling bluetooth became conditional, making me feel uncertain as to if the issue is really gone.
Dan, I agree in that I went and searched the release document for the 5.3.1 version and a search for "ADC" did not turn up any mention of this specific issue. Since they didn't explicitly mention this problem nor a specific fix, I remain a bit skeptical that if it works now it might be more accidental and potentially something that could happen again on a later release.
Well, if it does appear again, we will at least be able to trace down which commit caused it.
So it's not all that bad, I guess.
The test case is simple:
import board, analogio, wifi
wifi.radio.connect(...)
adc = analogio.AnalogIn(board.Ax)
while True:
adc.value
So long as this passes and doesn't die within seconds or minutes we shouldn't have trouble with adc.
I assume this won't be rolled out until CircuitPython 9.2.0-alpha.2352 (with 2351 being the current one)?
I assume this won't be rolled out until CircuitPython 9.2.0-alpha.2352 (with 2351 being the current one)?
CircuitPython has CI/CD, you can download the latest artifact for your board from:
https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/
@eightycc or @tannewt I understand that you are very busy but is there any update on this or any way to help?
Also how come there isn't a branch or fork with the features being worked on?
Thanks very much for your work.
I've done a little digging through the CircuitPython source code and I suspect that it's a NimBLE error, in which case it would be an Invalid HCI Command Parameters error (0x212).
Nice job digging! Maybe we aren't flagging the address correctly internally. Want to see if you can fix it? We're happy to help guide. It's probably not a high priority for us to work on ourselves.
Ok, closing since it appears fixed. Feel free to request a reopen or make a new issue if it happens again.
I understand that you are very busy but is there any update on this or any way to help?
No update about Pico W from me. BLE is supported on ESPs now in CircuitPython too. You could start working on it yourself too but its probably better to wait for @eightycc to reply.
Also how come there isn't a branch or fork with the features being worked on?
It doesn't look like @eightycc has pushed their WIP code. It is up to them.
can the pico2 be programmed to allow access to memory only after a passcode is supplied?
no
Just as a data point: I had an old system with arm gcc 10 and it did NOT make a binary that worked on rp2350. this one does work: gcc version 12.2.1 20221205 (15:12.2.rel1-1)
@gilded cradle you around?
@slender iron the pico2 has 4MB of flash, right? do we want the FW space bigger than 1MB?
now's the best time to change it 🙂
(AFK)
It does! do we have builds with more space already?
@slender iron pico w is 1.5MB I think, it was a compromise to fit all the wireless & ssl stuff. it'd be nice to enable ssl on pico 2 so it can be used with wiznet ethernet. for instance. but also thinking of the future, it's 80% full or something.
Sure, I can give it a go!
I'll definitely need guidance though
Awesome! Have you gotten it building? There is a tutorial for building here: https://learn.adafruit.com/building-circuitpython
We can answer development questions on Discord in #circuitpython-dev.
@tulip sleet I think I'm out from under the ESP bugs if you want some extra eyes
I may have a fix for the async bug. I'll test that locally and then push it and see if it makes any difference to the other stuff. I'll ping you in a bit.
- Correctly free memory used by ESP
_bleio.Characteristicby addingdeinit(). - Correct
gc_alloc_possible()because it was true after the first VM run and caused BLE characteristic allocations outside the VM to occur on the VM heap. - Clear the serial RX buffer when receiving a CTRL-C. Without clearing it, you may skip straight to the REPL without the "press any key" prompt. The file transfer over serial stuff looks for the "press any key" line.
This enables picodvi by default on RP2350 boards and fixes #9615
good news! it has yet to crash! thanks for the update!
Looks like it is fixed in the alpha with the IDF and BLE updates. Closing.
Please retest with the absolute newest build.
Moved to 9.x.x because we need a clearer reproducer to debug.
I suspect #9344 broke this. The current implementation only works with the SD (BLE) is running. Fix coming shortly.
Fallback to setting GPREGRET without SD if it isn't active. This fixes resetting into UF2 when BLE isn't active. Fixes #9423
seems sensible, good to merge if you tested it too :)
Yup! Tested on Feather nRF52840.
@onyx hinge I've got two others PRs that need review if you have time
Looks good. floppyio should work on rp2350 and this build should test that.
Looks good. floppyio should work on rp2350 and this build should test that.
Yup, some had them on. I think it was an artifact from early builds.
@slender iron#9616 looks more detailed than I should just drive-by review... and it's time to make dinner
np
Lots of interrelated fixes. Thanks for the debugging!
Closing this because it hasn't been worked on ages and we're not sure when we'll get back to it. #3477 is still open to track the desire and links to this PR.
This will reduce clicks and pops.
#7618 did this but without our shared ramp code.
Closing in favor of issue #9620
@slender iron I fixed the async bug: I had rearranged some flags that I didn't realize were in the .mpy (so I can't change them now), and also made some other flags be in the wrong place. The native modules tests are broken, now in a different way: https://github.com/adafruit/circuitpython/actions/runs/10839445181/job/30080111626
I am going to take a break and eat. If you want to look at that, go ahead.
The windows build is failing because a build is too big (so that will be coming up when we build all the boards)
I can look tomorrow. Ari is here with me so I'm not doing much else. Will just merge the PR
Same issue as described above. Here is the error after it restarts into safe mode:
Adafruit CircuitPython 9.1.3-2-gfad755d5e7 on 2024-09-12; 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.
Please file an issue with your program at github.com/adafruit/circuitpython/issues.
Press reset to exit sa...
Wow! it works! Thanks CDarius for his great job!
The full example code works like a charm.
I've managed to get it building
https://github.com/espressif/esp32-camera/pull/677 which updates to the new I2C API, is now merged.
I would merge this but I think it's worth seeing which other similar boards still have ESP_CONSOLE_UART.
@slender iron I am getting somewhere looking at the last test failure, so don't bother to start independently yet.
mpy subversion was bumped from 2 to 3, which is only used to change the format for native .mpy. Studying that code more carefully, I may have made a mistake when trying to add back separate flag for async vs generator.
Going to punt on extending consider_instruction for now.
are these messages during doc building important? ```Unmapped Pins:
{ MP_ROM_QSTR(MP_QSTR_red), MP_ROM_PTR(&tft_r_pins) },
- makerfabs_tft7
- sunton_esp32_8048S070
- espressif_esp32s3_devkitc_1_n8r8_hacktablet
- adafruit_qualia_s3_rgb666
- espressif_esp32s3_lcd_ev
I suspect this means that some items won't show up correctly in a board specific stubs file
@slender iron I fixed some minor things, but I still haven't fixed the native x86_64 mpy-cross tests. However, I'm wondering whether to just turn them off for now and open an issue -- we don't enable that, and we don't do a very thorough testing job anyway. It's true that for anyone who actually did enable that, it's now broken.
right now this is blocking the merge and therefor 9.2.0
Turning it off is fine with me @tulip sleet
should I comment out the tests in run-tests.yml in the hope they would be restored, or just remove those lines
- name: Build native modules
if: matrix.test == 'all'
run: |
make -C examples/natmod/features1
make -C examples/natmod/features2
make -C examples/natmod/heapq
make -C examples/natmod/random
make -C examples/natmod/re
- name: Test native modules
if: matrix.test == 'all'
run: ./run-natmodtests.py extmod/{heapq*,random*,re*}.py
working-directory: tests
comment them out I think. so its easier for someone to come back and fix it
i'll make the removal its own commit
👍
As of #9611, the native code generation tests are failing, and are commented out in .github/workflow/run-tests.yml by https://github.com/adafruit/circuitpython/pull/9611/commits/2679916d5a60da21838568ec8d364fed27eafc27.
CircuitPython does not enable native code generation, but we have had latent support. There is some bug in the merge that is breaking the tests. In the interest of moving forward on 9.2.0, we're skipping fixing this for now.
Note that "native" in this case means machin...
There is a big difference in build size, like 1800 bytes for Feather M4, which is causing some build failures. I'll investigate that.
Thanks for the retest! It looks like you got the latest of the 9.1.x branch. Please try https://adafruit-circuit-python.s3.amazonaws.com/bin/unexpectedmaker_feathers3/en_US/adafruit-circuitpython-unexpectedmaker_feathers3-en_US-20240913-main-PR9619-64cb762.uf2 which is on the main branch and includes IDF updates.
do we want to do the esp-camera update for 9.2.0?
we need to do the I2C driver update everywhere, I assume. You said you had to branch that started that. So did I, but I think yours is further along.
could wait for a 9.2.x or 9.3, I guess
we can also wait to see if the i2c issues are fixed already or not
I will also be doing a PR to document RP2350 GPIO issue and turn off touchio
I turned off touchio already
in my picodvi pr
https://github.com/tannewt/circuitpython/commit/8a4ad54fe71b78011050f962f8a5eb7f37ffc6b5 is my i2c wip update
not sure I know what you mean: do you mean switching to new driver might fix existing issues?
not sure whta you mean by "wait to see"
right. but also the 5.3.1 update may have fixed them
oh, oh, i see
I am walking to the grocery store and will work on the merge size growth when I get back
Thanks for adding this support! Just a few minor things.
//| """Access the state machine's rxfifo directly
Please add parens or switch to if statements. Nested ternary is very hard for me to read.
Want to wrap this in the version test to save object size on rp2040?
//| the result of accessing it is undefined.
@slender iron I have been trying to figure out some way to use pioasm to cross check that we assemble to the same bits but I didn't figure out the right way to do it yet
It looks to me like in addition to the Hacktablet and Makerfabs TFT 7" boards, the Espressif ESP32S3_LCD_EV and possibly (I don't know if non-S3 boards are affected) the Lilygo twatch_2020_v3 may be affected by this issue. I don't have either of those devices to test with but I'm happy to update the PR to include the same changes for those two boards as well.
I would feel better about changing the boards I can't test if I had an idea why this change is necessary for 9.2.x and not 9.1.2.
@jacobcrigby It will take some digging and I don't know how long it will take to update your code for the deinit issue Dan mentioned, but if you're lost to other projects, I could pick this up and try and get a PR published.
Let me know :grin:
https://github.com/mydana/CircuitPython_DMX_Transmitter Would love feedback.
Why won't circup see your package?
dmx_transmitter is not a known CircuitPython library.
:(
I'm on a pico plus 2 running CircuitPython 9.
There is a big difference in build size, like 1800 bytes for Feather M4, which is causing some build failures. I'll investigate that.
Most of that was due to the new ulab.numpy.random, which I turned off everywhere, at least for now. Another 100 bytes or so was due to adding the e type code to struct, etc. This is a 16-float format that is in CPython. That 100 bytes pushed some almost-full boards over the edge. I will see what I can do.
There were upstream changes to how frozen .mpy's were stored, and the results are impressive. CPX has almost 900 more free bytes. That was so large I was worried something was wrong with the frozen code, but I can import and use the CPX frozen modules.
CircuitPython version
Adafruit CircuitPython 9.1.1 on 2024-07-23; Waveshare ESP32-S3-Zero with ESP32S3
Adafruit CircuitPython 9.1.3 on 2024-08-30; Waveshare ESP32-S3-Zero with ESP32S3
Adafruit CircuitPython 9.1.3 on 2024-08-30; ESP32-S3-DevKitM-1-N8 with ESP32S3
Code/REPL
import alarm, board, time
from digitalio import DigitalInOut
led = DigitalInOut(board.IO1)
led.switch_to_output()
led.value = 1
time.sleep(1)
led.value = 0
time_alarm = alar...
I know you can change the volume(gain) using the circuitpython mixer object. However, there are a few reasons that I think it should also be added to the audioio object:
- Better preformance. I've tried to make a mp3 player on the Adafruit Pygamer but adding a mixer slows it down too much so the audio sounds poppy and choppy. Changing volume is really just multiplying all the samples by the volume. So one float multiplication built into the audioio module will probably be faster than having...
CircuitPython version
Adafruit CircuitPython 9.1.2 on 2024-08-22; Waveshare ESP32-S3-Zero with ESP32S3
Code/REPL
from touchio import TouchIn
import board
import time
pins = []
pins.append(TouchIn(board.D13))
pins.append(TouchIn(board.D12))
pins.append(TouchIn(board.D11))
pins.append(TouchIn(board.D10))
pins.append(TouchIn(board.D9))
pins.append(TouchIn(board.D8))
pins.append(TouchIn(board.D7))
while True:
i = 0
for pin in pins:
...
After some tinkering I found a workaround: Calling .deinit() on the stuck pins causes them to reset to a working state, e.g.
led = DigitalInOut(board.IO1)
led.deinit()
led = DigitalInOut(board.IO1) #led works again
The reason for this issue seems to be that preserve_pin_number() calls gpio_hold_en() but the corresponding call to gpio_hold_dis() o...
resolves: #9606
There turned out to be two different cases to handle for this:
- When the user attempts to navigate to a different page by clicking a link to a file, or refreshing the page
- When the user clicks a directory which is a link containing a hash value instead of going to a different page which does not trigger the beforeunload event
For 1 the solution of adding the event listener for beforeunload event and then preventing the default behavior causes the alert to t...
Is it possible to add a display rotation property to
settings.toml(or whatever is used for setting WiFi credentials)? That way, if a particular board needs display rotation, we do not need multiple versions.
I suspect settings.toml is read prior to the execution of board.c (I'm not sure though). Even if it is, it's probably not worth adding the additional code (firmware space) to the core to carry a parameter forward to support screen rotation options.
That being said, it is possib...
The settings.toml is read every time you access a variable defined in it, so I think there should be no problem getting it in board.c. I have done a similar thing on my PewPew M4 boards that can use displays with different initialization requirements, but in their case the display parameter is stored in the UF2 bootloader: https://github.com/adafruit/circuitpython/blob/main/ports/atmel-samd/boards/pewpew_m4/board.c#L93-L95
CircuitPython version
Adafruit CircuitPython 9.1.3 on 2024-08-30; ESP32-S3-DevKitM-1-N8 with ESP32S3
and latest
Code/REPL
import alarm
import microcontroller as uc
uc.cpu.frequency = 240_000_000 # change
alarm.exit_and_deep_sleep_until_alarms()
Behavior
The title is my current guess about what is going on. I am currently debugging a custom board with a ESP32-S3-Mini-1-N8 (8MB flash) which does not want to enter deep sleep and instead draws ...
This is a possible solution to the screen variant problem that showed up after PR #9340 from @occasional-contributor was merged. There was some discussion regarding the issue in #9340 after it was closed.
This change will use a new settings.toml parameter (CIRCUITPY_DISP_ROTATION) to set the screen rotation. I kept it simple and did not perform any value validation, however if the parameter doesn't exist I defaulted back to the 0 degree rotation that was originally used. I think that makes...
I have been getting stock quotes using the matrix portal m4 hardware and using the code from MarioCruz/MatrixPortalStockTicker GitHub site. The code now gets ESP32 not responding error. Can some help determine why this is no longer working? I am using the latest circuit python libraries 9.x
What's the next step towards fixing it?
Stop multi posting. I've seen this message 3 places
My apologies . Sorry
[adafruit/circuitpython] Issue opened: #9628 Since pr #9490 picodvi doesn't work for the pico rp2040
CircuitPython version
All builds after (and including) the merge of pr #9490 (except any 9.1.X) don't work
Adafruit CircuitPython 9.2.0-alpha.2351-35-g64cb76213f on 2024-09-13; Pimoroni Pico dv Base with rp2040
Adafruit CircuitPython 9.1.0-20-g060018be7b on 2024-08-08; Raspberry Pi Pico with rp2040
Code/REPL
# For DVI Sock
import board
import picodvi
import displayio
import framebufferio
displayio.release_displays()
fb = picodvi.Framebuffer(320,...
In order to run the Demo program from the Adafruit DVI Sock learn guide the picodvi Framebuffer dimensions need to be changed from 320x240 to 640x480, however even with that change the larger framebuffer uses a lot more RAM so even with the additional resources of the Pico2 the demo won't run unless the color_depth is cut from 8 to 4.
If the RP2350 version of picodvi could support the older 320x240 resolution that would...
Currently, the RP2040 PIO support covers all the hardware configuration bits except the state machine
exec control for SIDE_PINDIR: this is defined in the hardware_structs header pio.h, for PIO_SMx_EXECCTRL : SIDE_PINDIR.
The bit next to it, SIDE_EN, is supported:
The line parsing in adafruit_pioasm.py only checks for 'opt', and not 'pindirs':
elif line.startswith(".side_set"):
sideset_count = int(line.split()[1], 0)
sideset_enable = "opt...
@tannewt all green now; #9621 is the known remaining issue here.
So at this point I have three questions:
-
If we are going with different modules is it worth doing a draft PR before those are decided? And second part does anyone have any opinions on groupings that make sense?
-
I believe getting a draft PR out so others can provide feedback may be valuable at this point. I have realized each effect will be standalone but likely follow a template (that all audio follows) so having one as a "standard" to follow would be helpful. That said there may ...
So at this point I have three questions:
1. [...] anyone have any opinions on groupings that make sense?
If the grouping desire is based on memory usage, then perhaps grouping names that imply "no buffer" vs. "small buffer" vs. "big buffer". e.g. "Compressor" would go in the "no buffer" group, "Chorus" in "small buffer" and "Reverb" in the "buffer" group.
Otherwise, maybe organize by user-facing effect type. Groups like:
- "Filters" (e.g. SVF, ladder, autowah, wavefold)
...
@onyx hinge @slender iron I was looking into something, and found out that some interesting C23 additions to the C language are in gcc 13. Various refs to this, but this is a nice but incomlete summary: https://lemire.me/blog/2024/01/21/c23-a-slightly-better-c/. Maybe you know this already.
#embed: like
const uint8_t image[] = {
#embed "image.png"
};
See https://gcc.gnu.org/onlinedocs/cpp/Binary-Resource-Inclusion.html.
constexpr, e.g.constexpr int LIMIT = 12 * 3. The expression (no function calls allowed) must be constant at compile time.int x; typeof(x) y;. Those are two declarations. That declaresyto be the same type (int) asx;static_assert(LIMIT == 36): causes a compile warning if false.
those are all nice features. Many had alternate ways to accomplish them such as enum { LIMIT = 12 * 3 }; (C99 compatible), MP_STATIC_ASSERT (C99 compatible macro). typeof() has long been a GCC extension.
#embed is a convenience. constexpr might have some interesting applications.
i went down this path due to thinking yet again about how to do cheaper compilation of translations. The things above don't really help, though.
If anyone ends up having a moment and can review https://github.com/circuitpython/CircuitPython_Library_Screenshot_Maker/pull/21 I'd be appreciative. There are some infrastructure bits updated to new versions that are necessary in order for actions to pass, and for pre-commit to run locally under newer OS environments.
I'm working on a few other fixes to the screenshot utility as well and will file seperate PRs for each of them, but the actions for the rest of them will be gated by this one with the version updates I believe.
Per a discussion with @bd34n, who runs https://www.bdmicro.com/, the VINA-D21 board is no longer supported and almost no boards are out in the world. Together we agreed the best thing is to remove it.
Making this draft for now because merging it before #9611 will cause merge conflicts. After this is merged I will remove it from circuitpython-org.
Howdy all and particularly <@&356864093652516868> -- This ping is a bit early, but in around 2 hours from now we'll have our weekly meeting in the CircuitPython voice channel and in this text channel. It's a great moment to add your notes to the shared document, like I'm about to do. If you want me to read your notes aloud just add a parenthetical like "(missing meeting)" or "(text only)" next to your name. Talk to you soon!
Is anyone able to usefully try the memorymap example for rp2040 that sets pin drive strength? On a pi pico (1) I find that get_pad_drive doesn't return the value I set a moment before. A modified set function does seem to work, so maybe the problem lies in the implementation of set_pad_drive ```py
if d not in range(4):
raise ValueError(f"invalid drive strength {d}")
pads_bank0 = memorymap.AddressRange(start=0x4001C000, length=0x4000)
pad_ctrl = int.from_bytes(pads_bank0[p4+4:p4+8], "little")
pad_ctrl &= ~0x30
pad_ctrl |= d << 4
pads_bank0[p4+4:p4+0x8] = pad_ctrl.to_bytes(4, "little")
(I was testing first on rp2350 which puts the registers at a different start= but that's a whole different thing)
aha figured it out -- the offset for "atomic xor register" is 0x1000 not 0x3000! pads_bank0[p*4+0x1004:p*4+0x1008] = pad_ctrl.to_bytes(4, "little")
trying to get a message to @turbid radish - noticed a minor typo - but we know what you mean - in today's Adafruit Daily "16 or 32 MHz of PSRAM"
https://www.adafruitdaily.com/2024/09/16/python-on-microcontrollers-newsletter-circuitpython-comes-to-the-esp32-p4-emulating-arm-on-risc-v-and-much-more-circuitpython-python-micropython-thepsf-raspberry_pi/
After this is merged I will remove it from circuitpython-org.
Maybe we should add a way to link to the last supported version instead of removing it completely. That could set us up for stopping support of more boards.
I think we can set this up to work. It is a good point that the demo should port over.
Thanks - I'll add the request this over there as well, linking back to here.
One typo I spotted. Good otherwise.
howdy folks! I've got to get a drink and then I'll get the meeting going -- please give me 5 minutes!
You'll need to sort out why the error is being returned and change the input parameters so it succeeds.
I was recently tasked with creating a tactile Augmentative Alternative Communication (AAC) device; a speech-generating communicator for someone who is largely nonverbal and has difficulty using touchscreens.
10 x 16 grid of snap-dome buttons covered with a sheet of icons, represent 160 pre-recorded phrases that play when their buttons are pres...
Behold the tactile AAC board: a 160-phrase, snap-dome button symphony for nonverbal communication! Foldable, spill-resistant, and CircuitPython-powered. Portable version with neck strap included. Speech tech meets absurdly practical design!
I'd write out DISPLAY so it's more readable. Other than that, I think this is a great solution. Thanks!
os_getenv_err_t result = common_hal_os_getenv_int("CIRCUITPY_DISPLAY_ROTATION", &rotation);
Yes, please, it's hard scouring the whole Internet for good stuff
Can you make a PR for Clue 3 please? That makes it easier to see changes.
Is the issue that ble_serial_connected is true when it shouldn't be?
Thanks for looking into this!
It's an IO/ADC expansion
I wasn't too far off
Can you make a PR for Clue 3 please?
Yes, will do tomorrow. But like I said, that was just a temporary change for debugging, by making CP never fake deep sleep, even when it thinks that a workflow is currently active.
Is the issue that ble_serial_connected is true when it shouldn't be?
Yes that's my current guess. If I'm not mistaken this means that deepsleep is currently broken on all 8MB esp boards (specifically: all boards that have BLE enabled)
beta release today @tulip sleet ?
sounds good! I'll start on the release notes
Thanks Jeff 😁
Thanks for hosting Jeff, have a great week everyone.
thanks all, have a good week. Thanks for hosting Jeff
@tulip sleet lemme look at jeff's PIO changes before you tag the release
sure. I have plenty to do beforehand
Or call
gpio_hold_dis()on all pins after wake?
I think the DigitalInOut constructor should call this. It is taking control back over from the hold. Want to make a PR for this? Thanks for testing!
I don't really think we want this. To do it, we'd need most of what mixer is doing (the extra buffer and multiply). I don't think the object creation is what slowing things down. I suspect it's the multiplying of all of the samples. We could probably make mixer work better in single voice mode that you could use after a multi-voice mixer.
@dhalbert did you mean to self-assign this?
is #9627 stuck on the "read the docs" check? nvm
- If we are going with different modules is it worth doing a draft PR before those are decided? And second part does anyone have any opinions on groupings that make sense?
Yup! A PR is a perfect place to discuss this. No need to decide beforehand. My main driver for separate modules is code size. Small amounts of code can fit before the larger ones.
- I believe getting a draft PR out so others can provide feedback may be valuable at this point. I have realized each effect will be st...
I tried resolving a suggestion using the github web interface for the first time and am worried I messed it up....
@dhalbert did you mean to self-assign this?
Yes, I discussed it with @BennettB123 in discord and plan to test this in more detail.
Main explanation is in digitalio. Briefer mentions in keypad and rp2pio, xref-ing to the digitalio writeup.
Also document that touchio is not available on RP2350.
@BlitzCityDIY See how this is for the guide, and whether you have any suggestions.
would you like to take a stab at adding it?
Sure: I found a workaround for this project, but would like to do so for upcoming designs.
I'm a github noob (lifelong member of the 'other' team (SVN) 😉 ) but will do my homework on how this works.
Will have something in a few days...
Thanks!
Joe Curren
Principal Development Engineer
Amphenol All Sensors Corporation
[cid:12e27e3c-fb1a-425e-90fd-bb6d96e33948] @.@.>
[cid:44032606-8be7-4323-931e-8b4b321b1081] (408) 225-4314 ext. 206
[cid:3fad2755-6...
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/1Kil0whAQDQslpSEEDm26UhSE6VEA6aKnUccQCe2IFbM/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for September 23, 2024 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you can’t make the meeting and w...
Why won't circup see your package? @mydana
I needs to be added to the community bundle for circup to see it: https://github.com/adafruit/CircuitPython_Community_Bundle/tree/main/libraries/helpers
Thank you! Please also make a PR to https://github.com/raspberrypi/usb-pid to publicly document the PIDs.
After using settings.toml to deal with the Sunton display board variants I thought the same technique might be used to deal with the Makerfabs MaTouch TFT 7" board which comes in two different screen resolutions (800x480 & 1024x600). Currently we were not initializing the display in board.c because of the variants so instead, the display needed to be initialized using python code.
This update will default to initializing the board at 800x480 (which results in a partially readable display o...
I've been testing #9634 using main (9.2.0-alpha.2351-39-g1e36e05380-dirty on 2024-09-16; MakerFabs-ESP32-S3-Parallel-TFT-With-Touch-7inch with ESP32S3) as a base and haven't been seeing the boot looping that this was supposed to address. I'm not sure why but I'll do some more testing to see if this has been fixed by something since I was seeing the issue.
Okay, I'm not seeing the issue anymore using Absolute Newest:
Adafruit CircuitPython 9.2.0-alpha.2351-37-g015a5cf922 on 2024-09-16; MakerFabs-ESP32-S3-Parallel-TFT-With-Touch-7inch with ESP32S3
Adafruit CircuitPython 9.2.0-alpha.2351-37-g015a5cf922 on 2024-09-16; ESP32-S3-DevKitC-1-N8R8-with-HACKTABLET with ESP32S3
The absolute newest (en_US-20240916-main-PR9625-015a5cf.uf2) from S3 doesn't have all the 9.2 Alpha changes back ported to it yet, does it? I may have closed 9583 too soon :sad:
main is a direct descendant of 9.2.0-alpha.2351. There isn't a branch for 9.2.x yet. It's 9.1.x that doesn't have the alpha changes.
it might still be good to remove that stuff from the sdkconfig. I'm not sure what use it has except for debugging purposes.
Okay cool, that makes sense 😁 I should be good then, #9569 doesn't seem to be happening any more...
Want me to reopen it?
yah sure
Looks good, and I'm sure you tested!
Ugh, rtd is breaking trying to pip install pycrypto, which looks like it might be due to pyusb (whose version has not changed)? https://readthedocs.org/projects/circuitpython/builds/25647116/
Otherwise, maybe organize by user-facing effect type. Groups like:
- "Filters" (e.g. SVF, ladder, autowah, wavefold)
- "Delays" (e.g. chorus, flanger, phaser, echo),
- "Dynamics" (e.g. compressor, limiter, bitcrush, overdrive)
- "Reverbs" (for lack of a better name, where all the big buffer stuff goes)
Those make sense to me so we could have:
audiofiltersaudiodelaysaudiodynamicsaudioreverbs(unless someone thinks of a better name)
Not that it isn...
Repeat of #9631, which went haywire in some way while getting rid of merge conflicts.
A few files had STATIC.
This does not fix the docs build problem.
The demo now works without modification using this artifact. Thanks!!!
Yes that's my current guess. If I'm not mistaken this means that deepsleep is currently broken on all 8MB esp boards (specifically: all boards that have BLE enabled)
There is #9464 that seems to address this.
Horrah for the (new?) way to update your CPY directly from the download page. How nice, thank you!
Automated website update for release 9.1.4 by Blinka.
@slender iron microdev merged a bunch of stuff last night. I think the rtd problem fixed itself, because those builds did not fail in doc. Is there anything else you want in beta.0? I have the release notes already.
as you see, I did a 9.1.4 for your recent 9.1.x PR's (thanks!)
lemme look
nothing I haven't PRed
I think its good to go. we can always do another as needed
Automated website update for release 9.2.0-beta.0 by Blinka.
New boards:
- barduino
- challenger_rp2350_bconnect
- challenger_rp2350_wifi6_ble5
- circuitart_zero_s3
- espressif_esp32p4_function_ev
- pimoroni_tinyfx
- seeed_xiao_esp32_s3_sense
- seeeduino_xiao_rp2350
- wk-50
Thanks! One question before merging.
Did you find that you need this? I think it should be covered by:
https://github.com/adafruit/circuitpython/blob/8969ddc8f5387fb397d2edb13aa8794fd151b5b9/ports/espressif/common-hal/microcontroller/Pin.c#L220-L224
@wanton dirge Are you getting close to PRing the max support?
Still working on adding some basic module support and then considering what additional HW to port on...would you prefer a "bare" PR that adds basic support and then separate PRs later for digitalio, busio, etc? In addition to more for separate boards?
I'd say depending on what you'd deem necessary for a base PR I would likely target e.o. next week timing-wise; I'm currently in Ireland for some tech training 🙂
I have a raspberry pi zero as my "desktop" with the pico w attached to the data usb port of the raspi zero. I have run "mkdir /media/CIRCUITPY" on the raspi zero. Can someone please give me the mount parameters in the format for /etc/fstab.
I currently use a line in fstab:
UUID=******** /media/CIRCUITPY vfat defaults,nosuid,nodev,nofail,sync,uid=1000,gid=1000,umask=027 0 0
I have been having problems with it mounting read-only too. I swapped the usb cable and re...
No, I was using the Hacktablet as a template and carried the block over. I'll drop it from the PR and I guess pull the block from the Hacktablet while I'm at it.
Thanks :grin:
Fun! I love Ireland.
Earlier is better.
digitalio would be good though
shouldn't be too hard
Yep, I'm actually almost done with that anyway.
great!
So I'll look at doing an initial PR for the MAX32690 with USB workflow, supervisor, and digitalio.
sounds good!
Do you have the APARD32690 board? That's what I initially targeted b/c it was handy, but I can target MAX32690EVKit for initial PR if that works better.
@garberw The automount that Ubuntu is doing for shows up as this:
/dev/sdb1 on /media/halbert/CIRCUITPY type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
Which board are you working with? We want to fix the read-only issue.
I don't think so. I'll let you know in the next hour what I have. (After I finish a meeting I'll look)
Name is actually AD-APARD32690-SL
https://blog.adafruit.com/2024/09/17/circuitpython-9-1-4-released/
Highlights of this release:
- On nRF boards, fix programmatic resetting directly into bootloader.
- Fix BLE storage leak.
- Clear input after ctrl-C on UART REPL boards. This fixes some USB workflow issues.
Can you make a PR for Clue 3 please?
Here is a PR to compare the changes: https://github.com/Sola85/circuitpython/pull/2. Removing ble_serial_connected() from supervisor_workflow_active() makes deep sleep work again (For course this is not a proper fix, just a debugging step).
I think the DigitalInOut constructor should call this.
I thought about this too but wasn't sure: Would it be only DigitalInOut, or every class that manages a pin? Like PWMOut, AnalogOut, I2C/SPI, ... Thats why I thought managing it centrally could maybe be easier
This does not happen if the USB filesystem is disabled from boot.py.
In other words, USB reconnects when just USB-CDC is enabled.
The old offset was for "atomic bitmask clear on write" not "atomic XOR on write".
I was investigating this because the example didn't seem to work on rp2350; the reason for that is the registers having a different memory layout, so I noted this too.
https://blog.adafruit.com/2024/09/17/circuitpython-9-2-0-beta-0-released/
Highlights of this release:
- On nRF boards, fix programmatic resetting directly into bootloader.
- Fix BLE storage leak.
- Clear input after ctrl-C on UART REPL boards. This fixes some USB workflow issues.
- Update to Espressif ESP-IDF V5.3.1.
- Merge MicroPython updates from v1.23.
- Raspberry Pi RP2350 additions, fixes, and documentation.
- Espressif BLE improvements.
- Add math.dist().
- _eve updates.
This sounds like it might be #9472. I am closing this in favor of that, but will add additional details as needed. Thanks!
I have the EVKIT and two feathers
@BlitzCityDIY Did you say that you are still seeing this? Not sure if it can be replicated reliably.
Should be fixed by #9616. Please reopen if you find otherwise.
@BennettB123 I tested this with an Adafruit Metro ESP32-S3, running CircuitPython 9.2.0-beta.0. I connected some ~4-inch jumpers with alligator clips at one end to D8 through D11. Touching two alligator cips with one hand and two with another produced raw values of 65535, as expected, but the loop was still running very quickly. I also tried clipping coins with the alligator clips, and that made no difference.
I am suspecting something about your setup, but I'm not sure what it is. We did ...
i just tested with 9.1.4 and could not recreate it on the s3 tft. previously i could when iterating on code so i think this is good to close
From https://github.com/adafruit/circuitpython/pull/9583#issuecomment-2354071837:
Adafruit CircuitPython 9.2.0-alpha.2351-37-g015a5cf922 on 2024-09-16; MakerFabs-ESP32-S3-Parallel-TFT-With-Touch-7inch with ESP32S3
Adafruit CircuitPython 9.2.0-alpha.2351-37-g015a5cf922 on 2024-09-16; ESP32-S3-DevKitC-1-N8R8-with-HACKTABLET with ESP32S3
We think this may be fixed in 9.1.4 and 9.2.0-beta.0. The reporter of #9472 was unable to reproduce with 9.1.4. Try again if you can with a newer version.
@RetiredWizard Could you make the same change on espressif_esp32s3_lcd_ev? That board also specifies GPIO43 and GPIO44. However, the LILYGO watch board uses special UART pins, so I'd be inclined to leave that alone.
I would have made the same change myself but you have disallowed upstream maintainers from pushing to your repo.
I retested on 9.2.0-beta.0, and could not reproduce this with the Qualia. I tried both with and without a settings.toml that connected to the local wifi.
While I'm at it, is circuitpy a good LWIP hostname for the espressif_esp32s3_lcd_ev board?
# LWIP
#
CONFIG_LWIP_LOCAL_HOSTNAME="circuitpy"
# end of LWIP
Maybe changing the hostname is a breaking change and I should just leave well enough alone.....
you could take that away, it's kind of non-standard compared with the other ESP32-S3 boards.
I'd just do what most of the other boards do.
They usually have a more board specific hostname defined
i'm looking... yup espressif-esp32s3-lcd-ev would be good, I think?
Foundation to add audio effects to CircuitPython as discussed in issue #8974.
This PR aims to create initial modules, some base effects and utilities to help create future effects. The ones included will serve as a template for future creations.
To do:
- [ ] Create modules for filters, delays, dynamics and reverbs
- [ ] Create 2 or 3 effects (echo, chorus and TBD open to suggestions)
- [ ] Test effects against audio sources that are not signed, 16-bit
- [ ] Add "mix" setting for how...
I retested the code in the first post with a seesaw board and 9.2.0-beta.0, which has ESP-IDF 5.3.1. I am still getting ETIMEDOUT. If I lower the frequency to 50000, it works, as above. bitbangio may also work.
I'll move this forward to 9.x.x since it may need the new I2C driver (and that may not help either!).
@dhalbert Thanks for testing! I went ahead and upgraded to 9.2.0-beta.0 to rule out differences there and I'm still getting the same behavior. One thing I may not have made clear is that the loop still runs very quickly when I'm touching several pins. However, the actual raw_values don't update every loop iteration like they do when no pins are touched.
If you touch 3 of your alligator clips and leave the 4th alone, do you notice any slowdowns in how often the raw_value of the 4th pin u...
Could you re-test with 9.2.0-beta.0? Thanks. I am not seeing an issue now. But I don't have an SSD1306 connected, just a seesaw board.
I have a raspberry pi zero wh (not zero 2 w) as "desktop" and a pico wh as microcontroller. it's not the pico2.
I tried the above mount option and it did not improve things even with a simple straight through cable with no hubs or anything inbetween;
Previously I tried using fsck on a different pico board of the same model. that showed a corrupted boot sector on CIRCUITPY;
I also tried flashing the "nuke" .uf2 to reset the board and reinstall circuitpython;
the problem sometimes happe...
@tulip sleet The "Allow edits and access to secrets by maintainers" checkbox is ticked off on my PR. Is that the setting you mentioned that was blocking you?
yes, hmmm. I've got a meeting now, sorry!
or maybe you have to mount it as type "-t msdos"
I just noticed that #9608 adds a new version 1.5 of the s3-lcd-ev board and in that PR Scott suggested along with all the lines this PR is removing from sdkconfig, the CONFIG_LWIP_LOCAL_HOSTNAME can be dropped as well.
Lots of boards have that configured, but I could go through and cut it from all the S3 boards as long as we're updating these three?
I used the mount options
UUID=4F17-3FFE /media/CIRCUITPY vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2 0 0
and after rebooting and reflashing circuitpy .uf2 it was mounted read write. I have not been able to crash it yet.
It may have something to do with the (wrong) mount options used when copying .mpy precompiled binaries to /media/C...
big hint
The original problem was that I installed raspbian in desktop mode but I switched to booting to console mode.
Unfortunately when I ssh in to raspbian on the zero it still tried to autostart pcmanfm when I plugged in the pico ...
but since the zero was headless (logged in over ssh) pcmanfm just hanged; so I turned off the autostart for pcmanfm;
Does the autostart for pcmanfm come from udev ????
the rapsi zero keeps telling me that e.g. after a reboot when I do `umount /medi...
the CONFIG_LWIP_LOCAL_HOSTNAME can be dropped as well.
That is OK too, there are plenty of boards without that. It doesn't serve a lot of purpose.
Okay, I'll put the removal of the LWIP hostnames from S3 boards in a new PR so it doesn't hold this one up.
Ah, I did misunderstand you about the loop timing. However, I am seeing quick response when touching three and then adding a fourth. I will try some more experiments tomorrow.
I'm still digging into the code, but my first instinct is to have the delay_ms property just be a float in seconds as delay instead (ie: rather than 500 ms use 0.5 s). The calculation that is being used to allocate the buffer uses floating point regardless.
Speaking of buffer sizes, it may be nice to explore having a fixed buffer size and altering the rate of playback of that buffer depending on the delay setting. This would be similar to a bucket-brigade style delay pedal and require ...
I'm creating a library (https://github.com/CDarius/CircuitPython_RaspberryPI_BuildHAT.git) for the community bundle but the the build.yml github action fails with this error:
Can anyone help me to understand how to fix it?
im not familiar with python's packaging/building tools, at all... but do you need all 3 of these?[build-system] requires = [ "setuptools", "wheel", "setuptools-scm", ]i see nothing like build.py or setup.py on your repo 🤔
also, if you look though the action's output, there are a lot of warnings before that final error, which also look like mis-configured or not-configured building tools
This is what you get when the pico is automounted on fedora:
/dev/sda1 on /media/CIRCUITPY type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
@spare jacinth The repo structure is created by cookiecutter https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/creating-a-library
that link does indeed mention a setup.py which you dont have
and im guessing setuptools uses (welp, tries to, on your repo) that file
I tested with an SSD1306 breakout. Interestingly, I have a very simple reproducer, on ESP32-S2 only:
d = adafruit_ssd1306.SSD1306_I2C(128, 32, board.STEMMA_I2C(), addr=0x3c)
produces:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "adafruit_ssd1306.py", line 262, in __init__
File "adafruit_ssd1306.py", line 103, in __init__
File "adafruit_ssd1306.py", line 160, in init_display
File "adafruit_ssd130...
@spare jacinth Check this repository https://github.com/CDarius/CircuitPython_M5Stack_PbHub.git. There isn't any setup.py and the action run successfully. Both repositories are created with cookiecutter, if it was necessary a setup.py it would have been there
no need to ping me with every reply
there isnt any other convo taking place, message wont get lost
yeah, folder structure looks the same 🤔
error said something about "raw on line 26", and you do have this: https://github.com/CDarius/CircuitPython_RaspberryPI_BuildHAT/blob/33b632f4c2839b051e8ada9e7d72ced38c65803c/README.rst?plain=1#L26
im going to guess that's invalid rST syntax (or at least disabled) and that's why the build fails: CI tries to put the formatted text into a section named "long_description" perhaps
though, with the formatting, it is not clear whether it is an error (line has same indentation as error) or a warning (what the text actually says) 🙃
Thanks, that was the problem. Now the action works
I'm trying to add the SDIOIO modules from https://github.com/jacobcrigby/circuitpython/tree/espressif-sdioio. I had them working a few months ago before the updates to the IDF. I've updated the obvious makefile bits for the updated IDF structure, but I'm missing something because the link is failing with "undefined references".
...bin/ld: build-makerfabs_tft7/common-hal/sdioio/SDCard.o:(.literal.common_hal_sdioio_sdcard_construct+0x18): undefined reference to `sdmmc_host_init'
that can happen if we're missing an IDF source file
I usually rg for the function name to find the file that defines it
it could be in an IDF module
grep -> ./ports/espressif/esp-idf/components/esp_driver_sdmmc/src/sdmmc_host.c:381:esp_err_t sdmmc_host_init(void)
It looks like the indicated routine is there, which is what me think it was a makefile issue and the build wasn't finding the src directory to compile from
CMakeLists.txt? I did add sdmmc, but maybe that's the old idf
okay same, I added sdmmc, I'll try esp_driver_sdmmc
ya, they renamed the driver stuff
Well that seems to have reduced the number of undefined references but it's still not finding all the references
I think DigitalInOut would be enough because that is what preserve_dios takes.
[adafruit/circuitpython] New review comment on pull request #9608: Add Espressif esp32s3 lcd ev v1.5
Sorry, I meant the file should be empty. The build fails with it missing.
Thanks for the initial PR! This is very exciting.
I suspect you'll want delay and decay to be BlockInputs so they can be varied.
//| def stop(self) -> None:
It's probably better to drop "the effect's" and "the mixer's" so we can share these messages.
Sucess!!! After some more grep'ing I noticed that there were needed files in both the original sdmmc and the new esp_driver_sdmmc folder so the Makefile needs both added to the components link 😁
@slender iron ESP32-S2 I2C is 80 times slower in 9.2.0! e.g. 1.25 kHz instead of 100 kHz. Well, I will investigate that! 9.1.4 is fine. ESP32-S3 in 9.2.0 is infe also
weird! a clock change?
maybe ... time.sleep(1) is fine
clock to the i2c peripheral maybe
i was having trouble with an apparently flaky Metro ESP32-S2, though, might be due to something like that. Another sample is ok
anyway I will check
nothing obvious in esp-idf issues
👍 I was wondering if we should swap the i2c impl in 9.2
maybe we just have a setting problem
maybe, but we should start with your branch. Depends on how fast you want to get 9.2.0 out
not many remaining issues
true. probably better to wait and get 9.2 out
though we probably want some MP change soak time
the ble sleep thing is probably an easy fix too
But DigitalInOut might not necessarily be the first object to take control of the pin after deepsleep.
Is there a particular reason why only some ESP32-S3 boards have _bleio module available?
Seems the Adafruit boards, only the ones without PSRAM has it
yes, flash space
Ah, so 8mb flash space only.. got it
As much as I'd like to see BlockInput on delay, it would cause a reallocation of the buffer on each update. I do think that would be a great feature for a fixed buffer delay.
void common_hal_audiodelays_echo_set_delay_ms(audiodelays_echo_obj_t *self, uint32_t delay_ms) {
self->delay_ms = delay_ms;
self->echo_buffer_len = self->sample_rate / 1000.0f * self->delay_ms * (self->channel_count * (self->bits_per_sample / 8));
self->echo_buffer = m_realloc(self->echo_buffer, ...
we are going to fix that in CircuitPython 10.0, but it requires new bootloaders and is also destructive to existing CIRCUITPY drives, because the flash partition scheme must change to make more room.
I have a circup question I hope can be answered quickly, maybe by @lone axle. I have a couple of libraries in the bundle that were created with adafruit/cookiecutter-adafruit-circuitpython and now when I do circup update if I have those libraries installed I get errors like this:
% circup update
Found device at /Volumes/CIRCUITPY, running CircuitPython 9.1.1.
A newer version of CircuitPython (9.1.4) is available.
Get it here: https://circuitpython.org/board/raspberry_pi_pico
Found 2 module[s] needing update.
Please indicate which module[s] you wish to update:
WARNING: Library tmidi repo has incorrect __version__
metadata. Circup will assume it needs updating.
Please file an issue in the library repo.
https://github.com/todbot/CircuitPython_TMIDI.git
'tmidi' is a Major Version update and may contain breaking changes. Do you want to update? [y/N]: y
Updated tmidi
WARNING: Library noise repo has incorrect __version__
metadata. Circup will assume it needs updating.
Please file an issue in the library repo.
https://github.com/todbot/CircuitPython_Noise.git
'noise' is a Major Version update and may contain breaking changes. Do you want to update? [y/N]:
Nothing has changed in these libraries. What is circup wanting from my version string? These version strings came from cookiecutter.
I looked at this with a Saleae. On ESP32-S2, the I2C bus frequency is only 1.25 kHz (!), even though I requested 100 kHz. This is apparently due to some bug in ESP-IDF v5.3.1 (used in CircuitPython 9.2.0), which switched things around under the covers for the legacy I2C driver. It's fine in ESP-IDF v5.2.2, which is used in CircuitPython 9.1.4.
I reproduced the problem with an ESP-IDF-supplied example and opened an ESP-IDF issue:
https://github.com/espressif/esp-idf/issues/14603
We want...
I'm getting ready to submit a PR that includes some message changes to circuitpython.pot. pre-commit suggested running "make translate" and "git commit locale/circuitpython.pot". I ran the first but the commit looked like it was going to submit a PR with just the messages changes? Is that what I want to do, or is there something I should be doing differently to include circuitpython.pot changes with a PR?
the circuitpython.pot changes should be in addition to your previous commits
you are not editing circuitpython.pot by hand, right? It's generated by scanning the rest of the sources
did you git add your other changes yet?
hmm, no I edited by hand 😆
Everything is still local, I haven't pushed anything yet. I'll back the .pot changes out.
they will usually be in MP_ERROR_TEXT(...)
Answering my own question maybe: It seems that circup has the concept of module.device_version (what's in the mpy) and module.bundle_version (the string that's from the github releases version). In my case, device_version is "1.0.1" and bundle_version is "v1.0.1". This seems new. but I can push a new release that has updated release tags I guess
I did update the strings in the source, I just thought they needed to be changed in both places
nope, that's exactly what make translate does for you
Am I correct in remembering that there was a flash size advantage to reusing existing messages in the circuitpython.pot file or was that a different set of messages somewhere?
If you can reuse a message then the string only gets stored once versus two different messages both need to be stored.
aka: string intering
i would love to understand how (if) that works for printf-style strings, which need to be something FANCY_MACRO("hello %d") in the source code
(opposed to simpler ones that get written like QSTR_hello_world which i guess is simply an enum's item at the end of the day)
I do think that circup expects a "plain" semantic version string with specifically 3 numbers seperated by two periods and nothing else (so the leading 'v' would throw it off I think.)
The other "gotcha" that I am aware of is that the versions are only embedded within "released" library artifacts in the bundles. So if you clone a repo and then simply copy/paste the code to your device you'll end up with a copy that is version 0.0.0 and circup will always update it because presumably it will always find a release newer than that. For that reason I actually don't tend to use the update command within circup that much because I often have modified versions of the libraries on my devices that are from a PR or some other local development work and I don't want them all to be overwritten by real published versions.
This closes #8498
@jacobcrigby created this update (Thanks so much!!!) to support sdioio for ESP32S3 and I think they planned on submitting it as a PR, however with the recent updates to the IDF I wanted to get this code integrated before the refactoring got more difficult.
Dan had mentioned that updates from #9418 would probably be needed which I've gone ahead and done. The symptoms from #9417 appear to have been resolved with those updates.
I noticed some messages in circuitpython...
I was just scrolling through the changes and was wondering if I should enclose all the ESP_LOGx statements withing if DEBUG compiler conditionals?
it does work for %-formatting. The %whatever are literally stored in the string and are substituted at run-time. One of the codes is %q, which is the internal interned string ("qstr") representation in CPy. We use that to substitute different arg names, etc.
yeah, i get that... i didn't mean the "get string, format based on its content" part, but what #define FANCY_MACRO(str) ... does under the hood to not repeat str several times over memory
perhaps it just gets replaced by a comptime script, using regex or the like 🤔
there is a lot of preprocessing of the source that happens to extract the strings. But we don't compiled altered source. The MACRO actually turns into a huge if (or case?) statement that the compiler turns back into a constant.
because all the values of the if-arms are known at compile time (only one is true)
cool and interesting, thx for the info
CircuitPython version
9.1.4
Code/REPL
import adafruit_datetime
print(adafruit_datetime.datetime.fromisoformat("2024-09-18T19:33:00Z"))
Behavior
A ValueError is raised with message "Invalid isoformat string: '2024-09-18T19:33:00Z'"
Description
ISO 8601 says:
"If the time is in UTC, add a Z directly after the time without a space. Z is th...
I'm still digging into the code, but my first instinct is to have the
delay_msproperty just be a float in seconds asdelayinstead (ie: rather than 500 ms use 0.5 s). The calculation that is being used to allocate the buffer uses floating point regardless.
I'm not too worried at this point as I'm using Echo basically to test out ideas/concepts. Is there a reason you would want time in a float of seconds vs more precise?
Same thought on the BlockInput for the buffer size. You ...
Agreed. Fixed delay is fine. A future refinement could also specify a "max_delay" that does the alloc and "delay" lets you move within that range.
Thank you @dhalbert for wrangling this issue.
I updated to 9.2.0-beta.0 and retried my code with original h/w (QTPY-ESP32-S2, adafruit_ssd1306, adafruit_seesaw (rotaryio, #4991)
Result: Now fails even when I don't do a i2c.scan() -- this succeeded with v9.1.1
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
main.py output:
sys.implementation=(name='circuitpython', version=(9, 2, 0, ''), _machine='Adafruit QT Py ESP32S2 with ESP32S2', _mpy=7...
Oh this looks interesting!!! My new storage shield has 4bit wide eMMC data on non-default IO, and folks have only been able to use it in Arduino and IDF but with this folks should be able to use CP as well!
Wicked!
thanks all. running 9.2.0-beta.0, but cancelling the running example and calling microcontroller.reset caused the tfts3boot drive to show (still running tinyuf2 0.18.2 bootloader).
Updating bootloader to 0.20.1 allows the microcontroller.reset to reliably work fine and show the circuitpy drive.
it seems to be mounting rw (read-write) now consistently; do not know how long this will last; only changes were
(1) update; full-upgrade;
(2) apt --reinstall install mount
(3) pipx install mpremote (I think this installs micropython also !!!!)
something fixed it; hopefully that will help you;
In general, is there a straightforward-ish way to check some web page to determine which release version of tinyusb is included in a given release of CircuitPython?
I tried looking in 9.2.0 beta release notes and on github, but I guess I didn't look in the right spot? I'm wondering if the new tinyusb 0.17.0 release will end up in CircuitPython 9.2.0. Going by the 0.17.0 release notes, I think the changes for MAX3421E support may unlock a bunch of new USB wireless gamepad adapter stuff that I failed to get working previously. So, I'm really looking forward to 0.17.0
Check out the repository at the given commit/tag, and see what the submodule(s) commit/tag is?
And you wouldnt even need to really use git clone/checkout which may take a long time, but a bit of scrapping on github
Yeah, I tried that, but that just gives me a commit hash. It's kinda hard to get from the submodule commit hash back to a release version. Like, it's possible, if you search through all the commits, but I'm hoping there's some easier way?
This is what I found on github: https://github.com/adafruit/circuitpython/tree/main/lib
this is what I found on that page:
If you click on the link to jump to the submodule's repo on github, maybe it shows some better versioning?
Yeah, that does get me to the commit, but my git/github skills are not sufficiently advanced to easily get from that commit back to its nearest ancestor commit that happens to be a release. Like, I could do it manually if I spent the time. I'm really just asking about whether I've overlooked some obvious place the version info is already recorded.
thanks for your time!
If you go into the submodule, lib/tinyusb, then type git describe --tags, you'll get a tag that shows the last tag plus a suffix. E.g., right now, for me, it's
(.py) halbert@cod:~/repos/circuitpython/lib/tinyusb$ git describe --tags
0.16.0-1083-g4349e99f
you could also just do git --log in the submodule and look for the most recent tag.
note that we are at a commit past the last release tag
awesome! thank you!
[adafruit/circuitpython] New review comment on pull request #9608: Add Espressif esp32s3 lcd ev v1.5
Thank you, I am a newbie for build the Circuitpython.
@slender iron well, given that updating the I2C driver fixes https://github.com/adafruit/circuitpython/issues/9561 and esp32-camera is now updated to the new driver, maybe I should work on that after all, since we have to do it sooner or later. You pointed me to https://github.com/tannewt/circuitpython/commit/8a4ad54fe71b78011050f962f8a5eb7f37ffc6b5. Do you remember the state of that (was it untested, etc.)?
Looks good but shouldn't it be enabled by default for all S3 boards?
@slender iron https://github.com/tannewt/circuitpython/tree/idf5.2_i2c looks pretty complete, should it just be a PR for you to submit, or should I cherry-pick or merge from it into my own PR branch
Bumps google-protobuf from 4.26.1 to 4.27.5.
Commits
See full diff in compare view
Dependabot will resolve an...
@tulip sleet it is untested because I got it compiling but then it errored on startup. there is a runtime check that the two i2c apis aren't used together
I imagine you want to cherry pick it and test
i'll do that, and I will update esp32-camera, which maybe is the only use of the old API at that point
@tiny peak looks like we're 30 commits behind 0.17.0 https://github.com/hathach/tinyusb/compare/4349e99...0.17.0 generally we don't wait for a release because we drive development of new things and fixes
I believe so. yup
[adafruit/circuitpython] New review comment on pull request #9608: Add Espressif esp32s3 lcd ev v1.5
This is breaking the CI. Have you built and tested this locally?
I was just scrolling through the changes and was wondering if I should enclose all the ESP_LOGx statements withing if DEBUG compiler conditionals?
ESP_LOG does this automatically.
There is probably a message we can reuse here too.
Do you want to track both slots so you can use two cards?
Thanks for adding this! I'm excited to try it out. I've added a number of suggestions to look into.
Move all of these pin claims after the inits below that can throw errors. That way pins can be reused if the init fails.
I think you could adjust your initial allocation to be larger if given a non-fixed value. That way you don't need to re-allocate when the value changes. You just don't use all of the buffer for short delays.
I also think it's good to show how to use BlockInput so that further effects use it too. It is more complicated, but it'd be good to show how to use. It is super powerful IMO.
But
DigitalInOutmight not necessarily be the first object to take control of the pin after deepsleep.
Ya, that's true. I wonder if we should detect that a pin is held and then make a DigitalInOut available for it. Then you would need to deinit it to use it for something else. Otherwise we have to decide when to un-hold the pin.
Makes sense, I'll start working on an update...
Looks good but shouldn't it be enabled by default for all S3 boards?
Thanks, sounds right to me, I didn't look too long at the mpconfigport settings. The PR currently sets CIRCUITPY_SDIOIO to 0 (using ?=) for all Espressif chips and then hard disables it for the following chips:
esp32c2, esp32c6, esp32h2, esp32p4, esp32s2
It's currently left overridable on esp32, esp32c3, esp32s3.
It looks to me like the SDMMC_HOST peripheral is supported on the esp32, esp32s3 and esp32p4, so I'...
I looked briefly but not carefully, I'll look again :grin:
@slender iron have you tried PSRAM on the Feather 2350? I ran across my adafru.it/4677 64mbit psram
and wondering whether to try soldering it on
Yup! It should work. there are likely bugs around it though (probably DMA related)
I should see it in gc.mem_free if it works right?
Looking at the code, it looks to me like the slot is determined by the command and clock pins. there also appears to be data pin requirements depending on which slot is being used. I haven't dug through the Espressif documents to verify but if you think that's more restrictive than the peripheral requires (which the comment does suggest) I can try and figure that out.
I believe, currently both slots could be used by selecting the associated gpio pins for each slot?
8264480
>>> d = digitalio.DigitalInOut(board.NEOPIXEL)
>>> t0 = time.monotonic_ns(); neopixel_write.neopixel_write(d, a); t1 = time.monotonic_ns()
>>> dt = t1-t0
>>> dt / 1e9
10.4861
You can DMA a megabyte to a hypothetical 349,525 1/3 pixel RGB strand, it only takes 10 seconds.
>>> neopixel_write.neopixel_write(d, m)
```DMA'ing a isngle pixel seems to work, even though it's living in PSRAM!
oooh this is exciting
@candid sun what pins were you using on pico 2 or feather 2350 for i2s out?
I found this in a learn example, I'll try it audio = audiobusio.I2SOut(board.GP0, board.GP1, board.GP2)
@onyx hinge just getting back from a walk, let me check the fritzing in the feather guide
I got it working with those settings, thanks!
just had one of the pins backwards in the physical wiring, as usual
cool! yeah i2s always takes me a few tries
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0-2-g2d30b672fa-dirty on 2024-09-18; Raspberry Pi Pico 2 with rp2350a
Code/REPL
# SPDX-FileCopyrightText: 2021 Kattni Rembor for Adafruit Industries
#
# SPDX-License-Identifier: MIT
"""
CircuitPython I2S MP3 playback example.
Plays a single MP3 once.
"""
import board
import audiomp3
import audiobusio
audio = audiobusio.I2SOut(board.GP0, board.GP1, board.GP2)
mp3 = audiomp3.MP3Decoder(o...
@onyx hinge there is a separate streaming endpoint for the psram that'd optimize it
it goes around the cache so it doesn't trash it
@slender iron Question about add16signed and mult16signed in Mixer.c. I get they let you work on both halves of a 32 bit value. Was this mostly because Mixer wouldn't care if the two 16 bit values were left/right stereo or mono/mono samples?
Asking because I'm thinking for the effects it may make more sense to work 16 bit sample by sample (though need logic to deal with # of channels) because then like synth does values may exceed 16 bits and be brought back into that range.
I'm not sure I added that (and understand it.)
Jeff may be a better person to ask
No problem, saw the copyright date. Looking at the history that stuff existed 5+ years ago.
And someone named "gamblor21" added the non-M4 support and must have forgot what he did 😂
You probably found an answer for this, but for RP2350 any I2S pins I’ve used for RP2040 worked. Most recent for me on RP2350 was GP20,21,22 : https://gist.github.com/todbot/7dc50b8de8db03638a9a291e9132b488
I think that 32 bit code was there when the code landed in my hands but I'm not sure
I don't know fancy arm asm instructions
Thanks for the thoughts. I'm now 90% sure it was to take advantage of the M4 when core speeds were too slow to do it even in C without a FPU.
Thanks for the reply! That helps me plan my timeline for future projects. Once 0.17.0 eventually makes its way into a CircuitPython release, I have a USB wireless gamepad adapter that I want to see if I can get working. It's a little tricker than hardwired USB because it sometimes sends USB NAKs. According to the 0.17.0 release notes, that may be supported by tinyusb now.
I've added the code to track the slot usage but ended up defaulting to slot 1 because using slot 0 isn't working. I've spent a lot of time staring at the code and tweaking little things but so far I'm stumped. The code still seems to mount an SD card fine using slot 1.
Thank you! My RP2040 based Adafruit Macropad was also failing/crashing on Windows 11 when Samsung Magician is installed. Temporarily uinstalled so I can update to newer CircuitPython with this fix. Cheers!
@tannewt started a branch with an update to the new ESP-IDF driver for I2C: https://github.com/tannewt/circuitpython/tree/idf5.2_i2c. I'm continuing with that on main. Got it working on ESP32-S3 just fine. On ESP32-S2 the clock speed is now correct, but I'm getting errors and crashes which I'm debugging.
[adafruit/circuitpython] New review comment on pull request #9608: Add Espressif esp32s3 lcd ev v1.5
Not yet.
I update macro name as commit 4a5624a by @dhalbert.
Testing this with the new ESP-IDF I2C driver in conjunction with testing #9561.
Add a new board built around NXP MIMXRT1011DAE5A: Makerdiary iMX RT1011 Nano Kit.
It seems that there are a few different variations of bad actors opening issues on open source repos that have comments containing malicious links. Some claim to have found security vulnerability in the repo, and others try to mimic a message from Github staff. I'm sure they've got other tricky varieties of messages as well. These issues are created in order to send out the email that goes to maintainers in the hopes they'll follow the link in the message. Here is one article discussing this tactic https://www.bleepingcomputer.com/news/security/clever-github-scanner-campaign-abusing-repos-to-push-malware/
I thought it was worth mentioning here so everyone is aware and warn to be wary of any links that come via Github issues, PRs or comments.
This issue of spontaneously-incrementing mDNS hostnames (e.g., "blahblah-4") appears to be back in CP 9. CP 8.2.10 seems fine. @donutcat spotted it, and there's been discussion on Discord last evening and prior in #help-with-circuitpython.
Adafruit CircuitPython 9.1.4 on 2024-09-17; Adafruit QT Py ESP32-S3 4MB Flash 2MB PSRAM with ESP32S3
No code.py file.
settings.toml:
CIRCUITPY_WIFI_SSID="Redacted"
CIRCUITPY_WIFI_PASSWORD="Redacted"
CIRCUITPY_WEB_API_PASSWORD="pass...
Feel free to make a PR updating it. It should be a smooth update
RP2350 feathers are in stock: https://www.adafruit.com/product/6000
there si no way to use a dvi display in portrait mode with picoDVI lib.
The lib support only 320*240 in 8b colordepth or 640*480 in 2b
If we try by inverting size, we received error
Traceback (appels les plus récents en dernier) : Fichier "", ligne xx, dans ValueError: height invalide
to use in portrait mode, it could be like this
# Adjusted framebuffer dimensions for portrait mode
fb = picodvi....
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0-8-g340cc6328c on 2024-09-20; ESP32-P4-Function-EV with ESP32P4
Code/REPL
import board, sdioio
sd = sdioio.SDCard(clock=board.IO43,command=board.IO44,data=[board.IO39],frequency=20000000)
Behavior
Traceback (most recent call last):
File "", line 1, in
OSError: SDIO Init Error 107
Description
This is the same message that occurs when "slot 0" is used as the default slot...
@dhalbert
broken again. I did
apt --reinstall install mount pix install mpremote
then it worked fine as reported in the previous post. Was tested quite a bit. Stayed mounted but had other stability problems.
then installed blinka and it failed immediately. There's something in blinka that fouled it up.
The problem that the CIRCUITPY disk on the pico keeps mounting read-only ... I fixed it myself. run fsck -CVlr /dev/sda1 as follows:
`root@weathervt ####-> fsck -CVlr /dev/sda1
fsck from util-linux 2.38.1
[/usr/sbin/fsck.vfat (1) -- /media/CIRCUITPY] fsck.vfat /dev/sda1
Locking disk by /run/fsck/sda.lock ... succeeded.
fsck.fat 4.2 (2021-01-31)
There is no label in boot sector, but there is volume label 'CIRCUITPY' stored in root directory
- Copy volume label from root directory ...
If this happens again, could you run fsck -VN just to report with what fsck thinks is wrong? I am thinking that the drive is being dismounted when it is an inconsistent state or the dirty bit is set. The latter should not make it be read-only, but there may be some defaults on your system that are causing this. I am not sure that blinka has anything to do with this. The volume label manipulation you mentioned above may also have corrected some other issue as a side-effect.
I will do so...
On ESP32-S2 the clock speed is now correct, but I'm getting errors and crashes which I'm debugging.
I've fixed these crashes. Should have a PR after I convert espcamera.
[adafruit/circuitpython] New comment on issue #9648: ESP32-P4 SDIOIO: Unable to create sdioio object
I wired up an external SDIO breakout and was able to mount the card using both SDIO and SPI interfaces so SDIOIO is working on the ESP32-P4 and I apparently either have an incorrect pin selection for the built-in SD card, or a hardware issue with my board.
(env) root@weathervt ####>> fsck -VN /dev/sda1 fsck from util-linux 2.38.1 [/usr/sbin/fsck.vfat (1) -- /media/CIRCUITPY] fsck.vfat /dev/sda1 (env) root@weathervt ####>>
This time my "solution" did not work. Also did fsck -CVlr and did not work.
If this keeps up I can not use the pico as it (or something) is too unstable. Works better if it is plugged into a fedora machine. Mounts read-write more often.
9.1.x same behavior. Crashes when connected device disconnects.
Adafruit CircuitPython 9.2.0-alpha.2351-35-g64cb76213f on 2024-09-13; 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.
Please file an issue with your program at github.com/adafruit/circuitpython/issues.
Press reset to exit safe mode.
...
Do you have a regular x64 desktop as well? If so do you see the same kind of behavior? And do you have a second RP2040 board of some kind? If so does it also act up in the same way? I'm just trying to narrow the problem down. How about if you run regular Raspberry Pi OS on the Pico W?
is it possible to add picovga to bundle
or picovga from codaris, to use picovga as a display with framebuffer
as there is picoDVI in circuitpython.
Raspberry give hardware design to use vga with circuitpython
it could be (as picoDVI)
displayio.release_displays()
fb = picovga.Framebuffer(320, 240,
vga_b0=board.GP0, vga_b1=board.GP1,
vga_g0=board.GP2, vga_g1=board.GP3,
vga_g2=board.GP4, vga...
For lilygo_tembed_esp32s3 in display init sequence added command INVON and changed MADCTL from BRG to RGB
@titimoby these changes are in conflict with what you submitted in your pull request #7658. I'm assuming you tested. Has the board changed? @bytiful are you using a genuine LILYGO board or a clone?
I have two computers
(1) x86 running fedora
(2) raspberry pi zero W (not raspberry pi zero 2W) running raspberry pi os most recent version
And one microcontroller
(3) raspberry pi pico running whatever it came with plus circuit python .uf2
You can't run raspberry pi os on the pico w as it is not a computer just a microcontroller.
What I want is for the pico to plug into the zero over usb and mount the pico CIRCUITPY on the zero using fstab on the zero or anyhow reliable and controll...
Sorry, I mean Pi Zero W, of course. Too many boards with "Pi" and "W" in their names. I will test on a Pi W and maybe some other Pi's.
From a quick glance -- this should be fairly straightforward to implement, given that the web workflow is all implemented in straight C (i.e. there is no "web server" framework, it's all directly implemented). The only complication is probably PROPFIND -- DAV PROPFIND works with XML documents, including proper namespace definitions and such, meaning that at least a very lightweight XML namespace aware xml parser would need to be present. Something like yxml...
Update for anyone following along:
- Mix has been added
- Mix/Delay/Decay are all BlockInput now. Unlike most synth uses these values have max/min values that have to be checked during the buffer computation time to ensure they are within the acceptable range.
- You can set the max delay and then alter the delay without memory reallocations.
- After looking at what I modeled the first code after in Mixer, I think re-writing it to be clearer (and more like synth) still has the performance....
see update it is a pico WH with wireless and a zero with wireless
The zero power supply is 1.5 Amps on usb at 5 V and the whole system uses only 350 mA max at 5 V which is distributed in a complicated way.
It seems to me very unusual that Pi Zero W shuts down sometimes when you plug in the Pico W.
If you disconnect everything from your unusual power supply but the Pi Zero W does it happen?
If you use a more conventional wall wart power supply (say 1A or 2A), does that happen?
If you swap out the Pi Zero W for another Pi Zero W, does it also happen?
These are all things I would try in an effort to isolate the problem.
Espressif is playing around on the ESP32-P4 with support for UHS-1 SD cards that use 1.8v signal voltages. Currently they have a couple of recommendations on how to deal with the new voltage. One option is to just design the hardware with your intended voltage feeding the SD_VSS pin. A second option is to utilize some [LDO power supply features](https://docs.esp...
The answer is no to all of those questions. I suspect those are in fact due to my complicated power supply (solar weather station)
But I have a clue about the mounting read-only problem.
At one point I thought the pico had crashed but it was just stuck in the repl after a crash. When I learned how to use the program "screen" I could differentiate between these crashes and real lockups.
There is another problem "real lockups" where what I think is going on is you are disconnected from...
I'm assuming you tested.
Yes, I compiled the changes and uploaded them to my board.
I do not know if I have a clone or a real board, but it looks like the image "Pin Diagram"on the official website
Changes:
- Added additional information about the possible need to hold BOOT button while programming.
- Added info about touch and display driver ICs as these can be difficult to find on product pages for this board.
With a board sourced from Banggood, I found that I had to hold down the BOOT button while programming. I also added information on the display driver and touch driver ICs used as this information can be difficult to find on seller's websites.
I think this additional info...
Glad to hear you have diagnosed it. Here are some ideas about how to make things more robust.
- Wrap the entire program in a try-except that catches all exceptions. This could be something like:
try:
do_everything()
except Exception:
# do a reset, etc.
You can put the main program in do_everything(). That makes the code a little neater. However, if you have a lot of globals, this might force you to restructure the program, so the alternative is just to wrap the...
Thank you for your attention :-) sorry if I was panicked. wires everywhere !!!!
I am continuing this here
https://forums.adafruit.com/viewtopic.php?t=213700
Why do you need an extra buffer to multiply all the samples?
@lone axle could you take a look at the community bundle build failure? https://github.com/adafruit/CircuitPython_Community_Bundle/actions thanks!
it was right after a new library was merge in
Yep, I'll take a look
In this case I think the newly added libraries are a red herring. It seems a recent commit in one of the previously added libraries causes circuitpython-build-tool to fail https://github.com/adafruit/CircuitPython_Community_Bundle/actions/runs/10969895769/job/30463140170#step:8:42
I think the root cause is a recent commit to https://github.com/buildwithpiper/circuitpython-piper-make-library which made a change in one of it's root files. Build-tool doesn't support multiple root files for a library. They must be either in a single file, or refactored into a python package folder.
However there is still a bit of a mystery involved as well. I don't see any clear reason why it just started failing now. The second root file was added ~7 months back it appears to me, and somehow didn't cause any issue at that time. But a few days ago there was a change made in the original root rile (not the newer one) and that leading to the build failing.
I'll open an issue on that repo see if the owner is willing to refactor to a package.
if you don't get an answer rather quickly I'd say remove or pin the library. Learndev said the broken bundle broke bundlefly bundle generation in general. But they put in a fix which should just ignore broken bundles
In the medium / longer term it might be nice to update build-tool to be more forgiving of failed builds even if just for the community bundle. If it could make note of the failure for a particular library but continue on and build the rest of the bundle successfully I think that would be ideal.
that sounds like a good idea! could note this in an issue if it isn't already
<@&356864093652516868> The weekly meeting is set to take place here on Discord in just over an hour at 2pm US eastern / 11am US pacific. The notes doc is pinned #circuitpython-dev as usual for you to add your hug reports and status updates. We look forward to hearing from you!
@EthanPal Please make a pull request with the changes.
You don't. That's my mistake. I still think this is better done as an optimization on Mixer though.
Thank you @wtuemura and @andibing
You could write a Python level driver that uses memorymap: https://docs.circuitpython.org/en/latest/shared-bindings/memorymap/index.html
Adafruit Industries - Makers, hackers, artists, designers and engineers!
Check it out on: code.circuitpython.org With Adafruit’s Circuit Python code editor, you can edit code from a web browser. This lets you connect via WiFi, Bluetooth or USB. The editor features AutoC…
thank you!
Have a great week everyone!
@lone axle I fixed the link to the Pico VS Code extension, the Github repo didn't exist, so I linked it to the Raspberry Pi blog
Oh good catch, Thank you
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/1dEv4L6a7rlbu6jaDnt3s0uKD_SMrFeFtmVQAP0wDE5U/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for September 30, 2024 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you can’t make the meeting and w...
I think a python driver would be better, since we could have it frozen and the user could override the version if needed.
I'll look into it once I get a P4 if it's not done till then.
This was probably better suited to #help-with-circuitpython. Moving there.
I'll take a look at memorymap but at first glance, figuring out how to interface the LDO via memory manipulations would take me deeper into the IDF than I ever expected to go :grin:
The issue is sort of board related as it depends on how the chip is wired up to an SD card slot (or other SDIO peripheral) so maybe before deep diving the IDF, I'll see if I can create an object in board/board.c, maybe board.LDOn, similar to how board.DISPLAY is created.
Well after a quick look at the board/board.c thought I had, I realized that's not really any different than my original suggestion to create a core device/library. I'll spend a bit of time poking at the memorymap option but may come back around to a core module eventually, unless @bill88t get's to it first.
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0-9-gcda19477e4 on 2024-09-23; Raspberry Pi Pico with rp2040
(head)
Code/REPL
import audiobusio
import audiomp3
import board
audio = audiobusio.I2SOut(board.GP0, board.GP1, board.GP2)
mp3 = audiomp3.MP3Decoder(open('test-truncated.mp3', 'rb'))
print('\n\nplaying')
audio.play(mp3)
while audio.playing:
pass
print('done')
Behavior
It never finishes playing (i.e., it doesn't print...
I have been spending a lot of time deep-diving into the audio code lately and I'm not sure if moving it from Mixer to anywhere else will see much of a speedup. As is the Mixer code basically only does what you describe, multiple each sample by a value. I'm not even sure there is room for much optimization in there.
The other issue is the audioio code is port specific so would have to be done for each port.
I do not have a PyGamer so cannot easily try it out unfortunately.
In the IDF the LDO code is here:
https://github.com/espressif/esp-idf/blob/master/components/esp_hw_support/ldo/esp_ldo_regulator.c
and
https://github.com/espressif/esp-idf/blob/46acfdce969f03c02b001fe4d24fa9e98f6adc5e/components/hal/esp32p4/include/hal/ldo_ll.h
and
https://github.com/espressif/esp-idf/blob/master/components/soc/esp32p4/include/soc/pmu_struct.h#L857
and
https://github.com/espressif/esp-idf/blob/46acfdce969f03c02b001fe4d24fa9e98f6adc5e/components/soc/esp32p4/include/so...
This makes sense, thanks.
at elf, there's data underflow that does need to be treated as a true failure rather than something that might be recoverable. These recoverable underflow cases were added to improve streaming recovery when the network didn't deliver data in time.
haha "at EOF", thanks autocorrect & writing while in the car
This just adds information regarding the board variant options that can be adjusted in settings.toml for the Sunton ESP32_243S028 and Makerfabs_tft7 boards.
I need to grab a screencap of it from my scope, but now I understand why the official workaround for RP2350-E9 is not useful for making touchio work.
Relative to the pull down current (I think I was using a 3.3M resistor to GND), the amount of current injected when the input buffer is active is substantial. touchio wants to poll the pin as frequently as possible, but activating the input pad for just long enough to read the pin value injects a substantial amount of current, and the voltage STILL settles at around that +2.2v even if I enforce a minimum of 10us with the output buffer disabled.
For this particular resistor and inherent capacitance, a 50us delay with the input buffer off makes touchio "kinda work", but there's no value that would "work for sure" because it's highly dependent on the RC constant of the particular setup.
Assuming adafruit/circuitpython-org#1479 is appropriate and approved, this adds a note to the list of documented CircuitPython settings.toml keys indicating that there may be additional board specific keys and that information may be found on circuitpython.org/downloads.
This turns out to be needed by the testsuite of jepler_udecimal, which needs to add the jepler_udecimal directory both to PYTHONPATH and MICROPYPATH.
Thanks! In the original issue you mentioned that you also wanted to revise the photo. Are you planning to do this in a separate PR? If not, we can merge this as-is.
Update to the latest image.
Yes, my colleague has submitted a new request #1481 to modify the photos.
[adafruit/circuitpython] Pull request opened: #9656 Remove CONFIG_LWIP_LOCAL_HOSTNAME from S3 boards
As discussed in #9583 this removes the CONFIG_LWIP_LOCAL_HOSTNAME parameter from the sdkconfig files of all ESP32-S3 boards.
I actually just commented out the configuration setting but can easily update this to completely remove the lines if that is preferred.
For completeness: I checked an S2 board with an empty sdkconfig file, and it looks like boards without CONFIG_LWIP_LOCAL_HOSTNAME defined will have the hostname espressif, unless changed in user code (wifi.radio.hostname). The hostname shows up in the router via DHCP, and may be used by some other protocols.
What happens if you try to work around the E9 erratum via the input pad enable bit. With this particular resistance & capacitance, the ~120ns the IO pad spends enabled is almost able to recharge as much as the resistor discharged over 20us.
120ns is 18 clocks @ 150MHz so while it could maybe be a bit shorter it is already pretty short & enforcing an arbitrary minimum delay after reading any pin is pretty terrible. However short the input buffer on time & however long the forced IO delay, some R,C values would still be problematic...
that said, with this hack touchio kinda works in this one particular circumstance, it reads ~60 no-touch & 100 to 600 with touch.
[but very noisy]
I found that using a pull-up for touch works reliably, but we decided not to do that. I think it is not worth trying to get this to work right now. We'll just recommend external touch breakouts.
@tulip sleet I agree, it's not worth it to try to get touchio-with-pulldowns to work right now. Until performing this experiment for myself I didn't yet understand WHY the workaround wasn't useful for touchio.
[I consider myself a person with typical color vision but boy I had a hard time deciding if the multiplier band on this resistor was green or blue]
i have red insensitivity and I measure every resistor. I also keep them carefully sorted.
the friend I visited this weekend keeps his resistors sorted & bagged. I don't have so much discipline.
I have a digikey resistor assortment i bought about 40 years ago, and I also have a parts drawer thing. Most of the resistors in that are on strips with tape
I took a VLSI course in grad school but could not tell what was going on with the overhead slides. I had to choose extremely different colored pencils. I gave up doing a design project and did a software project instead
I submitted this not really knowing as much as I should have about core Circuitpython WiFi. It seems to me if the variable is used somewhere that is visible via Circuitpython we should probably leave it alone.
Feel free to re-open if there's a reason to pursue this.
I made these changes using a script so it would be relatively painless, if for some reason we wanted to expand to other chips or make a different change to the files/default values.
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0 on 2024-09-17; Adafruit QT Py ESP32-S3 no psram with ESP32S3
Code/REPL
import os
import ssl
import time
import wifi
import socketpool
import adafruit_requests
from adafruit_io.adafruit_io import IO_HTTP
wifi.radio.connect(os.getenv("CIRCUITPY_WIFI_SSID"), os.getenv("CIRCUITPY_WIFI_PASSWORD"))
pool = socketpool.SocketPool(wifi.radio)
requests = adafruit_requests.Session(pool, ssl.create_def...
I didn't mean to shut this down, only highlight what the new hostname would be. We haven't been consistent with having CONFIG_LWIP_LOCAL_HOSTNAME or not, or how to name it. I don't know if there's a use case to rely on an expected default where the old expectation wouldn't be met... I'd be a little surprised.
I'll take a look at
memorymapbut at first glance, figuring out how to interface the LDO via memory manipulations would take me deeper into the IDF than I ever expected to go 😁
Ya true! If you want to wrap the IDF then you can add another ESP-specific module (like espulp). I don't think we want to abstract it for all ports yet.
Please document the board specific keys here too. Having a central place will make them easy to find and use for other boards that need it.
I do want to get rid of these settings so that our IDF builds are more uniform across boards. I think we should set it to the board id by default though. That's basically what folks use this setting for anyway.
Perhaps we should unify this with the MDNS name too. It could be cpy-board_name-MAC.
The line of text with an extra space was erroneously inside the code block just above it
There was some discussion here about the QT-Py ESP32C3 and it's antenna (similar sized). Lowering the tx-power solved the connections issues there too.
The gaierror is something I have also seen on other S3 boards. This is I think related to name resolution (DNS). It is nothing I see during productive operation, but sometimes during development with multiple restarts, e.g. due to crashes.
The asterisk character in the screen resolution and interface listing gets interpreted as a formatting instruction messing up the output. This replaces the '*' with an 'x'.
Thanks. There may be a way to escape the * characters but this is a fine solution.
Any pointers as to where the initialization should take place. It looks like common_hal_wifi_init happens when wifi is imported which sounds too late to me.
This PR adds a background_read method to rp2pio.StateMachine to complement the existing background_write.
Added draft background_read method: https://github.com/adafruit/circuitpython/pull/9659. Seems to work with TAC5 codec, needs more testing.
I would think common_hal_wifi_init is fine. There is no wifi access point or wifi network access possible until that time, and user code can't access the hostname without importing wifi. It should happen before web workflow or auto-connect start up., but that's enforced I think by web workflow calling common_hal_wifi_init.
Thanks for this, I'm excited!
I did have some review comments & requested changes. I also didn't actually test the code. Any suggestion on something that would be useful to try/test if I don't have a TAC5xxx codec?
Please document that the pending property is a deprecated alias for pending_write and will be removed in a future version of CircuitPython.
Please use the MP_PROPERTY_GETTER macro here, even though it wasn't used in the code whose style you were emultaing elsewhere in this file. We should tidy away the direct uses of const mp_obj_property_t that have not previously been done, like the other ones in this file.
Can you please combine the fill_buf_info_{read,write} routines? I notice you've added detection of mismatched stride between the "once" and "loop" variants, which should probably apply to write as well. I think you'd just have to add the access type parameter and pass MP_BUFFER_{READ,WRITE} in.
Or is there a reason the new checking you added should not also have been done for the background write case?
I wouldn't personally have changed the parameter and local variables names but this is OK.
Word to the wise... 44.1Khz dual channel audio with asyncio without enough sleep in a loop causes weird stuttering that you will try to debug all night long, and turns out just add a small delay to the sleep loop and you are good. Maybe a sign a 0 asyncio.sleep isn't running audio tasks fully?
But it did prompt me to add double buffering in.
We prefer MP_PROPERTY_GETTER and MP_PROPERTY_GETSET, as these can save flash space on some ports and are also more self explanatory
There's not currently a macro for a property that supports deletion. If there's some rare property that supports deletion, we should introduce and use MP_PROPERTY_GETSETDEL for it (albeit maybe with a better name)
ports/raspberrypi/bindings/rp2pio/StateMachine.c:const mp_obj_property_t rp2pio_statemachine_writing_obj = {
ports/raspberrypi/bindings/rp2pio/StateMachine.c:const mp_obj_property_t rp2pio_statemachine_pending_obj = {
ports/raspberrypi/bindings/rp2pio/StateMachine.c:const mp_obj_property_t rp2pio_statemachine_txstall_obj = {
py/objproperty.c:extern const mp_obj_property_t __property_getter_start, __property_getter_end, __property_getset_start, __property_getset_end;
py/objproperty.h...
The library that was blocking it has been changed and the Community Bundle was able to build successfully last night.
🎉
sunton_esp32_8048S050 ,Similar to sunton_esp32_8048S070, but with a 5-inch screen.
Hi, dhalbert,
Could I re-open this? I know how to reliably replicate the problem.
Reboot the host but don't log in at the terminal and display, log in by ssh as a remote user.
The login path of scripts run of a physical user vs login path of remote user are different and CIRCUITPY as a drive isn't by default mounted by ssh (but is by physical log in).
When you mount by mount command over an ssh, the default mount action is read only.
The problem is, if you have multiple r...
Thanks for this, I'm excited!
I did have some review comments & requested changes. I also didn't actually test the code. Any suggestion on something that would be useful to try/test if I don't have a TAC5xxx codec?
For testing with no codec, I'm getting together a loopback example similar to https://github.com/adafruit/Adafruit_CircuitPython_PIOASM/blob/main/examples/pioasm_i2s_codec.py that will send a background_write to a background_read by connecting output and input data ...
Maybe a sign a 0 asyncio.sleep isn't running audio tasks fully?
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.
I've been running my keyboard for more than a year now with an mp_hal_delay_us(1); to allow more time for the pin to be pulled to its resting state.
In the absence of a better solution, do you think this is acceptable to merge?
In the absence of a better solution, do you think this is acceptable to merge?
I think this is fine. It's probably due to a weaker pull. One microsecond is very small. Go ahead and make a pull request.
CircuitPython version
Adafruit CircuitPython 9.2.0-beta.0-12-gcd5c9d2632 on 2024-09-25; Raspberry Pi Pico 2 with rp2350a
Code/REPL
import board
import busio
import terminalio
import displayio
import adafruit_ov5640
import digitalio
import time
import adafruit_st7789
# Support both 8.x.x and 9.x.x. Change when 8.x.x is discontinued as a stable release.
try:
from fourwire import FourWire
except ImportError:
from displayio import FourWire...
testing with display_bus = displayio.FourWire(spi, command=tft_dc, chip_select=tft_cs, reset=None, baudrate = 9375000) instead of spi.configure(frequency=) and that actually affects display speed. display is staying up but the bottom 1/3 pixels on 240x240 disappear and show the REPL
The CoreS3 SE is basically a stripped down version of this board:
https://circuitpython.org/board/m5stack_cores3/
Compared to the M5CoreS3, the M5CoreS3 SE does not feature a camera (GC0308), proximity sensor (LCR-553ALS-WA), IMU (BMI270), or magnetic compass (BMM150).
https://docs.m5stack.com/en/core/M5CoreS3 SE
The CoreS3 firmware .bin loads and runs. I will take a crack at removing the camera, prox sensor, and compass.
I'm trying to reproduce this with a similar setup:
- adafruit picowbell tripler https://www.adafruit.com/product/5967
- raspberry pi pico 2 https://www.adafruit.com/product/6006
- eyespi 100mm ribbon cable https://www.adafruit.com/product/5239
- eyespi 1.9" st7789 display https://www.adafruit.com/product/5394
- adafruit camera cowbell w/ 72 degree autofocus lens https://www.adafruit.com/product/5945
 /examples/ modules in a build of CircuitPython? I'd like to get the build size under 1.5MB for the Pi Pico.
The stuff in examples should not be included. Are you seeing that it is?
the size reserved for the firmware is fixed, so that CIRCUITPY is at the same place all the time.
however, there will be unused space in there
see CIRCUITPY_FIRMWARE_SIZE in mpconfigport.mk
that is 1MB
So sorry, I meant to say "demos". When I type help('modules') in the REPL, I'm seeing:
demos/lightsout os ulab.scipy.optimize
adafruit_register/i2c_bcd_alarm demos/othello paralleldisplay ulab.scipy.signal
adafruit_register/i2c_bcd_datetime demos/snake paralleldisplaybus ulab.scipy.special
adafruit_register/i2c_bit demos/sokobon picodvi ulab.utils
adafruit_register/i2c_bits demos/tetris
And by size, just the size of the uf2 that gets output
Are you doing a custom build? The demos modules are not in the standard Pi PIco UF2
are you freezing in some extra libraries?
the freezing process will discard stuff in examples/, but not in demos/
I didn't intend to - and yes, it is a custom build. I'm not sure how those got frozen in, though.
did you add frozen modules in mpconfigboard.mk?
For the Raspberry Pi port, yes, but I didn't edit the one in the /py/ directory.
could you point me to your mpconfigboard.mk?
Oops, let me take you straight there: https://github.com/buildwithpiper/circuitpython/blob/piperCP9.0.0/ports/raspberrypi/mpconfigport.mk
so, those libraries are not in the "standard" format. The build process that freezes the frozen modules assumes that directories in the libraries should be frozen, except that it discards code in examples/ (and tests/ I think). Your examples are in demos/, so it thinks that directory is a regular part of the library
same if you called it wonderful_stuff/ ,etc.
Ah - okay, got it - I didn't connect work done by an author a few years ago to what it happening!
So just renaming the folder to examples/ in the library should do the trick?
I actually forgot those demos were in there - I thought it was something to do with makecode arcade or something like that 🙂
looking...
yes, just rename demos to examples
and you will need to update the submodule commits
Got it, thank you so much!
@tulip sleet Just found this, and indeed I'm using "adafruit_huzzah32_breakout" as a generic board to get CP up and running on my https://www.waveshare.com/e-paper-esp32-driver-board.htm. It's working like a charm. feather_huzzah32 works too, but didn't define all pins. One request, it seems like the Built-in modules between the two boards aren't the same. I can confirm because I can't use "alarm" with my board. After digging it seems like CIRCUITPY_LEGACY_4MB_FLASH_LAYOUT is the culprit. The comment in mpconfigport.mk says you're moving away from that. I'm wondering if that's going to change for the adafruit_huzzah32_breakout port? Or will I have to make a one-off build for myself.
When you mount by mount command over an ssh, the default mount action is read only.
This is strange and certainly not "default" for Linux. I work with ssh on all kinds of Linux boxes and I never experienced this issue. It does not mean that there is not some voodoo added by Ubuntu that triggers this behavior.
Can you reproduce the issue on Ubuntu installations without graphical environment ("Ubuntu server")? If your boxes are remote, you should not need the graphical environment afte...
It's going to change but not until CircuitPython 10. It's a breaking change, because CIRCUITPY moves in flash, so people will lose their old CIRCUITPY contents, and we'll need to supply new bootloaders with a revised partition table (and still provide old bootloaders too!)
hi, bablokb
My IT person disagrees with you on the default setting. I'm just the middle-man app developer (please don't shoot the piano player :-).
I have not tried this on a system without the GUI, we are not using that type of system, all our remote boxes are full-up linux boxes (whether for GPUs (jetson based) or low price rasbperry pi based (onlogic)). Mount has to be by sudo. My IT guy is hesitant to edit the /etc/fstab and I've asked/told him several times previous to this that this...
@schaefer01 Which version of Linux and which desktop environment are you using?
Just to clarify: are you using ssh and then mount locally on the remote machine, or do you use sshfs to locally mount a remote filesystem (a "share" in windows-speak) on your local machine?
hi,
Haven't checked journalctl, will do an experiment sometime today, my IT guy shows up later in the day too.
I'm running the bespoke dev board against a linux DELL laptop, basically pretesting because once the app is copied into the box, and the box is closed and placed, everything gets way more difficult to test. The remote lboxes will be the same linux version but there will be to-be-discovered differences because of differences that are related to the processor unit vendor choic...
thank you all, I truly appreciate the help!
This is definitely not a CircuitPython problem, but a problem of your system configuration. I just logged into a remote Pi system running a GUI, and mounted a Pico-W running CircuitPython without any problems:
The first command sudo lsblk... lists all the drives and you can see /dev/sdb1 as the Pico-W with CIRCUITPY. The second command sudo mount ... does the mount without any special options (and the device is not in /etc/fstab either). The third command sudo findmnt ... shows all...
@schaefer01 The permissions problem you describe sounds similar to trouble I had mounding CIRCUITPY over SSH with Debian 12. Debian and Ubuntu are similar enough that it might be the same problem. In my case, the solution was to use pmount and pumount.
I handled mounting and unmounting of CIRCUITPY with a Makefile including these rules:
# Path to CIRCUITPY on Debian
D_CPY=/media/CIRCUITPY
# Mount CIRCUITPY from Debian command line (works over ssh).
# You might need to do `su...
Non-Adafruit boards are usually community supported. There are instructions for adding a new board here: https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython
This really boils down to the policy you have. You said "mount has to be by sudo". If this is true, then pmount won't help either, because this tool does not need sudo.
Another solution: since you have GUI boxes, why not use a vncviewer to connect? From a system perspective, this should then be a local login.
Anyway, there are multiple solutions to your problem. Your IT guy just has to pick one. Installing programs, changing polkit-configurations, adding a line to fstab, keep you walkin...
thank you all, I need to block out some time to try each.
The "has to be by sudo" this is what I said but not exactly what I meant - not IT admin policy but OS response as in, "or else I get a permissions error message."
As suggested by tannewt on discord, I'm making this PR to update the lib/tinyusb submodule commit from its old value of tinyusb @ 4349e99f to the new value of tinyusb @ 5217cee5, which is the commit for TinyUSB release 0.17.0.
The main benefit of this from my perspective is to get better support for USB host interfaces usi...
@tulip sleet @candid sun in the meeting yesterday I said I understood what Limor was saying about clock rates for pixel data vs everything else, but I think it turns out I don't. That is, I don't think we can control those separately in CircuitPython...
That was my impression too, that's why Scott had to increase the clock rate on the Qualia to get it to stop tearing.
if we are talking about the same thing
no, this is about display corruption on a fourwire st7789 display
could you just change the SPI speed when sending pixel data?
What Liz is seeing (I didn't reproduce it) is in a demo with pico 2, the camera cowbell, and an eyespi tft. Liz tried clocking down the SPI clock (from about 20MHz to 10MHz) and still saw it. But didn't see it in a modified demo that doesn't use the camera. She filed an issue yesterday if you want to look at the details
it's super weird and i'm actually going to try a second pico 2 just in case
I made a similar setup but didn't see any problem during the time I let it run. She was seeing problems as frequently as every 5 minutes (which would be about 1500 full display refreshes)
i also want to check the original pico's SPI speed to see if it's slower because i hadn't seen it happen on the original pico when i initially used the example for the camera picowbell guide
@candid sun (unrelated) did you test any epaper with pico2 or feather rp2350?
that is a lot of stuff to power from a USB port, I wonder if it's a power issue
i am talking out of my hat
i have not. i have an eyespi one i could hook up
i also saw it with an ili9341 fwiw
eyespi 100mm ribbon cables in both our cases, I think.
yes, same length
what's different about the camera vs no camera situation is that the camera is also pumping a lot of data on nearby pins...
anyway with epaper this is what I'm seeing, corrupt top lines and the whole image is shifted down. the same code on a feather rp2040 doesn't ever update the display so that's not a great double check
@slender iron does this kind of thing ring any bell? it's a new https://www.adafruit.com/product/4195 so I'm using the code under "Newer 2.13" 250x122 Monochrome Breakout and FeatherWing" on https://learn.adafruit.com/adafruit-2-13-eink-display-breakouts-and-featherwings/circuitpython-usage
though I spot this note now: # For issues with display not updating top/bottom rows correctly set colstart to 8
if the display is breaking at 10mhz you could use a saleae to capture it
yes, this is likely a colstart issue
huh actually using colstart of 0 fixed my display. OK, whatever
the eink display products aren't well labeled to know the exact setting you need
I dropped a feedback on the guide page but it may not be super actionable then.
yeah it's always a little Tricky to get them setup right
thanks
we can do a better job with the next eink rev I think
I don't think limor expected the displays to change chipsets as much
@slender iron any idea how in a saleae trace you'd FIND where it goes wrong? If you hit stop within 1 second that's still 10 million clock cycles to look through and interpret.
I suppose you could clock out 0xAA (not using displayio, but with the camera active) and see if saleae sees any anomalies != 0xAA), or just look at the pins in analog on a real scope while the camera's running to see if there's a significant amount of noise being injected
but it sounds like just running the display at around 20MHz should be fine
you could parse the data captured to reconstruct the image
or validate the commands
yeah it's not that there's a stray messed up pixel, it's (my interpretation) the display getting reconfigured inappropriately
typical clock data (D9) pin measured near the camera cowbell (camera data does not seem to be the problem)
typical DC pin measured at the header nearest the connector
typical MOSI
none of these traces look like they should be problematic
I'd look at the logic level trace first
I appreciate your POV, I was doing this test to see if there was an obvious big problem that looked like camera data showing up in the display control signals. especially since I can't reproduce a problem here, trying to look through a bunch of data in saleae for a needle in a haystack -- especially since who knows if the saleae logic levels exactly match the display -- was not where I wanted to start
but since all I see looks like the totally normal overshoot of logic transitions and not injected noise from nearby traces my theory is not looking too useful
@candid sun I assume you tried re-seating the eyespi ribbon cable at both ends during this process
while poking around with scope probes I did get a distorted image but I very likely bridged two pins briefly to cause that.
@onyx hinge yes, also tried a new cable. i'm starting to assume it's something with my setup that i'm missing
@candid sun if it's something that doesn't happen 100%, it'd be good to know if it happens 95% or 5%...
you also noticed we weren't using the same camera module, they might be different in a relevant way?? many unknowns especially until someone else has reproduced it
hrm true true
I'm gonna take a break and leave this running for a couple hours.
i appreciate you looking into it!
Just saw all these messages now, but is this ST7789 tearing similar to what was seen with the FunHouse a couple years ago? Not sure if it is related but sounds similar
@onyx hinge do you remember any particular issue getting the autofocus firmware to load? I see you sped it up at some point by writing in chunks. With the old I2C driver, it loads fine, with the new one I get _OV5640_STAT_FIRMWAREBAD after loading. I've tuned up the loading process and tried various delays, changed the chunk size and went back to writing one byte at a time. Not asking for detailed analysis, just if something seems familiar.
If I just skip the autofocus loading then it doesn't take pictures: I get None back as the image.
I did a bunch of instrumentation. The I2C writes do indeed seem to be happening in common-hal, etc. I will do some Saleae tracing later.
That's odd. the firmware shouldn't be needed just to take images. The transaction size was something that I arrived at empirically but it was just less than a power of 2 or something like that so it seemed to make sense
i get reasonable values back when reading data from the camera, so I think I2C is working in general, and I2C to other devices seems absolutely fine.
that's what I thought. There are a few other tricky bits: the python code was not using write-then-read, but separate write and read, but that didnt' fix it.
thanks
Any suggestion on something that would be useful to try/test if I don't have a TAC5xxx codec?
I've added a loopback example at https://github.com/timchinowsky/tac5 which you should be able to run as is on a Feather RP2040 if you connect DOUT (D9) to DIN (D10).
This gives the matrix columns more time to discharge and settle down to their resting state. PR #5031 improved matters but didn't seem to wait long enough for keypads/keyboards with particularly long traces.
See issue #7621 for discussion.
Excellent! I've created PR #9665.
There were spaces on the blank lines you added. pre-commit doesn't like that. I edited the file to remove them.