<@&356864093652516868> The weekly meeting is occuring here on discord in about 90 minutes at the normal time of 2pm US Eastern / 11am US Pacific. We're looking forward to hearing from everyone! Status updates and Hug reports can be filled in to the document at any time: https://docs.google.com/document/d/11hSXWvZY9pqH1RNT7wBU3gzwwDjjEJVO2yg_-E999D4/edit?usp=sharing
#circuitpython-dev
1 messages · Page 63 of 1
CircuitPython version
Adafruit CircuitPython 9.0.0 on 2024-03-19; Raspberry Pi Pico W with rp2040
Code/REPL
import gc
print(f"free memory at start: {gc.mem_free()}")
main.py Ausgabe:
free memory at start: 126112
Behavior
With CP 9.0.0, we have about 123K of free memory. With 8.0.5, we had 152K (139K with 8.1.0/8.2.10). So we lost 20% of available memory from one major release to the next.
This really hurts. Using e.g. a HTTPS-API and up...
I think the trade off is firmware size. The web workflow is going that way by using a code.circuitpython.org to piece things together. code.circuitpython.org also works with usb and ble
The best way to debug this is with a logic analyzer and comparing what the arduino example does vs CP's output.
I attemtped that, but the rp2040 as a logic analyzer doesn't seem to be able to keep up with the speed of the data, even when I set the parallelbus frequency down to 4mhz, the lowest it will go and still turn the screen on. The results it got were inaccurate and spotty, with some of the init sequence being visible in the decoded data stream, but a lot of it not matching what is defined in code, becuase of missed bits
huh, that's surprising
you could try capturing just the clock line first
to see if the parallel version is what slows it down
which is the clock line?
actually, parallel doesn't call it clock I think
maybe "write"?
it's been a little while since I did it
Has anyone confirmed recently that it works on the tdisplay?
Confirmed that this is a hardware error. Flashed a second identical unit in the default manner and it does not have this issue
Confirmed that this is a hardware error. Flashed a second identical unit in the default manner and it does not have this issue
Whew!
@tulip sleet @gilded cradle still seeing the qualia wifi weirdness using 9.0.0 with libs from 2024/03/23 bundle
Adafruit CircuitPython 9.0.0 on 2024-03-19; Adafruit-Qualia-S3-RGB666 with ESP32S3
>>> from adafruit_qualia import Qualia
>>> from adafruit_qualia.graphics import Displays
>>> qualia = Qualia(Displays.ROUND28)
>>> qualia.get_local_time()
Connecting to AP peanuthamper
Getting time from IP address
Traceback (most recent call last):
File "adafruit_connection_manager.py", line 271, in get_socket
OSError: [Errno 116] ETIMEDOUT
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "adafruit_portalbase/__init__.py", line 492, in get_local_time
File "adafruit_portalbase/network.py", line 270, in get_local_time
File "adafruit_portalbase/network.py", line 237, in get_strftime
File "adafruit_requests.py", line 591, in get
File "adafruit_requests.py", line 525, in request
File "adafruit_connection_manager.py", line 282, in get_socket
RuntimeError: Error connecting socket: [Errno 116] ETIMEDOUT
>>>
Ah, okay, good to know. I keep seeing references to firmware image size, particularly for M0 boards as I'm reading around to get oriented. Also, I ordered an OrangeCrab 85F, and I'm working on getting dev tools installed.
Awesome! I'd love a simple, clear way to run CP on the orangecrab.
that's my goal. also, fwiw, it seems like the OrangeCrab 25F and 85F variants are not bistream compatible. The 85F seems more available, so I plan to focus on that one.
it can also fit more stuff 🙂
@slender iron so I just hooked that same parallel ili9341 external screen to an ESP32-S3 and it works.. so.. i guess the issue is with the OG ESP32
I can take another look after the meeting
I was just thinking about that
you could try my idf 5.2 PR.
maybe espressif fixed it in the idf
The primary ram hog is the wifi stack really. I don't think much (ram) can be gained from custom builds.
The difference between CP versions is probably just from the underlying lib version changes.
Some tips:
- Consider switching to / rewriting smaller more task focused modules.
- Consider using internal modules (like displayio for the display).
- Consider using
mpy-crossto partially-compile .py files.
If these are not enough for your applications, you may wanna look into ESP3...
How would I go about doing that, and is it going to break my current build environment? 😄
merge or rebase against this https://github.com/adafruit/circuitpython/pull/9071
you can see my branch name there
Those are called lithography prints where details come through via backlight.
I've never seen one that rotates with a servo, very cool.
👋
@tulip sleet this looks helpful for MP merges: https://speakerdeck.com/schacon/so-you-think-you-know-git?slide=69
```/home/circuitpython/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/../lib/gcc/xtensa-esp-elf/13.2.0/../../../../xtensa-esp-elf/bin/ld: build-sunton_esp32_2432S022c/esp-idf/esp-idf/wpa_supplicant/libwpa_supplicant.a(esp_wpa3.c.obj):(.literal.wpa3_build_sae_msg+0x18): undefined reference to esp_wifi_sta_get_rsnxe' /home/circuitpython/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/../lib/gcc/xtensa-esp-elf/13.2.0/../../../../xtensa-esp-elf/bin/ld: build-sunton_esp32_2432S022c/esp-idf/esp-idf/wpa_supplicant/libwpa_supplicant.a(esp_wpa3.c.obj): in function wpa3_build_sae_commit':
/home/circuitpython/repos/circuitpython/ports/espressif/esp-idf/components/wpa_supplicant/esp_supplicant/src/esp_wpa3.c:37:(.text.wpa3_build_sae_msg+0x4f): undefined reference to `esp_wifi_sta_get_rsnxe'
@onyx hinge what are using to make your pycon slides?
@slender iron google (sigh)
make sure all of the idf submodules are updated (check git status)
and clean and rebuild
I was gonna try marp for my pycascades talk
Added firmware features do not necessarily use up RAM immediately. The difference may be due to the new "split heap" storage allocation. We would need to track down if the RAM is actually used up, or whether gc.mem_free()'s report is as helpful as it appears.
it was Scott who added those warnings, and I'm sure he's delighted to hear it because it has been a source of concern for some. nice to know some are helped too.
- but daisy is unsupported
❤️ @idle owl
@fringe yarrow what board do you have exactly? I don't see any 8 bit parallel here: https://github.com/rzeldent/platformio-espressif32-sunton/tree/main
Forgot to give you a hug @lone axle for also making a PR that fixes the sorting first.
👍 I don't see it on amazon unfortunately
I suspect this ESP32 vs S3 is the answer.. since I hooked the same model screen to the same model esp32 and got the same result as that board, but that screen worked on an S3 with no other changes..
I think I missed a step.. When I'm checked out on your idf5.2.1 branch, done the submodules, did the esp-idf/install.sh, it still looks like esp-idf 5.1 is installed
Ok, I didn't add it in the document, since this is the first major CircuitPything thing I'm working on, and just didn't think to do it... but I'm working on porting CP to the Daisy Seed board.
Figuring out how to do XiP on the 8MB external Flash is not easy, but the board stats are too tempting to not try! 😻
you'll need to run an export too
Awesome it looks neat but I can't justify it myself
did that, too.. ```$ ./esp-idf/tools/idf.py --version
ESP-IDF v5.1-dev-9318-g722fba96a1
this should be the commit: https://github.com/adafruit/esp-idf/commit/4a7e8f4299e88ce8ca0ed0cc906848532028359b
I think "good first issues" are specific to every repo, having typing as "good first issue" was sort of odd in our history
We could create issues to validate that example code in libraries are working
Every library could have a .pyi file that the typing library pulls in...
fulfulling is a good word
I agree that typing issues are **not ** interesting (ahem...boring... ahem) as first issues 😄
+1 to opening issues. I investigated the ssd1306 driver (see more notes in the document) -- it was intended to work with 8.x and 9.0 without warnings, but a mistake was made and it needs to be revisited.
I just filed https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_SSD1306/issues/40 for the ssd1306 issue I saw
historically we ran pylint with different flags on examples
I wonder if there's a way to make pre-commit have a level of indirection. ```repos:
- repo: https://github.com/adafruit/circuitpython-precommit
rev: main
hooks:- id: ...
@onyx hinge you may know this https://forums.adafruit.com/viewtopic.php?t=209441
@slender iron at the moment it's not designed to be flexible, it's designed to do exactly what our demos needed. Not idea, but that's the situation.
This is on @BlitzCityDIY's plate, but awaits some changes in the Arduino library.
Thanks!
yep! 😄 @midnight ember @slender iron
a lot of audio stuff is not implemented for stm32
no, no st
teensy is imx
it's not open source anymore 😑 they closed it a few months ago
frustrating asf
there are schematics for older revs, if you dig hard enough (i have rev 5 btw... you should have the last one, rev 7, @midnight ember so we will need test both)
sure, thank you! 🙂
Huh, interesting idea. We could make our own pre-commit hooks to just call different command line options and have a config file like you described. It feels a little hacky but that's because the typical use case isn't concerned with parity across several hundred repos 😅
It would be a lot like the composite GitHub actions I suppose
It looks like pre-commit-hooks.yaml can't have "- repo" blocks so you'd have to pip install in a venv or something...
Pre-commit should handle the venv part - I think we would just add ruff and the others to the requirements file of the hooks package.
When it installs the hook, it should handle all the dependencies as well
The out of the box hooks get the yaml (and toml, if needed) libraries that way: https://github.com/pre-commit/pre-commit-hooks/blob/main/setup.cfg
That was my thought. Didn't know how worth the work that would be.
Also, what happens when we update the rules and someone's simple PR is now a lot bigger?
Bigger in what way?
So, a user changes 1 line, and then has a bunch of unrelated formatting changes because the global ruff file was changed
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/1fwE8nNrxx4lDEbSlGUqE9iR_XqECxSljZI2_6P-UdDw/edit?usp=sharing
We could always run a patch to push changes to main for all libraries, but at that point, should we just push changes to the config file?
It's turtles the whole way down

