#circuitpython-dev
1 messages · Page 57 of 1
🤦🏻♀️ I can't believe I forgot.
Also, I don't see a refresh time in the ACeP7In lib, but I also don't know how to read... bytearrays I think they are?
@slender iron I see you moved epaperdisplay to its own thing 😄
In shared-module
Does that change anything in the board files? Or can I incorporate that as-is?
Sorry, this hasn't been implemented. @dhalbert confused this with the Pico W, which has the same chip. We don't have a plan for the Zero W.
@slender iron I went back to main, dumped the board files in from the PR, and was met with a boatload of build errors. I managed to fix all of them and build successfully! 🤯 Now to see if it actually works. 😄
It's using the new module now though, I think.
Please also try the latest 9.0 pre-release to see if the issue has already been fixed.
In the docs for terminalio.Terminal it makes reference to a cursor and moving that cursor's position.
Is there any more information about that anywhere? Is that meant to be a cursor that can be visible on the display as a reverse colored character or something similar to indicate a position or highlighted text?
I wonder why is this issue in the "Long term" milestone? Is it too hard to be handled sooner or is it considered low priority?
Thanks for retesting! It's a low priority because we only have one C3 board from Adafruit. It is hard to know difficulty until after it has been debugged and fixed.
Woof. Why does the REPL tell me I have CP 6.2.0-beta.1-somestuff when building from a modified version of main?
It is internal state. There currently isn't a way to see where it is in displayio.
We could add it though
you likely need to fetch newer tags
goes for a short walk
Ah thanks.
Blergh. Updating what appears to be the rotation value is changing nothing. It started as 180, which was upside down, so I changed it to 0, which did nothing, so I thought maybe it was something else that changed with the use of the new module, so I put it back to 180. Still same. Hmm.
This is like waiting for an image to download in the early '90s. 😂
Ok, verified, updating rotation doesn't change anything. I tried 90 even. Not sure how to go about resolving this.
Is the space saved because there are more shared messages? I'd really rather not do this but understand we're hitting a code size wall on SAMD21.
My understanding is, they're terser, and some forego any %-formatting which also saves code space. There are definitely some that combine too, see mp_arg_error_terse_mismatch.
Even with the new settings.toml text removed, this over-fills a couple of boards, including one where the sd placeholder would be helpful (feather_m0_adalogger). I'll see if it can be pared down further.
@lone axle for editor.py in particular, it always tracks where it thinks the cursor is, so you could try relying on that (def move on class Screen).
Do you have thoughts on what might be the path of least resistence to adding the ability to see the cursor?
I had a look in terminalio.Terminal core code and can see that it has cursor_x and cursor_y variables internally. If those were added to shared-bindings to be available from python then with them and some pixel multiplication it could place something over the top as a rudimentary way to indicate a location.
Is it possible to access the terminalio.Terminal instance that is visible by default that mimics the serial console? I know there is displayio.CIRCUITPYHON_TERMINAL which is a Group that contains the TileGrid(s) that the Terminal is using, but I don't know of a way to access the Terminal instance itself in order to access any properties it may have.
It'd probably be better to do it internally so it works when the VM isn't running
Thank you! I was just tracing through that code. ( I never imagined how tricky print debugging could be in an app whose main output is the same stream where prints go 😅)
I think I could use the locations tracked in there to translate to a location on the display in pixels.
I'm not very experienced with the sys.stdin / stdout concepts that this seems to be using (though hope to learn from studying this code more).
Is there somewhere in here that would make it easyish to access which character is currently at the position of the Cursor? Or to access as a String what is currently visible on the display?
ah, I think I just found the answer to that last question. buffer is the list of strings for the current "screen" it looks like.
yes I think that's true. Though, I was thinking you'd just access the terminal's TileGrid to find it out, that may work better
I think buffer is only (part of) the edited file, so for instance the status line wouldn't be there
i could be wrong, I haven't looked at this file in months
Thank you. I'll keep poking at it. I missed this when you created it, very neat project! I never knew the default serial console in circuitpython was capable of this sort of nano-like control
you'll need to get ahold of the terminal's tilegrid anyway to find the true width/height of the display
@onyx hinge remember that idea to separate keys from values in dict tables?
@slender iron yeah?
I wonder if that'd help us for samd21 instead of error messages
it's no easy undertaking
board on arduino zero alone is 264 bytes
and the savings would be 1/4 of the bytes
so 66
builtins is 784 with a savings of 196
I understand that this doesn't really makes sense for boards without sdcardio/sdioio, however those boards do get plugged into carrier boards with SD cards, and sdcard breakouts can also be added on to boards without native sdcard support.
I'm only bringing this up for consideration, I'm really not sure what the answer is but, is the possible confusion from having debatably, two different mounting methods for boards that have native SD card support and those that don't going to be more pro...
Does this mean a physical sd directory in boards now or will it be a placeholder for a virtual /sd?
@midnight ember 9 now requires the "mount point" (technical term) of an SD card [or other more exotic thing] to exist within CIRCUITPY as a directory. To make it easier on folks, the idea is to create a directory named "/sd" when the filesystem is created. If there's enough flash space, additional code to create an explanatory "/sd/placeholder.txt" file is included too.
The "/sd (or other mount point) has to be a directory" requirement in 9 is for adafruit_sdcard as well as for sdcardio/sdioio. It's just that I'm using this #define to turn the functionality off where it's less likely to fit.
Will the directory be writeable while the filesystem is in read-only? I would love that. If it's for virtual mounts only then the use of virtual /sd not creating files in the physical /sd directory might be more confusing for beginners.
@onyx hinge assuming example code will need to be updated similar to how we went thru and updated display.show() to display.root_group=
I think it's more a matter of instructions -- because CIRCUITPY will be read only to Python code [without using boot.py or other methods] the user will have to create CIRCUITPY/sd manually from their host computer.
Since I'm not really using 9.0 in my main projects yet will just wait for the roll out and cross that bridge when the time comes.
All the new changes and amazing projects every week is brain candy. It's a wonderful thing.
I installed 9.0.0-beta.0
It is better, BUT: On a hard reboot - unplug 5 volt - seems to run OK. If
I restart the code, I get runtimeError: AP could not be started line 24.
If I comment out this line, it runs OK on subsequent runs. I tried
stopping the AP at the end of the program, but this didn't change anything.
Here is the current code:
I had a lot of trouble coding the access point.
The code runs fine, but when it stops, it crashes the PicoW
AND SOMETIMES WIPES OUT T...
There is still an issue ( #8718 ) with stopping and re-starting an AP. For now, RuntimeError: AP could not be started will arise if start_ap() is called twice in a row, even across reloads. A reset is needed to fully stop the AP.
I haven't seen the crashes in testing 9.0.0-beta.0. It might not hurt to nuke the flash and re-install UF2 and code from scratch.
So just to be clear I understand this: A compatible CP device could be detected as a UVC device and send frame buffer content that the host computer could capture like it was a webcam? Like in OBS or LC or whatever?
If so, wow, that is wild!
How's this:
//| :param int debounce_threshold: Emit events for state changes only after a key has been
//| in the respective state for ``debounce_threshold`` scans on average. Successive
//| measurements are spaced apart by `interval` seconds.
//| The default is 1, which resolve immediately. The maximum is 127.
I think replacing the original term of "scans" by "intervals" made it a little confusing in different way, by implying that at leas...
@UnexpectedMaker
ESP32-S3R4 + espcamera + uvc (+ espnow secondary preview monitor). 🤫
I’ve been thinking about how CircuitPython might support dual-core cpus.
Support for the end user has lots of complications.
[spitballing] Might there be a solution where the board developer can specify what might run on each core? It would logically be things which take a lot of cycles, run continuously, and/or use buffering so things can be “loaded up” and left to run.
would there be any reason to not run on the second core something that could run there?
things like wifi, sound, display, etc.
That is my thinking. For boards with WiFi and two cores, it’s a logical choice. Sound is another great subsystem to consider.
It would require a buffering solution to handle data from CircuitPython in one core to/from the subsystem running on the other core. But an “under the covers” solution could be easier to implement and little/no change for the CircuitPython user.
we already have sounds playing in the background using buffers
the main problem I see is that it would all still need to work the same way on boards with a single core, so the implementation might be tricky
a good architecture would help
Background execution on “the other core” is the goal. The most popular microcontrollers (by far) now are dual core.
Update cyw43-driver to branch circuitpython9 of the Adafruit fork. This updates cyw43-driver to its upstream MAIN plus two patches awaiting upstream merge.
This pull resolves #8718.
For more capable multi-core SOCs it may make sense to add an RTOS kernel above CircuitPython. This would have the advantage of exposing a mature interface for multi-core support and would future-proof for coming 4 and up multi-core SOCs.
Failing CI checks are due to Russian M0 flash overflow and are not related to this pull.
Requesting review.
Build artifacts for 9.0.0-beta.0 with fix for #8718 are here: https://github.com/adafruit/circuitpython/actions/runs/7712683561/artifacts/1205824119.
for the OV5640 camera with auto focus https://www.adafruit.com/product/5840 the product page says Note that to use the auto-focusing capability, you need to load a new firmware binary over I2C Does anyone know where to get the new firmware and how to load it? I have not been able to find any instructions.
after some digging, seems to be on adafruit_pycamera
and (trying?) using the bin is the default option in the initializer (it ends up causing autofocus_init() a couple of nested functions later)
@mortal kernel I'm still getting AP could not be started with 9.0.0-beta.0-5-ged345f4ea2 on 2024-01-30
(adafruit-circuitpython-raspberry_pi_pico_w-en_US-20240130-main-PR8861-ed345f4.uf2)
Thanks for following up. I tried 9.0.0-beta.0-5-ged345f4ea2 , but the
same result. If I add a microcontroller.reset() to the end of the program,
everything restarts and works just like a power reboot.
Without the reset, the code only runs correctly once.
= > ÷
Rob Coe
@.***
On Tue, Jan 30, 2024 at 7:11 AM eightycc @.***> wrote:
Build artifacts for 9.0.0-beta.0 with fix for #8718
https://github.com/adafruit/circuitpython/issues/8718 are here:
https...
Ah, thanks, so it is already implemented in the library. That’s nice!
We already do this. On the S3 CircuitPython runs on one core and the network stack on the other. On RP2040 CP runs on one core and usb host or picodvi will run on the other.
That's a bummer. I've got an exploded water heater here, so I won't be able to get back to it until later today or early tomorrow.
@slender iron - nice! Where can a development learn how to do this?
Specificly, on an RP2040,which is not implementing USB host, how can the developer move “something” to the second core?
It's manual now. Moving CP to an RTOS would make this easier (and a reason to do the switch.)
it is easier with esp-idf stuff because it uses freertos
but all of CP runs in one task currently
@rpcoe There's a submodule versioning problem with cyw43-driver that I'm looking into.
Looks good to me! Thank you!
what if we used python stubs to generate the locals dict tables?
that way we don't have the requirement to list key next to value
So just to be clear I understand this: A
compatibleCP device could be detected as a UVC device and send frame buffer content that the host computer could capture like it was a webcam? Like in OBS or LC or whatever?If so, wow, that is wild!
Yes, that's the idea. displayio -> host like a webcamera.
I am still getting an identical error when trying a basic request (getting time from adafruit IO) on 9.0 beta.0 on an ESP32-S2.
Same code worked before on 8.2.9, still works on an S3 right now.
I think this is the same issue, so seems like it's not fixed.
code.py output:
Traceback (most recent call last):
File "adafruit_requests.py", line 515, in _get_socket
espidf.MemoryError:
The above exception was the direct cause of the following exception:
Traceback (most recent call ...
Very excited for this! Thank you! Just a few small things.
Can we do RGB if we have high speed usb?
//| def disable_framebuffer() -> None:
I'd probably add _framebuffer so it's symmetric.
Why up? That seems like a way to allocate more memory than intended.
Not ready for review, not picking up the correct submodule branch.
Looks good to me! Thank you!
Half a kb for holding placeholder text is not really ideal.
May I instead suggest something along the lines of:
# Settings in this file can be retrieved via os.getenv()
# Certain settings starting with CIRCUITPY_ are also used by CircuitPython.
# For more information, visit docs.circuitpython.org/../settings-toml-tutorial
Excluding the url that would be only 163 bytes and being presented a nice webpage explaining the options is much more functional in my opinion.
Additionall...
I am still getting an identical error when trying a basic request (getting time from adafruit IO) on 9.0 beta.0 on an ESP32-S2. Same code worked before on 8.2.9, still works on an S3 right now.
I think this is the same issue, so seems like it's not fixed.
code.py output: Traceback (most recent call last): File "adafruit_requests.py", line 515, in _get_socket espidf.MemoryError:
The above exception was the direct cause of the following exception:
Traceback (most r...
@rpcoe This build artifact picks up the correct cyw43-driver submodule branch: https://github.com/adafruit/circuitpython/actions/runs/7715586486/artifacts/1206479517.
I think I've got the submodule updated correctly. The branch parameter in .gitmodules was ignored. I had to take the additional step of manually checking out the branch.
ya, you'll likely need to checkout the commit you want to use in the submodule too
@mortal kernel testing now, looks good 
Yes, that's what worked for me. And there I thought I was being so clever using git submodule set-branch -b circuitpython9 ports/raspberrypi/lib/cyw43-driver.
that's good to set too so that it's clear where it is coming from
Phew, back to the water heater.
I have a PR that adds a couple of methods to wifi.Radio for discovering connected stations in AP mode. What's the best way for y'all to figure out the specifics of the calls that would feel right to you? Currently it returns a list of dicts for the stations but I can see the wisdom in defining a wifi.Station class and returning those instead. Would you prefer discussing it in the PR or here or something else?
Addressing issue 8790. I did this for fun and to learn more about CP internals, hope I'm not stepping on anyone's toes and am fine ignoring this if you'd prefer.
Added a new property ma...
Its a Feather S2 reverse, article 5345, 2 MB PSRAM. I could test with the same thing in S3, if you think that may be relevant.
The espidf commands immediately before the requests.get() read:
code.py output:
espidf.get_total_psram()=2097152
espidf.heap_caps_get_total_size()=2271279
espidf.heap_caps_get_free_size()=1975079
espidf.heap_caps_get_largest_free_block()=1867776
Traceback (most recent call last):
File "adafruit_requests.py", line 515, in _get_socket
espidf.MemoryError:
Now picking up the correct submodule branch. Word to the wise: Update both branch parm in .gitmodules and checkout the desired submodule branch.
Please review.
I'll leave code review to someone else, but tested with the code in https://github.com/adafruit/circuitpython/issues/8718#issuecomment-1915279055, and it looks good: any sequence of starting or stopping station or AP works now. Simultaneous station + AP is fine.
PR is probably best. chat is pretty ephemeral
Please post your code and I'll reopen this to take another look.
Here is a reduced example which triggers the error:
import os
import espidf
import ssl
import wifi
import socketpool
import adafruit_requests
pool = socketpool.SocketPool(wifi.radio)
requests = adafruit_requests.Session(pool, ssl.create_default_context())
aio_username = os.getenv("ADAFRUIT_IO_USERNAME")
aio_key = os.getenv("ADAFRUIT_IO_KEY")
#ntp = adafruit_ntp.NTP(pool, tz_offset=1, server="ntp.metas.ch")
#rtc.RTC().datetime = ntp.datetime
#print(time.localtime())
locat...
Add lilygo t-display s3 because it has a parallel display.
Fixes #8437
Just tested on an ESP32-S3 Reverse TFT Feather with the same flash/psram setup, and it works fine. So, S2, specific? Because of the somewhat smaller SRAM?
Went and also ran it with alpha5 on the S3, also works fine.
This will require care when merging 8.2.x to 9, because we want to make sure and retain the version 9 functionality.
Ya, S2 has less internal SRAM. Trying to replicate it now on a plain ESP32S2 feather with the same flash and ram. I don't have one with a display.
I gave them asymmetric names because I hope we add support for MJPEG over UVC as well. There would be just one "disable", but there would be "enable_mjpeg". This mode would take a pixel size and possibly a maximum frame data size argument.
No, I had the same thought and tried changing that flag to true.
Do you want the whole module named usb_uvc?
how to get latest ?
Today I sync’d my fork of CircuitPython with that from Adafruit. I then checked out main, did a pull, checked out my board branch. Did a merge. And sync’d to my fork.
Everything seemed right.
When I build and install, boot_out.txt still shows 9.0.0-alpha.5-50
Is there instructions I can review to do this correctly so I have the latest (currently beta.0)?
git pull --tags
I usually just do git remote update or how it was
by default git doesn't pull tag information, because Linus doesn't like it
Where is the version info within the repository so I can verify I have it without going thru the build and deploy every time?
Hello, all. I'm working on trying to get the Inky Frame 7.3" working with CircuitPython. It's definitely on its way, with a few hiccups. One of them is the display is rotated 180 degrees. I changed the rotation value in board.c but it has no effect. I tried 90 even, simply to verify. I have no idea where to go with this.
The other issue is that the buttons are on a shift register, and they're reading fine with the keypad module, but they show up as number 3-7. There are 5 buttons total. I also don't know where to look into that.
git describe --tags
@slender iron - OK. That still shows “alpha” so I am missing a step somewhere.
When I look at my fork on GitHub it said the main branch is up-to-date
I pull from my fork to my build machine. It still shows “alpha”
I usually do git fetch adafruit and it gets the tags
tags aren't technically part of a branch. so it may only be updating the branch
I went ahead and did this because of #8863.
Sorry to be a pain. … from my local machine, what is the full command to get tags from aidsfruit?
what remotes do you have? (git remote -v)
@empty salmon in the top directory, make fetch-tags
I get an error “does not appear to be a git repository” if I use “upstream”
(which should work regardless of your git remote settings)
Thanks! Worked.
good
Is there an up to date guide on building C extensions for CircuitPython? Or just a good example somewhere on GitHub? The Adafruit guide dates back a few years.
No updated guide but this is a good place to get help with it.
This PR adds a new module with only functions at the top level: https://github.com/adafruit/circuitpython/pull/8786
Thanks for the code @veloyage. I've reproduced it here. It looks like the S2 has more free internal memory with 9.0 but still runs out when setting up mbedtls. I'll keep poking at this. Thanks!
Is it still the case that a new C extension requires recompiling all of CircuitPython, there's no dynamic linking?
yes
Did something change?
- my board has an integrated ePaper display.
- 2 or 3 months ago, if there was an error that dumped to REPL, the error would show on the display. (I didn’t like it).
- Now, it seems errors don’t show on the ePaper display.
I’m happy but confused.
This looks like it works!!
Thank you eightycc and anecdata.
= > ÷
Rob Coe
@.***
On Tue, Jan 30, 2024 at 10:24 AM eightycc @.***> wrote:
@rpcoe https://github.com/rpcoe This build artifact picks up the
correct cyw43-driver submodule branch:
https://github.com/adafruit/circuitpython/actions/runs/7715586486/artifacts/1206479517
.—
Reply to this email directly, view it on GitHub
<https://github.com/adafruit/circuitpython/issues/8858#issuecomment...
This should resolve #8718 and #8858.
I recently fixed an issue with refresh sequences breaking. It should still show the error though
@slender iron - hmmmm …. I will do more testing. I tried a few things and could never get an error on the ePaper display.
Addendum: I want to reiterate, I like that errors don’t appear on the ePaper display. I just know we rode this merry go round a couple months ago and at that time the consensus was that errors should appear on ePaper. 😉
It is very cobbled together but I've managed to show a visible cursor on top of the Terminal with some modifications to Jeff's editor project 🎉
CircuitPython version
Adafruit CircuitPython 8.2.9 on 2023-12-06; BLING! with ESP32S3
Code/REPL
# SPDX-FileCopyrightText: 2023 Kattni Rembor for Adafruit Industries
# SPDX-License-Identifier: MIT
"""
CircuitPython I2S Tone playback example.
"""
import time
import array
import math
import audiocore
import board
import audiobusio
import neopixel
import microcontroller
BLING = neopixel.NeoPixel(board.MATRIX_DATA,320,brightness=0.05,auto_write=...
@tannewt Is it OK to merge this, to prevent further failed builds?
I am not sure why you'd rather not do this. Is it because the messages are different, because they are less informative, or some other reason?
My feeling is that they are almost the same, and only slightly less explicative. I don't foresee this being much of a support issue at all.
Yup, I am aware - I asked the OP to post this issue - OP is using his own code, and HW works elsewhere - So this is 100% a CP related issue, and I've not really used I2S at all in CP.
Ya I'm ok merging it now to unblock us. I may try and turn it back on later if I come up with free space some other way.
I hesitate because good error messages are really helpful. We don't always have a good understanding of why the builds are growing either. I think we can be more disciplined about feature freezing to save the space instead.
One notable difference I see in comparing the port definitions of unexpectedmaker_bling and adafruit_qtpy_esp32s3_4mbflash_2mbpsram is:
OPTIMIZATION_FLAGS = -Os does not exist in unexpectedmaker_bling/mpconfigboard.mk
@abv @berto-1 could one of you prepare that change as a pull request?
well done!
oh hey there's a way to see your open pull requests across all repositories on github: https://github.com/search?q=type%3Apr+author%3A%40me+is%3Aopen&type=pullrequests
huh there is no way to close your own PR in an archived repo, so it'll hang out in your list of open PRs forever. e.g., https://github.com/tenko/gltools/pull/3
aha, you can use archived: false https://github.com/search?q=type%3Apr+author%3A%40me+is%3Aopen+archived%3Afalse&type=pullrequests&ref=advsearch&s=updated&o=asc
@slender iron did you want the whole "uvc" module renamed "usb_uvc", or just the #define ? I asked on the PR last night but asking again so I can get working on it now.
@random junco hey, what's a good permalink for circuitpython show podcasts? awesome-circuitpython has an outdated domain that doesn't work (hxxps://circuitpythonshow.com)
English and translated messages probably have wildly frequency distributions. Are they different enough that having two static huffman tables (and spending 1 byte per message to select between them) is a benefit?
Thanks for asking, please use https://www.circuitpythonshow.com/@circuitpythonshow
@tulip sleet I'm talking to Kattni about the Inky Frame. One of the problems is that the buttons share a shift register with "other stuff" including the e-ink busy signal .. and those bits get shifted out first. What do you think about adding a "skip # bits at start" for ShiftRegisterKeys to accomodate this 'feature'?
D7 gets shifted out first so "key 0" is "inky busy", and physical buttons E...A are mapped onto keys 3..7 in that order, if I understand right what's happening
otherwise we can probably work through some code to discard events that don't matter
4816c0e Fix circuitpython show links - jepler
I checked with Paul Culter on discord and this is the new link.
The previous links lead to a security error; if you continue past it you get a 404.
[belatedly remembers dan's out this week, sorry for the ping]
I like usb_uvc more
OK
CircuitPython version
Adafruit CircuitPython 8.2.6-37-g7af75178ed-dirty on 2024-01-31; BLING! with ESP32S3
Adafruit CircuitPython 9.0.0-beta.0-7-g96be941d83 on 2024-01-31; BLING! with ESP32S3
(Both built for UM BLING by myself locally)
Code/REPL
"""
CircuitPython Wav files
"""
import time
import audiocore
import board
import audiobusio
import microcontroller
audio = audiobusio.I2SOut(microcontroller.pin.GPIO2, microcontroller.pin.GPIO1, micr...
I've reproduced this issue overnight on a Bling but I haven't seen it happen yet on a different S3 board running the same code overnight.
I think just or ignoring unwanted events is easiest. The unwanted signals may be in any order, and could be unused buttons, etc. Do I wouldn’t special case anything. If the transitions on the unwanted pins are really swamping the event queue, then I think a bit mask would be the thing to do.
Problem still happens in the final macOS 14.3 release and in macOS 14.4 beta1. Reported through Feedback Assistant, I name dropped Adafruit this time and filed it under Finder with a screenshot but made it clear where the issue is and that it affects command line utilities as well.
Current list of feedback IDs is FB13554680 FB13547720 FB13528351 FB13513401 FB13469123 FB13468526 FB13269327 FB13428357 FB13416096 FB13226668 FB13306896
@dhalbert how does this sound?
wifi.Radio.stations_ap returns a list of associated wifi.Station objects or throws an exception if not in AP mode (read-only)
wifi.Radio.max_stations_ap returns the maximum number of stations that can be associated in AP mode (read-only)
wifi.Station can't be created by users, has these properties:
- mac_address - byte array MAC address of the associated station (read-only)
- rssi - current RSSI of associated station (read-only, None on Pico W)
- ipv4_...
Renaming to usb_video per review request.
Because of how YUYV works, there are always a multiple of 2 horizontal pixels. This only affects oddball cases: you simply can't allocate a framebuffer that is (say) 95x96 pixels in size when working with the YUYV format.
Does it crash without the neopixel updates?
It is possible the I2S interrupt isn't being loaded into RAM for when the flash is busy. The I2S code was changed in 9.0 to the new ESP IDF 5 API.
I2S was changed in 9.0 for IDF 5 so I'm not surprised there are bugs like this.
The only types defined in the UVC standard are YUYV and other chroma style formats. A note on microsoft.com says that only YUYV and NV12 are required to be supported. However, I did find some info in Linux source code about GUIDs for RGB565_SWAPPED format, so we could look at it as a possibility.
I don't think that the RGB->YUYV conversion is taking much compute resource or causing much artifacting.
[I wrote a longer comment about this but apparently lost it rather than submitting it]
Removing for now, since it's redundant.
The impact of a mix of english + another language on compression has crossed my mind too. Maybe it is partly just the number of codepoints total?
Ah, ok. I had originally read this as power of two.
I'm ok leaving the plain disable too.
That wasn't actually my intent with this comment. All of the other locations were already CIRCUITPY_USB_UVC I was just making this consistent. I do think usb_video is a better name though.
Thank you! The CI errors are unrelated.
Thanks for the update! one q
Want to remove this comment?
Additionally having
/sdalways exist, a fixed unconfigurable name, while only a small amount of projects will rely on permenant sdcard mounts, doesn't sit right with me.
It will be created by default but can be deleted. I think this is fine.
This issue has been fixed upstream with https://github.com/espressif/esp-idf/commit/615d928aa59315f81f052b34f59db7eb502e8199.
Once we upgrade esp-idf in CP, this will be fixed.
Do note however, some more authmode changes have been made since last update.
One suggestion for the SD placeholder.txt.
The file itself isn't required so I'd say something different.
"SD cards are mounted at /sd and will shadow this file from Python. USB will not see the SD card contents here.\n");
Closing in light of testing after driver update. If similar behavior arises, feel free to re-open or create a new issue.
Thank you! I wonder if we should translate these strings in the future.
@dhalbert how does this sound?
wifi.Radio.stations_ap returns a list of associated wifi.Station objects or throws an exception if not in AP mode (read-only) wifi.Radio.max_stations_ap returns the maximum number of stations that can be associated in AP mode (read-only)
wifi.Station can't be created by users, has these properties:
* mac_address - byte array MAC address of the associated station (read-only) * rssi - current RSSI of associated station (read-o...
If you make it a namedtuple then you don't have to create a class.
I would say don't bother to raise an exception if you aren't in AP mode. There are other operations that just return None, etc. if you are in the wrong mode. In this case, just return an empty list.
I tried this now to check and make sure (I've tried so many variations of things to try and narrow this down I'll probably mix them up in my head). If I comment out all neopixel stuff, but let it make beeping sounds it willl also bomb with Hard fault: memory access or instruction error. I provoked it a little harder by copying a little directory of small .wav files instead of doing a lot of just touches while the program was running.
# SPDX-FileCopyrightText: 2023 Kattni Re...
@limber tinsel I'm not sure whether we've tried building silabs on mac
Ah...
You may need to change this line: https://github.com/adafruit/circuitpython/blob/main/ports/silabs/Makefile#L39
seems like you got almost to the end of the build
OK, time for me to learn how those make files work 😆
you can do make V="steps commands" to see what it is running
Thanks for the help, I'll see if I can edit the file to get to the correct place.
👍 I'm in pacific time so I'll be around for five or so more hours
I did manage to build it on linux
ok cool, thanks, I am in PT as well.
Even easier! I'll make it a named tuple (thanks for the example :)) and not raise the exception. Thanks!
We used to default to malloc() using SPIRAM but it disables dynamic WiFi TX buffers. The increased static buffer allocation prevents MBEDTLS from allocating everything it needs. So, switch the IDF to SPIRAM through caps_alloc only. This is pretty much what we do in CP8 except we no longer need to explicitly give the IDF SPIRAM memory to use.
Fixes #8682 (again)
Any improvements in the latest macOS beta with the FAT issues?
ok cool, thanks, I am in PT as well.
I don't think so. I think there was an update on the issue that went by
Oh, ok, I'll take a look. Thanks Scott.
I'm still running Ventura on my main work Mac as I was hoping this would get sorted before I upgraded it... but I'm going to have to move soon.
Oh, lots of updates in that issue - I've not been getting email notifications, weird.
I'm happy to add OPTIMIZATION_FLAGS = -Os to my board definitions, but I'd like to understand what it actually does and what side effects this might introduce.
I just tried this example on a Feather ESP32-S2 and don't see the crash. Please try with a recent 9.0 beta.
Please comment if this is still an issue and we'll reopen. (Or file a new issue.)
Please re-test this with a 9.0 beta release. If it is still an issue, then file a new issue referencing this one.
Please re-test this with a 9.0 beta release. If it is still an issue, then file a new issue referencing this one.
Please re-test this with a 9.0 beta release. If it is still an issue, then file a new issue referencing this one.
Please re-test this with a 9.0 beta release. If it is still an issue, then file a new issue referencing this one.
Please re-test this with a 9.0 beta release. If it is still an issue, then file a new issue referencing this one.
Please re-test this with a 9.0 beta release. If it is still an issue, then file a new issue referencing this one.
Please re-test this with a 9.0 beta release. If it is still an issue, then file a new issue referencing this one.
Please re-test this with a 9.0 beta release. If it is still an issue, then file a new issue referencing this one.
Please re-test this with a 9.0 beta release. If it is still an issue, then file a new issue referencing this one.
Please re-test this with a 9.0 beta release. If it is still an issue, then file a new issue referencing this one.
According to #8520 it was never fully implemented and the IDF API has changed in 5.2, which we haven't switched to yet.
I don't think this is urgent for 9.0.
I'm going to close this because there hasn't been any specific reproducing code added. Feel free to file another issue if it crops up again.
-Os is a gcc option that tell the compiler to "optimize for size". In general it's not wrong to omit it, but it'll help compiled software occupy less RAM. In theory any program should behave identically whether you use it or not, but we all know how that goes...
I think this is set in the 9.0.0 builds though and not 8.2.9 and if I'm reading the issue right the problem is happening in 8.2.9, so this probably isn't the issue.
-Os enables all -O2 optimizations except
thos...
@atomic summit can all of your boards do quad spi for flash and ram at 80mhz?
Technically they should all be able to. I thought we had already set all of that up, at least for 9.0.0?
I think your boards I did. I'm searching and replacing for the rest...
Ahh, ok.
it won't change octal ones. just dio
Thank you! I wonder if we should translate these strings in the future.
I hope it fits this time. :sweat:
We inherited a bunch of DIO from 8.x which used it for ROM flash settings. Pretty much everything should be able to do QIO.
S2, S3 and ESP32 all support 80mhz as well and ESP modules tend to work at that speed too. Only on ESP32 do we leave PSRAM at 40mhz because the 80/80 mode uses an extra SPI resource that we don't want to use.
Fixes #8612
Smoke tested on Adafruit Feather S2 with 4MB flash and 2MB ram. No other boards tested. We can back out these changes if boards have trouble wi...
I will occasionally mount SD cards to alternate folders so the placeholder message was bothering me a bit. It also took me a couple reads before I understood what the second sentence was trying to say. It's probably just me but what do you think about this as an alternate wording?
"SD cards mounted at /sd will hide this file from Python."
" SD cards are not visible via USB CIRCUITPY.\n"
The callbacks are marked as IRAM but the Python objects themselves aren't available when the cache is disabled. Flash accesses disable both external flash and external ram. I'm updating this API will have static counters in IRAM for it.
I believe I've reproduced the crash with a Matrix Portal S3, so it's not BLING-specific
Ran the same code as originally posted, just changing the neopixel pin
Copying around 25 Python source files from a project to CIRCUITPY while it was running it hard crashed into the boot loader. MATRXS3BOOT came up. Reset got me back to CircuitPython and the system was able to mount CIRCUITPY. I'm on Sonoma but I'd manually done the remount workaround. I seem to be able to crash it around 50-75% of ...
The Inky Frame is working with the latest CircuitPython changes. There are two sections towards the beginning of pins.c that handle making user-facing names for the buttons (because they are otherwise handled by a shift register, and return bit numbers). However, they also include the RTC alarm, ext trigger, and the display busy pin. This means that if use keypad.ShiftRegisterKeys and print the key_number, every time the busy pin is triggered, it shows that key_number 0 pressed. I wonder whether there's a way to separate out the three extra items, and still make them available in board, but not have them being picked up by keypad.
Anyway, that's my latest update. I'm heading out.
Images automagically compressed by Calibre's image-actions ✨
Compression reduced images by 6.6%, saving 38.00 KB.
| Filename | Before | After | Improvement |
|---|---|---|---|
| assets/images/boards/large/lichee_pi_4a.jpg | 49.08 KB | 45.75 KB | -6.8% |
| assets/images/boards/large/picomo_v2.jpg | 62.04 KB | 57.09 KB | -8.0% |
| assets/images/boards/original/lichee_pi_4a.jpg | 72.83 K... |
So far, since I built and started trying Adafruit CircuitPython 9.0.0-beta.0-7-g96be941d83 on 2024-01-31; BLING! with ESP32S3 and working around the IDFerror stuff I haven't had a hard fault. Some quick testing with the code above wouldn't crash it (not extensive, just a few minutes testing), and I spent time coding my regular program which would bomb it every few saves in vscode and that didn't crash it.
@slender iron apologies for the ping, got a last minute #circuitpython-2024 wish... I would love to be able to use long range wifi on the esp, it gets about 500m... no LoRa license fees or extra hardware required (but benefits from external aerial of course)... <#help-with-wippersnapper-and-adafruitio message>
I should have waited five minutes, they just gave the email address for it 🤦
That would be nice. Might negate the need for RFM with my mailbox project.
from adafruit_featherwing.tft_featherwing_35 import TFTFeatherWing35
wing = TFTFeatherWing35()
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; Adafruit Feather RP2040 USB Host with rp2040
Traceback (most recent call last):
File "code.py", line 2, in <module>
File "adafruit_featherwing/tft_featherwing_35.py", line 49, in __init__
File "adafruit_featherwing/tft_featherwing.py", line 81, in __init__
RuntimeError: Mount point directory missing
Fix: Create /sd on CIRCUITPY.
This looks great! We should add it natively
My guess is that there is interrupt code running when flash is unavailable and it's loading memory in PSRAM that is invalid. A DEBUG=1 build may stop with a backtrace instead of resetting into safe mode.
I can give it a try to add in the core, but It's probably beyond my means to get it working in time to use for the editor project for next week.
The current implementation of this relies on code in Jeffs adafruit_editor library which holds strings representing what is currently visible within it's terminal window.
I only had a quick look, but I didn't see anything inside of terminalio.Terminal that keeps that data as a string, or provides a way to read it back out of the Terminal after it's been written.
Right now the cursor is a 1 character Label that gets updated with the character currently at the X,Y location of the cursor each time it updates. So being able to get the string representation is necessary at least how it works now.
If there were a way to invert, or manipulate the palette used by a single tile within a TileGrid that might offer an even easier way to achieve a very similar visual.
Anyone have any idea how to install an older version of uncrustify on MacOS? Their own GitHub repo only has the two latest versions, which do not appear to be compatible with CircuitPython pre-commit.
The terminal doesn't know the string but it does know the tile index. It can copy that out. No worries if we need to add it later. It looks good either way!
I thought about that but it might mean more memory use to store which of the tiles are inverted
do you know if there is a way to get from a tile index to the character that it represents within a font? get_glyph_index() goes the other way from character to tile index. If we could reverse that then we could read characters from the TileGrid.
I think you'd need to build a reverse table lookup
the tilegrid only knows what is on screen though
Maybe it could copy the bitmap data for 1 tile into a new bitmap to put on top. Then it won't really need to know the character, just be able to copy from the source region and flip the colors.
it doesn't need to know the character. only the index into the bitmap
I'm running this version: Uncrustify-0.78.1_f from Homebrew on MacOS Sonoma. pre-commit works as expected with this config.
Really? I got a ton of errors seemingly related to the circuitpython/tools/uncrustify.cfg file.
I reinstalled uncrustify, and now it works. 🤷🏻♀️
Thanks @mortal kernel!
Inconsistent behavior. My favorite. 🙄
Part of the fun as I see it 🥸 . Seriously though, it's little problems like this that keep me on Linux for most of my dev work.
Quick question: What is the best way to measure elapsed wall clock time inside CP core code? Looking for something with millisecond accuracy suitable for use in a polling loop.
I'm thinking that supervisor_ticks_msxx() is the way to go.
I think so too
@gilded cradle I was wondering, on your journey to make the display ports for qualia to circuit python, did you first make them for the ESP IDF?
They seem to have drivers for some chips here .. https://github.com/espressif/esp-iot-solution/tree/master/components/display/lcd
I was wondering if you have something for the nv3052 .. there's something for the nv3022 here
@onyx hinge (who is off for the next couple weeks or so) originally wrote them and wrote up some technical information in a guide. I took that and reformatted a lot of it into a regular guide, did a lot of testing, figured out init settings if they were missing or not quite right, and wrote the qualia library as well as adding some Arduino stuff. I don't believe they were written specifically for the ESP IDF, but I could be wrong.
OK! I bought an awesome looking nv3052-based display on alibaba and have a qualia coming in tomorrow .. I hope I can get it to work. If so I will share the results!
I believe the round 4" 720x720 display is actually NV3052, so I would start with that. There are pages in the learn guide about figuring out the settings.
perfect I had a read through already and that's what I'll try first!
Is it possible to call something equivalent to usb_cdc.data.write() from within the core? I found this object: https://github.com/adafruit/circuitpython/blob/8e3e95307b56f66ef3833cf547e74ff5e1368a03/shared-module/usb_cdc/__init__.c#L162-L166 which seems possibly related, but I'm not certain if it actually is and thus far I've been unable to call write() on it if so.
looks like you want to call https://github.com/adafruit/circuitpython/blob/8e3e95307b56f66ef3833cf547e74ff5e1368a03/shared-bindings/usb_cdc/Serial.c#L109 with it?
is something like this getting close?
common_hal_usb_cdc_serial_write(usb_cdc_data_obj, "hi", 2, 0);
I'd guess so, but I'm not really good with C
not sure if the size should include the terminating \0 for example...
yes, in the circuitpython code I started doing that so that debugging prints don't interfere with the Terminal. Being able to do the same from the core will help me poke around and try implementing the cursor in there.
I'm not sure what that entails or how to do it.
makes a console_uart_printf() that only goes out the UART
you could make something similar for usb_data
Interesting, I could use UART as output as well if that one is hooked up already.
I tried a build with this code:
char myMessage[] = "hi";
common_hal_usb_cdc_serial_write(usb_cdc_data_obj, (uint8_t *)myMessage, 2, 0);
but it gets this error
../../shared-module/terminalio/Terminal.c:67:37: error: incompatible type for argument 1 of 'common_hal_usb_cdc_serial_write'
67 | common_hal_usb_cdc_serial_write(usb_cdc_data_obj, (uint8_t *)myMessage, 2, 0);
| ^~~~~~~~~~~~~~~~
| |
| usb_cdc_serial_obj_t
In file included from ../../shared-module/usb_cdc/__init__.c:33,
from ../../shared-module/terminalio/Terminal.c:33:
../../shared-bindings/usb_cdc/Serial.h:35:69: note: expected 'usb_cdc_serial_obj_t *' but argument is of type 'usb_cdc_serial_obj_t'
35 | extern size_t common_hal_usb_cdc_serial_write(usb_cdc_serial_obj_t *self, const uint8_t *data, size_t len, int *errcode);
| ~~~~~~~~~~~~~~~~~~~~~~^~~~
make: *** [../../py/mkrules.mk:85: build-pyportal_titano/shared-module/terminalio/Terminal.o] Error 1
My guess was that I have pointer vs. referenc eof the cdc_data_obj wrong, but I'm not sure how to do it properly (I really should try to take a step back and learn more C fundamentals).
I did also try:
common_hal_usb_cdc_serial_write(&usb_cdc_data_obj, (uint8_t *)myMessage, 2, 0);
and it seems to get further in the build process but does still result in other errors.
the & addition is right. what are the other errors?
GEN build-pyportal_titano/frozen_content.c
/home/timc/repos/circuitpython/gcc/gcc-arm-none-eabi-10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: build-pyportal_titano/shared-module/terminalio/Terminal.o (symbol from plugin): in function `usb_cdc_console_enabled':
(.text+0x0): multiple definition of `usb_cdc_console_enabled'; build-pyportal_titano/shared-module/usb_cdc/__init__.o (symbol from plugin):(.text+0x0): first defined here
/home/timc/repos/circuitpython/gcc/gcc-arm-none-eabi-10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: build-pyportal_titano/shared-module/terminalio/Terminal.o (symbol from plugin): in function `usb_cdc_console_enabled':
(.text+0x0): multiple definition of `usb_cdc_data_enabled'; build-pyportal_titano/shared-module/usb_cdc/__init__.o (symbol from plugin):(.text+0x0): first defined here
/home/timc/repos/circuitpython/gcc/gcc-arm-none-eabi-10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: build-pyportal_titano/shared-module/terminalio/Terminal.o (symbol from plugin): in function `usb_cdc_console_enabled':
(.text+0x0): multiple definition of `usb_cdc_descriptor_length'; build-pyportal_titano/shared-module/usb_cdc/__init__.o (symbol from plugin):(.text+0x0): first defined here
/home/timc/repos/circuitpython/gcc/gcc-arm-none-eabi-10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: build-pyportal_titano/shared-module/terminalio/Terminal.o (symbol from plugin): in function `usb_cdc_console_enabled':
(.text+0x0): multiple definition of `usb_cdc_add_descriptor'; build-pyportal_titano/shared-module/usb_cdc/__init__.o (symbol from plugin):(.text+0x0): first defined here
/home/timc/repos/circuitpython/gcc/gcc-arm-none-eabi-10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: build-pyportal_titano/shared-module/terminalio/Terminal.o (symbol from plugin): in function `usb_cdc_console_enabled':
(.text+0x0): multiple definition of `common_hal_usb_cdc_enable'; build-pyportal_titano/shared-module/usb_cdc/__init__.o (symbol from plugin):(.text+0x0): first defined here
/home/timc/repos/circuitpython/gcc/gcc-arm-none-eabi-10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: build-pyportal_titano/shared-module/terminalio/Terminal.o (symbol from plugin): in function `usb_cdc_console_enabled':
(.text+0x0): multiple definition of `usb_cdc_set_defaults'; build-pyportal_titano/shared-module/usb_cdc/__init__.o (symbol from plugin):(.text+0x0): first defined here
/home/timc/repos/circuitpython/gcc/gcc-arm-none-eabi-10-2020-q4-major/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: build-pyportal_titano/shared-module/terminalio/Terminal.o (symbol from plugin): in function `usb_cdc_console_enabled':
(.text+0x0): multiple definition of `common_hal_usb_cdc_disable'; build-pyportal_titano/shared-module/usb_cdc/__init__.o (symbol from plugin):(.text+0x0): first defined here
Memory region Used Size Region Size %age Used
FLASH_BOOTLOADER: 0 GB 16 KB 0.00%
FLASH_FIRMWARE: 578204 B 1000 KB 56.47%
FLASH_FILESYSTEM: 0 GB 0 GB
FLASH_CONFIG: 0 GB 0 GB
FLASH_NVM: 0 GB 8 KB 0.00%
RAM: 10936 B 256 KB 4.17%
collect2: error: ld returned 1 exit status
make: *** [Makefile:382: build-pyportal_titano/firmware.elf] Error 1
perhaps the way I did the include is incorrect?
#include "shared-module/usb_cdc/__init__.c"
with either of these:
#include "shared-bindings/usb_cdc/__init__.h"
// or
#include "shared-module/usb_cdc/__init__.h"
it gets this same undeclared error:
../../shared-module/terminalio/Terminal.c: In function 'common_hal_terminalio_terminal_construct':
../../shared-module/terminalio/Terminal.c:67:5: error: implicit declaration of function 'common_hal_usb_cdc_serial_write' [-Werror=implicit-function-declaration]
67 | common_hal_usb_cdc_serial_write(&usb_cdc_data_obj, (uint8_t *)myMessage, 2, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../shared-module/terminalio/Terminal.c:67:5: error: nested extern declaration of 'common_hal_usb_cdc_serial_write' [-Werror=nested-externs]
../../shared-module/terminalio/Terminal.c:67:38: error: 'usb_cdc_data_obj' undeclared (first use in this function); did you mean 'usb_cdc_data_enabled'?
67 | common_hal_usb_cdc_serial_write(&usb_cdc_data_obj, (uint8_t *)myMessage, 2, 0);
| ^~~~~~~~~~~~~~~~
| usb_cdc_data_enabled
../../shared-module/terminalio/Terminal.c:67:38: note: each undeclared identifier is reported only once for each function it appears in
cc1: all warnings being treated as errors
make: *** [../../py/mkrules.mk:85: build-pyportal_titano/shared-module/terminalio/Terminal.o] Error 1
where in the file are you including it?
try shared-bindings/usb_cdc/Serial.h
rg common_hal_usb_cdc_serial_write ../..
../../shared-module/usb_cdc/Serial.c
81:size_t common_hal_usb_cdc_serial_write(usb_cdc_serial_obj_t *self, const uint8_t *data, size_t len, int *errcode) {
../../shared-bindings/usb_cdc/Serial.c
109: return common_hal_usb_cdc_serial_write(self, buf, size, errcode);
../../shared-bindings/usb_cdc/Serial.h
35:extern size_t common_hal_usb_cdc_serial_write(usb_cdc_serial_obj_t *self, const uint8_t *data, size_t len, int *errcode);
The include statement itself is at the top of the file with the other pre-existing includes. I've put it inside of shared-module/terminalio/Terminal.c and the line trying to actually use it is down inside of common_hal_terminalio_terminal_construct() where I just stuck it as a test to see if I could get it building.
with #include "shared-bindings/usb_cdc/Serial.h" it gets undeclared error:
../../shared-module/terminalio/Terminal.c: In function 'common_hal_terminalio_terminal_construct':
../../shared-module/terminalio/Terminal.c:68:38: error: 'usb_cdc_data_obj' undeclared (first use in this function); did you mean 'usb_cdc_serial_obj_t'?
68 | common_hal_usb_cdc_serial_write(&usb_cdc_data_obj, (uint8_t *)myMessage, 2, 0);
| ^~~~~~~~~~~~~~~~
| usb_cdc_serial_obj_t
../../shared-module/terminalio/Terminal.c:68:38: note: each undeclared identifier is reported only once for each function it appears in
make: *** [../../py/mkrules.mk:85: build-pyportal_titano/shared-module/terminalio/Terminal.o] Error 1
../../shared-module/usb_cdc/__init__.c
162:static usb_cdc_serial_obj_t usb_cdc_data_obj = {
258: usb_cdc_set_data(data ? MP_OBJ_FROM_PTR(&usb_cdc_data_obj) : mp_const_none);
260: usb_cdc_data_obj.idx = idx;
You'll need to remove the static and put an extern in the corresponding header
It's stored as data in usb_cdc_module's .globals, would it make sense to fetch it from there rather than exposing the underlying C struct's name as a global? Not that I know how to get a value from a module's dict in C.
Ooof. Thanx for the update, John.
While I"m normally a C++ dev, this week I've tried to use Matrix S3 with
Circuit Python 9 that insists that doing a reboot every time you save your
Python source is a sane thing and this bug makes developing on that device
just miserable since most unmounts will fail and/or corrupt the drive.
Writing and debugging code isn't hard enough - let's do it on a device that
literally self destructs some substantial percentage of the time you press
"save" in...
@robertlipe - is it a reboot - CIRCUITPY ejects and then re-connects and the serial terminal disconnects and re-connects - or is it the REPL reloading and re-running code.py? If it's the latter, it's expected behavior and you can disable that with
import supervisor
supervisor.runtime.autoreload = False
in boot.py or code.py
if it really is a reboot, CircuitPython 9 has just moved to beta and I'm sure the devs would like to hear about any code that can cause a reproduci...
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; Raspberry Pi Pico W with rp2040
Code/REPL
import board
import busio
import sdcardio
import storage
spi = busio.SPI(clock=board.GP18, MOSI=board.GP19, MISO=board.GP16)
cs = board.GP17
sd = sdcardio.SDCard(spi, cs)
vfs = storage.VfsFat(sd)
storage.mount(vfs, '/sd')
with open("/sd/pico.txt", "w") as file:
file.write("1. Hello, world!\r\n")
Behavior
Tr...
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; Adafruit Feather RP2040 USB Host with rp2040
Code/REPL
"crash.py"
"""Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27;
Adafruit Feather RP2040 USB Host with rp2040
TFT FeatherWing 3.5in"""
import displayio
from adafruit_featherwing.tft_featherwing_35 import TFTFeatherWing35
wing = TFTFeatherWing35()
display = wing.display
group = displayio.Group()
display.root_group.append(gr...
I just tried building from a clean install on MAC OS sonoma -- I am trying an espressif build for adafruit_esp32s3_camera but it fails with ```The following Python requirements are not satisfied:
Requirement 'pyelftools<=0.29' was not met. Installed version: 0.30
To install the missing packages, please run "install.sh"
Diagnostic information:
IDF_PYTHON_ENV_PATH: /Users/jerryneedell/.espressif/python_env/idf5.1_py3.11_env
Python interpreter used: /Users/jerryneedell/.espressif/python_env/idf5.1_py3.11_env/bin/python
Constraint file: /Users/jerryneedell/.espressif/espidf.constraints.v5.1.txt
Requirement files:
- /Volumes/CircuitPythonBuild/circuitpython/ports/espressif/esp-idf/tools/requirements/requirements.core.txt
Python being checked: /Users/jerryneedell/.espressif/python_env/idf5.1_py3.11_env/bin/python
CMake Error at esp-idf/tools/cmake/build.cmake:366 (message):
Failed to run Python dependency check. Python: python, Error: 255
Call Stack (most recent call first):
esp-idf/tools/cmake/build.cmake:498 (__build_check_python)
esp-idf/tools/cmake/project.cmake:547 (idf_build_process)
CMakeLists.txt:12 (project)
-- Configuring incomplete, errors occurred!
gmake: *** [Makefile:420: build-adafruit_esp32s3_camera/esp-idf/config/sdkconfig.h] Error 1
jerryneedell@Mac-mini espressif %
When runnig the install.sh I see ```Installing collected packages: pyelftools, cryptography
Attempting uninstall: pyelftools
Found existing installation: pyelftools 0.30
Uninstalling pyelftools-0.30:
Successfully uninstalled pyelftools-0.30
Attempting uninstall: cryptography
Found existing installation: cryptography 36.0.2
Uninstalling cryptography-36.0.2:
Successfully uninstalled cryptography-36.0.2
Successfully installed cryptography-39.0.2 pyelftools-0.29
All done! You can now run:
. esp-idf/export.sh
I think that is where it is accessed from in python land, but I'm not sure if it's possible or how to access it from C in the core.
Thats what it looks like to me in the first error it mentioned wanting <=0.29 but you had 0.30 originally.
Is the install.sh not getting the right versions?
the output in your second copy/pasted chunk looks like it did successfully uninstall 0.30 and then install 0.29, so from that output it seems like it suceeded in getting the version it wants to have as far as I can tell.
hmmm -- okay -- it is happier now -- confusing, but happier...
It seems like it took a few tries to get it right, but it is working now...
Hello. I did a circuitpython 8.2.x build with DEBUG=1 Adafruit CircuitPython 8.2.6-37-g7af75178ed-dirty on 2024-02-02; BLING! with ESP32S3 and man in DEBUG=1 it is just eager to crash. With the same test program above with the flashing neopixels and the audio beeping it will die without even copying files in a minute or two. Copying a single file about 50k to the CIRCUITPY will bomb it.
If I comment out all the audio lines (leaving flashing neopixels) it seems to run fine withou...
Some grep'ing shows that might be coming from common-hal/microcontroller/__init__.c
void common_hal_mcu_disable_interrupts(void) {
assert(xPortGetCoreID() == CONFIG_ESP_MAIN_TASK_AFFINITY);
if (nesting_count == 0) {
portENTER_CRITICAL(&cp_mutex);
}
nesting_count++;
}
CircuitPython version
Adafruit CircuitPython 9.0.0-alpha.6 on 2023-12-12; Waveshare RP2040-Zero with rp2040
Code/REPL
from collections import deque
sa = deque((), 4)
list(sa)
Behavior
It's pretty self-explanatory:
Description
No response
Additional information
No response
Good morning! I was trying to create a USB MIDI host using a Lolin S2 Mini (equipped with an ESP32-S2, so supposedly should have support for USB host). But... I found out that usb.core is not supported on that board. Why is that? Is there any workaround for this?
a far as I know usb host is still very much work in progress
I thought USB host was iMX and rp2040 based on the release notes
I understand it's released for several boards, isn't it?
it usually requires special hardware to be added to the board
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; Adafruit MatrixPortal S3 with ESP32S3
Code/REPL
# SPDX-FileCopyrightText: 2023 Liz Clark for Adafruit Industries
#
# SPDX-License-Identifier: MIT
import os
import gc
import ssl
import time
import wifi
import socketpool
import adafruit_requests
import adafruit_display_text.label
import board
import terminalio
import displayio
import framebufferio
import rgbmatrix
impor...
@stuck elbow I understand. But ESP32-S2 supposedly has built in host capabilities. I've been trying to make it work in Arduino framework to no success. I was hoping I was more lucky with Circuitpython...
the fact that the chip has some capabilities doesn't mean that circuitpython has support for them, or that the particular board has the hardware for them
Starting with CP 9.x, a folder has to be created to be used as a mount point before the SD card can be mounted. The quick fix is to add
import os
if not '/sd' in os.listdir('/'):
os.mkdir('/sd')
sometime before the storage.mount command.
Although I believe PR #8860 will resolve this by creating the mount point file for most boards (they need to have the sdcardio or sdioio modules enabled on the build, which I believe is the default).
This sounds like it could be related to #8690
By the manufacturer, it has USB OTG built in
Adding a description to the T-Display ESP32 4M with 3 new pictures.
Pull request for this board was added January 18th, 2024 https://github.com/adafruit/circuitpython/pull/8787
do they also have documentation on how to use it?
Kind of... They have a library for ESP-IDF framework. It should work in Arduino too . This example should work https://github.com/touchgadget/esp32-usb-host-demos (but in my case, it didn't)
Ya, or it looks like there is a usb_cdc_set_data(). We could add usb_cdc_get_data() if it doesn't exist.
USB OTG isn't supported by TinyUSB yet. We only support USB host in CircuitPython where we can have a second USB instance dedicated for host.
(So usb_host isn't implemented on ESP)
we also want to support an external host chip from circuitpython but we haven't added that yet
I understand... things are much more complicated with 1 USB only. But there are some ESP boards with 2 USBs, like these, no? https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/hw-reference/esp32s3/user-guide-devkitc-1.html
One is just an external USB to serial adapter. So from the ESP perspective it is only one USB still.
we do want to support OTG eventually
but the external host chip is more of a priority
Although I believe PR #8860 will resolve this by creating the mount point file for most boards (they need to have the sdcardio or sdioio modules enabled on the build, which I believe is the default).
This will only apply to new filesystems. It likely won't apply to most folks.
Does this work in MicroPython?
I was thinking there's probably a way to lookup something in the dict but I'm already at the limit of my knowledge here
Interesting! Maybe some CP code is being run on the other core.
I wouldn't worry about it too much though since 9.0.0 seems to work. That's where we're headed and we're working to get that stable.
The terminal's group is stored in ROM. I'm not surprised it is crashing. :-)
We should add an error message for this.
Ya, there definitely is.
looks
mp_map_lookup
if you don't know it off the top of your head I feel better about failing to figure it out 😉
You need write access to CIRCUITPY '/' to create the '/sd' folder. Maybe print instructions for doing that?
Unpopular work-around for Sonoma: Disable CIRCUITPY, use ampy to write files to the device.
MicroPython v1.22.1 on 2024-01-05
doesn't work either.
My knowledge of CP memory management wouldn't fill a teacup, so before I resort to the code I'm wondering if there's a write-up somewhere?
(I'm making some assumptions about what gets GC'ed that might be bad)
it's a mark and sweep gc
it starts with the root pointers, scans the memory they point to, and follows anything that looks like a pointer in there, marking all that as used, then it frees everything that's left
You need write access to CIRCUITPY '/' to create the '/sd' folder. Maybe print instructions for doing that?
I suspect most folks would create the folder through the CIRCUITPY drive, so it's probably not worth adding instruction text on changing the storage.remount flag in the CircuitPython core.
I personally liked the idea of adding the os.listdir check from the snippet above because it doesn't hide any error messages like "read-only file system" as a Try/Except block would. Getting t...
So far, so good. I understand mark and sweep. If I use an m_ prefixed allocator like m_alloc I'm guaranteed that the allocation is GC'able?
sorry, no idea
the trick is that it doesn't know for sure if it's a pointer or just a part of some string or something, so sometimes it will keep pieces of memory that are not actually being pointed to
this is why it can't move things around - it can't go back and update the pointer, because it's not sure that it's a pointer and not just some random data
Looking into the code, I think I have it. m_new() is a macro that invokes m_alloc() which invokes malloc that is overridden by a macro in py/malloc.c that invokes gc_alloc(). So, the allocation will be GC'ed.
Yes
One thing we could do to save code size is remove the context manager of the core classes. I don't think I've ever seen someone use that
BusDevice uses it for transactions but not the core classes
I would love to take a deep dive into CP memory management. Maybe after I've got _bleio buttoned up.
note that you can only use m_malloc when the vm is running
(and ble runs outside the vm sometimes)
Whoa, where is that happening? With BTstack events are delivered only when polled, I'd assumed that was true for other BLE stacks as well.
the ble workflow runs ble outside the vm
I see. So memory allocations that happen in BLE workflow need to be static or ?
they used to be static only
but you can use port_malloc in 9.0 to allocate outside the vm
no GC though
Thank you! All good to know.
CircuitPython version
CP 9.0 beta.0
The code runs OK under CP 9.0 alpha.6
Code/REPL
I am trying to run the MartixPortal_S3 SMS Messge Board code https://github.com/adafruit/Adafruit_Learning_System_Guides/tree/main/Matrix_Portal_S3_SMS_Scroller
Behavior
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; Adafruit MatrixPortal S3 with ESP32S3
>>>
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to ...
Might have something to do with the helper library having a 65535 buffer limit hardcoded which was recently raised to 32bits?
I have the same issue, but some additional info:
- If I enter the IP address only into the browser, the main page for workflow loads correctly
- If I click on the link for "file browser", the file browser page loads, but the following message appears near the top of the page:
ℹ️ USB is using the storage. Only allowing reads. Try ejecting the CIRCUITPY drive. See Getting Started with Web Workflow for detail...
This has to do with the changes to validation of arguments to bitmaptools.blit.
The bitmap is created with a size of 0x0 pixels initially:
self._buffer = displayio.Bitmap(0, 0, 65535)
this is rather dubious,but in the past it worked.
Now, it appears the changed ("improved") argument validation rejects this, because the pixel (0,0) is not actually in the image. There are no valid X coordinates in the image, because the valid coordinates are from 0 to (width - 1), or f...
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM with ESP32S3
Board ID:adafruit_feather_esp32s3_4mbflash_2mbpsram
Code/REPL
# SPDX-FileCopyrightText: 2023 Frederick M Meyer
#
# SPDX-License-Identifier: MIT
import ipaddress
import ssl
import wifi
import socketpool
import adafruit_requests
import random
import os
import time
import rtc
import adafruit_ntp
import adafruit_date...
Are you using the 8.x .mpy bundle for running with 8.2.9, and the 9.x .mpy bundle for running with 9.0.0-beta.0?
I used circup to check the libs. I saw it download both 8. and 9. bundles. I'll do it manually and see if that makes a difference.
C:\Users\fred>circup update --all
Found device at D:, running CircuitPython 9.0.0-beta.0.
None of the modules found on the device need an update.
I tried simply changing
self._buffer = displayio.Bitmap(0, 0, 65535)
to
self._buffer = displayio.Bitmap(1, 1, 65535)
``` in the two places I found it in message.py . It still works with alpha.6 but now fails in the display_text library under beta.0
It does get further along and displays a message briefly before failing so this was progress
Traceback (most recent call last):
File "code.py", line 142, in <module>
File "/lib/messageboard/mess...
Yes, that PR is directed towards RP, for a product id (PID) from their vendor id (VID, 0x2E8A). For a proper CircuitPython port we need to have a unique VID:PID for every board that exposes USB.
Is that really true? Why do you need to have a unique VID:PID? Why can't you instead have a standard VID:PID for a particular piece of silicon and identify the board through the Product ID?
From the conversation here it looks like we may have landed on deciding that 0 width or height blit should be allowed: https://github.com/adafruit/circuitpython/pull/7867
although it doesn't state specifically 0 height and width it would follow that both should work if either is allowed IMO. Nor does it say that a Bitmap with 0 width or height is allowable, just the blit action. But perhaps we should aim for consistency. If blit allows 0 sized actions because it makes certain image proce...
Is that really true? Why do you need to have a unique VID:PID? Why can't you instead have a standard VID:PID for a particular piece of silicon and identify the board through the Product ID?
I'm not sure what you're suggesting here. The "Product ID" is the "PID". The RP2040 chip itself presents a single VID:PID because it has a built-in bootloader in ROM. But when the board is running Arduino or CircuitPython, it presents an Arduino-specific VID:PID or a CircuitPython-specific VID:PID f...
Replicated on macOS 10.5.7 on an Intel MacBook Pro with
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; Adafruit Macropad RP2040 with rp2040
and tio v2.4.
I'd be happy to get a stack trace or even do a bit of debugging once I get a RP2040 board with accessible SWD pins, which I don't currently have. It might be a while before I get around to obtaining one.
If you have a spare Pico or even better, a Feather RP2040 with SWD header that you can send my way, that would be great. Otherwise, I probably won't get one until the next time I have an Adafruit order to add on to.
Additional observation: running this loop on a M2 MacBook Air will succeed for a long time (several minutes before I stopped it), but will tend to cause the crash once interrupted with Ctrl-C:
while :; do stty -a < /dev/cu.usbmodem1101; done
In the past, when tracing USB CDC traffic on a different device with a Beagle, I noticed that macOS will sometimes abort a CDC-related control transfer partway through, and I wonder if that's related.
I'm gone for a week, so I recommend that if someone decides how to fix this in the meantime that they add tests. Creation of bitmaps and use of bitmaptools (&bitmapfilter) functions can be tested at build time by adding files under tests/circuitpython: a .py file and a .py.exp file containing the expected output.
I do somewhat understand the purpose of allowing the creation of a 0x0 bitmap, and I can see that it's probably then also necessary to allow to blit from a 0x0 bitmap, whi...
currently only Bluetooth LE profiles are supported by Circuitpython. I would like to implement a A2DP with my ESP32S3. Has there been some work for supporting Bluetooth Classic protocols?
Had another look at MKRVidor4000 as a FeatherM0Basic
mainly because I found a Dallas DS18B20 that I got ages ago and realised it might have some EEPROM inside it
...which originated from a search to find 1 floating gate memory cell as a through hole component...
CircuitPython is able to drive pins ~3, ~4, ~5 as D0, MOSI, SCK on a board it has no idea it's running on!...
The procedures outlined might be a bit experimental and latest versions should be used if possible
but I have included a quick port of the OWI/OWB driver from the webpage rewritten as def DS18B20_<Method>(Port, Data, etc):
This is one potential solution for #8876.
The crux of the 0,0 size was that max was ending up less than min in the range check which causes it to fail range validation automatically.
With this build I am able to run the SMS scroller code successfully on a Matrix Portal S3. It's only scrolling the default text, I have not set up anything wtih adafruit.io or SMS for it. But I did successfully replicate the exception mentioned in the issue with that default text and confirmed this version ...
@FoamyGuy Thanks for the quick fix. I have also tested this on my MatrixPortal S3 and even sent an updated message via AIO. I won't pretend to fully understand the fix. I need to study the code and previous discussions to come up to speed but it works from me ;-)
Bluetooth Classic is only supported by the ESP32 chip, not by ESP32-S3. We have looked at bit at Bluetooth Classic support, but not in earnest.
Note that Bluetooth Classic is only supported by the ESP32 chip, not by ESP32-S3.
Was this ever implemented in Circuit Python? I am seeing a stuck bus issue with I2C using:
Adafruit CircuitPython 8.2.8 on 2023-11-16; Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM with ESP32S3
In a very specific situation, the clock line gets stuck low. In my case, I am trying to initialize an SHT40 sensor, but no sensor is present on the bus.
try:
sht = adafruit_sht4x.SHT4x(i2c)
except:
print("No SHT40 device detected")
This causes the code to crash next time I a...
Changes in 18 files is a lot. I copied the changes to my local build, compiled the image and uploaded the created firmware.bin to my T-Display S3 with esptool write_flash 0x0 firmware.bin. It appears as FTHRS3BOOT flash drive after reset. Now I copied the firmware.uf2 into this drive and the board is now running Circuitpython 9.0.0 with display:
The MADCTL value 0x60 seems...
Two problems are solved. I had already flashed another CircuitPython image to this board prior to trying this new build here. The old image was compiled for 8MB and I think the partition scheme was carried over and not overwritten. After now erasing the flash first and then flash the firmware.bin with the esptool it appeared right away as CIRCUITPY USB flash drive in Windows with a capacity of 13.6 MByte.
Don't know yet how to get into the UF2 boot mode where I could just...
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; uGame22 with rp2040
Code/REPL
>>> import bug
>>> bug.__file__
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'module' object has no attribute '__file__'
Behavior
Make a directory bug and create a file __init__.py inside. When you import it, the imported module will have no __file__ defined.
Description
This is a regression. Previous...
Pin description for STEMMA connector is also working correctly. Warning of missing pull up resistors if nothing is connected, and finding attached bus devices.
Def still an issue. For anyone looking through this thread for an answer, Adafruit published a shell script that did work for me: https://github.com/adafruit/circuitpython/issues/8449
Adafruit: would be great to add a notice about this to the pages for affected boards! Took a lot of looking around to find the answer
Interesting Note: on the ESP32S3 TFT, running 8.2.9 I got 3 open sockets before it raised an exception. On 9.0.0-beta.0 I got 4 (SSL to be specific)
@tlyu what version of macOS are you using?
@ure What is your OS, and if macOS, what kind of Mac?
Adafruit: would be great to add a notice about this to the pages for affected boards! Took a lot of looking around to find the answer
We put warnings here: https://learn.adafruit.com/adafruit-feather-rp2040-pico/creating-and-editing-code (same page is mirrored to almost all the board guides, and there is more detail here: https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting#macos-sonoma-14-dot-x-disk-errors-writing-to-circuitpy-3160304.
One trouble is that there are mul...
Mentioned above: 13.6.3 on the M2 MBA; 10.5.7 on the Intel MBP. If it does happen to be a timing issue, CPU speed and system load might be a factor.
Al running sonoma 14.3 one mac mini m1, one studio m2, macbook m1. I can confirm that this does not occur on linux, don't have access to a windows computer
It's likely to be a lower-level problem, possibly with the Pico SDK. On a hunch, I uploaded a Blink sketch from the Arduino IDE, Philhower core v3.6.2. connecting and then disconnecting with tio causes the program to freeze and the device to become unresponsive on USB CDC until physically reset.
@tlyu ok super, if fixed upstream this will follow in a future release, nice ;)
Updated to 3.7.0 of the Philhower core; bug still present.
Sending thanks to you all for having the majority of the conversations you all have be so open and available, I know that it must be slower to do it that way but it sure makes for a good community.
Is Liz hosting tomorrow? Unsure if Scott is hosting where to put my status update above or below in the doc.
Usually I'm the first one during the week to write in the doc so I don't have this dilemma. 😅
This adds optional device specific stubs for the board module. This is built upon the work of @justmobilize from this stub generator script: https://gist.github.com/justmobilize/1a29481069a7dcf121d0fcc0d91a3121
They get generated by make stubs and included inside of the stubs under a new directory board_definitions/
Nothing changes by default so users who just pip install circuitpython-stubs and don't do anything else will see the exact same things they see today in IDE Hints an...
so eventually i'll probably try to track down the RP2040 hard fault with a debugger, possibly with Pico SDK (because it's starting to look like the bug is there, or in the TinyUSB driver). still need an RP2040 board with accessible SWD lines. let me see if there's anything else i'm likely to want to order at the moment to piggyback on
With the Pico SDK, using a blink example modified to enable CDC for stdio, though not outputting anything to it, connecting and disconnecting from the CDC serial port a few times using tio freezes the program and makes CDC unresponsive.
By adding the 'sd' directory to the CIRCUITPY drive manually or through the code, solve the problem.
Thank you.
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; ESP32-S3-EYE with ESP32S3
Code/REPL
import board
import espcamera
cam = espcamera.Camera(
data_pins=board.CAMERA_DATA,
external_clock_pin=board.CAMERA_XCLK,
pixel_clock_pin=board.CAMERA_PCLK,
vsync_pin=board.CAMERA_VSYNC,
href_pin=board.CAMERA_HREF,
pixel_format=espcamera.PixelFormat.JPEG,
frame_size=espcamera.FrameSize.SVGA,
i2c=board.I2C(...
This appears to be addressed by PR #8880.
Leaving open pending review and acceptance of the PR.
With the Pico SDK, using a
blinkexample modified to enable CDC for stdio, though not outputting anything to it, connecting and disconnecting from the CDC serial port a few times usingtiofreezes the program and makes CDC unresponsive.
This is very interesting. Pinging @hathach on this: this problem appears specific to macOS. This could be an issued opened either on https://github.com/hathach or https://github.com/raspberrypi/pico-sdk. @hathach would you prefer one repo or the other.
Update: the hello_world/usb Pico SDK example also fails in a similar way, though somewhat less obviously than a blinking LED ceasing to blink.
please add tests so someone doesn't break this again.
The 8 parallel lines connecting to the display really speed up the graphic output. A simple 1000x "Hello world" gets around 5x faster:
import board, displayio, time
board.DISPLAY.root_group = displayio.CIRCUITPYTHON_TERMINAL
start = time.monotonic()
for i in range(1000):
print("Hello world!", end=" ")
print(f"\nThis took {time.monotonic() - start} seconds.")
New 1.89 seconds versus 10.3 seconds. Without rendering to the build-in display (serial) its 1.27 seconds. L...
Working on the test for this and realized that the fix is insufficient. It covers the usage from SMS scroller but not more generally the 0 width or height blits.
new commit incoming with a corrected fix and test.
I'm not sure what's up with the pre-commit failure. It passes for me locally on this branch. In the actions log it looks like it found a handful of formatting changes it wants to make, but none of them appear to be in files that this PR touches as far as I can tell.
I re-tested this version on the Matrix portal s3. I also ran the test code (with uncommented section for display) on a Feather TFT S3.
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; ESP32-S3-DevKitC-1-N8R8 with ESP32S3
Code/REPL
# Crashes:
import board, busio
serial = busio.UART(board.IO15, board.IO18, baudrate=115200)
serial.write(b'1234567890')
# Works:
import board, busio
serial = busio.UART(board.IO15, board.IO18, baudrate=115200)
serial.write(b'1234567890')
Behavior
>>> import board, busio
>>> serial = busio.UART(board.IO15, board.IO...
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; Adafruit Feather RP2040 USB Host with rp2040
Code/REPL
https://github.com/adafruit/circuitpython/blob/main/tests/circuitpython-manual/usb/basic_keyboard.py
import array
import usb.core
import sys
# This is a WASD Code Keyboard with a generic controller in it.
USB_VID = 0x258a
USB_PID = 0x1
# This is ordered by bit position.
MODIFIERS = []
device = usb.core.find(idVendor=...
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; Adafruit Feather RP2040 USB Host with rp2040
Code/REPL
print("hello")
Behavior
I've tested various states of powering on the microcontroller with and without the USB Keyboard plugged in to the host port and found that if the microcontroller powers up with the keyboard plugged in, the keyboard will not work until it has been unplugged and re-plugged.
I tested the following...
I tried toggling that pin in boot.py as well with this code:
usb_host_power = digitalio.DigitalInOut(board.USB_HOST_5V_POWER)
usb_host_power.direction = digitalio.Direction.OUTPUT
usb_host_power.value = False
time.sleep(0.5)
usb_host_power.value = True
But it still results in the same ValueError: USB_HOST_5V_POWER in use that came from code.py as well.
<@&356864093652516868> We'll have our weekly meeting in about 90 minutes from now in this text channel and in the circuitpython voice channel. Please take the time to add your notes in advance to the document: https://docs.google.com/document/d/1TwKXc8VJyR-Zju5QWouz7psBYjrVBhrkBT4DtXMLVlQ/edit -- I look forward to everyone's updates!
I think Liz is. Everything but the host is usually alphabetical
When I needed to build a video player/recorder recently, I decided to house it inside a VHS cassette to make it look really cool! It uses a Raspberry Pi 3A+ and a bunch of other parts. You can see the full list and the code in the alanb128 GitHub repository.
If you enjoy videos about retro-technology, Raspberry Pi projects, electronics, audio e...
the use of the with statement does help a lot of traditional python programmers transitioning into circuit python. It has helped me explain a few concepts of what a micro can and can't do, but that's a different group
probably worth an audit, hard to know how much extrnal code will break ; definitely need context managers on files, sockets, and other core-core stuff
that sounds prudent 👍
@slender iron if you let me know the branch for SSL changes, I can try to build and see if it's any different
Things like uart would still allow it?
Thanks for hosting Liz! Hope everyone has a great week 🎉
Thanks all! Have a great week!
potentially not. that's why I'm asking if people like having it
Is there a command to build a single board? I haven't done this yet
I do really like the context manager because it's design pattern is something that's native to python, so I've found it helpful when explaining how to manage resources on a micro--if someone see's it in a with statement, it makes sense that the statement handles opening and closing of the resource. That said, the demographic I normally engage with is python programmers who have little to no electronics experience, and I can see that making up a fraction of a fraction of the userbase
fwiw on PRs there are also "artifacts" that get built and uploaded to github. You have to navigate the actions section to find them as their a bit buried. But they can be downloaded and used from there without needing to build if you're specifically trying to build a PR branch. For that PR they're here: https://github.com/adafruit/circuitpython/actions/runs/7732060051 if you scroll down on the right half of the page to the artifacts section then find the device you want in the list.
I think having it on large resourses (responses) and things you spicifically want to close after (sockets) makes the most sense if you want to limit it
(note that the thing at the top of the right column prevents normal mouse scrolling because it's some kind of canvas drag n drop thing. But once you scroll past it by moving mouse outside then the page scrolls like normal.)
Nice! I'll still try to build it, but will test with that one!
Still just got 4. Might try out a few other boards to do some comparisons
I'd filing an issue with MicroPython if one hasn't been filed already. We're trying to get our copy of the VM to match MP.
Is that really true? Why do you need to have a unique VID:PID? Why can't you instead have a standard VID:PID for a particular piece of silicon and identify the board through the Product ID?
Host OSes (like Windows) may cache the USB information based on the VID:PID combination. For Adafruit boards we usually do one PID per board x software combination to ensure that caching isn't triggered.
Don't know yet how to get into the UF2 boot mode where I could just drop a new
firmware.uf2in to uf2-drive and get an updated firmware, but this might be an ESP32-S3 specific problem. It always worked with rp2040 boards and generally everything offered by Adafruit .
On ESP you need to install UF2 separately. The RP2040 has it in ROM and adafruit boards usually have it factory installed.
The other T-Display boards with ESP32 and rp2040 also have two buttons, and we agreed on a...
Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1vjpP9hQ4GBs0NdMWnkvaJG_9DMT7LGeDYivrRXcfbl4/edit
Also tested on MatrxPortal S3 -- still works!
Question for the ConnectionManager.
I know you all have a ton to do, and for me when I have too many places to look it's hard to prioritize.
Would you taking ownership of the repo so it's in the Adafruit domain make it easier to see? I can easily fork and recreate the pull requests.
ConnectionManager is already under Adafruit right?
Nope
One minor change. Otherwise it looks good. Thanks!
boards_file.write("# SPDX-FileCopyrightText: 2024 Justin Myers\n")
I only add "for Adafruit" because I'm paid to do it.
Ok, that's where we should start since the other changes depend on it
Hmmmm. I get You don’t have the permission to create public repositories on adafruit, is there a different way?
You could also just cookie-cutter it since that's all there is on main and then I can fork from there...
You can add me as an owner and then I can move it
Sent!
got it
Yay!
I have been working on an iterable version of the MP/CP deque for my own application and in researching this, it looks like the lack of iteration has come up numerous times over the years. I believe this Issue in the MP repo covers it the best: https://github.com/micropython/micropython/issues/4776.
Long story short(er), the MP folks seem to have punted on a performant native C implementation of deque that is iterable and are suggesting folks that need/want deque iteration can use an i...
I have also encounter issue with ESP32S3 streaming with Arduino, somehow host does not issue any IN token to the bulk streaming endpoint. The example https://github.com/adafruit/Adafruit_TinyUSB_Arduino/tree/master/examples/Video/video_capture work with other ports (samd/nrf/rp2040).
However the stock video_capture example from tinyusb repo does work with esp32s3 https://github.com/hathach/tinyusb/tree/master/examples/device/video_capture . Hopefully it is probably some configuration/setup...
@adasauce that's basically what @joedevivo does in his extension, he has some scripts that parse the C code to combine it with the board.pyi stub. So it's certainly doable, just would be nice if it were provided from upstream.
I’ll be off and on today
@slender iron for whenever you are around: should I fork ConnectionManager and redo the PR (and close the other one)?
This functionality is in #8882
@candid sun since you mentioned interest in my TimeHelper class, I threw together a quick GIST of my class I'm using. Would love any thoughts if you take time to look.
oh cool! yeah i'd love to take a look at it
It looks to me like the original range checks were just wrong, and you fixed that, because the subscripts are zero-based anyway, so, say, 0 to 3 is pixels 0, 1, 2. But I have not used this code as all, so just want to confirm.
I'm not able to reproduce this:
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; ESP32-S3-DevKitC-1-N8R8 with ESP32S3
>>> import board, busio
>>> serial = busio.UART(board.IO15, board.IO18, baudrate=115200)
>>> serial.write(b'1234567890')
10
It's actually an S3 N16R8 - but I have the exact same issue with the build for the YD-ESP32-S3 N16R8. This is what took me down the path that it might be a bug in busio common to all ESP32-S3 build variants.
@rowsail what is the exact board you are using?
Yes, it looks like these are supposed to be inclusive lower-bound, exclusive upper bound "like python slices":
//| :param int x1: The left corner of the area to blit into (inclusive)
//| :param int y1: The top corner of the area to blit into (inclusive)
//| :param int x2: The right of the area to blit into (exclusive)
//| :param int y2: The bottom corner of the area to blit into (exclusive)
which even more makes the [0:0] blit make sense, it's an empty ...
I have an ESP32-S3-WROOM-1 N16R8 mounted on a PCB with a direct connection to USB, and IO15 and IO18 connected to an RS485 transceiver (along with a couple of GPIO to control DE and RE).
(Please ignore the value field for the ESP32-S3, a N16R8 was placed.)
Along with an additional 100uF on the 3v3 rail close to the ESP32 power in.
Just for completeness, using GPIO15 does seem to operate fine too:
<details>
<summary>code</summary>
import time, board, busio
serial1 = busio.UART(board.IO15, board.IO18, baudrate=921600)
serial2 = busio.UART(board.IO16, board.IO17, baudrate=921600)
while True:
serial1.write(b'1234567890')
print(f'serial 2 read: {serial2.read(10)}')
serial2.write(b'1234567890')
print(f'serial 1 read: {serial1.read(10)}')
time.sleep(1)
</details>
<details>
...
nope, it looks like it moved just fine. I'll look now
you can fork for further changes
Then I am stumped! Thank you for your help on this. Just to confirm, you are using an N16R8 device?
so fork and make changes to the branch that has an open PR?
It will also only take 30 seconds to re-open it
I can give you access if you can't push to the existing branch. I just replied on the PR
no, I only have N8R8 and N32R8... I could try the N32R8 flashed with N8R8, although that's a Wroom-2 and could be different in other ways
Looks like I can. Responded back on comments
@tannewt, if I am successful in creating an iterable C implementation of deque (based on the existing MP deque code), I was originally planning on offering it for incorporation into CP. In light of your statement above that you are trying to get the CP copy of the VM to match MP, would your preference be for me to try getting it added to MP instead?
Please make a PR to MP with it first. If they don't respond quickly, then we can do it to CP directly. We can also merge it into CP after MP...
A user on the forum reports bytes being swapped in UART read on ESP32-S3. https://forums.adafruit.com/viewtopic.php?t=208042
Same behavior (REPL and code, as above) on N32R8 flashed with N32R8 and with N8R8.
OK - Thank you again. I'm going to close out this issue - there must be something else at play. I can't believe there is something wrong with the N16 versions of the chip, surely? Is there another way I can use a UART without busio?
@hathach thank you for digging deep on this!
I guess I would check whether maybe IO15 is being pulled out of 0-3.3V range. If you just measure voltage there, what do you see? If you reverse TX and RX, does it crash? If you cut the IO15 connection to the transceiver, does it work?
You can try bitbangio.UART. But the fact that IO16 works but IO15 doesn't is really weird.
Do you have anything in a boot.py?
I will check all those things. This is a fresh install of CP, so there shouldn't be anything untoward in boot.py - but I'll still check. I'll also load some earlier versions of Circuit Python to see if behavior is the same or not. Failing that, I'll look for a real Devkit with the S3 N16R8 on it and try that.
CircuitPython version
master
Code/REPL
import wifi
wifi.radio.connect("wpa2wifiname")
Behavior
Traceback (most recent call last):
File "", line 1, in
ConnectionError: Unknown failure 15
Description
Network is WPA2, code is trying to connect to it as if it's an open network.
Additional information
This is just a visual issue. A value must just be mapped to that error, saying that authmode is wrong.
Tested:
Adafruit CircuitPython 8.2.8 on 2023-11-16; Adafruit Feather RP2040 with rp2040
with
serial = busio.UART(board.TX, board.RX, baudrate=921600)
connected to:
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; ESP32-S3-DevKitC-1-N8R8 with ESP32S3
with
serial = busio.UART(board.IO15, board.IO18, baudrate=921600)
Each transmitting then receiving. All bytes arrive in order on both sides.
@lone axle so excited to see the stubs in there! Can't wait for the next beta release
Does not crash on an N8R2 board.
>>> import board, busio
>>> serial = busio.UART(board.IO15, board.IO18, baudrate=115200)
>>> serial.write(b'1234567890')
10
I think this will be OK.
I'll note that after I filed #8612, I made some of these changes on a few boards, and was unable to quantify any speedup whatsoever with short and long (e.g. say 30 lines of code) loops.
@tannewt This now has merge conflicts.
Has a decision been made about the button pin names?
Switching the ESP32-S3 to Adafruit CircuitPython 8.2.9 on 2023-12-06; ESP32-S3-DevKitC-1-N8R8 with ESP32S3 gives the same result. All bytes arrive in order on both sides.
@candid sun I was looking for the link in my comment to you to check something and realized I forgot to add it. Feel dumb...
Here it is:
https://gist.github.com/justmobilize/0a61e290fbb946815d172f58bb880b7c
Everything works as it should using a different board (completely different design), but still using a S3 N16R8.
Works OK:
Adafruit CircuitPython 8.2.9 on 2023-12-06; VCC-GND YD-ESP32-S3 (N16R8) with ESP32S3
Works OK:
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; VCC-GND YD-ESP32-S3 (N16R8) with ESP32S3
Removing the RS485 transceiver from the original board - so there is nothing externally connected to IO15, it still does not work - the only thing I can think of is that ther...
Confirmed - ESP32-S3 on board was damaged.
@tannewt This now has merge conflicts.
Has a decision been made about the button pin names?
I intend to do it. Just haven't gotten to it. Will do tomorrow hopefully.
hopefully a quick question -
I clicked on https://circuitpython.org/board/feather_m7_1011/
and it has a picture of some Feather boards, but the product link goes to a different shaped board
maybe there is a new feather M7 product in the works - but it is confusing to have a link go to another product
Maybe the product number was swapped for the metro. I think the feather was designed by a contractor first. It is on the TODO list but not soon.
Monday, January 22, 2024. 1h38 PM GMT
Board: Adafruit Feather ESP32-S2 TFT Flashed with: Adafruit CircuitPython 9.0.0-alpha.6-29-g5f318c37bb on 2024-01-19; Adafruit Feather ESP32-S2 TFT with ESP32S2
IDE: Mu 1.2.0
The REPL output below shows that the board, connected to the in house WiFi, receives the UPD multicast data packets that X-Plane 12 was set for to transmit.
a) REPL output of manual test to see which attributes socketpool.SocketPool has now (with the lat...
EDIT: Already merged
May I ask any of the CircuitPython developers to take a look at latest adafruit_httpserver PR, current release has a serious flaw which prevents usage.
The faster the fix is merged the fewer people will download the non-working version.
https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer/pull/80
Hi @zenz , thank you for your request. I published/renewed my repo on Github. Here is the link: repo . Let me know if you need more assistance. Don't forget to fill in the blanks in file ´settings.toml.
Thank you @PaulskPt , But the repo doesn't exist?
I had an issue with the repo. I deleted it and created a new one. I pasted the new link in my first answer to you above. Try again please.
I had an issue with the repo. I deleted it and created a new one. I pasted the new link in my first answer to you above. I tested the link. It works. Try again please.
Still no luck. perhaps you'd make it private? I can't see it with 404 error.
I have never used WHEN_EMPTY, but for me on m5stack_timer_camera_x everything works fine.
I will try that parameter when I can.
I am so sorry, yes the repo was labled private. I don't understand it because I use Github for Desktop (MS Windows 11) PC, created the repo and clicked to publicize it.
Try again please
Enviado do Outlookhttp://aka.ms/weboutlook
De: Zenz @.>
Enviado: 7 de fevereiro de 2024 13:24
Para: adafruit/circuitpython @.>
Cc: Paulus H.J. Schulinck @.>; Mention @.>
Assunto: Re: [adafruit/circuitpython] CPY core module ...
I am so sorry, yes the repo was labled private. I don't understand it because I use Github for Desktop (MS Windows 11) PC, created the repo and clicked to publicize it. Try again please
Thank you, I can see it now. but from your code, I think you actually use unicast, not multicast?
I'm trying this out:
<details>
<summary>code.py</summary>
import os
import asyncio
import traceback
import wifi
import socketpool
import time
import traceback
# choose your own multicast group adventure
GROUPS = (("239.255.255.250", 1900), ("224.0.0.251", 5353), ("239.255.1.1", 138))
MAXBUF = 256
TIMEOUT = 0 # non-blocking
async def udpserver(group):
with pool.socket(pool.AF_INET, pool.SOCK_DGRAM, pool.IP_MULTICAST_TTL) as s:
s.bind((group[0], group...
Years ago when I started the project, it used MULTICAST_GROUP and MULTICAST PORT. Then my SBC (Raspberry Pi or equivalent) and later microcontrollers, wered connected to the desktop PC running X-Plane (10 it was) via USB-cable and a USB-to-Serial converter. Now, XPlane-12 offers this transmission to an IP-address. I use this now because the ESP32-S2 TFT can now run the application using WiFi and only be powered from a battery.
no prob, thanks for the link! i'll try to try this out later today
Thanks for your efforts.
I tested the current build after the commit and can confirm that the test code above works.
Unfortunately, my full code with display and all still crashes on the S2, and works fine on the S3 (alpha5). When running the first time it gets as far as the MQTT connection and fails to connect. After a soft reset it crashes in the same place as before, during the first get request (espidf.MemoryError).
Thanks for testing @anecdata! Would you mind sharing your full code? I'd like to use it myself :-)
Sure,...
<details>
<summary>ESP32-S3</summary>
import time, board, busio
serial = busio.UART(board.IO15, board.IO18, baudrate=9600)
while True:
print(f'serial wrote: {serial.write(b'1234567890')} bytes')
time.sleep(1)
print(f'serial read: {serial.read(10)}')
time.sleep(1)
</details>
<details>
<summary>RP2040</summary>
import time, board, busio
serial = busio.UART(board.TX, board.RX, baudrate=9600)
while True:
print(f'serial w...
Could someone elaborate on what the problem might be ? Did I perhaps solder the wires incorectly ?
I replied in the thread: https://forums.adafruit.com/viewtopic.php?t=208042 that perhaps it is not out of order, but out of sync. Two bytes read in incorrect order will appear to be swapped bytes. We can continue discussing in the forum thread. It might be a US100 driver problem.
Would it be reasonable to let fourwire.Fourwire allow for optional cs_pin?
Many times when using little TFT displays, I don't need or want to run a CS line. I'm devoting the SPI to the display, I tie the CS line to ground at the display, yet I need to use a cs_pin (I'll sometimes just stick it into an onboard LED if I'm not using that)
Rediagnosis of #8887:
When a busio.UART() device is first created on an ESP32-S3, a stray byte of some number of consecutive 1's may be read put into the input buffer. I saw this on both 8.2.9 and 9.0.0-beta.0, so it's not ESP-IDF version-dependent.
Adafruit CircuitPython 9.0.0-beta.0 on 2024-01-27; Adafruit QT Py ESP32-S3 no psram with ESP32S3
>>> import board
>>> board.UART().read()
b'\xc0'
The byte read may be b\x80 (seen at 9600 baud), or c0 or e0.
I see th...
Yup! I think so
@tulip sleet I'm digging into why test-stubs.sh is only failing once when the message says it should fail twice. It looks like the two string type names in WriteableBuffer are preventing the test from erroring when passing in a bytes object
I see, but not sure why it should not just ignore those, because neither of them is bytes
I don't really know anything about mypy
so if you comment them out, it works?
I agree. I don't know why it breaks. I just removed them and they work
there aren't any warnings about them
but then that will break some library typechecking maybe
circuitpython_typing/http.py:16: error: Skipping analyzing "adafruit_requests": module is installed, but missing library stubs or py.typed marker [import-untyped]
circuitpython_typing/device_drivers.py:12: error: Skipping analyzing "adafruit_bus_device.i2c_device": module is installed, but missing library stubs or py.typed marker [import-untyped]
circuitpython_typing/device_drivers.py:12: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
circuitpython_typing/__init__.py:39: error: Name "rgbmatrix" is not defined [name-defined]
circuitpython_typing/__init__.py:40: error: Name "ulab" is not defined [name-defined]
circuitpython_typing/__init__.py:48: error: Name "rgbmatrix" is not defined [name-defined]
circuitpython_typing/__init__.py:49: error: Name "ulab" is not defined [name-defined]
circuitpython_typing/__init__.py:131: error: Name "audiocore" is not defined [name-defined]
circuitpython_typing/__init__.py:132: error: Name "audiocore" is not defined [name-defined]
circuitpython_typing/__init__.py:133: error: Name "audiomixer" is not defined [name-defined]
circuitpython_typing/__init__.py:134: error: Name "audiomp3" is not defined [name-defined]
circuitpython_typing/__init__.py:135: error: Name "synthio" is not defined [name-defined]
circuitpython_typing/__init__.py:141: error: Name "rgbmatrix" is not defined [name-defined]
circuitpython_typing/__init__.py:144: error: Name "alarm" is not defined [name-defined]
circuitpython_typing/socket.py:129: error: Name "_FakeSSLContext" is not defined [name-defined]
Found 14 errors in 4 files (checked 8 source files)```
maybe @short tendon understands python typing
mypy -c 'import busio; b: busio.I2C; b.readfrom_into(0x30, b"")'
Is supposed to fail because readfrom_into() needs to write into the buffer but is given a byte string. However, it doesn't. WriteableBuffer includes two string types that break the whole thing. If you remove them, then the test will fail.
Running mypy on the typing module gives a clue in how it fails:
mypy circuitpython_typing
circuitpython_typing/http.py:16: error: Skipping analyzing "adafruit_requests": module...
Ok @dhalbert and @kreier please take another look. It should be good to go.
Rediagnosed in #8890.
Did this come from the stub work, or is it unrelated?
Is this from the new stub work, or a big that's been around for a while?
it has been around a while I think
Okay. I'm happy to take a peek tomorrow
thank you!
gah. don't tempt me
I also tried switching to GrabMode=LATEST but it fails with the same IDFError....
There was a small mistake in the example code for sdcardio.SDCard (this section in the docs). It initialized SPI with board.SPI(), instead of busio.SPI().
@tannewt,
I was able to get this to pass by:
- Adding the following imports to
circuitpython_typing/__init__.py:
import alarm
import audiocore
import audiomixer
import audiomp3
import rgbmatrix
import synthio
import ulab
from alarm.pin import PinAlarm
from alarm.time import TimeAlarm
from ulab.numpy import ndarray
- Adding the following imports to
circuitpython_typing/socket.py:
from adafruit_requests import _FakeSSLContext
or
cla...
@slender iron I have some "which modules on/off" for ESP32-S3 to discuss when you have time. User in forums noticed gifio was not on for ESP32-S3 TFT boards. There are some odd linkages between modules.
is off for space reasons
Ok I’ll ping once I’m at my desk. Have a dermatology appointment this morning
Generally 4mb flash boards have less
yup, i am seeing some better tradeffs, though, maybe
Doesn't busio.SPI() require the clock, mosi and miso arguments? So this should be something like:
sd = sdcardio.SDCARD(busio.SPI(board.SCK,board.MOSI,board.MISO), board.SD_CS)
I tested this version of the code using a board that had board.SPI() defined and it gave a "ValueError: IO40 in use" (IO40 is the clock pin).
Perhaps both the busio and board lines should included in the example code with one of them commented out:
sd = sdcardio.SDCard(board.SPI(), board.SD_CS)
# ...
ugh... Made a branch for adafruit-circuitpython-typing, but then the circular dependencies block the install. Will keep looking
Bluetooth LE question for Pico W: When setting an address of type BD_ADDR_TYPE_LE_RANDOM I am allowing the caller to set a random address or have a random address generated automatically. The cases are differentiated by the low-order 2 bits of the high-order byte of the caller provided address. If the bits indicate the address is locally administered/individual (L=1, G=0) the user provided address is used; otherwise, a random address that is locally administered/individual is generated and used.
This "feels" right, although I cannot locate a passage in the BT specs that says it is. Any opinions?
i thought the differentiation would be between a user-supplied address and a generated random address. Does the nRF _bleio handle this?
a user supplied address is not "random", I would think
if (local_address[0] & 0x02) {
// Set adapter to the caller-provided random address.
gap_random_address_set_mode(GAP_RANDOM_ADDRESS_TYPE_STATIC);
gap_random_address_set(local_address);
} else {
// Set adapter to a randomly generated address.
btstack_crypto_random_t request;
volatile bool crypto_done = false;
btstack_crypto_random_generate(&request, local_address, NUM_BLEIO_ADDRESS_BYTES, &random_addr_ready, (void *)&crypto_done);
// Synchronize with random address generation completion.
while (!crypto_done) {
RUN_BACKGROUND_TASKS;
}
// Set the L bit and clear the G bit (locally administered, individual address)
local_address[0] = (local_address[0] | 0x02) & 0xFE;
gap_random_address_set_mode(GAP_RANDOM_ADDRESS_TYPE_STATIC);
gap_random_address_set(local_address);
}
that's your code or current nrf code?
Right, arbitrary. It looks like the SD does the work for nRF, common_hal_bleio_adapter_set_address() , all CP does is pass the user provided type and address to sd_ble_gap_addr_set().
What happens from there is opaque and not documented.
yes, just looking at that
but I don't remember anything about fiddling with those bits to get it to do something else
Are you adding a capability that the nRF impl doesn't have?
Yes. I'm concerned about presenting a valid address given its type.
Not really. It's crypto unit can generate random bytes.
In this case I ask it for six bytes.
The Nordic doc is interesting. Are there rules coming from the BT spec or are they Nordic's own?
I would say that you don't need to do this. It's up to the user. In the nRF world, you can use sd_ble_gap_privacy_set(), which will use a dynamic random address that is refreshed at a specified internval
is there something like that in the CYW API?
No. The Nordic SD seems to be half a driver on top of the hardware.
ok, looked more ... we have an anonymous flag in start_advertising(), that will turn on privacy to use a changing really random address. If CYW doesn't have something like sd_ble_gap_privacy_set(), then that needs to be coded explicitly. But I'd check whether there's a CYW advertising parameter that does that, maybe
don't make Adapter.set_address() do something tricky. If you want to reject an address with the wrong bits set, that's fine. CYW may do that. I don't know whether nRF SD checks the validity of those bits .... I'll look
BTW, your CP code for nRF code looks really good.
sd_ble_gap_set_addr() checks the top two bits and will complain with BLE_ERROR_GAP_INVALID_BLE_ADDR
thanks, it was inspired by our earlier Arduino BLE code, which was done by some real BLE experts. It took me a long time to wrap my head around BLE, which I feel is not great at clean layering of abstractions
Good, I'll enforce nRF rules for the high-order address byte.
the CYW equivalent of set-address may do that check too?
No check in BTstack or cyw43-driver that I can find. Caveat emptor code!
So, to summarize: Enforce nRF rules for high-order address byte in common_hal_bleio_adapter_set_address. Also, prohibit setting private address here, private addresses may only be set in start_advertising.
uint32_t sd_ble_gap_addr_set ( ble_gap_addr_t const * p_addr )
Set the local Bluetooth identity address.The local Bluetooth identity address is the address that identifies this device to other peers.
The address type must be either @ref BLE_GAP_ADDR_TYPE_PUBLIC or @ref BLE_GAP_ADDR_TYPE_RANDOM_STATIC.
Still, I remain mystified by the high-order address byte.
see (old) post here, first reply: https://devzone.nordicsemi.com/f/nordic-q-a/10758/why-is-hardware-address-of-bluetooth-device-different-than-device-address
it points to somewhere in the BT spec (probably obsolete chapter number, etc.)
two test branches for you:
https://github.com/adafruit/circuitpython/compare/main...justmobilize:circuitpython:typing-fixes?expand=1
https://github.com/adafruit/Adafruit_CircuitPython_Typing/compare/main...justmobilize:Adafruit_CircuitPython_Typing:typing-fixes?expand=1
<img width="1187" alt="image" src="https://github.com/adafruit/circuitpython/assets/1547881/37c42dd3-1ba5-4f40-8ede-eb2a33716cfa">
I know the try/except to get around the circular imports is strange, but not sure ano...
Yes! That is the reference I've been seeking. Huzzah!
@slender iron 2 things:
- have some branches up and comments for the typing test bug
- also have a question on the ConnectionManager PR about some code that really isn't right (pulled from requests) and trying to see what should be done
(I'd been extrapolating from IEEE 802-2001, which is how I wound up where I was.)
i did see that mentioned in a less useful search result
As always, our chat has been informative and helpful. Thank you, Dan!
You're welcome, and thanks so much for working on this!
It seems we have a circular dependency between circuitpython_typing and circuitpython stubs.
It seems like this would come up in the CPython world too. I wonder how they get around it.
is there anyway to skip the 1 second safe mode blinks?
On start up, the LED will blink YELLOW multiple times for 1 second.
for faster boot
yes, there is a compile time option
I'm at my desk now
I'm here now
It'll be skipped when booting back up from deep sleep
in a call - will ping
thanks. i think they're use case is more simple. if you've got suggestions:
https://forums.adafruit.com/viewtopic.php?p=1002948
Fixed the try/except by using if TYPE_CHECKING. Which looking is what seems to be common
Seems like they just want to know why. The UF2 bootloader also has a delay for the same reason
that's how the double tap works
yep, but PWMing in CP is much easier. so if there had been any way to reduce that delay, could've been useful for them.
"posix" port advances. All "basics" tests now pass locally. ```jepler@bert:~/src/circuitpython/ports/posix$ make test TEST_ARGS="-d basics"
[...]
523 tests performed (16408 individual testcases)
523 tests passed
17 tests skipped: array_micropython builtin_next_arg2 builtin_range_binop class_delattr_setattr class_inplace_op2 class_notimpl fun_globals fun_name generator_name io_buffered_writer io_iobase memoryview_itemsize memoryview_slice_size namedtuple_asdict nanbox_smallint sys_getsizeof sys_tracebacklimit
overall 72 tests failed, 181 tests skipped.
Something has definitely changed WRT CircuitPython and integrated, on-board, ePaper displays - e.g. board.DISPLAY.
I have run several tests and I no longer get runtime error output on the display.
I assume this new behavior is intentional (and if so, thanks 😉)
CircuitPython version
latest
Code/REPL
n/a
Behavior
search for tft, notice the 4 feathers amongst 5 results...
search for feather tft, notice only two reverse tft feathers.
I wanted the feather s3 tft at the time, but I'm sure the search issues relate to more boards.
Description
No response
Additional information
No response
@slender iron ok, free now, if you are
just a couple minutes and I'll be ready
Is there a place to put a demo that is specific to a particular board, but not a particular library?
@idle owl good question. I don't think we have anywhere. There's the git repo for learn, of course, when it's related to a learn guide but I assume that's not at all your goal.
It's easy to share random files as github gists or create a repo under your own git user. I kinda like gists because of how they can be embedded on a blog entry with just a couple lines of javascript.
example of a blog post with an embedded github gist (python but not circuitpython): https://emergent.unpythonic.net/01705158260
This laptop's keyboard has an indicator on the F4 key, which also serves
as the mic mute toggle key.
Frustratingly, in Debian 12 (bookworm) with pipewire audio, the LED doesn't
actually follow th…
embedding code: <script src="https://gist.github.com/jepler/ff55a475e9c90c8b1b7f00707799565c.js"></script>
Valid. Thanks. There's an unusual thing about the buttons for this board in CircuitPython, so having a demo available to folks seemed like a good idea. I can host it though.
The reason that is happening is because if you type feather tft, it will search for the exact string in board names, manufacturers, titles, and keywords. The keywords section was added as a way to combat this problem, but it's not thorough. The only reason the reverse one was showing up was because it had some alternate spellings in the keywords sections.
There's a couple of possible fixes:
- Somebody would need to go through about 500 board files and add variations they think might wo...
@lone axle willing to test https://github.com/adafruit/circuitpython/pull/8894?
@short tendon not asking you to change that PR -- you're clearly making a minimum change relative to what was previously there -- but just for your awareness: https://docs.python.org/3/library/importlib.resources.html#importlib.resources.files might be a less finicky way to access .pyi files that are bundled as part of a package. It's in 3.9 and newer (which is in debian oldstable stable and ubuntu LTS 22.04, so even the chronically slow updaters are well covered)
In the unlikely event support for python 3.8 is desired (EOL not until this october) there's https://docs.python.org/3/library/importlib.resources.html#importlib.resources.read_binary but this has been deprecated in 3.11.
For the circuitpython_setboard one (sorry have a couple in flight)?
yeah that makes sense. What version would you support? Since this is for the common circuit python developer, I could see them having a pretty old verion of Python installed...
A thought to file away: The Pico W's CYW43439 has a cryptographic unit that may be useful for other CP purposes like TLS handshake.
This turns the search function into more of a 'fuzzy search': The search is expected to be a series of space-separated terms, but the terms can appear in any order, can be just part of a word (e.g., "uefr" would match "bluefruit") and with other terms between them.
So for instance after this change both "tft feather" or "feather tft" will show the Feather ESP32-S3 TFT PSRAM (as well as 3 other feather boards)
Closes #1321
@onyx hinge I like that much better:
from importlib import resources
import os
import sys
import shutil
def set_board():
if len(sys.argv) != 2:
print(f"Incorrect args. Please call with: 'circuitpython_setboard chosen_board'")
return
chosen_board = sys.argv[1]
print(f"setting board: {chosen_board}")
board_stubs_file = resources.files('board-stubs').joinpath("__init__.pyi")
board_definitions_path = resources.files('board_definitions').joinpath(chosen_board)
board_definitions_file = board_definitions_path.joinpath("__init__.pyi")
if not board_definitions_file.is_file():
print(f"Board: '{chosen_board}' was not found")
return
shutil.copyfile(board_definitions_file, board_stubs_file)
Would you recommend this method or supporting 3.8?
nah, I doubt supporting 3.8 for new optional features is important. I only mentioned the version 3.9 and newer limitation because i saw it in the docs.
Aha, that explains it! Thanks @makermelissa (and @jepler for smashing out a fix already)
sure, though with the caveat that I haven't even touched this new functionality.
It's working for me. And I know FoamyGuy knows how to test
The other board does not have BUTTON_L and BUTTON_R, just BUTTON0 and BUTTON1.
{ MP_ROM_QSTR(MP_QSTR_BUTTON0), MP_ROM_PTR(&pin_GPIO6) },
@kreier would it be OK to drop the "left" and "right" names? The inconsistency of the underscore or not is also confusing.
Not sure about comment change in CIRCUITPY_BOARD_SPI block of code.
I don't think you want this change, I assume you meant to update the comment to busio not boardio, however this block of code seems to be setting up the board.SPI for boards that do have it defined. If that's the case, I think the original board.SPI() in the comment was correct.
I'd prefer to keep this example simpler by using board.SPI() or busio.SPI() but not both. The simplest change would be to remove the busio import and only rely on board.SPI().
Sorry @RetiredWizard, I was a bit too hasty on this PR. Should've proofread it better.
I'd prefer to keep this example simpler by using board.SPI() or busio.SPI() but not both. The simplest change would be to remove the
busioimport and only rely onboard.SPI().
True, it's indeed a bit messy to have both. I'm okay with reverting back to the original documentation, but how will we notify users that they could need busio.SPI() instead? The reason I put up this PR in the first place is because one of my students ran the example code from the docs and got an error the `b...
Is it perhaps possible to change the __init__ argument and spi param to use Union[busio.SPI, board.SPI] instead of simply board.SPI?
@SiboVG, no need to apologize :grin:
If we want to keep the example as simple as possible, I agree that it's more likely someone would be wanting an SD mount example for a board with a built in SD card and the board.SPI is probably the best choice.
I think you could take the view that embedded example code like this should be considered a starting point or hint at what's needed and hopefully gives you enough information to figure out (via google, discord, forums, etc) a solution for you...
First of all, there is no boardio.SPI, it's busio.SPI.
Second, the type of board.SPI is function that takes no arguments, and returns an instance of busio.SPI. We certainly don't want that as our spi type.
So the correct type here is busio.SPI, this the class of the object we want to pass here.
Alright, I just missed the mark on this PR; I think it's best to close it. Thank you all for the feedback and patience!
@tannewt, 2 questions:
-
Where would you like
_FakeSSLContextimported from incircuitpython_typing/socket.py? We can either:- Do
adafruit_requestsnow and if/whenadafruit_connection_manageris merged, update it (before we remove it from requests) - Wait for
adafruit_connection_manager
- Do
-
Looking at the change for synthio, do you know what should be in the...
I filed #8895 for the synthio problems (I don't get why we weren't seeing this at CP build time!) but if you want to cover it in some other PR that's fine. The waveform argument should be Optional and the correct default is None.
Awesome! Once this is merged, I'll get it in my temp branches to continue to work through the other issues.
@slender iron do you have enough info to know of the 4 exceptions currently tracked in the get_socket in requests, which should be retryable? I assume the memory error is, after we release any no longer used sockets. But what of the other 3?
I don't know. I'd go based on what minimqtt does
K. Will dig in
Thanks! Seems like the retry code needs a new set of eyes anyway
Do you know who is most knowledgeable on minimqtt? Would love to chat with them a bit to find common ground
I suspect it is brent
Ah, that would make sense, since he pinged me on my last change in requests...
I'd suggest checking the minimqtt commit history
I usually look at the earliest commits
there is a lot of automated tooling and updating that happens as well
Is brentru on GitHub the same Brent you were thinking?
Alright, I just missed the mark on this PR; I think it's best to close it. Thank you all for the feedback and patience!
Thanks for the PR! It helps us to see where confusion comes from.
@tannewt, 2 questions:
1. Where would you like `_FakeSSLContext` imported from in `circuitpython_typing/socket.py`? We can either: * Do `adafruit_requests` now and if/when `adafruit_connection_manager` is merged, update it (before we remove it from requests) * Wait for `adafruit_connection_manager` 2. Looking at the change for [synthio](https://github.com/adafruit/circuitpython/compare/main...justmobilize:circuitpython:typing-fixes?expand...
how functional is the usb_host for CircuitPython 9.0.0-beta.0 on the Feather RP2040 with USB Type A Host? and can the usb host be able to send serial commands to a marlen 3d printer usb controll port?
yup
Yes but you'll need to do the low level endpoint writing
I don't think we have a host cdc library yet
what is cdc
because there is usb_cdc for both CircuitPython 8.2.9 and CircuitPython 9.0.0-beta.0 built-in to the circuitPython uf2 installer
And is that @ brent here? Still learning who's who....
I'm trying this out:
import os import asyncio import traceback import wifi import socketpool import time import traceback # choose your own multicast group adventure GROUPS = (("239.255.255.250", 1900), ("224.0.0.251", 5353), ("239.255.1.1", 138)) MAXBUF = 256 TIMEOUT = 0 # non-blocking async def udpserver(group): with pool.socket(pool.AF_INET, pool.SOCK_DGRAM, pool.IP_MULTICAST_TTL) as s: s.bind((gro...
That is CDC device support, not host support
CDC is USB serial (like COM ports, /dev/ttyACM0, etc)
can cdc work for usb controlled 3D printer aka the Anycubic Kobra Go?
if it uses USB serial, yes, but, again, we don't have USB CDC host code yet
than what is this?
This looks good to me.
I tested successfully by building this locally and installing the built stubs with pip.
Thanks for adding the check for user passing wrong number of arguments.
That is for acting as a USB device, not a USB host. If your printer is a USB device, then those don't help to talk to it. e.g. usb_cdc is for plugging a CircuitPython device into a host computer (Windows, Mac, Linux, etc.) and talking to the host over its serial ports.
dose cdc sand for "com device connetion"?
cdc is how serial is done over usb. (it's an old modem protocol.) usb_cdc is for device mode. not host
yup @prime flower
Thanks @tannewt for the good work! And standardizing the button names for all T-Display boards!
I wouldn't mind but had the same thought as Scott - since its already out there it might break the code of some users. We can have it clean for the T-PicoC3 (same just with Wifi added) and have only BUTTON0 and BUTTON1. I see already more direct offers for the T-PicoC3 than the T-Display rp2040.
Hello @prime flower, I had a quick question on MiniMQTT I was hoping you could answer.
In ._get_connect_socket during sock.connect if it raises a OSError, it sets backoff = True and then delays the next try.
Do you know why? I'm working on the new ConnectionManager and trying to make a unified method for getting sockets and between Requests and MiniMQTT this is the outlier...
@slender iron but dose cdc sand for "com device connection"?
This might've been a change made by an external contributor, give me a moment to pull up the history on that file
Seems it was added by this PR, https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/commit/7cab7d87b7821094ed15fd91c6d8058ff0741263. I understand why. It was added as a way to implement exponential backoffs for reconnections. These are used in order to avoid throttling by a MQTT server for too many retries during the auth process.
Do you feel it's needed in that particular case? When the socket can't even physically connect?
And another question, what reason does socket.connect((host, port)) raise an OSError?
Don't think so, it should required when the broker sends back an unauthorized message to the client (I think this is a CONACK msg in MQTT spec. parlance)
Could you link me to the GitHub page with the line number, like https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/blob/main/adafruit_minimqtt/adafruit_minimqtt.py#L14
Yup it's here: https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/blob/a05b19f522fae5232f7d92edcd88160c4de4ed28/adafruit_minimqtt/adafruit_minimqtt.py#L365. That's the only one in the get/connect socket flow that isn't a TemporaryError that would then be retried right away
I am not sure why it would raise an OSError
Do you think it's safe to not have that one cause the delay? Allowing ConnectionManager to just have it's own retry logic to connect and either raise an exception on return a socket?
@tannewt if you look at this PR for Adafruit_CircuitPython_Typing, if I pull out the changes to circuitpython_typing/socket.py and requirements.txt would you be good with that? It will get almost everything done.
@tannewt OMG. Realizing that circuitpython_typing/socket.py exists, means that we don't need that defined in ConnectionManager code at all. And that kills a whole kb of the mpy. Technically we could also remove it from Requests now...
If we actually add a _FakeSSLContext definition in circuitpython_typing/socket.py, we can fix this bug now and remove all that typing code from ConnectionManager
Sorry I wasn't being clear, the iProduct field in the device descriptor defines the product string descriptor. You could use a single VID/PID descriptor for a particular device, then use the product string descriptor to identify the specific board.
This is the way the ARM CMSIS-DAP works, it just needs "CMSIS-DAP" in the product string descriptor and OpenOCD will automatically detect the device.
@justmobilize Oh, please, certainly, do that!
Am I correct that here https://github.com/adafruit/Adafruit_CircuitPython_Typing/blob/0dc12dfb696a5f8c9174ccda0972404338984091/circuitpython_typing/io.py#L43 the , / shouldn't be there? My PR is failing because:
$ /c/tools/mpy-cross/mpy-cross-8.2.9.exe circuitpython_typing/io.py -o output.mpy
Traceback (most recent call last):
File "circuitpython_typing/io.py", line 43
SyntaxError: invalid syntax
That is a missing feature in micropython/circuitpython. It works ok in CPython. But circuitpython_typing does not need to be importable in circuitpython, right? I'm surprised we're trying to mpy-cross it, but I guess it is like any other library
Since it's been there forever, I assume originally it wasn't. What would you like me to do? No PR will work until that's changed...
And no, it's only for type checking your development work...
You could try it. I'd remove it first, and see what happens (expected behavior) before re-implementing with this new connection manager
I think this is a CI problem related to https://github.com/adafruit/Adafruit_CircuitPython_Typing/issues/34
Sounds good. I image a test might fail depending on how in-depth they went when adding them.
we need to suppress building the .mpy's at all
Is there something I can change in the workflow?
i'm looking
Is it possible to get adafruit_board_toolkit.circuitpython_serial.data_comports()[0].product (in this case, M4 express running CP 8 with data serial enabled) to return a custom string?
there is some customization of USB ID strings but I'm not sure if it's this one or not. What is it returning now?
None
And my ignorant attempt at setting it in boot.py didn't work.
I'm not wedded to product but would like to otherwise identical uCs connected and having a programmatic way of telling them apart.
Looks like "communications device class" https://en.wikipedia.org/wiki/USB_communications_device_class
there are other names that say "CircuitPython"
if you don't enable the data comport it will not be there.
look at .interface instead
Yes, and the adafruit_board_toolkit is getting me 90% of the way there. I have a modular robot project where each module is controlled by a uC. I would like a user-friendly way for the host to know what modules are connected.
It's been a while since I got excited for removing a KB of compiled code...
So here's the PR, I'll take it out of draft as soon as the mpy thing get's figured out
the fact that data_comports returns a non-empty tuple at all means it's a CircuitPython device, because it's looking for "CircuitPython CDC2 ..."
in the .interface name
Right, and if I have 2 M4 express uCs, both with data enabled, connected to host, I should get 2 entries in that tuple. Right now, the only way I can differentiate them is if I have a host-side database that ties something like .serial_number to the function of the device.
aha, ok I thought this was CPy vs non-CPy boards
https://docs.circuitpython.org/en/latest/shared-bindings/supervisor/index.html#supervisor.set_usb_identification Note that this is the whole USB device, not the COM port. There are ways to get the device identification, but adafruit_board_toolkit does not provide them. Take a look at https://github.com/Neradoc/discotool
Thanks for the refs.
makes me think I should add USB device info fetching to board toolkit
Definitely wasn't intending to make more work for you 🙂
@short tendon I'm still looking at the workflow stuff too 🙂
Thanks!
@short tendon it does not look like a simple fix for the mpy-cross problem. See https://github.com/adafruit/Adafruit_CircuitPython_Typing/issues/36 which I just opened. So how about removing the , / in that signature for now? Maybe comment it out with a TODO to put it back when the CI workflows can not do the mpy-cross build.
Can do. Am I good to reference the issue in the TODO?
oh sure!
Done. PR updated and passing
Original code from #7996 by @dearmash. My rebase skills are not up to the task of updating from the original PR, so I am creating a new one.
I think the line 15 reference just refers to the whole construtor, not setting that particular parameter.
I noticed that MicroPython has a zephyr port for zephyr compatible boards. Would that be a reasonable template to try circuitpython with zephyr?
Ya, though I think they are still changing it. What board are you wanting to run CP on?
Remove this, since sdcardio can be used instead.
Superseded by #8896. Thanks @dearmash!
I was thinking an nRF board
Something simple like an nRF52840
OK, great! If you can add the board to circuitpython-org, that would be great too.
Silicon Labs - Issues rebuilding the .bin file for the dev_kit_xg25_brd2601b. Followed the Adafruit guide and the SiLabs READ.md. Trying to build with Ubuntu Linux 22.04.2 (x86_64 emulation) on a Mac with the Parallels VM version 19.2.1. This is the entire build output from the ‘make BOARD=devkit_xg24_brd2601b’ cli command.
The guides have been followed exactly with a new clean VM.
The Adafruit guide has the 'make BOARD=circuitplayground_express' at the end of their documentation which ...
@silabs-ChatNguyen I don't know what the issue might be in the build above. We asked @MHVUT to post here so we could ping you. My own build environment is working, but a clean build in a new environment should too. Do you know what the issue might be?
Are there Silabs forums that might also be a place to ask this question, or is this the best route? Thanks.
were you prompted by my discussion with JLA in #general-tech ?
Yeah,I was curious what the path to use zephyr looked like.
Just a quick glance I understand that it’s going to be specific to zephyr supported boards, likely at this point being ones that fit the cross section of circuitpython and zephyr
See https://github.com/adafruit/circuitpython/issues/8135 if you have not already.
Seems like the main zephyr issues in waiting have closed. I’m not confident that indicates progress can go forward but perhaps it does 🤷♂️
I am now 👋
@lone axle ok plz log into adafruit account, get cart with anything you want ready, adn go to the memtno page
ill relase one of our sekret stash
okay I am logged in, cart ready and on momento product page
@lone axle GO GO GO
okay got one in cart, checking out
@lone axle ok i restashed 🙂
checkout finished. Thank you!
ok i tagged ya on github with the idea
I was originally thinking that this was something to blanket change. However, after looking at examples, I see that the behavior as-is is useful if you are trying to sample a PWM signal that varies pulse length. You can set maxlen=2 and read pulse 0 continuously to see how it is varying.
So, you are right that this should be a new kwarg (maybe called pause_on_overflow) that adds in the auto-pause.
I am testing this on a MEMENTO board, and getting a slightly different error: espidf.IDFError: Requested resource not found which may be from a rework of error messages. Oddly, when I use the adafruit_pycamera library, it works, but the set-up appears similar. The library does a power-cycle and reset of the camera, but adding that to the test code above does not fix the problem. Still testing.
@slender iron thank you for pinging me on that type issue with test-stubs.sh. That lead me down quite a handful of rabbit holes, but also helped me discover some other parts of the infra, which let me kill 933 bytes out of ConnectionManager AND remove all the types from the docs.
espidf.IDFError: Requested resource not found is incorrect configuration. I think it's the i2c check that raises that.
Prolly an incorrect pin or something.
For me:
espcamera.Camera(
data_pins=board.D,
pixel_clock_pin=board.PCLK,
vsync_pin=board.VSYNC,
href_pin=board.HREF,
i2c=board.SSCB_I2C(),
external_clock_pin=board.XCLK,
external_clock_frequency=20_000_000,
powerdown_pin=None,
reset_pin=board.RESET,
pixel_format=vr("px"),
...
Thank you for taking the torch as it were, I'm glad to have helped with a start.
Things that I got "stuck" on were:
- Trying to get the "nonstandard" eink busy pin to work (required polling a shift register IIRC).
- Trying to figure out PSRAM. Using this out of the box in CPY left almost no memory to do anything. Other libraries manually mapped the display to psram, and I wanted to take the time to come up with an "elegant" solution. perfect is always the enemy of good.
@jerryneedell If I power-cycle and reset the camera (I had a mistake in my testing script at first), first, then your example works on the MEMENTO:
import board
from digitalio import DigitalInOut
import time
import espcamera
cam_reset = DigitalInOut(board.CAMERA_RESET)
cam_pwdn = DigitalInOut(board.CAMERA_PWDN)
cam_reset.switch_to_output(False)
cam_pwdn.switch_to_output(True)
time.sleep(0.01)
cam_pwdn.switch_to_output(False)
time.sleep(0.01)
cam_reset.switch_to_output(Tru...
I’ll retry on the Eye tomorrow but I have not had any issues with CP9 on my MEMENTO
I do not have an Eye to try but I do have a camera breakout.
Not seeing any issues. I needed to update one test. I'll check a few things and open a PR to MiniMQTT with the changes so others can look
Thanks for jumping into the rabbit hole. 🙂
Quite welcome. In the end it was net positive for me.
I also feel I have a path forward on ConnetionManager for retries. Will be similar as I work through some PRs in other places first
Hello i just recently got a adafurit rp2040 for using it for my macros like opening up google and discord and ect.. but i am having trouble putting the code on there. There isnt good vids or guide to help do that i am using Mu to edit my code
While not specifically related to esp32spi I was having difficulty getting sdcardio to share a bus. Came across this issue via google search. @jepler code did help. Was able to share SCK, MOSI, MISO with sdcardio and a SPI TFT. Each peripheral has its own CS pin. So can at least confirm the issue isn't the fault of sdcardio.
import sdcardio
import storage
from adafruit_display_text import label
from circuitpython_st7796s import ST7796S
displayio.release_displays()
# 4.0" ST...
No change on the eye
Adafruit CircuitPython 9.0.0-beta.0-22-g58b1ce46f1 on 2024-02-09; ESP32-S3-EYE with ESP32S3
>>> import code_test
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "code_test.py", line 15, in <module>
espidf.IDFError: Operation or feature not supported
>>>
I do not have an Eye to try but I do have a camera breakout.
I also have some breakouts, Let me know what MCU and breakout you use if you can get it to work and I will try to reproduce.
hmmm -- I tried your code on the EYE
10.0.0.16 | REPL | 9.0.0-beta.0-22-g58b1ce46f1 reload.
Adafruit CircuitPython 9.0.0-beta.0-22-g58b1ce46f1 on 2024-02-09; ESP32-S3-EYE with ESP32S3
>>>
>>> import code_test
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "code_test.py", line 6, in <module>
AttributeError: 'module' object has no attribute 'CAMERA_RESET'
>>>
@danh or @slender iron Similar to cyw43-driver, I need an Adafruit fork of BTstack that I can use for patches awaiting incorporation upstream. The specific case I have with BTstack is a pair of missing function prototypes that prevent extended advertising from building.
@prime flower / all - finally tracked down the page on pin config in UF2 files, that I saw in some MakeCode article, called Binary Bootloader-embedded Config (CF2):
https://github.com/Microsoft/uf2/blob/master/cf2.md
Basically adjust pin numbering/peripherals if same mcu without adjusting main code, just patch the uf2 CF2 section.
Also online patcher / example config https://microsoft.github.io/uf2/patcher/
example keys for CF2 (from patcher site)
which repo do you need us to fork?
bluekitchen/btstack
CircuitPython version
Adafruit CircuitPython 9.0.0-beta.0-23-g8af780c7fa-dirty on 2024-02-10; Adafruit Feather ESP32-S3 TFT with ESP32S3
(built from main with `CIRCUITPY_JPEGIO = 1`)
Code/REPL
from jpegio import JpegDecoder
from displayio import Bitmap
decoder = JpegDecoder()
width, height = decoder.open("/sd/example.jpg")
bitmap = Bitmap(width, height)
decoder.decode(bitmap)
# .. do something with bitmap
Behavior
This code is in the d...
The licensing of btstack is a bit tricky. Raspberry Pi got a supplemental license for Pico W: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_btstack/LICENSE.RP. I It may be OK. But I think I will check with management about our forking of it before we do that. As I understand you are just getting around some compiler warnings or lack of protoype declarations? Could you add those by hand somewhere or turn off some warnings for certain source files?
The 3rd arg should be 65535. There is no pallette, the image is RGB565_SWAPPED
I'll see what I can do. Jamming the prototypes into my btstack_config.h will be the easiest. The affected module hci.c is several thousand lines of code, so I hesitate to disable warnings. The functions in question should be static, the prototypes are only needed since they're not. The licensing of BTstack has worried me, too. Perhaps we should think about finding an alternative protocol stack?
Also, I'll likely find more breakage in BTstack as I progress.
Just a brief update. I created a custom build of the adafruit_feather_esp32s3_4mbflash_2mbpsram to add esp camera. I used the same mpconfigboard.mk settings as the memento
USB_VID = 0x239A
USB_PID = 0x811C
USB_PRODUCT = "Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM"
USB_MANUFACTURER = "Adafruit"
IDF_TARGET = esp32s3
CIRCUITPY_ESP_FLASH_SIZE = 4MB
CIRCUITPY_ESP_FLASH_MODE = qio
CIRCUITPY_ESP_FLASH_FREQ = 80m
CIRCUITPY_ESP_PSRAM_SIZE = 2MB
CIRCUITPY_ESP_PSRAM_MODE = qio
...
hmmm -- I just realized that the above test was don with an OV5640, but the EYE uses an OV2640 -- I should try swapping breakouts to an OV2640...
Bingo!! The same code that works with the OV5640 now fails with an OV2640... the plot thickens ;-)
Uhh on Firebeetle 2 ESP32-S3 I have an OV2640.
>>> import board
>>> from AXP313A import *
>>> i2c = board.I2C()
>>> a = AXP313A(i2c)
>>> enable_camera(a, camera_voltages.OV2640)
True
>>> import espcamera
>>> b = espcamera.Camera(data_pins=board.CAM_DATA, pixel_clock_pin=board.CAM_PCLK, vsync_pin=board.CAM_VSYNC, href_pin=board.CAM_HREF, external_clock_pin=board.CAM_XCLK, external_clock_frequency=20_000_000,
... powerdown_pin=None, reset_pin=None, i2c=i2c, pixel_format=espc...
I tried the Testing self-signed certificates and load_verify_locations instructions on an ESP32 S2 mini clone (identified as an ESP32 S2 feather chip) running adafruit-circuitpython-adafruit_feather_esp32s2-sv-8.2.9.uf2 and it works.
To use it with your own host name, replace the host name with your own when you retrieve the certificate file:
openssl s_client -servername <your host name here> -connect <your host name here again>:443 < /dev/null | openssl x509 > self-signed.pem
Just a...
It's not at all elegant, but I was able to work around the problem by jamming the prototypes into btstack_config.h so we can put the issue of forking BTstack to the side for now.
// The following prototypes work around missing prototypes in btstack/src/hci.c:
#include <stdint.h>
uint8_t hci_le_extended_advertising_operation_for_chunk(uint16_t pos, uint16_t len);
void le_handle_extended_advertisement_report(uint8_t *packet, uint16_t size);
While working on some experimental code ("posix port") I found some bugs & build problems.
The added includes are to get structure definitions and/or function prototypes for things that are included indirectly only when certain other features are enabled, which is why the problems weren't seen before.
The removed includes are for stuff not yet implemented on the POSIX port, where the include was apparently copied as boilerplate and is not actually needed.
@jerryneedell Yea I am always running the latest commit.
Also yes this board has a pmic and handles voltages with that library.
This way this board supports quite a few sensors.
I do not have any camera breakouts, so idk either.
AHA!! -- OV2640 support is not enabled for the esp32s3_eye!
adding it
#
# Espressif IoT Development Framework Configuration
#
#
# Component config
#
#
# LWIP
#
CONFIG_LWIP_LOCAL_HOSTNAME="espressif-esp32s3-eye"
CONFIG_OV2640_SUPPORT=y
# end of LWIP
# end of Component config
# end of Espressif IoT Development Framework Configuration
and I can now use the camera!!!
Now to figure out the AIO issues adafruit_requests is running out of retries but the camera is hap...
@jerryneedell would you like to submit a PR for this?
@jerryneedell would you like to submit a PR for this? If the other camera is turned on by default, it could be turned off
What do yo mean by "other camera"?
It's been along tine since did a "core" PR, but it will be a good exercise! First I should to try some other code to make sure the camera is fully functional. I'm still not sure why my example using AIO is not working on this board so I also want to delve into that.
Yay -- The LCD Viewfinder example https://learn.adafruit.com/capturing-camera-images-with-circuitpython/example-lcd-viewfinder now works.
I try to get a PR in later today and work on the AIO issues separately.
Possible 🎉!
macOS Sonoma 14.4 Beta 2 (23E5191e) was released a few days ago
Cautiously optimistic. I updated overnight, logged back in this morning and so far I'm able to write to CIRCUITPY on a Matrix Portal S3 via Finder and command line without triggering the issues that we've been seeing.
Copying files is very slow but seems to work. I've also removed files and installed libraries with circup.
I want to test a few other things (other boards, updating CircuitPython from th...
What do yo mean by "other camera"?
I mean that if CONFIG_OV2640_SUPPORT=y, to do CONFIG_OV5640_SUPPORT= , since we don't need support for that camera.
the cameras are easily swappable, if we support camera modules, we should support 'all' the types
macOS Sonoma 14.4 Beta 2 (23E5191e) was released a few days ago
There is nothing in https://developer.apple.com/documentation/macos-release-notes/macos-14_4-release-notes, but these release notes are really sparse a lot of the time.
What do yo mean by "other camera"?
I mean that if
CONFIG_OV2640_SUPPORT=y, to doCONFIG_OV5640_SUPPORT=, since we don't need support for that camera.
There was no support enabled at all in the current sdkconfig file.
the cameras are easily swappable, if we support camera modules, we should support 'all' the types
Do they need to be individually listed in sdkconfig?
the cameras are easily swappable, if we support camera modules, we should support 'all' the types
There are quite a few models supported: see https://github.com/adafruit/esp32-camera/blob/8f3f2cc8cfb2e4371870b0c5a974d40468114a9e/Kconfig. Each one has its own driver .c file which is of noticeable size. So maybe all the OVxxxx ones?
the cameras are easily swappable, if we support camera modules, we should support 'all' the types
There are quite a few models supported: see https://github.com/adafruit/esp32-camera/blob/8f3f2cc8cfb2e4371870b0c5a974d40468114a9e/Kconfig. Each one has its own driver .c file which is of noticeable size. So maybe all the OVxxxx ones?
OK -- I'll see how it does with flash if I enable more. The only board this applies to is the esp32s3_eye, correct. Earlier I tried setting up a cam...
but... I am confused....
the sdkconfig for the memento is
#
# Espressif IoT Development Framework Configuration
#
#
# Component config
#
#
# LWIP
#
CONFIG_LWIP_LOCAL_HOSTNAME="espressif-esp32s3"
# end of LWIP
#
# Camera configuration
#
# CONFIG_OV7725_SUPPORT is not set
# CONFIG_OV3660_SUPPORT is not set
# end of Camera configuration
# end of Component config
# end of Espressif IoT Development Framework Configuration
so no specific support is enabled
...
the cameras are easily swappable, if we support camera modules, we should support 'all' the types
Are there other modules available for the esp32s3_eye board? the docs only refer to the OV2640 "sub" board https://github.com/espressif/esp-who/blob/master/docs/en/get-started/ESP32-S3-EYE_Getting_Started_Guide.md
Sacrificial HDs in my life are more plentiful than sacrificial Macs.
I have a non-sacrificial 14.3.1 MBP that I may try it on. (I know this
isn't an Apple support group. I'm just whining/posting a warning/looking
for commiseration amongst the other seven C/C++ Mac native+multi-embedded
devs these days. :-) ) I try to not run betas and I didn't see exactly when
it happens (everything upgrades by itself so often these days...) but I've
spent a couple of hours (including removal and re...
This is really confusing. In https://github.com/adafruit/esp32-camera/blob/8f3f2cc8cfb2e4371870b0c5a974d40468114a9e/Kconfig, most of the cameras have default y entries. If I build espressif_esp32_eye without your change, in build-espressif_esp32_eye/esp-idf/sdkconfig (the computed sdkconfig made during the build) many are turned on:
# Camera configuration
#
CONFIG_OV7670_SUPPORT=y
CONFIG_OV7725_SUPPORT=y
CONFIG_NT99141_SUPPORT=y
CONFIG_OV2640_SUPPORT=y
CONFIG_OV3660_SUPPORT...
You built esp32_eye not esp32s3_eye
All right, I see. So if the camera is not replaceable in ESP32-S3 Eye, then I would say just enable OV2640 and be done with it, and there'll be more space.
and after enabling OV2640 , I see
CONFIG_OV2640_SUPPORT=y
CONFIG_OV3660_SUPPORT=y
CONFIG_OV5640_SUPPORT=y
in the generated sdkconfig so I guess I'll just leave it that way unless you want ne to try to explicitly remove the others
I'm unclear whether it is possible or not to support @micropython.native (and native .mpy modules) on the RP2040. #2271 allowed boards to "enable the decorator by adding CIRCUITPY_ENABLE_MPY_NATIVE to mkboardconfig.mk."
For ports/raspberrypi/mkboardconfig.mk, adding CIRCUITPY_ENABLE_MPY_NATIVE = 1 is not sufficient. There are a handful of build errors:
GEN build-raspberry_pi_pico/genhdr/qstrdefs.generated.h
../../py/compile.c: In function 'compile_built_in_decorator':
....
CircuitPython version
N/A
Code/REPL
N/A
Behavior
N/A
Description
If this is not the right depot, please redirect or inform where to file this report.
Reviewing new adabox21, which is based on Momento. The
Starting at CircuitPython.org website for the board.
Near the bottom is the link to [download](https://github.com/adafruit/tinyuf2/releases/download/0.18.1/tinyuf2-adaf...
Just a heads up -- I don't have time to file an issue now, but since CP9 beta.0 something has broken adafruit requests. With recent builds call to get an AIO feed reult in ans "Out of Retries" error in adafruit_requests lin 696. I'll create a proper issue later or more likely tomorrow but I was wondering if anyone ese was seeing issues in the last few days.
I've seen a bunch of SSL Handshake issues on ESP32S2s on CP9. Is that what you are using?
I’ve been using esp32s3s since I noticed this.
On latest CP9
Works fine with Beta.0…
What's the actual error you're getting?
The one hidden behind the max retries
I’ll post more details later. Tied up now.
I believe this will resolve the broken link...
Fixes #1324 adafruit/circuitpython#8903
@dearmash You did great! My original plan was to clean up your PR. However, there was a huge refactor of displayio requiring some significant changes to board.c and my rebase skills are nowhere near up to the task of bringing your PR inline with the latest situation. Thank you for putting together something to start with. I picked up one of these boards, not realising until after purchase that it hadn't been added to CircuitPython. I would have been able to put together a basic set of b...
CircuitPython version
9.0.0 beta.0 (current main)
Code/REPL
from jpegio import JpegDecoder
from displayio import Bitmap
decoder = JpegDecoder()
width, height = decoder.open("/sd/example.jpg")
bitmap = Bitmap(width, height)
decoder.decode(bitmap)
# .. do something with bitmap
Behavior
The docs and this sample code indicate that the tuple returned by decoder.open() is (width, height).
But in testing with a sample jpeg image I've fou...
resolves: #8904 and #8899
My testing of the new version on a Feather TFT S3 with JPEGIO turned on in mk file. I confirmed on this version that the example code now results in Bitmap with the same size as the JPEG instead of swapped.
@dhalbert The release notes do seem typically vague. I also suspect this is a "minor bug fix" from Apple's perspective.
Full web install of CircuitPython to a QT Py S2 worked, that would have failed before. I was able to copy files to CIRCUITPY via both Finder and command line. After erasing and using the web installer to install just the boot loader, I also was able to manually install CircuitPython by copying adafruit-circuitpython-adafruit_qtpy_esp32s2-en_US-8.2.9.uf2 to QTPYS2BOOT.
...
Still works after logout and an arbitrary reboot!
(I modified the initial message slightly to avoid spoilers)
@romkey and @dhalbert This is exciting news. I'm updating to 14.4 beta 2 now and will run traces.
Nice catch. Usually board and bootloader match, but not this time. I checked against https://github.com/adafruit/tinyuf2/blob/master/.github/workflows/build_esp32.yml#L83 and your change matches.
If you roll back to the last alpha does it work with the same version of the library? I would also check to see whether there was a library regresion.
I started going back from the latest and it was failing but I ran out of time. It works with Beta.0 -- not usre when after taht it quit -- I will investigate it tomorrow. Here is the full traceback ```Adafruit CircuitPython 9.0.0-beta.0-23-g8af780c7fa-dirty on 2024-02-11; ESP32-S3-EYE with ESP32S3
import aio
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "aio.py", line 29, in <module>
File "adafruit_io/adafruit_io.py", line 748, in get_feed
File "adafruit_io/adafruit_io.py", line 578, in _get
File "adafruit_requests.py", line 732, in get
File "adafruit_requests.py", line 696, in request
OutOfRetries: Repeated socket failures