It's a hard one. I like the idea of a source of truth, but it seems more complicated than it's worth...
(need https://learn.adafruit.com/adafruit-feather/feather-specification but for BFF & PiCowBell)
Also might be strange to see a PR with a bunch of formatting changes, but no configs changing...
@kylefmohr While we're waiting for this, you mentioned that you might have the Waveshare RP2040 GEEK PR waiting in the wings. My board just arrived :grin:. If you do have a PR ready, want to post it so I can start testing on my new board? If you haven't started and/or would prefer, I could draft up the PR as well. Just let me know....
I have done already all of this (e.g. use pre-compiled modules) and have carefully garbage collected my objects. All my tests are with the exactly same code and library versions. I have instrumented every part of my program and have detailed data for various modules I use.
The data clearly shows that wifi and other module usage does not differ greatly between CP versions. The big initial difference of free-mem at the beginning of the program carries through the whole runtime of the program...
I've been turning over ideas about good first issues and I think one of the easiest ways to contribute is to add a new board, I don't think we want 300 new boards added just for the sake of adding boards through. I wonder if there would be a way to design a playground board with all sorts of gadgets just for the purpose of teaching people how to add/fix CP features. The updates could be built and tested on the board (always rewarding to see CP do something new on hardware that you had a hand in) but maybe not even merged in so they could be added again by the next students/tinkerers.... Just thinking out loud....
I think one of the easiest ways to contribute is to add a new board
Speaking as someone who is just doing a board port as the first major CP project, I don't think I agree 😆
Maybe adding another samd21 board without many extra peripherals, so the port from another board can be just copy pasted, but I still think it would be intimidating 🤷♀️
CircuitPython version
Adafruit CircuitPython 9.0.0 on 2024-03-19; Adafruit ItsyBitsy ESP32 with ESP32
Code/REPL
# import time
# import board
# import neopixel
# pixels = neopixel.NeoPixel(board.NEOPIXEL, 1)
# while True:
# pixels.fill(0xADAF00)
# time.sleep(1)
# pixels.fill(0)
# time.sleep(1)
import board
import digitalio
import neopixel
import time
print("START")
# On MagTag, enable power to NeoPixels.
# Remove these ...
Possibly related to #9086 but unlikely as probably user error and a reasonable enough error message. Closing
I was curious if there was an explanation for why ADC2 association analog pins did not have value attributes. If that's a limitation of the ESP32 module, I wonder if the pins should be renamed (assuming they can be used for digital I/O).
I don't have an ItsyBitsy to test with but it looks to me like this is a Pin/GPIO miss-assignment. Can you test the attached firmware and if it resolves the issue I'll post a PR?
firmware.zip
hello community,
does anybody knows of any activity / efforts to program circuitpython with a VPL / node flow based UI / roberta (scratch) like / similar?
iam interessted in experimenting with this for an even easier start for beginners...
It looks like you can use scratch with the Circuit Playground Express: https://mryslab.github.io/s3-extend/
@proven garnet please let me know how I can help on the ruff stuff. In theory if you take the few changed files (maybe moving the config to ruff.toml per Dan) and flag any library that has issues, I can work on manually updating?
I can also create a branch with only the changed files...
For sure, I'll catch up on the meeting in the next day or so. Inevitably, there will be issues resulting from the patch that will need manual fixes 🙂
Sounds good. Just ping me with whatever I can do
Would it be helpful if I updated requests and connection manager to match on the pre-commit file? Since they both have isort?
Definitely look at https://edublocks.org/
Boards with already supported microcontrollers are easiest
One idea I had about potential good first issues is sensor + display examples. Right now I think there are a lot of sensor driver libraries that have examples that only print data to serial console. Many times on the product pages there is gif or video of an example running that updates the display with values from the sensor. I assume the ones used for the video are early in the devices life and are arduino based. I do think it would be nice to have CircuitPython display examples available in those sensor libraries though.
One thing we've seen folks have trouble with a few times over the years is getting the label created and updating it without creating new ones. That is documented in a DisplayText learn guide now, but it would be nice to have relavent examples to point someone toward for any given sensor they're working on.
Here is one such repo with only serial console examples: https://github.com/adafruit/Adafruit_CircuitPython_BME680/tree/main/examples
The starting heap memory is largely dictated by the static memory allocations. Features like picodvi can use this space up because it includes all code that needs to run when flash is unavailable (like the dvi conversion code.)
To dig into this, you'll want to do your own build and look at the .map file. It'll lay out how much of RAM is used statically and what symbols take up that space.
Possibly related to #9086 but unlikely as probably user error and a reasonable enough error message. Closing
This is probably an issue. A simpler example like the one @RetiredWizard is how to know for sure.
It turns out that at least on the QT PY, the the AnalogIn object for board.A2 doesn't have a "value" function:
I think this is a different bug around how dir() figures out what is on an object.
@kylefmohr While we're waiting for this, you mentioned that you might have the Waveshare RP2040 GEEK PR waiting in the wings. My board just arrived 😁. If you do have a PR ready, do you want to post it so I can start testing on my new board? If you haven't started and/or would prefer, I could draft up the PR as well. Just let me know....
DM'd you on Discord!
Ok, @dhalbert this is ready for review.
Possibly fixes #9086
I don't have the hardware but according the the learning guide pinouts the neopixel/power are on GPIO0 & GPIO2.
Port waveshare_esp32s2_pico still has CIRCUITPY_ESP_PSRAM_FREQ = 120m.
I ran a string search just in case there are others, but no.
Thanks for moving everything around!
Please try to reuse messages in this file instead of adding new ones. That way there is less to translate and less to store in the firmware.
Please add documentation for each of these values. Here is an example: https://github.com/adafruit/circuitpython/blob/e64082d60052f92720031b5a17aec3732a6c4e26/shared-bindings/synthio/Math.c#L54 You should use the MAKE_ENUM_VALUE() macro as well.
Generally we enable things immediately after the constructor is called.
Did you run into an error where you were constructing it a second time but deinit() hadn't been called? You can have the gc call it via a finalizer: https://github.com/adafruit/circuitpython/blob/e64082d60052f92720031b5a17aec3732a6c4e26/shared-bindings/countio/Counter.c#L63
You also need to add __del__ entry to the locals table that points to deinit.
https://github.com/adafruit/circuitpython/pull/9076 was just merged to add support for the Waveshare ESP32-S3-GEEK, here are the files to add it to the circuitpython.org site. Thanks!
CircuitPython version
Memory problem with CP 9.0.0 - code fails that works with CP 8.2.10
code.py output:
]0;🐍code.py | 9.0.0\Traceback (most recent call last):
File "code.py", line 1, in
MemoryError: memory allocation failed, allocating 1016 bytes
]0;🐍1@code.py MemoryError | 9.0.0\
Code done running.
-------
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
]0;🐍code.py | 8.2.10\TREK
- .-. . -.-
Code:...
One more tiny tip I have is that you may wanna consider setting CIRCUITPY_PYSTACK_SIZE to something like 1792 or even lower.
For every 256 you remove from this value it, you should gain 256 bytes ram but lose a few stack frames.
This means lower function depth.
If you have a lot of nested calls (or your libs do), you will see pystack errors with this change though.
You can fine tune it and have exactly the size you need though.
@slender iron sorry to keep on about this.. I'm not sure if I managed to fetch your 5.2.1 PR or not.. I think i did.. if so, it didn't make any difference.. the OG ESP32 still doesn't talk to the parallel LCD
the debug output will tell you want idf version it was built with
which would be a simple thing if this didn't have s uch little flash 😄 enabling debug means remembering the arcane list of things i had to disable again
If I understand right, you can save some RAM by doing a custom build with custom frozen modules: https://learn.adafruit.com/building-circuitpython/adding-frozen-modules
Things like "turning off PICODVI saves 4K" are useful to know.
The extra RAM from compiling .py files gets freed afterwards, so precompiling to .mpy doesn't really help with RAM, provided you have enough to complete the compilation.
CircuitPython version
9.0.0 itsybitsy esp32
Code/REPL
# SPDX-FileCopyrightText: 2024 Tyeth Gundry
# SPDX-License-Identifier: MIT
#TODO: Add Adafruit IO feeds for BME688.
#TODO: Add scaled output to air quality feed from scaled air sensor (CO2/PM2.5/gas-ohms)
#TODO: swap to using rotary switch inputs ( max_events=1 ) with keypad.keys:
# https://docs.circuitpython.org/en/latest/shared-bindings/keypad/index.html#keypad.Keys
#NO LONGER TRUE, WAS FOR Q...
@slender iron ESP-IDF v5.1-dev-9318-g722fba96a1 clearly I dont know enough about git to know how to get whats needed to compile with 5.2.1
how did you try to update your branch?
strangely my other longer code is working now having switched the base frequency from 100 to 300, the auto-adjusting code is now kicking in as expected and my frequency is varying. Not retested the test case, but it's in the same code.py just commented out, no power off of the device has happened yet.
I'm now turning off the itsy (its in a device). I'll look properly tomorrow evening
I pulled a fresh clone from adafruit/circuitpython, then used github cli and gh pr checkout 9071
I also have trouble with idf5.2.1..
I checked out the branch (I did fetch all right before)
[bill88t@lunchbox | ~/git/circuitpython/ports/espressif]> gs
On branch idf5.2.1
Your branch is up to date with 'tannewt/idf5.2.1'.
nothing to commit, working tree clean
but I am getting
-- Checking Python dependencies...
ERROR: /home/bill88t/.espressif/espidf.constraints.v5.1.txt doesn't exist. Perhaps you've forgotten to run the install scripts. Please check the installation guide for more information.
CMake Error at esp-idf/tools/cmake/build.cmake:365 (message):
Some Python dependencies must be installed. Check above message for
details.
Call Stack (most recent call first):
esp-idf/tools/cmake/build.cmake:502 (__build_check_python)
esp-idf/tools/cmake/project.cmake:605 (idf_build_process)
CMakeLists.txt:12 (project)
during the compilation, AFTER the idf has been loaded already
Setting IDF_PATH to '/home/bill88t/git/esp-idf-v5.2.1'
Detecting the Python interpreter
Checking "python3" ...
Python 3.11.8
"python3" has been detected
Checking Python compatibility
Checking other ESP-IDF version.
Adding ESP-IDF tools to PATH...
Checking if Python packages are up to date...
Constraint file: /home/bill88t/.espressif/espidf.constraints.v5.2.txt
Requirement files:
- /home/bill88t/git/esp-idf-v5.2.1/tools/requirements/requirements.core.txt
Python being checked: /home/bill88t/.espressif/python_env/idf5.2_py3.11_env/bin/python
Python requirements are satisfied.
Added the following directories to PATH:
/home/bill88t/git/esp-idf-v5.2.1/components/espcoredump
/home/bill88t/git/esp-idf-v5.2.1/components/partition_table
/home/bill88t/git/esp-idf-v5.2.1/components/app_update
[...]
/home/bill88t/git/esp-idf-v5.2.1/tools
Done! You can now compile ESP-IDF projects.
Go to the project directory and run:
idf.py build
I did wipe submodules as always and even made a new CP clone
I think the forked idf has something not playing nice with my external stock idf.
But I have been always having a seperate one. Why did it break now?
Is this intended to be set for both conditions?
Adafruit CircuitPython 9.0.0-2-g1ad5a73eb5 on 2024-03-25; Raspberry Pi Pico W with rp2040
+
latest release adafruit_httpserver 4.5.6
...works fine, no exceptions.
A number of resets of the server didn't yield any exceptions. We can test the no-reuse case pending the question above. I'm not sure how to reliably trigger the address in use exception though.
[adafruit/circuitpython] Pull request opened: #9090 Add support for new board: Waveshare RP2040-GEEK
This adds the Waveshare RP2040-GEEK board to CircuitPython. I've marked it as a draft because I'm waiting for a response from Waveshare technical support in which I requested a CircuitPython UID/PID pair.
Seems to be a Windows 11 problem. Tried two different picos, same result. Code.py is just print("Hello world!").
Works fine on Fedora 29.
I did some looking at this, first by just using arm-none-eabi-nm, and then by using https://github.com/google/bloaty (which I had never used before)
Here is some info, first comparing 8.1.0 to 8.0.5. Notice the growth in the in the .data and .itcm sections, which are RAM. .itcm is code in RAM (right?). .rodata can be flash.
I need to build without picodvi turned on, which I didn't do consistently yet.
$ ~/repos/bloaty/build/bloaty ~/build-raspberry_pi_pico_w_8.1.0/firmwa...
Artifact works. Can soft-reload without issue. Simpletests work. Good fix. 👍
Thank you all for looking into this.
@tannewt : I could create the map-files for the different versions and then compare them. What exactly am I looking for? All .data.xxx sections?
Disabling picodvi and usb-host brings me back to 143k. The build fails with CIRCUITPY_USB_HOST = 0, I am preparing a patch for that.
If CIRCUITPY_USB_HOST = 0 in the board-config-file, then tuh_task_event_ready is undefined. This patch prevents this.
I did test with longer intervals, works as expected, but then I'd have to set the integration threshold lower to get reasonable response times (obviously). I intentionally tested the extreme case of lowest latency -- increasing any of the two variables will always increase both reliability and latency.
If you'd like me to contribute to that write-up, maybe with a graph illustrating the algorithm as you mentioned, I'd be happy to help.
i have written down all findings in this featurerequest:
https://github.com/circuitpython/web-editor/issues/171
Bumping ESP32-S2 and ESP32-S3 bootloader versions.
Check https://github.com/adafruit/tinyuf2/releases/tag/0.18.2
I think you've confused new board with new chip type. Using an existing board to create your own derivative is a much easier prospect. Adding a new board that uses 2MB of PSRAM has plenty of precedence and examples. A 65MB SDRAM chip not so much. 😉
We'll work it out. As long as Scott says it's doable then it'll just take time and a lot of research.
this makes sense. didn't test.
This commit has functioning support for the Sunton ESP32-2432S028. It has an SPI 320x240 display, an SD card slot, and XPT2046 touch input.
Just to add it's still set at 300Hz and switched on fine this morning.
Leads me to believe it may have been from initialising the pwm pin at a fixed frequency of 100Hz when testing code initially (no variable frequency or False effectively), then soft rebooting and initialising at 100Hz with variable frequency True (no deinit performed?), at which point variable frequency was ignored.
With today's artifact and same latest release of the adafruit_httpserver library, I get OSError: [Errno 112] EADDRINUSE upon bind by default when the server is interrupted (^C) and restarted (^D). This code is in server.py:
if implementation.version >= (9,) or implementation.name != "circuitpython":
sock.setsockopt(socket_source.SOL_SOCKET, socket_source.SO_REUSEADDR, 1)
But if I change it to `sock.setsockopt(socket_source.SOL_SOCKET, socket_source.SO_...
Add the M5Stack CoreS3 board to CircuitPython
It would be a fine topic for https://adafruit-playground.com/, and we could point to it from the keypad Learn Guide.
@tulip sleet @short tendon Catching up on the meeting from yesterday, I think a centralized ruff.toml could be interesting. If we create our own pre-commit hook we could do a lot. I think the "being offline" issue isn't a problem because eventually they'll need to git push anyway so Internet access is an eventuality. We could use the venv pre-commit creates to run the tools we want via Python instead of command line, assuming they all have Python APIs (or use subprocess.Popen).
I think ruff.toml would be the only thing that would be factored out since the other infrastructure really is needed on a per repo basis. But unifying REUSE, ruff, etc. would be 
I do think it's feasible to do it, thinking about it. I could prototype it after the ruff patch if we want.
it might make sense to try it beforehand, to avoid a second round of patching across all the libraries. I didn't know whether pre-commit had any kind of customization of the install.
It does mean we probably won't run ruff as a pre-commit hook
So that's a good point
i think running ruff locally in pre-commit is important, just as pylint and black are now important
it's not terrible to have a ruff.toml or incorporate those settings into pyproject.toml. The dread is if ruff gets updated and causes a lot of code churn. Is the version of ruff that would be used by pre-commit specified explicitly, that is, does it have to be specified explicitly? pre-commit has very particular ideas about certain things
It would still run locally, but it would be our pre-commit hook running it instead, still within a venv. So our hook is installed and it has ruff and other tools as dependencies and runs those within that venv.
I thiiiiink you can use any valid PyPI version.
also i don't have a strong opinion about leaving the settings in pyproject.toml vs a separate ruff.toml. It's easier to patch only the ruff settings if it's separate, I guess, that leans towards a separate ruff.toml
But let me double check that
I do agree that ruff.toml is easier to patch and preferable in that regard
I am looking at a typical .pre_commit-config.yaml: https://github.com/adafruit/Adafruit_CircuitPython_HID/blob/main/.pre-commit-config.yaml
Sorry, GitHub, not PyPI
so the separate black and pylint entries would be moved into the hooks in lines 17-19? But those hooks are supplied by pre-commit, we might need our own. I should look and see whether pre-commit has already done anything with ruff
there is special handling for examples vs library code in that pre-commit .yaml, for instance, we need to be able to do that
Ruff has pre-commit hooks, but would need local settings in each repo for customization. If we make our own hook, we could "internally" run the tools, but with the benefit of being able to use "internal" default settings (i.e, a ruff.toml).
and vary the running on the different categories of .py files? I guess our hook could do anything we want it to
I guess the way I think about it is that we'd effectively creating a wrapper/combo CLI that runs all the tools and make a hook for it.
Yeah exactly
It does also mean that updating the hook versions is also easier because we just change the dependency in the combo tool.
as we've already done when factoring out other CI tasks (not pre-commit)
The more I think about it, the more of a neat solution it is, though it does mean the work @short tendon has done will need to get transferred to the new tool.
Justin said he was just experimenting with several representative libraries. That is all draft work and I think he would say it's fine to redo it in a different form. So I think the first thing to do is to set up the hook and then PR against one or more of those libraries (maybe suggesting modifications to Justin's PR's) to test it.
Sounds good! I'll get on it!
Thank you!!
what version is your external idf? it should match what CP is using
5.2.1
I got it from releases as usual
did you run the install script?
it would be saying 5.1 at the constraints if I messed up
my aliases are conplicated, but they haven't changed since idf 4.2
I just have been changing the version the same way up to now
I have always been keeping my own idf that matches cp version
what error are you getting?
this during the compile
it's as if it's trying to find 5.1 stuff
I can get a full log if you want
yea but the external idf works (I built examples)
at some point the makefiles are setting it idf version to 5.1 I think
in either case I will try in docker next
Port
waveshare_esp32s2_picostill hasCIRCUITPY_ESP_PSRAM_FREQ = 120m. I ran a string search just in case there are others, but no.
I left that in because it is marked as quad not octal.
I'd like other opinions on library changes like this: https://github.com/adafruit/Adafruit_CircuitPython_IL0373/pull/32
Just to add it's still set at 300Hz and switched on fine this morning with speed varying as expected.
Leads me to believe it may have been from initialising the pwm pin at a fixed frequency of 100Hz when testing code initially (no variable frequency or False effectively), then soft rebooting and initialising at 100Hz with variable frequency True (no deinit performed?), at which point variable frequency was ignored.
Power cycling obviously cleared the state / masked the problem...
Matches the schematic! I don't have one to test either.
@tyeth Please test with 9.0.x
FYI @lone axle
I don't think I really have a strong opinion one way or another between having compatible code that supresses the warning vs. not having compatible code that prints the warning.
But I do know that several libraries already had this change, I was (still am really) in the process of grepping the bundle to find them. The ones I've submitted so far I basically copy / pasted the changes from the last round that were completed.
At this point either way we will need to go back and do another round to switch to the 9.x only way after the 8.x bundle is finalized. Skipping these ones now would avoids one change in the interim but does leave the libraries in an inconsistent state since some already have it and some don't.
ya, I realize I'm late to the party
I tend to use try/excepts to ease migrations but my projects are much smaller and even then the code ends up hanging around longer than I intended. I haven't been following the concerns regarding the warning messages, but to me they seem like a better way to go. Maybe there could be an easier way to quiet the warnings at runtime?
If we need we could try to get something like libcst to analyze files and look for imports. I have been meaning to use/add it as part of the extended adabot tools. Maybe for the future.
I will say I look at making the changes earlier as a bit more than just supressing the errors. I look at it also as a way to communicate the new "correct" way to do whatever the thing is. So I do kind of like it when that finds it's way into the libraries before it's absolutely necessary for them to run or else they crash without the change.
I also agree with this sentiment.
But I also look at and copy from library code and examples quite frequently, I'm not sure if that is really true of the majority of the user base though.
I think you can do warnings.simplefilter("ignore") to turn them off
If we remove the warnings now, we can wait until we don't need to support 8 and just make the change in one go.
I'm not sure I follow, I don't have any prior knowledge of that tool. Like it would be dynamically switching imports to be 9.x vs. 8.x compatible for instance? or am I misunderstanding entirely?
since 9 supports both ways
later versions of 9 can have the warnings added back too
before 10 is stable
I feel like that no longer informs people that there's a new way to do things
I'd rather wait to inform them when they don't need to support the old way too
I know we don't want super long warnings, but could we add that info to the message?
libcst can parse a concrete syntax tree as well as make changes. And since the extended adabot tools can run python on all of the libraries, you could use it to programmatically make updates.
At the very least you can programmatically find specific code
I'd rather not but we should document it somewhere
And manually fix them
perhaps worth considering as part of this discussion is: https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/2755 which is applying basically the same changes to the Learn Guides, but these ones don't have the try/except only the 9.x way.
Thank you all for looking into this.
@tannewt : I could create the map-files for the different versions and then compare them. What exactly am I looking for? All
.data.xxxsections?
.bss and .itcm sections will also take space in RAM. The address can tell you want memory region everything is in.
I see, that does sound handy, in this case there are a few tweaks needed outside of the imports as well due to types and usages referencing things like displayio.FourWire in the ones I changed them to FourWire only and have the imports to switch which module it came from, that way a future change of this type would only require change to the import, but I don't know the likelyhood that it comes up again.
I think this is why I'm wanting to disable the warnings for now. It's too early to do all of this switching because we're not ready to stop supporting 8 (I think)
It's probably also worth bringing Dan and perhaps Limor into the conversation? I initially made those changes with direction from Dan that came originally from Limor.
@tulip sleet ☝️
@lone axle The libraries all have conditional from-imports that first try the 9.x naming and if that fails, they do from-imports the 8.x way. That way avoids any warning printings. I would suggest doing the Learn Guide code that way for now, and then undo the 8.x naming in both the guides and the libraries.
Limor's input was just that you should do it instead of me 🙂
Some of the libraries don't have this yet though, I've started working through them and adding it but Scott is thinking now is not the time to add that at the library level...
but we already did that on a bunch of the libraries
I know, I copied from them for the newer ones I've submitted.
I can go back and update the PR in Learn to make it compatible with both, but that sounds like code that Scott prefers not to have in the Libraries and I assume Learn though it wasn't mentioned specifically. I'm willing to go through and do it whichever way is decided is best.
PR for board was accepted earlier today. Offering images and description for website.
@slender iron @lone axle We did dozens of libraries or more with the conditional imports a few months ago, so I think it's OK to continue that trend for consistency. We could also turn off the warnings and just delay updating the libraries until we stop making 8.x bundles. So hold off on any new PR's now, and make 9.x-only changes after 8.x is no longer supported. we'll release a 9.0.1 soon anyway with other fixes and we can turn off the warnings then.
It's really fine with me either way. It's less work not to make these changes now and just do the 9.x-only at the right time.
My preference would be to remove the warnings for now. They are creating a lot of extra work
We can add them back when we stop supporting 8
in prep for 10
we will stop making new 8.x bundles sooner than that, I think. We stopped 7.x bundles pretty early after 8.0.x. What time frame were you thinking of? Maybe 9.1.0 final?
last 7.x bundle is 20231003
and 8.x was released in 202302
I thought we generally keep the last version going until we're wanting to do pre-releases for the next major version
maybe so, I am misremembering. OK, so we can leave the current dual-import libraries alone, since they work fine
ya, we can leave them for now
do you have a PR for turning off the warnings?
PR for board was accepted earlier today. Offering description and images of board.
To make sure I understand, I'm about half way through the grep results looking for instances of displayio.FourWire in libraries and example code and changing them to use the try/except importing new way and fallback to old way. Should I continue my way through that list when I can get back to it, or stop where I'm at?
And on the Learn Guide code what should be done there? Nothing further at this time? or go back thru and update with the try/except similar to the libraries?
Lastly how about Learn Guide pages, I've updated all of the relavent pages for changes from that PR already with the 9.x version of code... should I go back and revert those to 8.x or the try/catch fallback version? or just leave them in the new 9.x style?
Do you foresee a time when we will want these on? When 8.x is no longer supported? I'm deciding whether to remove this entirely or disable it by commenting out or with another flag for now. I think the former, so I should leave the code in but make it
#if CIRCUITPY_9_DISPLAYIO_WARNINGS && CIRCUITPY_DISPLAYIO && CIRCUITPY_WARNINGS or similar
The other option is that we could drop 8.x support now
Sorry about all this. It's awesome you are on top of it
We shouldn't add code that has to try/except to support two versions.
that's pretty early, in case there are library fixes we want to make available to 8.x users. I thought we would wait until 9.1 at least.
9 supports both so that we can wait to move once we're confident in 9
@lone axle I think we leave all try/except stuff that's been done already. Learn guides should still use the old way because we're not stopping 8 support yet.
how many Learn Guide changes did you make already? The Learn Guide repo code can stay the same. The in-guide rferences to one version or the other are painful to keep track of. I kind of hate the "here's an annotated listing of the Learn Guide code.py", which has to sync up with a moving targets.
I wonder if Learn could pull annotation text out of the source file.
Okay sounds good, I converted that PR to a draft so it can hang out there until we're ready for that change to 9.x syntax. I'll go back to the Guide pages themselves and swap back to the 8.x syntax.
I'm not certain how many I changed but it was fewer than the total number of code files that changed in the repo, not all of the guides contained page content reference the display setup portion of the code. If I had to guess I would say maybe only a 12-20 pages changed whereas 56 py code files changed.
I would like a better annotation mechanism. It could also just be comments. it makes the code.py a bit bulky.
but I also didn't mark which ones they were so I'll have to work through the list again, but it's fresh in my memory so I think I will spot them quickly this time.
undoing those could be done with the page history: you can roll back easily without having to re-type anything
unless you took the opportunity to do other copyediting
Nice I'll look for that way, I've never used it before but I assume it's on the right side controls.
Is there by chance a list of overall user activity on a page somewhere? then I could go thru that list of only the ones I touched in the last day or two.
Yes, click on history. It should be relatively obvious what to do.
- Wrapped main function in spresense_main
- video_uninitialize now requires dev path as parameter
[adafruit/circuitpython] New tag created: v1.21.0
[adafruit/circuitpython] New tag created: 2.2.0rc1
Thanks for your perseverance on this. Let's merge it in for 9.1.0. A writeup in https://adafruit-playground.com/ would be welcome.
@tulip sleet So, apparently the Feather ESP32-S3 Reverse TFT buttons, the three on the front, D0 is false when pressed, and D1/D2 are true when pressed. Is there still a way to use keypad with this?
Two instances of keypad makes things sad.
There is a request for that: https://github.com/adafruit/circuitpython/issues/8315. Also see Neradoc's library there. But you can also just have two keypad.Keys objects and do .get() on each one in turn. If the first doesn't have an event, go on to the second one.
Ah ok. I think what I was trying to do isn't happy with that, but I was printing both events at the same time, so it was printing None each time. Bad usage since that's not how it would work anyways. I think I understand. Thank you.
Turn off displayio warnings when using 8.x naming. This was intrusive and confusing for some users. Turn this back on when 8.x bundles are no longer being built.
OK, looks good! Looking forward to 9.1.0-beta.0!
I'm going to merge in this cosmetic spacing change. We tend to group pin aliases together surrounded by whitespace to make them more obvious.
{ MP_ROM_QSTR(MP_QSTR_GP25), MP_ROM_PTR(&pin_GPIO25) },
{ MP_ROM_QSTR(MP_QSTR_GP26_A0), MP_ROM_PTR(&pin_GPIO26) },
{ MP_ROM_QSTR(MP_QSTR_GP26), MP_ROM_PTR(&pin_GPIO26) },
{ MP_ROM_QSTR(MP_QSTR_A0), MP_ROM_PTR(&pin_GPIO26) },
{ MP_ROM_QSTR(MP_QSTR_GP27_A1), MP_ROM_PTR(&pin_GPIO27) },
{ MP_ROM_QSTR(...
Not needed to accept, but you can consider adding this if you are seeing xtal osc startup problems on some samples:
https://github.com/adafruit/circuitpython/blob/a6c6d099fd8c3e7ccb70602837b38dffcd8c1535/ports/raspberrypi/boards/adafruit_feather_rp2040/pico-sdk-configboard.h#L3-L4
I wonder if this should be 8_10 warnings? 9 has both.
I wonder if this should be 8_10 warnings? 9 has both.
I meant it was warnings reflecting changes between 8 and 9, which are disabled. This code would be removed entirely in 10. But the name doesn't matter a lot.
I wonder if this should be 8_10 warnings? 9 has both.
I meant it was warnings reflecting changes between 8 and 9. This code would be removed entirely in 10. But the name doesn't matter a lot.
I am working on CicruitPython support for a board with an I2S DAC. The bit clock (BCLK) and word clock (LRCLK) pins are in a different order than what is currently expected in I2SOut.c.
I followed the suggestion in #8680 by adding two I2S programs with swapped sideset values to be able to support either configurations.
This looks good to me! Could you test it on hardware with both orders on a Pico or other board? If you have done so already, great. I just want to make sure there hasn't been a regression.
I tested it on my hardware only, so the BCLK before LRCLK case.
.SO_REUSEADDR, 1 now prevents EADDRINUSE, and .SO_REUSEADDR, 0 raises EADDRINUSE within the timeout. Thanks, @jepler !
really appreciated the testing @anecdata !
The silabs port jobs are having trouble fetching the SDK today. I noticed this locally when trying to set up submodules in a new repo clone. So we'll ignore those build errors for now.
Closing, fixed by https://github.com/adafruit/circuitpython/pull/9084
Dan commented in another thread that adafruit_httpsrver does not need to use ConnectionManager.
Dan commented in another thread that adafruit_httpsrver does not need to use ConnectionManager.
I meant that the actual adafruit_httpserver library does not need ConnectionManager internally. But it's fine and useful to use ConnectionManager in a test program. ConnectionManager makes it easy to get the socketpool and the ssl context.
If you want to open a new PR to use Connection...
Thanks for clarifying, Dan
just for completeness of this thread... raspberrypi SO_REUSEADDR implementation added in #9084
@slender iron @onyx hinge I think I will do a 9.0.1 tonight or tomorrow morning with the current set of useful 9.0.x fixes: SO_REUSEADDR, displayio warnings off, minor pin and doc fixes
sounds good! thanks Dan!
@tulip sleet My pull request for minimqtt is failing because it can't import adafruit_ticks, does that need to be added to the test build environment?
add it to requirements.txt
Thanks for the testing on your board. I tested on an Adafruit Feather RP2040 Prop-Maker, and it worked fine.
On PicoW with the adafruit_httpserver library, after the MemoryError: is caught in httpserver, gc.mem_free() shows ~40KB+ free.
Tested an alternate simple-as-possible socket-level HTTPS server (w/o the library)... free memory before the accept call is ~80KB+, and ~50KB+ before the socket close. But simple requests can be received, and simple responses can be returned.
So it may be a "purely" memory issue (as opposed to something else masquerading as a memory error)... perhaps some...
I wonder if my issue getting an original ESP32 to work with a Parallel Display Bus LCD is down to how esp-idf seems to reference DMA and PSRAM within the i80 transmission functions..
Automated website update for release 9.0.1 by Blinka.
@dhalbert i added your xtal start issue prevention sugention ;) Many thx !
@dhalbert i added your xtal start issue prevention sugention ;) Many thx !
You're welcome! For background on this see:
https://github.com/raspberrypi/pico-sdk/pull/457
and https://github.com/raspberrypi/pico-sdk/pull/401 (which takes a while to reach the right conclusion).
@dhalbert thx ... interesting reading material ;) We use the RP2040 chip in many of our projects (10+ and counting ;)) and never ran into this issue ... luck must be on our side, hard fault on serial disconnect that was the first thing that really broke things ... but that's been solved in 9 also ... something to test in the weekend ;)
How does EPaperDisplay.time_to_refresh get set? https://docs.circuitpython.org/en/latest/shared-bindings/epaperdisplay/index.html#epaperdisplay.EPaperDisplay.time_to_refresh. Am I understanding the intention of it correctly that if you attempt a refresh and catch the "Refresh too soon" error, then sleep for the value returned by this property refreshing afterward is expected to be allowed?
We thought it had to do with our choice of capacitor and crystal but redoing the capacitor values did not seem to fix things. Not that many boards had the trouble, but it was a noticeable small fraction util we add the startup delay.
https://blog.adafruit.com/2024/03/26/circuitpython-9-0-1-released/
Notable changes include:
- Implement socket SO_REUSEADDR on Pico W.
- Turn off warnings about displayio name changes introduced in 9.0.0.
This updates the CI actions that have been updated to Node.js 20, and also sets show-progress:false on the checkout@v4 action.
Still awaiting an update for peaceiris/actions-gh-pages@v3. See https://github.com/peaceiris/actions-gh-pages/issues/1070.
Thre is something that looks like rate-limiting going on with git-lfs operations in ports/silabs when fetching its submodules. This is causing stalling and failures of ports/silabs builds. I've raised this in the Silabs support forum: https://community.silabs.com/s/question/0D5Vm000006eUqpKAE/difficulty-with-gitlfs-downloads-not-http-509.
There is a notice here about bandwidth limits, but I am not seeing 509 failures, just very slow fetches: https://github.com/SiliconLabs/.github
I will ping our Silabs github contacts if i don't hear back sometime tomorrow.
Yup, all my work can be trashed. It was mostly to show what each setting changed to help make decisions. Let me know if I can help. I've written a few pre-commit hooks myself...
If we have our own hook, we can also do things like make rules for code that doesn't work. Like importing something from os that doesn't exist...
@tulip sleet Should routine maintenance PRs go against 9.0.x?
if they fix a bug that needs fixing, sure. We will merge to main for 9.1, and if we don't release another 9.0.x, they'll still get in. What did you have in mind?
Just looking at adding some frozen libraries to the new Sunton board, haven't tested it out yet to see if it's worth doing.
that board addition was merged to main, so add frozens to main
Is there a reason why I shouldn't submit an example for httpserver with connection manager? Seems like Anecdata wasn't too keen on mixing them together. I have no idea what either of them does under the hood.
thx 😁
no, it's fine. It was a misunderstanding about what I said. CM is not needed inside httpserver, but the objects you need to set up httpserver could come from CM
ah ok yes that was the intention, only for set up.
that is, the args passed to the constructor or whatever
macOS Sonoma 14.4.1 is out, bug fix release, no change in this behavior
Turn off warnings about displayio name changes introduced in 9.0.0. Aww I actually really liked that feature.
CircuitPython version
Adafruit CircuitPython 9.0.0 on 2024-03-19; Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM with ESP32S3
Board ID:adafruit_feather_esp32s3_4mbflash_2mbpsram
Code/REPL
# This used to work fine in 8.0.0 beta on an Adafruit ESP32-S2 Feather
from analogio import AnalogOut
# Adafruit arcade button with LED. Only supplies power to the LED.
Reset_LED = AnalogOut(board.A0)
Reset_LED.value = 65535
I switched boards to the ESP32-S3 feather ...
Hello here, I have a question that I think belongs here more than in #help-with-circuitpython , but let me know if I am wrong.
I am adding support for a board that has an SSD1306 screen. I added adafruit_ssd1306 and adafruit_framebuf as frozen modules so that the screen is automatically usable.
My issue is that font5x8.bin is missing to draw text on the screen, and I am looking for a way to embed this file in the uf2 firmware to have it automatically available on the CircuitPython filesystem.
Is there a mpconfigboard.mk directive to embed assets on the filesystem?
You can define which font is used as the default display font like this board definition does:
There's almost assuredly some other board that does what you're looking to do, or very close to it, if you can find the right search terms.
the boards with built-in displays use displayio by default
If a driver for an as yet unsupported epaperdisplay is available for micropython, how big of an undertaking would it be to port it? Essentially a rewrite, or a mild coercion?
depends how different the protocol is from the already supported ones
often it's just a question of specifying a different init sequence
Naw its super different. It doesn't even have a traditional controller chip. Its a 8 bit parallel wired panel that the esp32 drives directly.
8 bit seems like too few bits for direct driving, is this just an 8-segment display?
in particular, it's this product: https://www.lilygo.cc/en-ca/products/t5-4-7-inch-e-paper-v2-3
LILYGO®
LILYGO® T5 4.7 Inch E-paper V2.3 ESP32-S3 Development Driver Board Display Module Support TF Arduino Compatible Raspberry Pi Due to the problem of the characteristics of the ink screen, it cannot be partially refreshed for a long time, otherwise, it will leave residual images and lead to irreversible damage. T5 4.7 Inc
looking at the datasheet, it looks like your regular spi display: https://github.com/Xinyuan-LilyGO/T5-ePaper-NewPanel/blob/master/datasheet/QYEG0290BNS800F6/QYEG0290BNS800F6_V1.0.pdf
see second page of the schematic/
in any case, the fact that it uses parallel instead of spi doesn't make it direct drive
you just use a different bus, the driver should be the same
Yeah, I don't know where I read the direct drive thing, clearly 8 bits wouldn't be enough for that.. I'm fairly sure it is 8 bit parallel, though.. they, unsurprisingly, seem to have conflicting information on their data dump..
https://github.com/Xinyuan-LilyGO/LilyGo-EPD47/blob/master/schematic/T5-4.7-Plus.pdf This seems to be the actual device in question.
yeah, just found it too
there is a datasheet for the display
but nothing abut the chip
ah, no, github lies to me, there is more
anyways, I think it should be relatively easy to port
Tested this with a Trinket-M0 (SAMD21):
- 8.0.5: 18416
- 8.2.10: 18480
- 9.0.1: 17552
This is in so far interesting, since we have 9.0.1/8.2.10 = 95%. And when I disable PICODVI and USB_HOST I have 94% for the Pico-W. So my assumption is that these 5% loss are from merging MicroPython. Drilling down into the symbols might give some more insights.
I also worked through the .data, .bss and .itcm sections, but there is not much room for improvement left. Disabling mdns, webworkflow an...
An annotation should probably be added to the Essentials learn guide Analog out page to advise users that there is no DAC on ESP32-S3.
changed the Makefile: include PicoDVI conditionally only when PICIDVI is set
The above tight loop with sensor readings has been running for 3 days contiguously (thanks to the power bank and also a bit due to the spring weather with some sunshine that charged the battery), without hitting the dreaded internal watchdog timeout. By now it has consumed both batteries so it is slowly descending towards drained battery, unless there is a lot of sunshine tomorrow which is likely, however because of these 2 properties (drained batteries and no sight in reproducing the problem...
Adafruit CircuitPython 9.0.0-15-g0046e3d8b7 on 2024-03-27; LILYGO T5 4.7 S3 EPAPER with ESP32S3 everything's working except the display.. which, of course, is 95% of the work 😄
you should be able to get something working by taking an existing eink driver, switching it to parallel and replacing the init sequence with one from that micropython driver
assuming this display follows standards in place, sure..
An annotation should probably be added to the Essentials learn guide Analog out page to advise users that there is no DAC on ESP32-S3 and they should use PWM.
The Essentials Analog Out section was written way before non-atmel-samd boards, and could use some cleanup to be less specific. The board-specific Learn Guides for ESP32-S3 do not include an Analog Out page (or at least the ones I looked at don't).
@bablokb How much RAM does this save? Does this get back a lot of what you were missing?
why wouldn't it
This looks good and there is no downside. Thanks!
What I would do now: Pimoroni has a number of boards (mainly with e-ink displays) that have an integrated Pico-W. Unless you have advanced soldering skills, the pins are not accessible. So disabling PICODVI and USB_HOST on these boards would probably not hurt anybody but would reclaim 20K of RAM. Maybe there are other boards as well that are candidates for this change, but I don't know.
That's a fine idea, if there is no way to have those use PCIODVI and USB host in any case. Thanks!
in preparation for 9.1.0-beta.0
Closing because this will be fixed in 9.1.0-beta.0 due to the ESP-IDF update.
So is this ready to merge or are we waiting on the issue you linked first?
You can merge it anyway, or just hold it up. It reduces the number of Node.js 16 warnings but there's still one left. I'm not sure why a merge conflict happened.
@slender iron I think it's time to do 9.1.0-beta.0, ya think? No pending PR's that look necessary. Is there something you are awaiting from TinyUSB you want to include?
I'm going back and forth on this. Adding the frozen library appears to save about 10K when running applications that use the libraries which isn't a huge amount but the device only has 520K and has some memory hungry devices (WiFi, LCD and Touch Screen).
I figured I'd go ahead and submit it, but if freezing libraries isn't desirable for some reason it's probably not critical.
The original motivation for frozen libraries was RAM-starved devices, like the CPX (32kB RAM). We haven't frozen things in general on ESP32 boards, but if you're having trouble fitting reasonable-sized projects, that could be a motivation. The whole point of this board is the display.
Well PyDOS isn't a "reasonable" sized project :laugh:. According to GC there's something like 115K available before loading any libraries and after loading the libraries I still have something like 75K so I would argue that typical/reasonably large applications are probably fine without the frozen libraries.
and dynamically calculate dvi_vertical_repeat
the 640x240 mode was useful for a little project of mine
It'll come back later.
All I'm working on can wait. It'd be good to get soak time on IDF 5.2. Maybe review jeff's PR he just made
What are the marking on the ribbon cable of the display?
it's hidden behind the display which is stuck down with adhesive.. but it's got 8 data pins, sth, ckh, cvk, stv and le pins..
as well as data, sck, adn str..
so lots of pins..
its a model ed047tc1 epaper display
Comment on one thing I don't understand.
Could you test this against some existing working cases to check for regression? Thanks.
640x240 -> 640x480? This does not preserve the aspect ratio. If that's what you want you could add this to the lines 640x480 and 320x240 if arm.
i am going grocery shopping and will start on the release when I get back.
silabs jobs are continuing to fail. We just to have ignore these for now.
Ah, ya. We don't support those displays at the moment.
Yeah, I didn't think so.. It's the same panel as the M5Paper, but that has a IT8951E chip driving the display through SPI
that's a different class of displays than what we already support
yup, we usually have a driver chip to talk to
i think the work entailed bringing that support to Circuitpython is beyond me at this point 😄
ya, it's not simple
well, i guess I'll try to come up with something clever to do with this device in edf-isp / arduino..
That's right, this mode will double pixels vertically but not horizontally. Lots of "classic" computers have modes with extremely non-square pixels such as CGA's 640x200 mode.
I thought Todbot was joking when he mentioned the DAC. There really is no analogout on this board? The pinouts reference GPIO pins for A0-A5. I feel like not being able to do AnalogOut should be mentioned in pinout diagram. I thought the DAC was only needed for music. 🤦
so you'd rather the resolution changing code looked more like this?
if ((width == 640 && height == 480) ||
- (width == 320 && height == 240)) {
+ (width == 320 && height == 240) ||
+ (width == 640 && height == 240)
+ ) {
timing = &dvi_timing_640x480p_60hz;
} else if ((width == 800 && height == 480) ||
- (width == 400 && height == 240)) {
+ (width == 400 && height == 240) ||
+ (width == 800...
Feel free to join us on #circuitpython-dev on Discord if you need help with CP core code.
oh it's great when you have code comments in there and discord translates the markdown as H1 headers instead.
@midnight ember also classic
i come back to discord and be like oh nooo it's so shouty. doesn't matter if you edit it. once it pops into dev chat it stays like that permanently. it's honestly a bit embarrassing. 🥹
that bot should just escape markdown
i think part of the problem is that it doesn't see the backticks everywhere. sometimes it's printing them literally instead of formatting it with them.
yeah or just skip the markdown. it's inconsistent.
Thankfully it's supported by ESPHome.. so its not all in vain!
Yup, that's what I meant, since all those cases choose the same timing value.
Anyone ever bothered to put Circuit Python on a quadcopter flight controller? They would be an interestings platform for robotics projects, having a bunch of position and accelleration sensors and servo outputs, and such..
That is correct, the ESP32-S3 does not have DAC. See https://learn.adafruit.com/adafruit-esp32-s3-feather/pinouts#logic-pins-3115989. The pinout diagram on that same page shows ADC channels on the An pins; it does not show DAC.
Hey, folks! My editor split an fstring into two lines, and CircuitPython failed with invalid syntax. I added a + to the first line and it works. Is that expected?
that has been my experience
Thanks so much!
No, but I wouldn't use it for the PID loop to keep it flying. You probably want the speed of C for that.
Oh no, it wouldn't be a flight controller anymore :D. Could be good for ground based projects.
I've got a MatekF405 fc here. Might try to get it and all its telemetry sensors and such working in circuit Python tomorrow, just to see if I can.
:laughing: OK, I think you're suggesting we close this.
I've learned that only the part of the string with the variable requires the f" in front otherwise there's some obscure error pylint will throw about the concatenated f-string line having no variable.
here's an example. this goes in and out of f-string mode. technically this is the most correct form of an f-string concatenation. only using f"" when/where needed.```py
TWITCH_FOLLOWERS_SOURCE = (
"https://api.twitch.tv/helix/channels"
+ "/followers?"
+ f"broadcaster_id={TWITCH_UID}"
)
also, in circuit python sometimes the above might fail with a syntax error but the below will succeed.
```py
TWITCH_FOLLOWERS_SOURCE = ("https://api.twitch.tv/helix/channels"
+ "/followers?"
+ f"broadcaster_id={TWITCH_UID}"
)
it can be very picky about indentation with concatenated strings.
TWITCH_FOLLOWERS_SOURCE = (f"https://api.twitch.tv/helix/channels"
+ f"/followers?"
+ f"broadcaster_id={TWITCH_UID}"
)
```while this one does work, pylint will hiss at you like an angry opossum for using f-strings in lines without {variables}
Interesting. Thank you!
splash.y=display.height//2
On CP 9.0.0 this line results in RuntimeError: Read-only. Is there any other way of shifting the terminal on display now?
Sometimes fast iteration by using only repos and not reading the learn guides after a while has its drawbacks. This is not an issue, it's user error. Closing.
@matemaciek Please file a new PR about this message. This most likely is an undesired side-effect of https://github.com/adafruit/circuitpython/pull/8923 that should be fixed.
When I try to use the ST7789 driver for this, I get an error:
Traceback (most recent call last):
File "code.py", line 14, in <module>
AttributeError: 'module' object has no attribute 'SPI'
The code was the example at https://github.com/adafruit/Adafruit_CircuitPython_ST7789
... and the 'module' is 'board'
I am gathering from the above conversation that LilyGo isn't using SPI to drive the ST7789. Can you help point me in the direction of how to get the CircuitPython Adafruit_gfx...
This is strange. I installed 9.0.1 on QT Py ESP32 Pico, and used @RetiredWizard's test program, and it's not breaking for me:
Adafruit CircuitPython 9.0.1 on 2024-03-27; Adafruit QT Py ESP32 PICO with ESP32
>>>
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Hellorld! 37076
Hellorld! 8797
Traceback (most recent call last):
File "code.py", line 7, in <module>
KeyboardInterrupt:
Code done running.
Press a...
To create the soft reboots, I was saving files to the device while code.py was running using web workflow.
If f you're using the tdisplay-s3, its a parallelbusdisplay and I believe it's already set up on boot for use feom the import board module. Just use display = board.DISPLAY instead of trying to use a LCD driver or initialize a bus. Its all done under the hood.
I am amazed at the synchronicity of this being PR #9100.
FoamyGuy just made a really neat quick video on the new board specific stubs. https://www.youtube.com/watch?v=VF2AK64koxg Definitely looking into this.
Thanks for the reminder. It's umm been a while. 😬
Is there a way to specify a git repo or something to keep this updated? Mine is obviously not setup to automatically update.
I would like to use repl.py to run a "virtual repl" after code.py runs on boards that aren't connected to a host PC and have an alternate input method not supported by the core (serial matrix/i2c keyboard, touch screen, etc) but currently after code.py finishes the
Press any key to enter the REPL. Use CTRL-D to reload.
message is displayed and unless an input device supported by the core is connected Circuit Python is done.
I think the advantage of this would be that as I ...
CircuitPython version
Adafruit CircuitPython 9.0.0-14-gc035ade1fd on 2024-03-27; sunton_esp32_2432S028 with ESP32
Code/REPL
No Code.py
or
import sys
a = ""
while a != 'q':
a=sys.stdin.read(1)
Behavior
When the board powers up with no code.py running, random characters frequently appear as input to the REPL, I believe if the core reads the uart device for console input at the "press any key to enter REPL" prompt and encounters a non-u...
Replace non UTF-8 character on serial UART input buffer during board startup at "Press any key to enter REPL" prompt.
Fixes #9104
@bill88t Was this resolved by #7973?
There is still a oddly specific Cx desync issue which I have workarounds in place for.
With that one workaround it's perfectly stable.
Without it, my terminal line is not printing no matter how hard I .flush().
@slender iron To practice for an eventual litex/orangecrab port, I'm trying to get the litex/fomu port building on a recent compiler (gcc from the fomu-toolchain v1.6 is old).
Using Debian Bookworm's gcc-riscv64-unknown-elf to compile for rv32i works well enough, but finding a suitable standard library to link against is more challenging.
Maybe I haven't looked in the right place yet, but so far I haven't found a supported RISC-V toolchain with a pre-built newlib standard library for rv32.
It seems like people who want an rv32 standard library tend to compile their own toolchain. I'd like to avoid creating a procedure that would require instructions starting with, "First you compile gcc..." I suppose it wouldn't be as slow as compiling a kernel, but still, it wouldn't be great.
At the moment, it looks like my best bet may be to use a prebuilt compiler from Debian (or Ubuntu LTS), then use a fetch-port-submodules to download newlib source, then add a make rule to build newlib? Does that sound plausibly reasonable?
If there's only one device on the bus, the chip_select pin of the peripheral can be fixed in hardware, therefore lowering the number of pins required on the microcontroller side.
This patch allows this by making the chip_select pin optional.
@bablokb How much RAM does this save? Does this get back a lot of what you were missing?
This only saves a few bytes. The change mainly speeds up the build and will make room in the firmware for other things.
Not really the way Python works. You just need to run that command occasionally. A new version is created with each CP release. So, when you download a new UF2 for a board, just update it then...
That's the problem. I never remember to.
I would also say it probably doesn't matter. Things don't change that much between major versions...
This doesn't look finished. There are a number of places in shared-module/fourwire/FourWire.c where self.chip_select is referenced and assume not to be None, e.g. line 83, and a bunch of others.
@onyx hinge do you want me to wait for https://github.com/adafruit/circuitpython/pull/9102 (640x240 DVI) to get it into 9.1.0-beta.0?
i'm working on the sht4x trinkey guide and starting on the sht4x demos in CP. when i call i2c = board.I2C() i get ValueError: Invalid pins. when i call i2c = busio.I2C(board.SCL, board.SDA) the sensor instantiates and the loop runs. dir(board) returns ['__name__', 'I2C', 'NEOPIXEL', 'SCL', 'SDA', 'TOUCH', 'board_id']. it seems odd that board.I2C() is not working unless i'm missing something?
that is odd, I'll take a look.
thank you!
@tulip sleet oh yeah it would be nice if this was in 9.0.x. I'll take a look this morning and switch which branch it's going in to.
well, since I just did 9.0.1, I don't think I'll 9.0.2 immediately, unless I need to for the sht4x trinkey (just above). But it could go in the 9.1.0beta.0 (typo above, fixed)
there's a compile error and it would be good to test for regressions for the typical non 640x240 case
the pins are wrong in mpconfigboard.h. I'll fix this and see which version it needs to go in
OK, I'll look at it still
thanks!
could you test this?
When is the guide coming out? That will help me schedule 9.0.2 to fix this.
@tulip sleet that works 🙌 i was going to be putting it into review later today/early tomorrow probably
thanks, i appreciate it
adafruit_sht4x_trinkey_m0: The SCLSDA pins specified for board.I2C() were reversed. Fixed that and made order consistent (alphabetical) in mpconfigboard.h and pins.c
@onyx hinge - ok, as seen above we need a quick 9.0.2, so if you want to rebase and test for regressions in the 640x240 PR It will go in 9.0.2, which I will try to release later today.
@tulip sleet no, probably best not to try to do this under pressure. Thanks though! I can make my project work either way, the text is just scrunched if the 200 line mode is not available.
ok, we'll just wait on that and you can reference a 9.1.0-beta.x in any guide
@slender iron I was going to make a 9.1.0-beta.0 today. Only addition from yesterday is a pin fix for trinkey sht4x. Do you have anything else to go in? Same fix is also going into a 9.0.2 (only fix for 9.0.1 -> 9.0.2, due to impending guide)
I don't think there is a mechanism built in to update it automatically but there are a few ways that it could be set up. The easiest is probably using Task Schedule (on Windows) or Cron (on Linux) or whatever the Mac equivalent is, to schedule a script to run once per day or however often you want have have it run a command like pip install circuitpython-stubs --upgrade I think that will check for versions newer than what you've got and install them if found. So if you run that once per day you'd stay up to date with new releases.
Another option perhaps more complex is to clone the circuitpython core repo locally and then use a similar type of daily repeating script to pull the repo and then build the stubs. Then you could use "editable" install with pip by going into the stubs directory and doing pip install -e . that will basically dynamically install whatever is in the directory you run it in (stubs in this case) and it will automatically notice any new changes in that directory. So if the next day you build stubs again and there is new stuff it will automagically be recognized in your python environment. This method is really meant more for development, and the way that the stubs need to be built out of the core repo ends up adding extra steps to this process. I'd probably recomend method above with install --upgrade instead. But if you ever find yourself working on local changes to something installed in pip this one is very convenient during development.
The only change to 9.0.2 from 9.0.1 is a fix for a pin error for the Adafruit SHT4x Trinkey board. You do not need to upgrade from 9.0.1 unless you are using this board.
We have seen similar junk on UART lines on startup, caused by other hardware issues: https://github.com/adafruit/circuitpython/issues/8890.
If this only happens on startup, then I think the fix is to clear the input buffer early on to discard any junk input.
I am not sure if your fix will work when a UTF-8 prefix is read and no further character is read immediately. Will the prefix then be discarded? If someone is trying to send a multi-byte UTF8 character then this I think may prevent ...
any known issues with ADC on nRF52?
Adafruit CircuitPython 9.0.1 on 2024-03-27; Adafruit ItsyBitsy nRF52840 Express with nRF52840
>>> import board
>>> import analogio
>>> adc = analogio.AnalogIn(board.A1)
>>> adc.value
0
>>> adc.value
0
>>>
reporting 0 regardless of actual value (using 10k pot as voltage divider)
same behavior on all Ax pins
not previously reported. I can try locally
@tulip sleet thanks. fyi. 8.2.10 works. so seems to be a 9.x thing.
Adafruit CircuitPython 8.2.10 on 2024-02-14; Adafruit ItsyBitsy nRF52840 Express with nRF52840
>>> import board
>>> import analogio
>>> adc = analogio.AnalogIn(board.A1)
>>> adc.value
35826
>>> adc.value
18785
>>>
maybe I'll need to release 9.0.3 today 🙂
Nothing imminent from me
My long term goal is to switch us to clang and build picolibc and compiler-rt when we need it
for exactly that reason
I thought I remembered seeing the issue before but I guess I didn't look hard enough. I like your idea of clearing the input buffer.
I think this PR only addresses a problem caused waiting for the "press any key to enter repl" prompt and it looks to me like that prompt only reads a single byte and doesn't really do anything with it except maybe check for ctrl-D. I don't understand how the non-utf8 char was causing the board to freeze but I haven't been able to reproduce the freeze since ma...
@danh I'm fine closing both #9104 and #9105 in favor of #8890, what do you think?
oh, wow... that might be just the thing I need
I am not sure it is the same bug: 8890 happens on ESP32-S3, but not -S2. I did not test on plain ESP32. But the probem might also be due to the USB-serial converter chip on the board not being reset properly, etc.
clang is easy to get. its the runtime libraries that are hard
in your case, I think some kind of clearing of the input buffer would help. I often see dozens of junk characters as first input on these ESP32 boards. There is often no reset line available for the USB-serial converters
would it perhaps be more interesting if I were to go off trail a bit and try a clang-based build with a new set of makefile stuff?
I've been trying that myself
I went even further and was experimenting with moving away from makefiles
though it is way more practical to integrate into our existing makefiles
Okay, I'll spend some time trying to figure out how to do a buffer clear, I may scream for help at some point 😁
Automated website update for release 9.0.2 by Blinka.
Why do you need it to run outside of code.py? I'd just make code.py a repl. This library may help with it: https://github.com/adafruit/Adafruit_CircuitPython_Prompt_Toolkit
You could also use supervisor.set_next_code_file() to run a subsequent VM with another python file.
I'm doing this on something like the cardputer or Hacktablet not connected to a host so all input goes though a virtual keyboard on the tablet or the cardputer keyboard.
The device boots into PyDOS through an import in code.py. The idea is that if PyDOS is exited or crashes a python coded version of the REPL would be available and started via repl.py. I'll look at set_next_code_file, I've tried using that for launching programs from PyDOS that wouldn't fit in memory along with PyDOS altho...
I reproduced the nRF AnalogIn problem right away. I could not find any code changes that would seem to affect this. But If I change the compiler from gcc13 to gcc10, the problem goes away (!).
@tulip sleet probably no surprise, but same thing happening on CPB
Adafruit CircuitPython 9.0.1 on 2024-03-27; Adafruit Circuit Playground Bluefruit with nRF52840
>>> from adafruit_circuitplayground import cp
>>> cp.temperature
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "adafruit_circuitplayground/circuit_playground_base.py", line 650, in temperature
File "adafruit_thermistor.py", line 126, in temperature
File "adafruit_thermistor.py", line 116, in resistance
ZeroDivisionError: division by zero
>>>
the denominator is just an analog read of board.TEMPERATURE
I think the compiler may be over-optimizing something
@tulip sleet want me to open an issue for general tracking?
i'll open one, that's fine, since I am already on the track of the cause. I'd kind of like to fix this pretty quickly, maybe today.
since it's pretty bad
The prompt_toolkit looks interesting, I'll have to see if I can simplify my ui abstraction using it.
The DOCS link seems to be broken for the Adafruit_CircuitPython_Prompt_Toolkit library though, fortunately it's not to bad figuring it out from the code.
[adafruit/circuitpython] New tag created: 9.1.0-beta.0
Automated website update for release 9.1.0-beta.0 by Blinka.
New boards:
- m5stack_cores3
- rfguru_rp2040
- sunton_esp32_2432S028
- waveshare_esp32_s3_geek
https://blog.adafruit.com/2024/03/28/circuitpython-9-0-2-released/
The only change to 9.0.2 from 9.0.1 is a fix for a pin error for the Adafruit SHT4x Trinkey board. You do not need to upgrade unless you are using this board.
Starting with early 9.0.0 releases, AnalogIn on nordic boards returns zero all the time, no matter what input is applied to the pin. For instance, even with A0 tied to 3.3V, you see:
>>> import analogio,board
>>> a0 = analogio.AnalogIn(board.A0)
>>> a0.value
0
The underlying code has not changed in some time.
We are currently using gcc13. I recompiled a nordic build 9.0.x with gcc10, and the problem goes away (!).
Added support for this 1.28" Touchscreen LCD ESP32C3 based device. Working built in spi display, i2c touch and user buttons.
Automated website update for release 9.1.0-beta.0 by Blinka.
New boards:
- m5stack_cores3
- rfguru_rp2040
- sunton_esp32_2432S028
- waveshare_esp32_s3_geek
https://blog.adafruit.com/2024/03/28/circuitpython-9-1-0-beta-0-released/
Notable changes since 9.0.0:
- Audio
- RP2040 I2SOut supports BLCK and LRCLK in either order.
- Built-in modules
- Enhance collections.deque functionality.
- Add keypad_demux.DemuxKeyMatrix: use multiplexer for one side of a keypad matrix.
- Add integration-based debouncing to keypad.
- Internal
- Espressif: update to ESP-IDF v5.2.1.
CircuitPython version
Adafruit CircuitPython 9.0.2 on 2024-03-28; Raspberry Pi Pico W with rp2040
Board ID:raspberry_pi_pico_w
Code/REPL
>>> help("modules")
Please wait a moment while I gather a list of all available modules...
/Applications/Thonny.app/Contents/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/_distutils_hack/__init__.py:33: UserWarning: Setuptools is replacing distutils.
warnings.warn("Setuptools is replacing...
Yep, @dsteidley I just verified what @SeanTheITGuy said is correct: just installing the CircuitPython for the LilyGo TDisplay S3 automatically creates the display and you can get it for your own purposes with display = board.DISPLAY.
If you do want to create your own, it looks like the equivalent is something like the below. But what I'd like to know:
why is rowstart & colstart swapped and rotation=270 compared to [lilygo_...
when rotated 270 (-90) degrees, the columns become rows, so colstart instead of rowstart makes sense, right? As to WHY it's rotated, I'd guess it comes down to how the individuals who wrote board.c vs that demo code wanted to hold the t-display.
There were several PRs like #8772 which eliminated the screen rotation of the display by updating the display init strings in the core board files. The library init strings probably haven't been updated the same way which is why you still need to specify the old rotation/rowstart/colstart values.
@dhalbert I tried moving the read loop down well below the board_init call hoping it would resolve #8890 but no matter where I tried the S3 I was testing on continued to come up with the stray byte. If you have any thoughts as to where the S3 needs the buffer cleared, let me know and I'll give it a try.
With the loop where I have it now seems to resolve the issue on the Sunton board.
@tulip sleet I'm not real happy with either of the Sunton UART fixes, filtering for non-UTF characters in serial.c still passes noise to the REPL so it feels partial at best and adding a buffer clear loop to main.c just to mitigate what's probably a device reset bug in the hardware design doesn't seem like a good idea either. Unless you think there's a better solution I'm thinking I should just close the issue as a hardware design flaw and be done. I'm also thinking the S3 bug feels like it's something different, I don't think that one happen in 8.x.
This is OK with us. We discussed the S3 issue internally and the essential point that was madeithen was that there can be junk on UART lines when starting up, and the user's code should guard against it.
After some testing I don't think this is the same issue as #8890. My best guess at this point is that this is caused by a startup issue with the board design. If there's no code.py running to catch and discard the noise it can be annoying to start the board with the UART connected to a host, as it may take several boot attempts, but if code.py is running, it can easily discard the noise.
I'm going to close this as it seems to be hardware related as well as the associated PR #9105.
Closing because tested solutions don't feel generally useful as they address a specific boards hardware quirk.
Thonny seems to be showing you your host computer. Can you directly connect to the Pico W serial REPL with Thonny, or over web workflow, or over USB with a different serial client?
Thonny seems to be showing you your host computer. Can you directly connect to the Pico W serial REPL with Thonny, or over web workflow, or over USB with a different serial client?
I am still kind of new to this. How do I connect to the Pico W serial REPL specifically? I thought that I was accessing the pico via thonny when I was using the code.py file open. Is that not the same REPL?
Thonny seems to be showing you your host computer. Can you directly connect to the Pico W serial REPL with Thonny, or over web workflow, or over USB with a different serial client?
Wait I may have just figured it out based on your comment. I was able to change the intepretor language from local Python 3 to Circuitpython and it found my device:
Adafruit CircuitPython 8.2.10 on 2024-02-14; Raspberry Pi Pico W with rp2040
>>> help ("modules")
__future__ builtins ...
Thought spurred by a review discussion in adafruit_httpserver:
https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer/pull/91#discussion_r1542612641
Example native wifi code commonly uses os.getenv("CIRCUITPY_WIFI_SSID") etc. with wifi connect logic, though that implies wifi has already auto-connected. Example.
Web [workflow](https://docs.circuitpython.org/en/la...
It may be too late, but a names like CIRCUITPY_WIFI_SSID_AUTOCONNECT or CIRCUITPY_AUTOCONNECT_WIFI_SSID (and same for PASSWORD) would make this clearer.
We could make the new manual name the longer one since auto-connect is the de facto (and still have the CIRCUITPY_ prefix.
I also had this idea, but I thought we could just add CIRCUITPY_AUTO_CONNECT and users could set it to False...
I like that, seems cleaner than two sets of credentials.
I just discovered something I'm curious about. Is there a technical reason why the sdioio library has been included in the atmel-samd, broadcom and cxd56 ports, but not esp32? Or is it simply a matter of lack of demand?
It is implementation I think
If settings.toml contains:
A_NUMBER = 123
os.getenv("A_NUMBER") will return the int 123.
This is non-standard compared with CPython, where os.getenv() always returns a string or None.
This came up because I was thinking about adding TOML bool support (true and false) to what we can parse in settings.toml.
I'm not sure this is worth fixing, but I think it's possible to fix.
I do like the CIRCUITPY_AUTO_CONNECT flag idea, and it defaults to true. We don't have support for TOML booleans (true and false) right now, but it could be added. We've kept the implementation very minimal so it fits on some small boards. Or we could use 0 and 1. Slightly related: #9113.
I'm also good with 1/0 or even "True"/"False"... Does the c code for auto connect use the same methods as the getenv does?
It uses some internal methods like common_hal_os_getenv_int() from shared-module/os/getenv.c.
Gotcha. So it would create a little bloat if added...
this behavior seems unusual:```
Code done running.
MemoryError:
MemoryError:
MemoryError:
does it repeat? it's so out of memory it doesn't even have room to set up the error message to rpint
just the three times
but in the past I don't recall getting multiple MemoryError:
and getting it after code stops
it can be debugged if you want to open an issue
the hardware setup is non-trivial and a bit contrived https://fosstodon.org/@anecdata/112171917417772517 or #help-with-circuitpython message
- Fixes #9109.
This is quite mysterious. The underlying code hasn't changed in quite a while. nordic AnalogIn.value was always returning zero on 9.x.x builds, including some early betas. The problem starts appearing when gcc13 starts being used. Compiling with gcc10 or gcc12 causes the problem to go away.
While debugging, I added a printf which also caused the problem to go away. Adding tiny delay calls almost anywhere also helped. Eventually I realized it may have been due to these ...
Thank you for the suggestion. Wrote a playground note for Windows devs on how to set that up. https://adafruit-playground.com/u/DJDevon3/pages/automating-pip-circuitpython-stubs-updates-for-windows-users
[adafruit/circuitpython] Issue opened: #9115 Adafruit ESP32-S2 Feather ESPIDF Memory & Socket Errors
CircuitPython version
Adafruit CircuitPython 9.0.0 on 2024-03-19; Adafruit Feather ESP32S2 with ESP32S2
Board ID:adafruit_feather_esp32s2
Adafruit CircuitPython 8.2.5 on 2023-09-07; Adafruit Feather ESP32S2 with ESP32S2
Board ID:adafruit_feather_esp32s2
Code/REPL
import gc
import traceback
import os
import time
import wifi
import ssl
import socketpool
import adafruit_requests
start_mem = gc.mem_free()
print(f"Prior to Script Configurations: ...
I have a cheap board from the Chinese market and couple my own with mini modules.
<img src="https://github.com/adafruit/circuitpython/assets/8849896/49664758-a55d-479f-b8ed-3449dcea4c33" width=200>
Can confirm that 8.2.10 is installable and usable, but any 9+ versions have serious problems to work on ESP32-C3
Hi there, we are running into a strange error and can't find any solution so far. We implement CP for the senseBox MCU with ESP32S2 (https://github.com/adafruit/circuitpython/tree/main/ports/espressif/boards/sensebox_mcu_esp32s2). The standard qwiic ports use GPIO39 and 40 for the I2C. The onboard MPU6050 is connected to the secondary i2c using the SDA=GPIO45, SCL=GPIO42. If we try to setup the secondary i2c using i2c = busio.I2C(scl=board.SCL1, sda=board.SDA1) we are running into the error: ValueError: Invalid pins . We already tried the script (https://learn.adafruit.com/circuitpython-essentials/circuitpython-i2c) identifing the i2c and possible combinations, but SDA1 (GPIO45) never shows up in the list. I already tried to update the pin definitions to G42 and G45 and build a new CP but same error. Is the GPIO45 somewhere is defined, so that it is blocked? In Arduino everything is working fine.
Removed these functions, since these boards cannot make use of them anyhow. See #9085
@tulip sleet -- a nit-pick, but in the release notes shouldn'tThis is CircuitPython 9.1.0-beta.0, a beta for CircuitPython 9.1.0, and is a new unstable release. This release has known bugs that will be addressed before 9.0.0 final. read This is CircuitPython 9.1.0-beta.0, a beta for CircuitPython 9.1.0, and is a new unstable release. This release has known bugs that will be addressed before 9.1.0 final. ?
good catch.
Fixed in all places - thanks!
From I2C.c for espressif:
// Pins 45 and 46 are "strapping" pins that impact start up behavior. They usually need to
// be pulled-down so pulling them up for I2C is a bad idea. To make this hard, we don't
// support I2C on these pins.
//
// 46 is also input-only so it'll never work.
I will check that this is true on ESP32-S2. Right now this is not conditionalized for any particular chip. how are you doing pullups on 45 and 42?
From the ESP32-S2 technical reference manual:
By default, GPIO0, GPIO45 and GPIO46 are connected to internal pull-up/pull-down during chip reset.
Consequently, if the three GPIOs are unconnected or their connected external circuits are high-impedance, the
internal weak pull-up/pull-down will determine the default input level of the strapping pins (see Table 54).
GPIO45 is used to select the VDD_SPI power supply voltage at reset:
• GPIO45 = 0, VDD_SPI pin is powered directly from VDD3P3_RTC_IO via resistor RSP I . Typically this
voltage is 3.3 V.
• GPIO45 = 1, VDD_SPI pin is powered from internal 1.8 V LDO.
Do you have one of these boards and are adding the board so you can use it?
I see espidf.MemoryError: on ESP32-S2 during requests _get_socket (8.x.x), even after a fresh reset. My code automatically retries a few times, and if those fail, resets (microcontroller.reset). It may go a few cycles like that, then be successful either after the retries or after one or more resets. I have suspected something variable not quite ready in the ESP-IDF on startup, though sometimes it can happen well into a run. No idea if this is comparable to your situation.
I do have one. I am using it. I thought it might be useful for others, so I shared what I came up with. It's the same form factor as the Waveshare 1.28 rp2040, but with an ESP32.
Adjacent to #9113 I wanted to explicitly test that string values have to be quoted when they appear in settings.toml.
It's worth noting that the formula x = int(getenv("VAR")) will be portable between circuitpython & standard python.
In this picture, from https://www.luisllamas.es/en/sunton-esp32-round/, I see a switch, maybe that's it?
Were you able to test this on an older working test case? Thanks. I just want to make sure there is no regression due to the new code further down in the change.
I tested the following modes:
{"width":320, "height":240, "color_depth":8},
{"width":640, "height":240, "color_depth":1}, # (new)
{"width":640, "height":480, "color_depth":1},
{"width":800, "height":240, "color_depth":1}, # (new)
{"width":800, "height":480, "color_depth":1}):
the 400x240@8bpp mode would not initialize:
MemoryError: memory allocation failed, allocating 110412 bytes
This allocation is the framebuffer of 96000 bytes plus the "TDMS ...
It is not. That only ties to the power management chip.
Waveshare support got back to me and supplied the Product ID for this device. Apparently they renamed the device since applying for the Product ID. The original name was RP2040-HACK. I'm assuming the MICROPY_HW_BOARD_NAME doesn't have to match the registered name so it can stay as is with the correct (current) name.
This is not a solution by any means but if you're keen on getting something working.... I have been able to use these board by uploading files using a serial transfer program similar to the way mpremote works. It's a little unfinished as I got it working "well enough" and left it at that. The UI is a bit weird but once you get used to it, works ok.
I have used ampy and the web file.manager without issue on c3 devices. With 8.2 through 9.1-beta.
This looks fine. Thanks. Please submit a PR to https://github.com/adafruit/circuitpython-org as well with board details. See https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website.
Nice, I knew about ampy (https://learn.adafruit.com/micropython-basics-load-files-and-run-code/install-ampy) once but completely forgot about it.
thanks! Here are the schematics: https://github.com/sensebox/senseBox-MCU-S2-ESP32S2/blob/main/hardware/2.1/SenseBox-MCU-2-1.pdf wondering why everything is working with arduino
There is no external pullup on IO45 for I2C_SDA (or on IO42 for I2C_SDL either). Maybe they are expecting to use the internal pullups (which are really too weak). I would say that's not a good choice. Note that there are 10k pullups on the QWIIC I2C lines.
I can give you a hacked build that allows you try out the I2C_SDA and i2C_SCL lines, but it might complain there are no pullups
yeah I just tried this and get the errors for missing pullups
you could change #if CIRCUITPY_I2C_ALLOW_INTERNAL_PULL_UP to #if 1 or set that in mpconfigboard.h, or set CIRCUITPY_REQUIRE_I2C_PULLUPS to 0.
did they supply some sample code that uses IO45 to read from the IMU?
This one here is working: https://github.com/sensebox/senseBox-MCU-S2-ESP32S2/blob/main/examples/mpu6050/mpu6050.ino
My preference is to change the examples. My intention with the CIRCUITPY_ prefix was to mark values that are used by the CP core.
I think we need to double check that web workflow will start when wifi is manually connected and the api password is set. That way user code can manage roaming multiple networks and still have web workflow work.
we have to look the Arduino Wire impl to see what it does with internal pullups, if anything
This happens. I don't think it is a CP bug.
The ESP-IDF keeps all TLS related buffers in internal RAM and, as a result, the S2 will run out before the S3 does. The S3 has more internal RAM. Use it instead.
I don't see any pull-up settings happening here: https://github.com/espressif/arduino-esp32/blob/master/libraries/Wire/src/Wire.cpp
maybe I missed something in the schematic, but I don't know where the pullups are coming from for the IMU. If you measure the resistance pins 42 and 45 to the +3.3v line when the box is unconnected to power, what do you see?
Add newly merged board https://github.com/adafruit/circuitpython/pull/9090#pullrequestreview-1969157331
Also updated the Waveshare ESP32-S3-GEEK page to include the Display feature.
sorry don't have the tools right now to measure it.. but #define CIRCUITPY_I2C_ALLOW_INTERNAL_PULL_UP 1 in mpconfigboard.h solves it and i'm able to read out the data
That makes more sense, but having the asm volatile anywhere after the declaration worked. So I moved it. But that may be an idiosyncrasy of the optimized code. By rights it should be declared volatile, but the nrf routines don't expect that declaration.
Moved and re-tested to confirm.
If you set CIRCUITPY_REQUIRE_I2C_PULLUPS = 0, does that also work? That removes the test and also does not set the internal pullup.
we can make an exception for this particular board in the pin check
No then the sensor is not found.
I find it mysterious that the Arduino program works, since I can't see it setting the internal pullups anywhere, but maybe it is deeper down in the code. I'll look further
I'm thinking it has to do with the pin's reset state which is not changed when the I2C peripheral is enabled
You can find VID/PID yourself:
https://superuser.com/questions/1106247/how-can-i-get-the-vendor-id-and-product-id-for-a-usb-device
For the ESP32-S3 Sense is:
USB_VID = 0x303A
USB_PID = 0x1001
Trying to comply with Seeed Spreedsheet in wiki.
https://files.seeedstudio.com/wiki/SeeedStudio-XIAO-ESP32S3/res/XIAO_ESP32S3_Sense_Pinout.xlsx
Added camera pinout and remove unused pins.
My preference is to change the examples.
Change the examples to:
-
assume auto-connect, and remove
wifi.radio.connectlogic? -
don't assume auto-connect, and keep
wifi.radio.connectlogic:
2a. continue to use the settings.toml web auto-connect credentials?
(potentially confusing or undesired per OP)
2b. use alternate credentials as discussed above?
(a standard method will make support easier)
2c. implement the CIRCUITPY_AUTO_CONNECT as discussed above?
3...
Removed CIRCUITPY_ESPCAMERA = 1 not working with Seeed Xiao ESP32-S3 Sense
Configuring PSRAM in order to give Camera suport
USB_VID = 0x303A
USB_PID = 0x1001
USB_PRODUCT = "Seeed Xiao ESP32-S3 Sense"
USB_MANUFACTURER = "Seeed Studio"
IDF_TARGET = esp32s3
CIRCUITPY_ESP_FLASH_MODE = qio
CIRCUITPY_ESP_FLASH_FREQ = 80m
CIRCUITPY_ESP_FLASH_SIZE = 8MB
CIRCUITPY_ESP_PSRAM_MODE = qio
CIRCUITPY_ESP_PSRAM_SIZE = 8MB
CIRCUITPY_ESP_PSRAM_FREQ = 80m
Removed CIRCUITPY_ESPCAMERA = 1 not working with Seeed Xiao ESP32-S3 Sense
What is not working exactly? I had it working in 8.x. Even it there is a bug that makes it not work right now, I think it should be still enabled and the bug fixed?
By the way, there is an old PR for that board: https://github.com/adafruit/circuitpython/pull/8095
I think that the real problem is the PSRAM settings.
Now appears to be working. I will add CIRCUITPY_ESPCAMERA = 1 again and see if it works;
Reproduced with 9.0.0. Tested with 9.0.2 and problem is now gone.
Fixed by #9087.
The beetle c3 is near exactly the same in terms of pins and functionality. I also have a supermini target created but since this was rejected once, I never bothered to submit it.
1001 is also the pid for this esp32s3 7" display unit I have. So its not unique to that device, its a generic from espressif that, I guess, was intended to be changed by the boardmakers.
The pre-commit is failing on extra white space at the ends of the lines in pins.c
How can I change that? I am using notepad ++ to change files here.
It also gets tricky when using projects across boards. ESP32SPI won't auto connect. I'm pretty sure I've had code check for connection and return false because negotiation takes too long...
I think @tannewt is suggesting (2b.) above. We could even devise a simple standard connect code block with comments about auto-connect vs. manual connect, and I think we could even make the code for native wifi and esp32spi more similar (would require supporting esp32spi connect with 2 params rather than / in addition to a dict¹, and adding a connected alias). Snippets borrowed from connection manager examples. Something like:
# "If the keys CIRCUITPY_WIFI_SSID and CIRCUITPY_WIF...
Just delete the extra spaces.
Yeah, I would really like to make those the same...
I think now I've done. Sorry for this. Is my first time doing this.
I've also been experiencing this on my TinyC6 and had to use a modified version of the Serial-File-Manager by @RetiredWizard to be able to communicate with my C6 boards running CP when under test on my test jigs.
It would be great if we could work out what this is as it seems to be specific to the Espressif serial UART setup in their C3/C6 chips, so will likely effect the H2, C61 and C5.
It's possible that's why I stopped using it on the S2 around 8.0 beta. It would work for a while then crash. At the time it was suspected that there was an ESP-IDF memory leak. Very likely why I haven't used this project since. At the time the ESP32-S2 was far more stable than the S3. The S3 is now so stable that it works like a dream for most of my projects.
I can switch to an S3 but that's not really the point. Yes Anecdata the behavior you're seeing is similar. It's random and t...
This allows a localhost:4000-style URL to be generated for local testing, but still gives an absolute URL, which enhances compatibility with RSS readers. A comment is added explaining the reason for the absolute URL.
Closes #1374
I am going to merge this to get the missing boards in for now. I am not sure what will happen for #1378, but if there's a merge conflict it can be redone.
This now has merge conflicts due to merging #1375. But I am confused too: where does absolute_url come from?
I can re-do 1378 if needed.
OK, I see absolute_url is predefined, apparently. I'll approve this. Could you merge when you are ready to check the result immediately? Thanks.
[adafruit/circuitpython-org] New comment on pull request #1378: Generate absolute URLs automatically
absolute_url: https://jekyllrb.com/docs/liquid/filters/#absolute-url
let's do this now if you're able
[adafruit/circuitpython-org] New comment on pull request #1378: Generate absolute URLs automatically
generation looks good
<!-- (uses an absolute URL for better compatibility with RSS readers -->
<img srcset="https://circuitpython.org/assets/images/boards/small/raspberry_pi_pico.jpg 300w,
https://circuitpython.org/assets/images/boards/large/raspberry_pi_pico.jpg 700w" sizes="(max-width: 1024px) 700px,
300px" src="/assets/images/boards/large/raspberry_pi_pico.jpg" alt="Image of Board" loading="lazy">
```
[adafruit/circuitpython-org] New comment on pull request #1378: Generate absolute URLs automatically
hmm I lost the | absolute_url on the src=, oops
@jepler Merge if you're ready
Never mind, I will go ahead. I think you're offline.
Silly question, but just in case: correct to assume that rp2pio isn't present in Blinka or any other library? (Context: was trying to fix CI issues in adafruit-circuitpython-pio-uart, but any library that imports rp2pio seems like it would have a problem.)
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM with ESP32S3
9.0.2
9.1.0 beta 0
Code/REPL
a = ''
while a != 'q':
a = input('_$ ')
Behavior
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
_$ Traceback (most recent call last):
File "code.py", line 3, in
EOFError:
Code done running.
P...
Hello,
It looks like this issue is the reason why my Feather M4 express can not do PWM on pins A2, A4, and A5 (they're TC4[0], TC0[0], and TC1[0] respectively according to this chart, so it matches up).
Could you please update the Feather m4 express pinout documentation here to reflect this limitation? Currently it says:
A2 thru A5 - These are each anal...
CircuitPython version
Adafruit CircuitPython 9.0.0 on 2024-03-19; M5Stack Dial with ESP32S3
Code/REPL
import gc
gc.collect()
start_mem = gc.mem_free()
print( "Available memory: {} bytes".format(start_mem) )
Behavior
Available memory: 162912 bytes
Description
This memory seems not right for M5Stack Dial with ESP32S3 ?
Additional information
No response
When I run Adafruit CircuitPython 9.0.0 with M5Stack Dial with ESP32S3 to load Image Bitmap using adafruit_imageload.load, it always give me error like 'MemoryError: memory allocation failed, allocating 57600 bytes', thus I checked memory at the beginning of my progtram. To my surprise, it showed 'Available memory: 162912 bytes'. Is this correct?
I'm sorry @dhalbert, I am not familiar with the codebase and I should've spend more time on this.
I added checks for the chip_select pin.
There is a non-zero chance that @aivarannamaa can fix something in Thonny and it will work. But it would be good to understand exactly what the problem is. There seem to be solutions that work.
I like the web file manager solution, thanks a lot for the tip, I'll give it a try
Could you please update the Feather m4 express pinout documentation here to reflect this limitation? Currently it says:
Now noted in the Learn Guide. Thanks.
I believe that is correct. rp2pio is a core module implemented in C code. It's not available in Blinka (You can find which modules are included in Blinka here: https://github.com/adafruit/Adafruit_Blinka/tree/main/src)
Does anyone know what might lead to the readme badges being stacked vertically instead of horizontally?
I've seen this randomly on a few library repo's now. I briefly looked into it one day but could not spot any syntax differences in the readme file. I'm sure it's something I overlooked, but I'm not exactly sure what things could cause it beyond something like extra \ns inserted or similar.
Hmm, maybe they are all that way actually. I'm pretty sure there were still some horizontal ones when I looked into it maybe a week or two ago. but now I'm having trouble finding any examples of horizontal ones.
https://github.com/adafruit/Adafruit_CircuitPython_Wiznet5k I did manage to find one. Interesting there are tiny blue <a> tag underlines inbetween some of the badges.
okay, something very strange IMO. When I view the readme section at the "home" URL of that repo, they are horizontal as depicted in that screenshot. But if I click on the readme file specifically they change to vertical ⁉️
I guess it's something to do with 1 empty line vs. 2 empty lines i.e. https://raw.githubusercontent.com/adafruit/Adafruit_CircuitPython_PIO_UART/main/README.rst and https://raw.githubusercontent.com/adafruit/Adafruit_CircuitPython_Wiznet5k/main/README.rst. But I don't get why the same syntax could render different on "home" page vs. readme page. It seems to me there is something subtle and weird going on with github CSS and or .rst rendering engine.
what is a readme.rst? I've only seen readme.md... should I be using .rst instead?
Also you could just fake it like I did https://github.com/DJDevon3/CircuitPython_ST7796S I meant to get back around to using cookie cutter but never did. 😅
.rst and .md are just alternative formats. .md is Markdown, .rst is reStructured text. They're both ways to make "rich text" just different syntaxes. There are probably some pro's and cons, but I don't think it matters that much.
ah thank you. i probably could have googled that 🤦
detective foamyguy tracking down /n's
i'm seeing the same results you are.
some of the headings are double spaced, some are not. it looks random from manual typing input not something that's been run through adabot or formatted in a specific way.
wiznet looks uniformly formatted, very nicely. the PIO_UART is not uniform.
[not critical, just a fun exercise for me] - is there a standard way to handle libraries that include some micro-specific C module? (It seems like a nice addition to the rp2040). Context: my failed attempt to address CI issues here: https://github.com/adafruit/Adafruit_CircuitPython_PIO_UART/pull/2/checks
I am not sure if there is a way or not. I do not know of one, but it's possible it does exist.
Ack - thanks @lone axle !
Since the C3 was on my mind, I pulled one out for a project I was working on yesterday. I did use ampy to get the initial settings.toml file loaded, but once it was connected to WiFi, I used the Web Workflow for everything. The File Browser to transfer files, the Internet based full code editor and associated internet based serial interface (not the CP hosted serital console) and everything went very smoothly. I was even able to use the Web Workflow feature of Circup to check and update the l...
it might be nice if there was an application similar to Circup that could be used to manage the file system of Circuit Python devices over a Web Workflow channel.
In addition to streamlining simple operations, this might allow for automated configuration procedures to be used in setting up multiple devices or the use of operating scripts to perform more complicated file management operations.
I'll have to look back at @FoamyGuy's Web Workflow/Circup streams to see if there's a similar a...
The following was run with ~/.espressif wiped.
[bill88t@lunchbox | ~/git]> git clone https://github.com/adafruit/circuitpython cptest && cd cptest/ports/espressif && make fetch-port-submodules && cd esp-idf
[...]
[bill88t@lunchbox | ~/git/cptest/ports/espressif/esp-idf]> git status
HEAD detached at 722fba96a1
nothing to commit, working tree clean
[bill88t@lunchbox | ~/git/cptest/ports/espressif/esp-idf]> ./install.sh
Detecting the Python interpreter
Checking "python3" ...
P...
I still haven't tested CP with idf5.2, did anyone check wifi authentication messages? The changelog reported a lot of changes there, and I think scanning was fixed in this release too.
CircuitPython version
Adafruit CircuitPython 9.0.2
Code/REPL
import wifi
import adafruit_connection_manager
import adafruit_minimqtt as my_mqtt
cert_file = mqtt_data["cert_file"]
with open(cert_file, 'r') as file:
cert_data = file.read()
radio = wifi.radio
pool = adafruit_connection_manager.get_radio_socketpool(radio)
ssl_context = adafruit_connection_manager.get_radio_ssl_context(radio)
ssl_context.load_verify_locations(cadata=cert_data)
...
The name for the python_env is ESP-IDF's choice, not ours. main is building on 5.2.1: you can see comments in git log in esp-idf/ that confirm it is 5.2.1.
This prevents building with an external 5.2.1 idf.
I don't understand what you mean here.
@makermelissa I'm not sure if this is a core issue or a https://github.com/circuitpython/web-editor issue.
The name for the python_env is ESP-IDF's choice, not ours.
Cloning espressif's esp-idf release 5.2.1, and running ./install.sh, shows it correctly identifying itself as 5.2.
The issue is with the forked idf, that is used for CircuitPython.
I don't understand what you mean here.
Up until now it has been possible to have a seperate esp-idf clone, elsewhere on the system and have it exported to path.
CircuitPython would then build just fine, so long as version matches.
That I r...
Sorry, I should have realized there was a web-editor repo. I should have opened this there. I'll close this one and open a new issue in the web-editor repo.
According to https://learn.adafruit.com/building-circuitpython/linux
For CircuitPython 6.1, 7.x, and 8.x, use the 10-2020-q4-major version.
For CIrcuitPython 9.x, use the 13.2.Rel1 version.
Aha, I see.
https://github.com/adafruit/esp-idf was missing a bunch of git tags, including v5.2.1. I fetch the tags from upstream and pushed them. Locally this seemed to fix the problem. Try again
Indeed this fixed the issue, built successfully now. Thanks a lot for the quick fix!
Added Pine64's Quartz64 model A board, recently added to PlatformDetect and Blinka
This is marked as a bug, but... is it really a bug?
According to https://github.com/adafruit/circuitpython/pull/5425 the only pins that can be used for PinAlarm are "IN0:PB00; IN1:PB02; IN2:PA02; IN3:PC00; IN4:PC01". Of those, it seems that only the PA02 pin is brought out on ItsyBitsy m4 – according to the pinout chart, it is the A0 pin.
PinAlarm does in fact work on my ItsyBitsy m4's A0 pin with this code:
import alar...
CircuitPython version
Adafruit CircuitPython 9.0.1 on 2024-03-27; Raspberry Pi Pico W with rp2040
Code/REPL
#code.py (provided by anecdata in the discord)
import time
import os
import wifi
import ipaddress
import socketpool
import mdns
MDNSFINDTIMEOUT = 5
ssid = os.getenv('WIFI_SSID')
password = os.getenv('WIFI_PASSWORD')
pool = socketpool.SocketPool(wifi.radio)
def connect():
# to connect in case CP8 web workflow hasn't already, or ...
I can report similar behaviour switching from 8 to 9 on Feather ESP32 S2
I can successfully requests.get() an https address but fail with IO send_data() using IO_HTTP
Adafruit CircuitPython 9.0.2 on 2024-03-28; Adafruit Feather ESP32S2 with ESP32S2
`Traceback (most recent call last):
File "code.py", line 313, in <module>
File "adafruit_io/adafruit_io.py", line 624, in send_data
File "adafruit_io/adafruit_io.py", line 564, in _post
File "adafruit_requests.py", line 595, in...
Can confirm that Web Workflow can be a sort of workaround.
I'm not sure how to use CircUp in the case of Web Workflow, it only tries to detect serial connections. Would be great if you could share how you achieve this.
I've been doing some thorough testing of Ampy with my TinyC6 on my test jig setup - and I can confirm the issue is still present, but it's it succeeds more often than it fails.
90% of the time it works and I can PUT files on the TinyC6.
70% of the time I can RUN a file on the device
The rest of the times a RUN hangs and a PUT fails, or the device locks up serial comms after a task completes.
This is way better than what I have been experiencing with mpremote and shell wh...
As there is some variety of very valuable in terms of makers chips, perhaps it is worth considering creating a new thread topic? Or maybe change the name to this one?
As there is some variety of very valuable in terms of makers chips, perhaps it is worth considering creating a new thread topic? Or maybe change the name to this one?
Well, the C3 and C6 both use the same UART peripheral, so whatever works or doesn't work for one, will be the same for the other, and all new chips from Espressif that use the same peripheral, like the C5, C61 and I believe the H2 + H4 will also have the same issues, so I think it's relevant token this here and not part mul...
Here's a revised test script that requires no logins for (8.2.5). Anyone with an S2 should be able to run this script.
Adafruit CircuitPython 8.2.5 on 2023-09-07; Adafruit Feather ESP32S2 with ESP32S2
Board ID:adafruit_feather_esp32s2
import gc
import os
import time
import wifi
import ssl
import socketpool
import adafruit_requests
print("-" * 40)
start_mem = gc.mem_free()
print(f"Prior to Script Config: {start_mem}")
# Initialize WiFi Pool (There can be...
Adafruit CircuitPython 9.0.0 on 2024-03-19; Adafruit Feather ESP32S2 with ESP32S2
Board ID:adafruit_feather_esp32s2
code.py output:
----------------------------------------
Prior to Script Config: 2039824
----------------------------------------
After Script Config: 2038848
Memory Used: 976
----------------------------------------
Prior to WiFi: 2038848
✅ Wifi!
----------------------------------------
After Wifi: 2038848
Memory Used: 0
------------------------...
I'm not sure how to use CircUp in the case of Web Workflow, it only tries to detect serial connections. Would be great if you could share how you achieve this.
circup --host xx.xx.xx.xx --pasword xxxx update
I've seen similar behavior on raspberrypi. Often, the browser tries to load but does not return with the page. The mdns server shows up in mdns.Server .find (done from a separate espressif device), but loading in a browser is problematic. In rare cases it will load in the browser (though I haven't been able to do that today), but in many of those the web workflow page will come up with all fields empty. Even accessing web workflow using the IP address sometimes shows similar behaviors...
CircuitPython version
Adafruit CircuitPython 9.1.0-beta.0 on 2024-03-28; DFRobot FireBeetle 2 ESP32-S3 with ESP32S3
Code/REPL
import wifi
wifi.radio.connect("secure_network")
Behavior
Traceback (most recent call last):
File "", line 1, in
ConnectionError: Unknown failure 210
Description
Now trying to connect to a secure network with no password produces code 210.
Additional information
I opened this issue to discuss as to what s...
210 is new since our definitions:
NO_AP_FOUND_SECURITY
@onyx hinge - thanks so much for the pointer at https://github.com/adafruit/Adafruit_CircuitPython_PIO_UART/pull/2#issuecomment-2028768956 (I closed it thinking I'd do a bit more research first rather than bother you folks!) will poke at it. 🙏
If you are trying to connect to what you think is an open network and you get "Authentication failure", it's pretty easy to guess what happened. I don't think we need a new message either.
I am making a PR to fix this.
Images automagically compressed by Calibre's image-actions ✨
Compression reduced images by 60.6%, saving 6.15 MB.
| Filename | Before | After | Improvement |
|---|---|---|---|
| assets/images/boards/large/adafruit_feather_esp32c6_4mbflash_nopsram.jpg | 119.17 KB | 65.64 KB | -44.9% |
| assets/images/boards/large/adafruit_floppsy_rp2040.jpg | 96.65 KB | 55.46 KB | -42.6% |
| assets/ima... |
So is the main branch supposed to be coming with idf5.2.1 now, or do you have to somehow install the toolchain manually? i've pulled and fetched-modules and esp-idf/install.sh export.sh and it's still 5.1
Some git tags were missing from the submodule (our fork of esp-idf. you could just cd esp-idf and do pull git -tag and then do install.sh again. See https://github.com/adafruit/circuitpython/issues/9122
- Fixes #9125
ESP-IDF added some new failure codes for wifi connections. Handle a couple of these by collapsing them to existing "authentication failure" code so they will print with a useful message.
Test: old and new:
Adafruit CircuitPython 9.1.0-beta.0 on 2024-03-28; Adafruit Feather ESP32-S3 Reverse TFT with ESP32S3
>>> import wifi
>>> wifi.radio.connect("MYLOCALNETWORK")
Traceback (most recent call last):
File "", line 1, in
ConnectionError: Unknown failure 210
>>...
@danh Not sure if you remember it, but there was a mysterious "IO8" in the esp32-c3 w/ round lcd that I submitted earlier in the week.. I just found it.. It's a tiny solder pad next to the UART connector,, I gues so you could hook a switch or a neopixel to it..
i remember looking for a switch that we couldn't find.
CircuitPython version
Adafruit CircuitPython 9.1.0-beta.0 on 2024-03-28; Adafruit QT Py ESP32-S3 4MB Flash 2MB PSRAM with ESP32S3
vs.
Adafruit CircuitPython 9.1.0-beta.0 on 2024-03-28; Raspberry Pi Pico W with rp2040
Code/REPL
import time
import os
import traceback
import microcontroller
import wifi
import socketpool
import mdns
PORT1 = 8086
PORT2 = 8088
time.sleep(3) # wait for serial
print(f'{os.uname()=}')
print(f'{microcontroller.c...
Footnote: it does not appear possible to have the same MDNS service-protocol on different ports:
service_type and protocol can only occur on one port. Any call after the first will update the entry’s port.
A non-MDNS HTTP Server can be run in code.py with web workflow enabled, but not an MDNS HTTP Server. User code could also (temporarily to permanently) commandeer the web workflow _http._tcp service-protocol to its own port for an in-code.py MDNS HTTP Server, but at that point, web ...
Here's another test script from issue 3651 that fails in an identical fashion. I tried that script and it fails exactly as described in that issue. There seems to be some kind of regression because apparently it was fixed and then it broke again sometime in 8.0 beta (best guess).
Thank you! Looks great.
I can re-do 1378 if needed.
If you like @jepler. I just created a version of the image for feeds, so it gets around the problem. If you want to figure out how to get the into the same code block, that would be cool, but no hurry at this point.
[adafruit/circuitpython-org] New comment on pull request #1378: Generate absolute URLs automatically
hmm I lost the | absolute_url on the src=, oops
You may need to point https://github.com/adafruit/circuitpython-org/blob/main/feed.html#L20 to board_image.html rather than feed_board_image.html.
Originally, both the RSS feed and the board list pages used the same board_image.html include; I added | absolute_url to this file for the RSS feed, which functions better when all links are absolute.
Using | absolute_url is preferable to just prepending https://circuitpython.org because it can give a correct URL when previewing locally with bundle run jekyll serve.
This crossed with a change by @makermelissa to switch the feeds to use a separate include, presumably (though I di...
Tested locally, the download list page images work and are relative; the rss feed links are absolute links to localhost:4000.
Do you know if the absolute_url works for loading images locally? If so, you could probably just combine the 2 pieces of code.
Yes, unless I'm failing to understand something or my testing is insufficient, the "feed_board_image.html" from this issue include would work equally well for the board list pages from the point of view of a user.
In 'view source' you would see a redundant specification of the full URL of the images (img src="https://circuitpython.org/...") so in a sense it's "less tidy", but it works the same.
If you want me to re-do this PR so that it re-combines the two include files I'm happy to do ...
If you want me to re-do this PR so that it re-combines the two include files I'm happy to do that. My assumption had been that since you split them out subsequent to my two PRs adding
|absolute_urlthe first time that either you were encountering a problem with the version I had written, or you didn't want the redundant URLs in view-source.
Please do. I was just in a hurry as I was at the end of my day and it was the simplest way to make the change that I knew would work for cert...
surprise <@&356864093652516868> -- I'm hosting the meeting today in about 80 minutes. Hope to see you in the voice channel & your notes in the notes doc.
The beetle c3 is near exactly the same in terms of pins and functionality. I also have a supermini target created but since this was rejected once, I never bothered to submit it.
Feel free to add more boards. It's fine.
re: voice chat roles... um.. I'm cool with just listening, but I could also say hi
listening in for your first time is a solid idea. we're happy to add you to the role anytime. it also gets you a few notifications a week, just about the meeting times.
cool that you've joined us in any case!
Lurking without notes...
One second I have 2.1MB of memfree then immediately afterward on the next line 1 single call to requests.get throws a memory error. It doesn't seem like a lack of memory or at least not according to the behavior reported by memfree. It's not like I have 10KB free... I have around 2MB free when it crashes. The API call I'm making when it crashes most times should only take about 200 bytes...
memfree is telling you how much is available for MP heap. It isn't accounting for the IDF memory r...
Attached: 1 video
There’s a neat new core library in CircuitPython: bitmapfilter. Originally designed for the PyCamera project, it’s got many useful operations for generative art stuff like I do in Processing/p5js. Here’s a start: random circles bluring away. note, it does require a fast processor like the ESP32-S3 as on this great Lilygo boa...
sorry, text only
I think this is because you are initializing the mdns.Server yourself. Right now, circuitpython.local is only added if the workflow starts the server: https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/common-hal/mdns/Server.c#L70-L76
Thanks for the info @raquo. I think you are right.
IIRC, we don't raise the issue from PinAlarm because it make work with light sleep just fine.
@jdswope You'll need to pick a different pin for deep sleep.
Does MQTT work ok when web workflow isn't enabled?
I do like autoconnect personally because it's nice to not have that portion of boilerplate in user code for some of my projects and examples that I test.
I don't fully get everything, but what about password less wifi, if something is trigger by the presence of a password?
something like CIRCUITPY_WIFI_AUTOCONNECT being a way to turn it on /off would be nice I think as well but don't have a strong opinion on it.
Sorry to have confused things, but now I get it. 😉
Yes, perfectly. My project had been running since Saturday without any
weirdness. And being super clear, WWF is still enabled. I just haven't
accessed since Saturday.
On Mon, Apr 1, 2024, 11:36 Scott Shawcroft @.***> wrote:
Does MQTT work ok when web workflow isn't enabled?
—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython/issues/9123#issuecomment-2030323059,
or unsubscribe
<https://github.com/notifications/unsubscr...
for examples: if we assume web workflow enabled, do simple examples even need connect logic?
wifi.radio.enabled = False
Would this prevent autoconnect?
...and, when connect logic is desired (but no auto-connect), do we want some pseudo-standard settings.toml credentials to use and recommend?
@dense glacier auto-connect would briefly connect on startup, then stop once that line gets hit in code
Thanks for hosting, Jeff! I need to head out. Have a great week, everyone!
Thanks all
thanks!
Thanks
Thanks for hosting Jeff, hope everyone has a great week!
CIRCUITPY_WEB_API_PASSWORD= "jk"
I think this is the web workflow case. My understanding is that mdns.Server(wifi.radio) in code accesses what's essentially the web workflow mdns.Server Singleton?
(Running the code above I don't think will show its own device, but running on a separate device should catch any MDNS _circuitpython._tcp.)
@studiostephe can chime in on their original observations from Discord. From my own observations, it can be difficult to connect to `raspberrypi...
Would it be considered a bug (i.e. should issue be created) the EPaperDisplay.time_to_refresh (https://docs.circuitpython.org/en/latest/shared-bindings/epaperdisplay/index.html#epaperdisplay.EPaperDisplay.time_to_refresh) is innacurate by a partial second? The docs state "Time, in fractional seconds, until the ePaper display can be refreshed." but I'm finding pretty consistently if I call refresh() as soon as that time is 0.0 I get the "Refresh Too Soon" error.
I ended up catching the error and working around the issue by adding some extra time "manually" with:
time.sleep(display.time_to_refresh + 0.6)
display.refresh()
If you'd like a video or to see it over a zoom/hangout call I'm happy to do
that.
20 years in QA and I know how important a picture can be with weird issues
like this. :)
Code:
- Main Program https://github.com/niccit/home_system_zone
- Helper Classes
https://github.com/niccit/circuitpy_helpers/tree/changes-to-timelord
(branch:
changes-to-timelord)
~nicci
On Mon, Apr 1, 2024 at 11:45 AM Nicci Tynen @.***> wrote:
Yes, perfectly. My project had ...
since it is a float, maybe just a precision issue? just like 0.1 + 0.2 == 0.300...004 on many languages
i guess the code could do something like time_since_last_draw >= (display.time_to_refresh - some_delta) to make it a bit friendlier in that regard (at the cost of not complying 100% with datasheet/recommendations)
but i would have expected the CircuitPy internals to automatically flush the display (if it has changed) after time_to_refresh has elapsed, and not that users need to eagerly flush themselves 🤔
could also store in milliseconds and use int instead? 🤔
this has been a longstanding issue. it would be good to get filed if it isn't already
This can happen due to memory fragmentation. The M5Stack doesn't have external PSRAM so ~150k seems reasonable for the mem_free() value.
It is possible that the TLSF allocation under the hood isn't performing very well when running out of memory. That's why I marked this as a bug (not support.)
Please get a unique PID for this board instead of using the generic one. https://github.com/espressif/usb-pids
For example, I just set up a Pico W with no code.py, but web workflow and auto-connect set up in settings.toml. I've turned off web workflow on all other devices.
Adafruit CircuitPython 9.1.0-beta.0 on 2024-03-28; Raspberry Pi Pico W with rp2040
A separate MDNS scanner shows the Pico W:
ipaddress.ip_address(pool.getaddrinfo(circuitpython.local, 80)[0][4][0])gives the proper IP address..find(service_type="_circuitpython", protocol="_tcp")gives the.hostnameas the `cpy...
I think @tannewt is suggesting (2b.) above.
Yup, that's what I meant. Use settings.toml keys without CIRCUITPY_ prefix for user config values. CIRCUITPY_ ones are used by CP itself.
I think @tannewt is suggesting (2b.) above.
Yup, that's what I meant. Use settings.toml keys without
CIRCUITPY_prefix for user config values.CIRCUITPY_ones are used by CP itself.
So we should update examples to not use CIRCUITPY_ and save those for examples when using webworkflow?
...and many examples can probably assume auto-connect and not need any credentials (but perhaps some comments about connection).
Maybe we wait for Dan to chime in, I think he was trying to summarize the in-the-weeds discussion from the call today.
@justmobilize The meeting video is not up yet. I was multitasking during the meeting and don't remember if you attended, but we discussed this in In the Weeds today.
- Using
CIRCUITPY_WIFI_SSIDandCIRCUITPY_WIFI_PASSWORDcauses auto-connect. - Using
CIRCUITPY_WEB_API_PASSWORDenables web workflow if auto-connect has happened. - The
CIRCUITPY_prefix on thesettings.tomlvalues is meant to signify that CircuitPython does something itself with these values. - There is currentl...
Right now the web workflow only works after auto connecting to wifi. We should make it work when CIRCUITPY_WEB_API_PASSWORD is set and the user code connects. That way user code can manage selecting one of a couple networks instead of the auto-connect network.
CircuitPython version
Adafruit CircuitPython 9.0.0 on 2024-03-19; Adafruit MagTag with ESP32S2
Code/REPL
import time
import keypad
import board
display = board.DISPLAY
buttons = keypad.Keys((board.BUTTON_A, board.BUTTON_B, board.BUTTON_C, board.BUTTON_D), value_when_pressed=False)
while True:
event = buttons.events.get()
if event:
if event.released:
print(f"btn {event.key_number}")
try:
...
@dhalbert thanks. Sadly I missed it today...
So we would probably want something like this in the examples:
if not radio.connected:
# We got here because CIRCUITPY_WIFI_SSID/CIRCUITPY_WIFI_PASSWORD are either incorrect or not set
# Try grabbing WIFI_SSID/WIFI_PASSWORD and connecting
ssid = os.getenv("WIFI_SSID")
password = os.getenv("WIFI_PASSWORD")
while not radio.connected:
try:
radio.connect(ssid, password)
except Connect...
Here is the notes document for next Monday’s CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1_cpbdNujG6Gb6YB18n2v94Jqyz09h4yPsyiRRcy9tgk/edit?usp=sharing
Video is up. Discussion starts here: https://youtu.be/fbg2qtGjxC8?si=hlf-NvkHwluSLIRg&t=1987
So we would probably want something like this in the examples:
That is the most thorough boilerplate. The retry while loop could be omitted, I think, and then also the try-except. I notice @anecdata also includes that in their example.
I think one question is whether to bother to include this for all examples or just depend on auto_connect.
Something like this code could go in `Conn...
Oh I would love to put that all in the ConnectionManager
Not sure if this was discussed, but it appears to be an artifact of GitHub's RST renderer. The docs don't have it, and other repos do.
not discussed yet, but it does appear to be quite widespread now. We'll have to decide if we want to try to do something to get it back to horizontal or if the vertical stack isn't bothersome.
Strangely, not EVERY other repo does either (like externally), so I wonder why it's not consistent
I tried looking into it last week as well on a personal repo and I couldn't manage to fix it, though that was where I confirmed that the RTD documentation was unaffected
We had a similar issue a while back where it wouldn't line them up horizontally without a :target: attribute I think, but that doesn't seem to be the case this time around.
@lone axle took a quick look before going to bed and AFAICT, the C code already works in ms but it gets converted when "handing" the value to Python with
shared-bindings/epaperdisplay/EPaperDisplay.c
return mp_obj_new_float(common_hal_epaperdisplay_epaperdisplay_get_time_to_refresh(self) / 1000.0);
and that's probably causing some rounding errors, as i was already guessing before
feel free to leave a comment on the issue with your findings.
aight 👌
And thanks for looking into it!
AFAICT the C code works in milliseconds yet it gets converted to seconds when "passing" it to Py, which probably causes a rounding error which is the real problem making the code fail
I think a viable solution would be to do a breaking change so that the property returns in milliseconds and call sleep_ms instead of sleep
On a side note, maybe there should be some (opt-in) ...
🛏️ 💤 👋
In any robust application, there would be a lot of exception-handling, etc. But for simple examples, there are two cases:
Auto-Connect enabled:
No wifi.radio.connect() logic is needed, but some documentation about settings.toml and auto-connect would set the stage.
Auto-Connect not enabled:
We could make it super-simple and simply call wifi.radio.connect(), no ifs or whiles even needed. .connect() is virtually a NOP if already connected, there is very little overhe...
My biggest worry is discord help. Almost all user code I see starts from an example. There ideally should be something clear that says you aren't connected.
If we build that into a global helper, then it's super simple. It could check for env vars check connection state and even try to connect (knowing for each radio how to do it)
I think it'd be simpler to add a bit of time to the milliseconds number before it gets divided to float.
That's true. And especially when reloading often in a flurry of development, initial connect exceptions happen more (for me, at least - maybe the AP hasn't fully dropped the old one yet). So acknowledging that connections are not guaranteed would be good.
Are there any devices that have an analog capable pin that has a resistor of a known value connected to it? I've been kicking around an idea in the back if my mind to try to catch things like that AnalogIn issue linked above.
It would be cool if we could make a utility that runs on a PC but connects to a connected CircuitPython device either via Filesystem and Serial, or HTTP and Websocket. It could load specific script(s) and run them testing for the output to match the expected values.
It probably can't easily comprehensively test everything but it could do quick sanity checks on the most basics like digitalio, analogio and maybe busio by communicating with a known connected I2C device or something.
If such a device / pin exists with a resistor connected internally then one script could init the pin and read the value to compare with the expected value based on that built-in resistor in order to do a baseline validation that analogio is functional.
@lone axle totally unrelated, but not...
I've been thinking about the same, and having it run this example: https://github.com/adafruit/Adafruit_CircuitPython_ConnectionManager/blob/main/examples/connectionmanager_ssltest.py so we would know if we had cert issues...
Nice, that seems like another nice usage of that type of mechanism.
when we having been thinking about actual hw testing we think about some kind of jig that would connect pins together on a single microcontroller, or have another microcontroller do I/O to the pins of the one under test
I ended up down a similar road, I connected 12 to 13 and then read 13 while setting 12
to really answer your question, on some chips you can enable a pull-up or pull-down even when the pin is in analog input mode. But that would just give you the ends of the range
I am thinking of adding something to adabot perhaps, does that sound like a good place for this functionality. It would run a script on the connected device and check for expected output, like these ones in the core: https://github.com/adafruit/circuitpython/tree/main/tests/circuitpython
you could also put some kind of bidirectional analog switch on multiple pins
I don't think this is adabot, I think it's a whole 'nuther testing system. we started owrking on this a long time ago but it was not stable enough to use, and we had far fewer boards to test: https://github.com/adafruit/rosie-ci. Scott did this. I collected some parts for it locally but never set it up
doing it on an RPi at the time was not stable enough. Lots of USB troubles and then also the RPI SD cards went bad too quick. A NUC or other small computer makes more sense. Now I have a lot of these because I'm already on my second generation of buying them.
(Dell Optiplex micro form factor, e.g.)
When I get to writing I'll start something fresh. I'm imagining starting with sort of "one shot" tests run from the command line without any other automation built in. Eventually this could get used by some other utility to automate it but I have in mind just the manual tool to start.
I reproduced this with 9.0.2 and 9.1.0-beta.0.
I tried this recent change to MicroPython, which allows some compilation garbage to be collected more reliably: https://github.com/micropython/micropython/pull/14136.
If I comment out the last four or so routines in TOS3.py (code.py), then I don't get the storage problem. So we are just over the edge.
If I use mpy-cross on TOS3.py, morse.py, and prt.py, replace the .py files with those .mpy files, and replace code.py with:
`...
Super, thanks for the update. I’ll try the mpy route - I’ve never used that before!
I'm impressed by what you've been able to squeeze onto this tiny board. You might consider an RP2040 Trinkey if you want more room.
weird thing... several of my ESP32-S2 devices, which I haven't touched and have been running since 7.2.0 (early-2022), suddenly all get espidf.MemoryError (_get_socket) when trying to connect to server ...something changed in TLS protocol or certs or something like that? (they do reload or reset as necessary when errors occur, but can't get past this now) ... 7.3.3 devices with almost identical code.py are unaffected
@jvprat spotted some mistakes in the new Waveshare RP2040-GEEK and ESP32-S3-GEEK devices. The RP2040 device does not support WiFi and neither board has a USB-C port. While double checking the feature list I also realized that the board does have a Stemma QT compatible connector so I added that feature as well.
Thanks, I get a kick out of squeezing as much as possible out of The NeoTrinkey. I do have one of the rp2040s - but I really like the NeoTrinkey’s four pixels for output and two pads for input :)
Yup, new Let's Encrypt cert March 29, that's when it started happening. There were a couple of cert upgrades between 7.2.0 and 7.3.3. I guess it's time to bring these devices fully up to date 🙂
Thanks again! I tried mpy-cross and got it working! As silly as my project may seem, I appreciate getting it to work with current CP, and as a bonus learning to use mpy-cross!!
Have you looked into the tests that adafruit runs on boards before putting them into inventory? There's a tests repo that Lady Ada mentioned in last weeks Desk of Lady Ada. Adafruit's test rigs mostly use fiducials and pogo pins but it seems like they might be pivoting to a new type of solderless header (coming to the store soon) https://www.youtube.com/watch?v=f1RlHjUq2iE By using the same headers that a user would, it will allow users to run the Adafruit test process on their board in the event of an incident like you're experiencing. I certainly like the idea of being able to factory test my boards if I suspect an issue. We have factory reset .bins but no factory test suite, at least not something that is beginner friendly with a learn guide for all boards... yet.
I think those solderless headers are permanent. They would still use pogo pins for testing
we have something like that for RPI, I haven't looked at the new ones in detail yethttps://www.adafruit.com/product/3662
these are harder to use because there are so many to insert, so you need a lot of force. Using a "hammer" jig helps
I think a board test suite could help support staff in the forums too. That would be nice if they could give someone a piece of code that would test everything on the board.
I think most physical issues end up in the forums or email before going to RMA?
I started working on some straightforward test programs for vetting CircuitPython board defs (not for factory use) but it didn't get that far.
You would have to emulate for analog/digital input and probably a bunch of other things.
I'd like to chime in on the discussion for web workflow/wifi auto connect. One of the things I like about the current boilerplate code in code.py for connecting is if wifi or dns goes down. It needs logic to reconnect and retry forever for an API script that is to be online 24/7. As long as that can still be handled I'm ok with whatever the devs decide.
Most of my projects are online 24/7 and require a good amount of try/except error handling to keep them online.
In an ideal world especially for beginners, code.py should not require a single try/except.
I didn't think it would be since this one seems to have continually affected the S2 since its debut. memfree reporting everything is good to crashing without warning is a bit jarring.
Having a TLS buffer error would be welcome so at least users will know it's TLS buffer related and not due to lack of PSRAM. After looking into it more yesterday and testing it in different ways all HTTP sites can be sequentially loaded without issue. It's specifically HTTPS responses that causes this on...
@RetiredWizard The problem lies in my browser settings. They're too restrictive. I've created a special profile to work with C3, although it's a rather controversial solution.
My observations match anecdata's above: a blank code.py, Web Workflow has started because its accessible via cpy-xxxxxx, but circuitpython.local never loads
Qtpy S2 on pin A0 has a ten kiloOhm resistor (worth double checking, but threw me when testing, it's mentioned in learn guide pinout page).
I was keen to do a test farm too, but thought probably worth trying wokwi before setting up some monstrous local farm. You can point pins at pins and have simple components attached which would cover a lot of the test surfaces (but never be capable of all on wokwi)
CircuitPython version
Adafruit CircuitPython 9.0.2 on 2024-03-28; Raspberry Pi Pico with rp2040
Code/REPL
# in boot.py file
usb_hid.set_interface_name("HP")
Behavior
USP iInterface field does not change.
Description
According to pull request https://github.com/adafruit/circuitpython/commit/ffa45dedb1ea306c5419e872b021f6da02f9b7bb usb_hid.set_interface_name() should work under 9.0.2.
Additional information
@MariuszCwikla what CP versi...
Pylint hates me.
This PR adds support for the Maker Go ESP32C3 Supermini, a very cost effective and prolific, if basic, esp32c3 dev board. It closely resembles several other boards, but UART configuration was an issue getting extant Circuit Python variants to work on it. This PR is tested working on real hardware.
Draft until pending PR to add device to the creationid database is completed.
Added documentation for the ESP32C Supermini by Maker Go.
Draft until pending PR to circuitpython for adding board support is completed.
I need help with a Pylint error. https://github.com/adafruit/Adafruit_CircuitPython_IS31FL3731/pull/54
oh come on! fine set it on both imports, see how ya like that pylint.
it liked it... a lot 🤣
the struggle is real
At least on my S3 from typing does not import therefore the check for TYPE_CHECKING will probably always be false and from circuitpython_typing won't get imported either. ```py
try:
from typing import TYPE_CHECKING, List, Tuple, Optional, Iterable
from PIL import Image
if TYPE_CHECKING:
from circuitpython_typing import ReadableBuffer
except ImportError as e:
pass
# This takes precedence over image() in __init__ and is tuned for the
# Matrix class. Some shortcuts can be taken because matrix layout is
# very straightforward, and a few large write operations are used
# rather than pixel-by-pixel writes, yielding significant speed gains
# for animation. Buffering the full matrix for a quick write is not a
# memory concern here, as by definition this method is used with PIL
# images; we're not running on a RAM-constrained microcontroller.
``` Except I am running it on a RAM-constrained microcontroller... 🤷
Not the image function specifically but the library yes.
I have no idea how to resolve this to make both Blinka and microcontroller circuit python happy with typing.
I initial aims with device testing aren't to have a comprehensive test that checks every pin or tries to validate every possible thing on the device. Though I think that kind of thing would certainly be valuable too.
My primary goal at least to start is to have the tests cover enough to be confident that the build of CircuitPython is okay. So things like analogio being broken for one port would get caught, but things like a specific bad pin on a specific device, or even a bad bin as a result of a bug in the PCB design would not necessarily get caught unless you were "lucky" enough to try the exact right pin(s) during the test.
The actual thing that I have in mind is more the "test runner" than the tests themselves honestly though. I am imaginging a tool that lets you run a command like:
circuitpython_hardware_test digitalio_test.py digitalio_test.exp
Where the first argument is the script to run and the second is a plaintext file containing the expected output of the script.
That mechanism could then apply quite generally to tests of different purposes.
Doing in wokwi would be cool as well. I'm not opposed to that path at all, I just don't think I have the knowledge to push it forward as much.
That's a neat idea. Use the power of Wokwi's emulation to mock up some tests.
so, completely unhinged thing I've been working on, I've hit a wall.. I've got this device [https://www.mateksys.com/?portfolio=f405-std] which has a STM32F405RGT6 MCU and a bunch of sensors and flash and such attached to it.. I have a fairly detailed pin arrangement, as defined in the INAV (flight control software) target for this device [https://github.com/iNavFlight/inav/blob/master/src/main/target/MATEKF405/target.h]. However, I'm missing some critical piece of information about the STM port, because trying to get a custom CircuitPython build to boot on it gives no joy. I've tried using the console from the vcp (which I may not have defined properly) as well as when hooked to the UART1 pins with an external usb serial device, and defining UART1 as the console UART in mpconfigboard. I get no output.. I'm not sure if it's not booting, or if it's just not putting out serial output, but I suspect it's not booting.. I used the feather_stm32f405 as a starting point, modified it for this devices' pins and flashed..
Seems as though Justin might have some experience with ReadableBuffer & WriteableBuffer not playing nice with typing. https://github.com/adafruit/circuitpython/issues/8891 I wasn't able to learn anything from that issue though.
I feel like I need to be using Union but unsure how or why.
After encountering the problem that a forbidden pin (GPIO 45) is used for the secondary I2C on the senseBox MCU-S2 we tried to find a solution which now works.
Added two flags to make use of internal pull ups in the board definition and added a possibility to bypass the pass for invalid pins for I2C.
Thanks @dhalbert for pointing to the right direction.
How can I import ReadableBuffer and WriteableBuffer from circuitpython_typing? Whatever I'm doing isn't working.
__init__.py:122:25: E0601: Using variable 'WritableBuffer' before assignment (used-before-assignment)
__init__.py:133:56: E0601: Using variable 'ReadableBuffer' before assignment (used-before-assignment)
@George-TL are you testing it on windows or on linux?
[linux] can you try running lsusb -vd 239a:80f4 | grep iInterface ?
[windows] I have noticed that windows caches name of the HID device. So if you have plugged in your Pico some time ago, then it will store name in registry under HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\OEM\VID_239A&PID_80F4 and basically "ignores" what you set up in boot.py (VID_239A&PID_80F4 are vid/pid of Ra...
I'm using a ESP32-S3-DEV board that has native USB and USB-to-Serial convertor on UART0. I want to recompile CP so the REPL console listens on UART0 instead of the native USB created comport. I openend the board's code but I can not find where it defaults to the native USB for the REPL console.
Hey all - I have a packaging question. Are the steps on this page, https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/setting-up-pypi-secrets-2, the most up-to-date steps for setting up PyPi? This is for a CircuitPython library I'm working with
Here is a place where it's imported in a different library: https://github.com/adafruit/Adafruit_CircuitPython_OneWire/blob/7c1fde6c4cf5b5614f9fa65e70f9f67a0770e001/adafruit_onewire/bus.py#L20-L25
not a big deal as i can just ignore them, but is there a good reason/easy fix for submodules saying they have modified content when i have git checkout repo/main + make fetch-tags + make fetch-all-submodules?
did i miss some updating step? 🙃
The easy fix I tend to go with when my repo starts to have weird git / submodule behavior is to just make a fresh clone and start over in there. I'm not sure it qualifies as a fix all the way, but it is easy.
i dont feel like cloning the repo again given its size, i'd rather have the "noise" there and ignore it 🤣
I think that wrapping this import with if TYPE_CHECKING is incorrect. The following snippet fails on standard python, and is also tagged in a similar way by pylint: ```py
import typing
if typing.TYPE_CHECKING:
import typing.Union
def f(x: Union[list, str]) -> int:
return len(x)
```$ python badtyping.py
Traceback (most recent call last):
File "/home/jepler/badtyping.py", line 5, in <module>
def f(x: Union[list, str]) -> int:
^^^^^
NameError: name 'Union' is not defined
The import of typing.Union should simply not be guarded by "if typing.TYPE_CHECKING".
@lone axle re: EPD refresh rate
could you give this a try? https://github.com/elpekenin/circuitpython/commit/70c0957583e24af01d4872bc01b256a194ffb205
100 ms should not be a user-noticeable delay, but im hoping it is good enough to avoid rounding errors
@lone axle I have a CI question if you have time.. I'm making a quick mock driver for the CircuitPython_BME280 library. It shares the same file structure as CircuitPython_BME280 where there's no expected file that follows the adafruit_drivername/drivername.py pattern. However, the CI is erroring on a FileNotFoundError
Thank you... I knew it wasn't just me.
check the ``tool.setuptools]entries in the real vs fake ones. The multiifile BME280 has apackages =` line. Yours does not
py-modules vs package
I think maybe this part of your pyproject.toml needs to be updated. https://github.com/brentru/CircuitPython_Fake_BME280/blob/409e1cd64813ac71e495d82b22b11919473b1e0a/pyproject.toml#L46-L48