#circuitpython-dev
1 messages · Page 68 of 1
I think it's good to test with that
hiccups are fine IMO
its crashes and stops that would be good to fix
New code looks good. I know you are still debugging so I won't approve yet.
How much do you gain by leaving PICODVI on? I could see it being useful for data display from wifi.
Does usb host work at all as-is?
Is there a built-in routine for setting up a debug uart? Not seeing one in the repo
looks it up
CIRCUITPY_CONSOLE_UART_RX and _TX
console_uart_printf() will print to the uart only
mp_printf(&mp_plat_print, <normal printf>) will go out all serial
Nice, thanks
CIRCUITPY_USB_HOST and CIRCUITPY_PICODVI both on (current settings main):
Memory region Used Size Region Size %age Used
FLASH_FIRMWARE: 1408412 B 1532 KB 89.78%
RAM: 106772 B 256 KB 40.73%
Only CIRCUITPY_USB_HOST on:
FLASH_FIRMWARE: 1397816 B 1532 KB 89.10%
RAM: 103076 B 256 KB 39.32%
Only CIRCUITPY_PICODVI on:
FLASH_FIRMWARE: 1379108 B 1532 KB ...
Yes, I still have the WiFi settings auto connecting like that. We did talk about disabling that over at the forums but I don't think I tried it. So that is now on my to-do list for tonight: Run both the Waveshare S3 and Feather TFT S3 without the .toml file.
If there is a conflict between the two (ADC and WiFi), that will be disappointing for me since I need both for my application, so I won't be able to simply not use WiFi. But the problem can't be fixed later if we don't narrow it down ...
I was just testing on a QT Py ESP32-S3, with the very simple test program below. With CIRCUITPY_WIFI_SSID and CIRCUITPY_WIFI_PASSWORD commented out in settings.toml, it runs indefinitely, with millions of conversions. With them not commented out (so web set up in advance) , it crashes hard almost immediately. I am using board.A2, which uses ADC1 on the QT Py S3.
So now I know how to reproduce this. It is strange because ADC2 is supposed to be shared with WiFi, not ADC1. But mayb...
Testing with A0, which is an ADC2 pin, I also get crashes rather quickly, and sometimes get safe-mode "Internal watchdog timer expired".
[initial comment updated with the current state of things. It's as good as the ability of the esp32-s3 to deliver packets on time, now.
H2 and C2 are alpha.
C2 outright "halts and catches fire" in some of my tests.
Memory/instruction errors, heap errors, all sorts of goodies.
I will be filing issues once I hopefully make repro code.
C3 and C6 are still fine being beta.
There is a lot of weirdness that isn't easily reproducible and can't be filed atm.
Also thread/zigbee is not implemented.
S3 is just as stable as S2 and ble is somewhat implemented now right?
OG ESP32 still not stable due to serial.
The SSL socket doesn't support the stream protocol, which is a common way to read, write & ioctl. This is needed for ...
- asyncio awaiting ssl socket readability
- mp3 streaming (#9284)
Right now under #9284 trying to stream an MP3 on https errors with OSError: stream operation not supported.
Hi Dan, Thank you very much for confirming this. Since I first reported this on the forums and after days of replies there and here, since no one seemed to be interesting in actually running the code to see if it could be reproduced, I was starting to wonder if it was me and everyone was just being polite by not telling me I'm the idiot. ;)
You and I actually had a conversation on the forums on the Wifi vs ADC about two months ago because I had read about the possible interference bet...
- Fixes #9053 (opened by @RetiredWizard).
The web workflow was using relative paths internally when adjusting paths at the root /. This made them subject to whatever os.chdir() had been set to. Instead, use absolute paths to avoid any influence by the current directory.
@slender iron hey, I came across an old form post of yours from 2016, I think I’m having the same issue. I have a fork of CircuitPython in my GitHub. I want to add my board to Micropython so I cloned it, made my changes, then tried letting GitHub desktop create a fork in my repository so I can make a pull request; however, GitHub hits me with a “nah man, this is actually circuitpython” and I’m like, “No, GitHub, you’re drunk, this is most definitely Micropython. Listen to me, I want you to make a fork of Micropython.” but git’s all like, “Sorry man, couldn’t hear you over the 7000 conflicts I’m trying to resolve.”
Anyway, if you remember how to fix that, I would greatly appreciate it lol.
@Timeline8 Rest assured we were interested, but if we can delegate some testing to eliminate possibilities, then we try that. (We have all too many bugs to look at :slightly_smiling_face:). For instance, was displayio involved or not? And I was hoping it was really fixed in 9.1.0-beta.3, since we'd upgraded the underlying Espressif software (ESP-IDF) in that release. I also spent time looking for similar reports in the ESP-IDF repo, but could not find any.
I hope we can figure this out s...
@tannewt One confusion I had when tracking this down was what MP_VFS_ROOT meant, as returned by mp_vfs_lookup_path() in extmod/vfs.c. It seems to mean only /, and not the whole default filesystem. I'm thinking that even CIRCUITPY is a VFS that is mounted on MP_VFS_ROOT. So it seems MP_VFS_ROOT is only the / mount point, and not the filesystem itself. Do you remember the details here?
I am not a GitHub expert and don't use GitHub desktop but in order to create pull requests for both Micropython and Circuitpython from my repo, I've had to fork Micropython and then use a branch of that fork for Circuitpython PRs using the following:
git remote add circuitpython https://github.com/adafruit/circuitpython.git
git fetch circuitpython
git checkout remotes/circuitpython/main
git switch -c projectName #Creates new branch 'projectName' in Micropython fork
git push --set-upstream origin projectName #I guess this one actually creates the branch 😁
You have to fumble a bit with the branch comparison screen when submitting a CircuitPython PR using the web github interface because it defaults to trying to submit the PR to Micropython.
Average github actions moment.
CircuitPython version
Adafruit CircuitPython 9.0.5 on 2024-05-22; Adafruit QT Py RP2040 with rp2040
Code/REPL
import board
from digitalio import DigitalInOut, Direction, Pull
btn_0 = DigitalInOut(board.D0)
btn_0.direction = Direction.INPUT
btn_0.pull = Pull.UP
btn_1 = DigitalInOut(board.D4)
btn_1.direction = Direction.INPUT
btn_1.pull = Pull.UP
Behavior
When I measure the voltage between GND and pin D4, it is set to +3.3v as expected b...
I am inclined just to remove the stability status from the README. I cover this in the release notes for each release. Having to PR changes to this is another thing to synchronize with the release notes.
I only looked at the changes so I don't have the context for what the variables are, but the comments are talking about mount points and the issue seems to be more general as simple sub-directories exhibited the issue.
I did test the artifact and it resolved the problem demonstrated by the test code.py in the original issue, however now I don't think a file can be deleted using web workflow if the folder has been changed from the root folder using os.chdir.
There could a cross-reference: "see the latest release notes" instead.
Internally, the code is now using an absolute path instead of a relative path. That eliminates the current directory as something that influences path lookup. I'll look at the "delete" case: it may be taking a different path.
Ah, I guess I didn't check the delete before this update, it probably never worked. Rename isn't working either but Edit does....
Last night I did not leave the USB connected to the docking station and this morning I did a full power cycle (disconnecting the battery) and started back up. It appeared to still hit the issue. I cannot be 100% certain since I wasn't connected to USB/serial to see the stack trace, but it hit the assert at the exact same time it usually does (and the app running has been unchanged for months and is pretty stable other than this issue).
It looks like this is failing some of the checks. I'd recommend moving your custom features into your description as bullet points.
I just ran into this with the cardputer.
Spamming the adc with wifi connected produces instant resets and hangups.
I just finished the battery driver, which uses IO10 of the ESP32-S3.
When connected to a network, after about 30 seconds it resets (NO SAFEMODE, RESET) or hangs up (neopixel went white, not a color I use, and stayed there, unresponsive).
The polling rate was 30 samples/s.
The code accounts for None reads.
Attempted this patch, which reduces the points of failure:
--- a/ports/espressif/common-hal/analogio/AnalogIn.c
+++ b/ports/espressif/common-hal/analogio/AnalogIn.c
@@ -115,10 +115,10 @@ uint16_t common_hal_analogio_analogin_get_value(analogio_analogin_obj_t *self) {
#endif
uint32_t adc_reading = 0;
- size_t sample_count = 0;
+ int sample_count = 0;
// Multisampling
esp_err_t ret = ESP_OK;
- for (int i = 0; i < NO_OF_SAMPLES; i++) {
+ whi...
Yep, fun stuff:
I (21616) EXAMPLE: ADC1 Channel[3] Raw Data: 562
I (21616) EXAMPLE: ADC1 Channel[3] Cali Voltage: 481 mV
I (21626) EXAMPLE: ADC2 Channel[0] Raw Data: 537
E (21626) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (21626) task_wdt: - IDLE0 (CPU 0)
E (21626) task_wdt: Tasks currently running:
E (21626) task_wdt: CPU 0: main
E (21626) task_wdt: CPU 1: IDLE1
E (21626) task_wdt: Print CPU 0 (current core) backtrac...
Ya basically what @wraith crow said. They are the same git repo so you’ll want two remotes locally. The easiest way to get the pr right is to push your branch and go to the micropython repo page. It’ll pop up a box that says you just pushed a branch and if you want to make a pr. Doing it from your repository page will default to CircuitPython I think.
Thanks @wraith crow & @slender iron !
I got my YD-ESP32-S3 which is a dual usb-C board, and is excellent for debugging and built some debug builds.
import wifi, board, analogio;wifi.radio.connect("SSID", "PASSWD");a=analogio.AnalogIn(board.GPIO10)
while True:
a.value
This reliably crashes it. Maximum 15s.
Decoded backtrace of debug build (clean tree, current master):
0x4037cc7a: ram_chip_i2c_readReg at ??:?
0x40378aa0: regi2c_ctrl_write_reg_mask at /home/bill88t/git/circuitpython/ports/espressif/...
@dhalbert, no problem on me doing some of the upfront testing. I know from my own experiences learning CircuitPython and also reading other people pleas for help, 99% of the time it is user error. So no harm on pushing back a bit on the user to kind of "prove it".
As for my project, it is for aquarium monitoring and eventually some controls later. Therefore I am sensing water temperature. Thermistors are well suited for this. Simple to use, and easy to waterproof if needed. I would love t...
@Timeline8: have you thought about using DS18B20-sensors? They are available in a waterproof enclosure. And they are easy to use.
Wasn't able to replicate this. Does it function correctly if you conclude your code with:
while True: pass
Or if you copy the code into the REPL?
Thanks for the info. That is weird! The simplest fix would be to catch the exception and retry.
To debug, we'd need the IDF logs that can be output over the UART.
Headers have been updated to SPDX. Is this based on an old branch?
I have good news and bad news.
Good news: I fixed the watchdog timer crash.
Bad news: It's 2 bugs. It now 100% does the weird crash, where usb dies, but the core keeps running.
I don't have a backtrace to work with now.
Also with my improvements adc is 100x faster, crashing in less than a second.
@tannewt One confusion I had when tracking this down was what
MP_VFS_ROOTmeant, as returned bymp_vfs_lookup_path()inextmod/vfs.c. It seems to mean only/, and not the whole default filesystem. I'm thinking that even CIRCUITPY is a VFS that is mounted onMP_VFS_ROOT. So it seemsMP_VFS_ROOTis only the/mount point, and not the filesystem itself. Do you remember the details here?
I don't remember. Sorry!
How are the other boards with picow soldered down setup? I guess this is ok for picow because folks can use the pico build if they don't want wifi.
espressif_esp8684_devkitc_02_n4 which I used as a base, wasn't updated apparently.
Updated.
@tannewt
| Board | PICODVI (off by default) | USB_HOST (on by default) | notes |
|---|---|---|---|
| cytron_edu_pico_w | + | + | lots of frozen modules, no display |
| pajenicko_picopad | + | - | gaming board with display |
| pimoroni_badger2040w | - | - | e-ink badge |
| pimoroni_inky_frame_5_7 | - | - | e-ink picture frame |
| pimoroni_inky_frame_7_3 | - | - | e-ink picture frame |
| pimoroni_pico_dv_base_w | + | + | point of board is DVI , non pico-W build availa... |
[Testing #9311]
I did test the artifact and it resolved the problem demonstrated by the test code.py in the original issue, however now I don't think a file can be deleted using web workflow if the folder has been changed from the root folder using os.chdir.
_Originally posted by @RetiredWizard in https://github.com/adafruit/circuitpython/issues/9311#issuecomment-2152786590_
- Fixes #9313. (via @RetiredWizard)
Very similar fix to #9311, but in a different place. I looked a bit at some refactoring to share the code, but the surrounding code has various different cases, and it didn't seem worth it.
Doing the adc sampling into the core also doesn't fix this.
There is nothing that can be done from the CircuitPython side to workaround this.
This needs to be fixed from ESP-IDF.
Here is my experimental patch with an updated ADC api that internalizes the sampling.
(So that python doesn't loop over adc reads)
<details>
<summary>Patch</summary>
diff --git a/locale/circuitpython.pot b/locale/circuitpython.pot
index 0e3878bc3d..407d3713a9 100644
--- a/locale/circuitpyt...
@bill88t Can you submit the state saving as a PR? Did you find any other reports of an ESP-IDF bug, in addition to what @jepler found?
I tested Web Workflow upload, delete and rename and everything seems to be working. Thanks!
This is only implemented for espressif.
If you reload before .deinitializing an analogio object it cannot be remade until reset.
Doesn't actually fix the crash. (I mean, it fixes the calibration crash..)
Is 100x times faster. Which is bad rn.
@dhalbert
#9315
No I did not find any more ESP-IDF bugs matching this.
Though, I didn't spend much time on the issue tracker.
@brazen hatch I am baffled as to why your latest PR says "First-time contributor". Did you change something about your account?
I died inside 3 times while debugging this.
Other than that no. 
did you switch to "Pro" recently?
nope, I literally have touched / changed nothing on my acc
If you reload before
.deinitializing an analogio object it cannot be remade until reset.
We can fix this by by making the AnalogIn object have a finalizer. It's on the list to do that anyway.
i've always been "pro"
that is a weird glitch
kinda funny one tho
New very interesting discovery:
The quick crash on ADC1 pins only happens when the board is a 4MB flash / 2MB PSRAM board. I tried an 8/0 QT Py ESP32-S3 and it does not crash. @Timeline8's boards are all 4/2, and I was testing on a QT Py ESP32-S3 4/2 when I reproduced the problem.
Cardputer is 8/0 and crashes just fine?
The YD-ESP32-S3 which is 16/8, also explodes to pieces.
Maybe some other factor is at play?
Chip revision, temperature?
so the commonality is no PSRAM .. what if you make a no-psram build on one of the 4/2s, does the problem go away? if so, maybe there's some object that needs to be located in main RAM not PSRAM?
Cardputer is 8/0 and crashes just fine?
Are you testing an ADC1 or an ADC2 pin on the Cardputer?
Thank you so much! I was hoping that this pull request would also allow people to flash the board directly from https://circuitpython.org/board/ThingPulse_PendriveS3/ How can I get that section to show up?
I guess this is ok for picow because folks can use the pico build if they don't want wifi.
@tannewt: I don't think so. The board led is wired differently. And VBUS and VSYS monitoring also are different.
To make this work in 9.1 the following needs to be added to mpconfigboard.mk:
CIRCUITPY_ESP_PSRAM_SIZE = 8MB
CIRCUITPY_ESP_PSRAM_MODE = opi
CIRCUITPY_ESP_PSRAM_FREQ = 80m
This adds the board defintion files for yet another CYD variant.
Are you testing an ADC1 or an ADC2 pin on the Cardputer?
BAT_ADC is wired to IO10 which is ADC1_CH9.
Leaving this here for quick reference.
My current working theory is that there is some critical period of time where wifi and adc may try to write to memory concurrently somehow.
Adc can trigger this scenario from the calibration data init and from .value.
It may be that slower, /2 (esp32-s3r2) memories trigger this a lot more often.
My 4/2 vs 8/0 distinction was wrong. I had neglected to uncomment CIRCUITPY_WIFI_SSID and CIRCUITPY_WIFI_PASSWORD on the ESP32-S3 8/0 board. When I enabled initial wifi on the 8/0 board, it crashed in the same way. I edited the posts above to indicate that.
what is the status of the paralleldisplaybus on the esp32-s3 boards? should it be working?
it should be, yes. But I can't find any project that uses it
thanks
@bablokb , Yes I am aware of the DS18B20 but I just happen to have a LOT of thermistors on hand that are waterproof, so that is one reason. No matter how cheap I can find DS18B20s, no one is going to beat FREE. 😉 While the DS18B20 are fairly simple to use once you get them setup, even they are no match for the dead-simple lowly thermistor. Plus I have seen enough reports of less than reputable supplies (counterfeits?) of DS18B20 being on the market that gives me pause.
But fundamentally, t...
I tested it on a lilygo t-display
I'm getting espidf.IDFError: Requested resource not found -- are there any restrictions on which pins can be used?
or do I need to configure memory in settings.toml?
no memory config needed
weird, after a reset I stopped getting that error
that's esp32, not esp32-s3, right?
oh, I see there it t-display s3
ya, the s3 version
could have broken since I did it though
did you release displays?
maybe that's their version of in-use
displayio.release_displays()
bus = paralleldisplaybus.ParallelBus(
chip_select=board.IO43, # CS
command=board.IO44, # RS
write=board.IO36, # WR
reset=board.IO18, # REST
data0 = board.IO6,
)
display = busdisplay.BusDisplay(bus, _INIT_SEQUENCE, width=320, height=240)
it's an ili9341 that I had working with rp2040 before
I will move to #help-with-circuitpython
CircuitPython version
Adafruit CircuitPython 9.1.0-beta.3 on 2024-05-22; FeatherS3 with ESP32S3
Code/REPL
import alarm
import board
import busio
import digitalio
import time
import adafruit_connection_manager
import adafruit_requests
from adafruit_wiznet5k import adafruit_wiznet5k
# delay so you can connect
print("starting:", end="")
for i in range(10):
print(".", end="")
time.sleep(1)
print()
print("getting radio")
chip_select ...
Thanks for the board def! Just a couple questions.
Are you sure it is DIO? I think most boards are actually QIO. DIO is only used when loading.
Since this board is new, do you want to remove OTA support in favor of BLE?
Ok, thanks! I'll up date it too.
Thanks for updating the other board too!
Thank you so much! I was hoping that this pull request would also allow people to flash the board directly from https://circuitpython.org/board/ThingPulse_PendriveS3/ How can I get that section to show up?
You need to have the board family and bootloader id, which it looks like you have. You'll need to add your board to https://github.com/adafruit/tinyuf2, which I don't see in the latest release, but maybe you added it already. And it looks like you'll need to wait for another release of...
Adds the RPGA Feather to circuit python-org. Tindie shop link will be active soon, we can wait to merge this until that's fully active if you'd like. I'm expecting approval any hour now.
And if I would have Waite 2 minutes, I would have gotten the email that the listing was approved. All links are good now, or should be anyway :)
I will note, that this is specific to the new feature in 9.1.0 that allows SSL to be used with the WIZnet5k
Have you tried this with espcamera and CP9? I'm just curious if you will have the same issues with memory.
Sorry for the delay, I didn't see your comment. I just tried with 9.1.0-beta on a Lolin S2 Mini, with this code:
import busio
import espcamera
import board
i2c = busio.I2C(scl=board.IO35, sda=board.IO33)
data_pins = (
board.IO21, board.IO17, board.IO16, board.IO18,
board.IO37, board.IO34, board.IO36, board.IO39,
)
c = espcamera.Camera(
data_pins=data...
including select. This assumes that the SSL layer is readable/writable exactly when the underlying socket is readable/writable.
Not tested. Will test monday.
note, for those who wondered: that particular URL redirects to https:, so this is using https even though the url is http
@jepler the same thing happens if it starts as https:. Should I update the example?
My assumption (although probably totally wrong) is that some resource is still being held onto by python when the fake sleep happens
and verified. This doesn't crash:
import alarm
import board
import busio
import digitalio
import time
import adafruit_connection_manager
import adafruit_requests
from adafruit_wiznet5k import adafruit_wiznet5k
# delay so you can connect
print("starting:", end="")
for i in range(10):
print(".", end="")
time.sleep(1)
print()
print("getting radio")
chip_select = digitalio.DigitalInOut(board.D10)
spi = busio.SPI(board.SCK, board.MOSI, board.MISO)
radio = a...
what if your code doesn't deep sleep, but just exits?
That works fine. So does supervisor.reload()
I was wrong, still had the old code. It fails the same way with both.
Being even more specific, this fixes it:
#connection_manager_close_all()
connection_manager = adafruit_connection_manager._global_connection_managers.get(pool)
connection_manager._free_sockets(force=True)
So it's the open socket via the ssl_context
Some more debugging:
Often USB disconnects, but the program is still running, if it doesn't hit a watchdog reset. I verified this by blinking the LED periodically and by writing a count to UART. Another interesting thing is that when it disconnects from USB, the UART output, both on the UART I'm writing to and the debug UART, become gibberish, as if the speed has changed.
This hasn't happened to me.
And I have run it 100 times by now.
Memory corruption most certainly.
I think it starts executing arbitrary code.
Ofc producing different random results every time.
USB-JTAG would be a blessing if it worked right now.
I still don't have a jtag dongle for normal jtag, so yea.. 👍
I think it starts executing arbitrary code.
That's not what I'm seeing (using a Metro ESP32-S3)
import analogio
import busio
import board
import digitalio
led = digitalio.DigitalInOut(board.LED)
led.switch_to_output()
analog = analogio.AnalogIn(board.A5)
uart = busio.UART(tx=board.TX, baudrate=115200)
count = 0
while True:
count += 1
if count % 100000 == 0:
print("count", count)
if count % 100 == 0:
led.value = not led.value
...
With my example:
while True:
adc.value
It either halts or safemodes.
I should note, I only tested from REPL.
If proc'ed by my os and the "halt" scenario occurs, the neopixel, instead of heartbeating in 2 different blues, it becomes 255-value white (not the REPL white). USB in this scenario is disconnected.
Also I have already determined the watchdog timeout is cause of the calibration init functions.
Under the adc pr, it doesn't happen, since those only run once dur...
@tulip sleet would it be useful to video the different crash scenarios?
Also sidenote, the cardputer has the screen. If it crashed to REPL, the displayio root would swap back to CP terminal.
it's not crashing to the REPL. It's continuing to run. It just loses USB connectivity. I see that and I also see the Internal Watchdog safe mode, both when using an ADC1 pin.
I don't think we need a video. I am reproducing it. I am going to look at the changes in the underlying code from when it used to work.
neopixel 255-white is not something my os would do..
It could be the system clock breaking down, causing invalid neopixel writes.
Lemme hook it to an oscilloscope real quick.
yes, I have seen that too
this is what I refer to as the "halt" scenario, that the pr doesn't fix
the UART going to garbage is really strange. I saleae'd it to make sure but I I can't tell the new baud rate or if it is wandering
something changed in ESP-IDF. I'm surprised no one else outside of us has seen this.
If proc'ed by my os and the "halt" scenario occurs, the neopixel, instead of heartbeating in 2 different blues, it becomes 255-value white (not the REPL white). USB in this scenario is disconnected.
I would see this mode when the failure was not reporting an internal watchdog timer expired. When I had the TFT display hooked up or running my S3 TFT Feather, the board disconnects from USB, the Neopixel turns solid white, and no reconnection of the board to USB. However the TFT shows the co...
@tulip sleet if you have time over the next week would be curious your thoughts on this: https://github.com/boxpet/circuitpython_network_tests
sure! if not over the weekend then early next week
Got a watchdog timeout while wiping storage.. huh...
I think the idf isn't feeling so good..
latest artifact
idf has just updated to 5.2.2 from 5.2.1, but nothing in the release notes that looks pertinent. Nevertheless Scott will be updating and we'll re-test
It's mainly just bug fixes.
I could go and try to merge it downstream for testing..
Awesome. I had a lot of fun putting it together
it is in or will be in an upcoming PR from Scott
Nothing has been done in the CP side yet, since last I checked at least.
I was thinking of just merging all the commits into an idf fork branch and pointing my local CP clone to use that.
Just a yolo merge. It wouldn't be the first time i'd done that.
Somehow I got the impression it was working in 8.x.x, but that is not right; just reproduced in 8.2.7.
Now for some reason that I got pwm running it's not crashing..
you stay up awful late 🙂
do you usually stay up until 5
yep, I can focus well at night
192 pretty much
tho my oscilloscope is pretty inaccurate
while running it says 480-520
it doesn't wander
I wonder if it was locked to USB and then lost that. Could you hook it up to a 5v wall wart and see if the same thing happens (500 Hz -> 192)
prob not that problem, but SAMD chips can lock to USB clock. That's how we get good timing on crystal-less designs
another thing I think I see is that sometimes it disconnects from USB and then reconnects, and then disconnects for good
plugged it to thinkpad, expensive gan charger, powerbank, all the same
thanks!
that would cause a lotta problems for many things.
i am looking through esp-idf issues
I commented out all the calibration code, so the only stuff left is
adc_oneshot_new_unit()
adc_oneshot_config_channel()
adc_oneshot_read() // twice
adc_oneshot_del_unit()
still fails
the core freq doesn't just change randomly, we will have to look in idf.
I imagine it clocks down for some reason to take a reading, fails, doesn't clock back up.
In which case a hack would be to read core freq and set it back in CP
after every adc read
i don't think it would do that, that would affect all kinds of other stuff. It hink it is a bug or a hw problem
I mean, a clock change for just a few cycles..
i still don't think it would do that. the peripheral has its own clocking from the master clock
it wouldn't change the master clock
but i am planning to read their code
I will too, after I finish my gh essay.
I don't know xtensa asm, so if it comes to that it will take a while
ESP32-S3 TFT Feather example:
from time import sleep
import board, analogio, digitalio
from neopixel_write import neopixel_write
import pwmio
state_a = bytearray([0, 8, 0])
state_b = bytearray([0, 0, 8])
adc = analogio.AnalogIn(board.D10)
pwm = pwmio.PWMOut(board.A4)
pwm.duty_cycle = 32767 # 50%
nx = digitalio.DigitalInOut(board.NEOPIXEL)
nxp = digitalio.DigitalInOut(board.NEOPIXEL_POWER)
nx.switch_to_output()
nxp.switch_to_output()
nxp.value = 1
print("Ripping!")
...
A few more tests:
CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ_160=y instead of 240 MHz: no help
CONFIG_ADC_ONESHOT_CTRL_FUNC_IN_IRAM=y: no help
CONFIG_FREERTOS_UNICORE=y, so that only one core is used: problem seems to go away
Then this also means that it's not some lock-not-being-updated issue, but that whatever function runs on the other core is not thread safe and causes the crash.
And that "whatever function" is most certainly a wifi function.
(Since this happens when connected)
Somewhere an rtc_spinlock is missing.
did i somehow mess my library up, or is this to blame on circup?```
$ circup install toml
Downloading latest bundles for adafruit/CircuitPython_Community_Bundle (20240608).
py:
There was a problem downloading that platform bundle. Skipping and using existing download if available.
Searching for dependencies for: ['toml']
Ready to install: ['toml']
'toml' is already installed.
$ circup update
Downloading latest bundles for adafruit/CircuitPython_Community_Bundle (20240608).
py:
There was a problem downloading that platform bundle. Skipping and using existing download if available.
Found 1 module[s] needing update.
Please indicate which module[s] you wish to update:
'toml' is a Major Version update and may contain breaking changes. Do you want to update? [y/N]: y
Updated toml
Checking 1 updated module[s] for missing requirements.
Downloading latest bundles for adafruit/CircuitPython_Community_Bundle (20240608).
py:
There was a problem downloading that platform bundle. Skipping and using existing download if available.
Ready to install: []
it installed 0.1.7 and latest update (yesterday) is 0.1.9
it appears that the automated build of the Community Bundle failed last night: https://github.com/adafruit/CircuitPython_Community_Bundle/actions those actions are responsible for building and uploading the bundle zip to the release page which is where circuip is trying to download it from I believe.
Since the actions failed, there is no 20240608 bundle so it fails to download. If you have an older copy cached locally already it looks like it will use that, but if you didn't have that I guess it would just fail entirely.
we should try to add some fallback logic if/when it finds that a bundle download link is dead, maybe it could work backwards through the most recent releases to find one that works? or perhaps that's too complex for handling something that ought to get fixed in the actions for the bundle.
could it be that i created a tag several days ago, then realized it had a bug and removed it (circup didnt get to publish it afaik) and i broke something?
i made another release a while ago (0.1.10) which has no code changes, in hopes to cause another packaging of the bundle with the daily update 😅
possibly, I'm not sure how / if it will handle a tag that got released. I'm not entirely sure though, I'll dig into the actions log here in a bit.
hah, think i got it
$ mpy-cross _toml.py
Traceback (most recent call last):
File "_toml.py", line 95
SyntaxError: raw f-strings are not supported
this should do :)```diff
--- a/toml/_toml.py
+++ b/toml/_toml.py
@@ -92,7 +92,7 @@ class Tokens:
return char, 1 + width
# TODO: should this raise instead?
-
warnings.warn(rf"Unknown/invalid escape sequence '\{escaped}'")
-
warnings.warn(f"Unknown/invalid escape sequence '\\{escaped}'") return "\\" + escaped, 1
if anyone can manually trigger an update, instead of waiting for the daily(?) one, we should be back to business 😎
I will try, but I don't know if they manual re-trigger will work. I've never done it for a full bundle release.
@spare jacinth did you re-release toml with a fix?
@lone axle I think the tag will need to be removed before any re-run, becuase otherwise it will pick up the same commit.
.... could just delete the broken tag and release and wait for tonight if a re-run doesn't work
unrelated to this, but I also just noticed we ended up with a driver folder in the community bundle as well, drivers plural is the one used by the almost all of the libraries, but singular was added accidentally more recently it seems https://github.com/adafruit/CircuitPython_Community_Bundle/tree/main/libraries
and sorry for the inconveniences! 😅
there's an open PR for that
it seems to have failed to build https://github.com/adafruit/CircuitPython_Community_Bundle/actions/runs/9426409028/job/25973855434#step:8:1694
I only re-ran the build action, not the release one. But it seems to have failed the build anyhow.
I'm not sure it really took the new one. I'm leaning toward just waiting for the automated one to kick in.
I think you'll have to delete the tag and the release and then re-run the scheuled action, which I found very tricky to do in the past
I'm not sure if deleting the tag is the same as deleting the release, I thought it was, but am not sure. If we delete the release then I don't think the actions can succeed because they assume the release exists to upload files to I believe.
it is "trigger" and not a "re-run" or something like that.
I'd say just delete the release first, then the tag, and let's wait for tonight
Ahh, it was definitely a "re-run" that I tried. anyhow though I'm scared to mess with it too much since we know that the automation will try again.
(and then try circup)
do you have privs to delete the release and tag?
I'll just do it...
done
I do, but I'm not confident enough to do it.
I'm unclear on the difference between tag and release. I thought they were the same, but looking closer now it appears technically they are different.
it makes a tag first (just a labelled) commit, then it builds a release at that tagged commit
but also the github UI makes it very confusing because this page: https://github.com/adafruit/CircuitPython_Community_Bundle/releases/tag/20240608 which is a tag detail page has "releases" in it's breadcrumb links.
tag is a git thing, like a commit or a branch, that you can git checkkout into
and a release is a zip with the code from that version
... i think
I cleaned out the local bundle storage and installed something with circup, and it downloaded the bundles OK. So I think we are all set
local bundle store is in ~/.local/share/circup. I thought it was in .cache/circup, but that just seems to be logs
it updated to 0.1.8 now, no idea why it said it was a major release
hopefully 0.1.10 will be available tomorrow 🙂
There was a PR we missed about the misspelling! https://github.com/adafruit/CircuitPython_Community_Bundle/pull/213 I merged it
personally I would just as soon remove the drivers/helpers distinction. It takes a lot of guessing sometimes
Yeah, they both seem rather broad. We have so many libraries in each one it's really practical to just browse them anyway. I'm not sure the extra organization that the different folders brings is really that big of a help anywhere.
I do believe there are at least a few things that are hard-coded to look for those directories though, so if we make that change we'll have some updating of various other bits that needs to be done at the same time
It might be nice to have a listing somewhere with them broken out into more specific categories like this one for the Adafruit bundle: https://github.com/adafruit/Adafruit_CircuitPython_Bundle/blob/main/docs/drivers.rst.
i'll be afk now
I went through all the files containing the string rtc_spinlock and extended the range of the critical code.
I also added it in a lot of places.
For the moment I assume all the spinlocks work as intended, across cores.
All of the test were performed with clean builds.
Nothing fixed it.
Not even switching to portENTER_CRITICAL_SAFE.
No wifi code explicitly spinlocks rtc, but instead leaves components/esp_hw_support/adc_share_hw_ctrl.c to do the adc stuff.
I don't think I can...
I went to test if there would be any performance difference with the unicore flag.
My os? Doesn't care.
Division spam? Also doesn't care.
from time import monotonic
from os import urandom
st = monotonic()
samples = 0
counts = []
try:
while len(counts) < 60:
if monotonic()-st > 1:
print("Samples taken:", samples)
counts.append(samples)
samples = 0
st = monotonic()
else:
for i in range(10):
(1045566123 + i) / 993999999955588
samples += 1
except KeyboardInterrupt:
pass
except:
pass
print("Total:", sum(counts)/60)
I let this rip on each build.
Current master total score: 14095.3
Current master with unicore total score: 14333.3
Which is a 1% difference. Margin of error stuff.
I tested all system functions, nothing seems affected.
CONFIG_FREERTOS_UNICORE has literally 0 downsides as far as I can tell.
Measured a 1.1% perf difference on a division benchmark, with the unicore build being the faster one.
There was no other differences across the builds.
(Other than that indeed, the crashes went away.)
So I think, at least temporarily, we should go with that, and open an upstream ESP-IDF issue to have it resolved properly.
(I can go do it if you want me to.)
Not opening PR, this was Dan's find.
Is there any desire to see this completed?
It makes sampling a lot faster.
It doesn't break the existing api.
Updated to do what was requested. Please let me know if it's to your liking.
Actions still don't feel like working.
I might have done this for #8690. If you want to complete it to check AnalogIn off in that issue, that would be great. Look for how finalizers are done in, say, #9165. Note that finalizer is spelled finaliser in function names due to the British/Australian spelling difference. The basic thing to do is to say it has a finalizer when you construct it, and to make __del__() call deinit(). You also need to remove any global init/reset.
It's the wifi code that runs on the other core. CircuitPython just runs on one core.
Wifi also feels normal.. I mean, CP does all the wifi stuff synchronously either way.
I did upload a build of this onto the cardputer and did some ftp package updates to my os.
Now it's been running for an hour, trying to drain it's battery.
The following ports are available: ``atmel-samd``, ``cxd56``, ``espressif``, ``litex``, ``mimxrt10xx``, ``nordic``, ``raspberrypi``, ``renode``, ``silabs`` (``efr32``), ``stm``, ``unix``.
However, not all ports are not fully functional. Some have limited limited functionality and known serious bugs.
For details, refer to the **Port status** section in the `latest release <https://github.com/adafruit/circuitpython/releases/latest>`__ notes.
I tweaked the language slightly and am merging. Thanks!
Double negative? Double word? Try:
However, not all ports are fully functional. Some have limited functionality and known serious bugs. …
CircuitPython version
Adafruit CircuitPython 9.0.5 on 2024-05-22; Waveshare RP2040-Zero with rp2040
Code/REPL
gamepad_a = usb_hid.Device(
report_descriptor=GAMEPAD_REPORT_DESCRIPTOR_A,
usage_page=0x01, # Generic Desktop Control
usage=0x05, # Gamepad
report_ids=(4,), # Descriptor uses report ID 4.
# in_report_lengths=(6,), # This gamepad sends 6 bytes in its report.
in_report_lengths=(3,), ...
Implemented finalisers. Now I just need to implement the sampling logic on all ports.
Updated the title an opening comment.
Also, @dhalbert turns out it's still possible to trigger a watchdog safemode with just CONFIG_FREERTOS_UNICORE.
You just have to be unlucky enough to .value during a dhcp leash renewal.
Well, with this PR this also goes away, since the object gets initialized only once.
Do you maybe want me to also include CONFIG_FREERTOS_UNICORE in this PR too?
Or are you going to PR it seperately?
CircuitPython version
Current master
CONFIG_FREERTOS_UNICORE=y
adc_paranoia (the name of the adc multi-sampling branch)
and pretty much every other build I tested
Code/REPL
# Assuming wifi connected via settings.toml
import microcontroller
while True:
a = microcontroller.cpu.temperature
# `a =` is there to not slow down with printing to serial
# It can take a lot longer than the ADC .value bug to proc.
Behavior
Auto-reload is off.
Ru...
still broken ?
$ circup update
Found device at E:\, running CircuitPython 9.0.0-alpha.6-4-g8e2235e34a-dirty.
A newer version of CircuitPython (9.0.5) is available.
Get it here: https://circuitpython.org/board/weact_esp32_s3_n16r8
Downloading latest bundles for adafruit/CircuitPython_Community_Bundle (20240609).
py:
There was a problem downloading that platform bundle. Skipping and using existing download if available.
Found 1 module[s] needing update.
Please indicate which module[s] you wish to update:
'toml' is a Major Version update and may contain breaking changes. Do you want to update? [y/N]: y
Updated toml
Checking 1 updated module[s] for missing requirements.
Downloading latest bundles for adafruit/CircuitPython_Community_Bundle (20240609).
py:
There was a problem downloading that platform bundle. Skipping and using existing download if available.
Ready to install: []
seems to have failed on the very same failed as yesterday (toml/_toml.py) but i can "compile" it locally with mpy-cross 🤔
and the bundle does point to my latest commit, i have no idea what's going on here
EDIT: I was wrong,
microcontroller.cpu.temperaturecan watchdog safemode.
That probably uses a an ADC.
Do you maybe want me to also include
CONFIG_FREERTOS_UNICOREin this PR too?
Or are you going to PR it seperately?
No, I am not prepared to turn off the second core yet. I would rather debug the underlying problem.
I believe that in order to do this, you would need to create multiple UBS HID interfaces, as the interface name is part of the USB Config Descriptor, and not part of the HID Descriptor. I believe you could do this in C with TinyUSB as a composite device, but CircuitPython creates only one HID interface that all HID devices go into (keyboard, mouse, any custom ones you create like gamepads, etc)
It seems that some of the circuitpython.org actions are failing that generate the libraries and contributing page info https://github.com/adafruit/circuitpython-org/actions
maybe it's due to the bundle build
...and i have no clue why my lib is breaking it 😅
could you diff your pyproject.toml, etc. with a working library in the community bundle. See https://github.com/adafruit/CircuitPython_Community_Bundle/actions/runs/9434183463/job/25986020456
I mean compare in detail the project files you have in your library with a working library and see what is different. Pick another library that's similar in terms of requirements.
maybe you have setup.py instead of pyproject.toml
yes, you have nothing that runs mpy-cross to build .mpy files, etc. That only ends up getting tested when the bundle is built.
We expect your library to be based on the cookiecutter template, which sets up all kinds of things. https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library
For immediate fixes, try running mpy-cross on your library to see what's breaking.
but you really need to set it up as described above
i did yesterday and removed the rf"" which was unsupported
and then, it supposedly builds my 3 files
there is something else it is upset about
$ ls toml
__init__.py _dotty.py _toml.py
$ mpy-cross toml/__init__.py && mpy-cross toml/_dotty.py && mpy-cross toml/_toml.py
$
yet the github action shows an error on _toml.py
It is fishy it says Automated update by Adabot (adafruit/adabot@20240604) but it happened 12 hours ago. The 20240604 tag is days ago
shall i nuke my repo off [github/bundle] and then add it again?
yes, let's try that. Remove it from the community bundle with a PR. I'll approve that, so that tonights build is OK. In the meantime you can then get it into standardized form.
the link you sent above doesnt mention the pyproject.toml file
not sure if it is missing on the docs, or it is not required
and it also says that setup is (mainly?) for pypi deployment, which i dont really want to do, but i guess i may still need to have an empty/minimal one
it is going to be created when you create the cookie-cutter template.
if you add it to pypi then people can use this library both in CircuitPython and CPython
@lone axle I deleted the community release and the tag, as i did yesterday
yeah i know, but python already ships a toml lib which will be orders of magnitude better
so i dont feel like maintaining a PyPi thing that really shouldnt get used because there's a better one 🤣
I don't believe it's required to release on pypi to have it in the bundle.
you can suppress it from pypi if you want. But use the rest of the structure. I don't know why it's breaking but if you use the standard release actions it will build .mpy files during a release, and do a bunch of other standard things so we'll know if that's failing
im on it
thanks!
fixed some tool yelling at licenses, then some pylint warns, but it still fails to build online (yet works fine locally, maybe i have another version of the cross-compiler)
hum, maybe i do```
$ mpy-cross --version
MicroPython v1.23.0 on 2024-06-01; mpy-cross emitting mpy v6.3
a fresh build of it doesnt fail either... ```
$ ./build/mpy-cross --version
CircuitPython 9.1.0-beta.1-17-g9ab8831d38 on 2024-06-09; mpy-cross emitting mpy v6.1
$ ./build/mpy-cross ~/circuitpython_toml/toml/_toml.py
$
im calling it a day for now, honestly
@spare jacinth the f"{whatever!r}" syntax is not supported in CircuitPython 8.x.
so i needed to run an older mpy-cross?
f"{0!r}"
jepler@bert:~/src/circuitpython_toml$ ./build_deps/mpy-cross-9.x banger.py
jepler@bert:~/src/circuitpython_toml$ ./build_deps/mpy-cross-8.x banger.py
Traceback (most recent call last):
File "banger.py", line 1
SyntaxError: invalid syntax
(build_deps/mpy-cross-* are downloaded when circuitpython-build-tools runs, you may have your own preferred ways of getting mpy-cross)
time for f"{repr(whatever)}" it is, lets see
apparently fixed now, today's bundle update will tell
do i need to make tag/releases each time i make changes, or will it simply look for new commits?
i've been doing them, but would love not to, if they aren't needed 🤣
I'm pretty sure (but not quite 100%) you need to make a release in order for the new version to get picked up by the bundle. If you just make commits and no release I don't think the bundle will "see" the change.
released just in case
bundles use github releases (or at any rate git tags), not branch tips
I'm actually not sure whether it fetches git tags or requests github releases; every release has a tag but the reverse is not necessarily true. creating a release via the github UI is probably the "best" way to mark a new revision of your code as being bundle-ready
that's what i always do
new release -(select tag dropdown)-> create tag on release
Seems like i didnt break the bundle this time, thx for the help yesterday @onyx hinge 😁
Will confirm using circup when i get back from work, but i can at least see a green tick on the action instead of an error 😛
Assets and board-file for Sunton-ESP32-2432S032C.
Note that there is a pending PR for CircuitPython (https://github.com/adafruit/circuitpython/pull/9316) for this board as well.
yay, it did work, however it seems like naming the release and tag as "cookiecutter" was not a great idea, will get back to semver next time i edit anything 🙃
Go ahead and make another release with a good version number.
done
and then go ahead and delete the bad release and then its tag
done aswell
@spare jacinth glad to hear it and happy I could help a tiny bit.
<@&356864093652516868> our weekly meeting is coming up in about 70 minutes, so take the time to add your notes to the document [checked pinned messages for link] & join us in the voice chat at 2PM ET / 10AM PT! I look forward to hearing what everyone is working on.
@dhalbert Is there any documentation on how to use this new wakeup feature?
I'll be joining you in voice in just 3 minutes! thanks for your patience
@dhalbert Is there any documentation on how to use this new wakeup feature in python?
It should "just work". If the HID device sends a report (e.g. a key press) to the host, the host should wake up. This is how a keypress on your regular keyboard works.
Let's re-program some 80s Retro games into MicroPython and run them on a Microcontroller.
Sponsored by PCBWay: https://www.pcbway.com
PCBWay, your ultimate destination for PCB manufacturing and assembly. Whether you're a hobbyist, a startup, or a seasoned professional, PCBWay has got you covered.
💁♂️ For more information on Kevs Robots, tuto...
Creating a Custom RP2040 Keyboard Configuration GUI from Scratch
Get a 0xCB helios here https://keeb.supply/products/0xcb-helios
Get POG here https://github.com/JanLunge/pog
Chat on Discord here https://discord.gg/ctYr5BVF7b
Support me
Either through YouTube or patreon.com/JanLunge
Pog documentation: https://pog.heaper.de/
I think this is another manifestation of #9291, since the temperature reading probably uses ADC functionality.
Thanks for hosting Jeff. Have a great week everyone!
hello all, it's good to be here, I am very new to all things ESP / Coding / etc and am looking for a little advice on how best to get started, I would like a rock-solid foundation to build up as I would like to get to the stage where I can design and build my projects, as I see so many cool projects on the internet / YT etc. I have bought a little adafruit circuit playground express, but if thats too much too soon, i am happy to put that to oneside and start with something else. thanks in advance for any tips or ideas.
I think playground express is a very good starting board, you don't have to use all of its features right away.
Start with blinking a led
Note, the actions on 39d26d66618001a572c80278961b752223aa85ba should not have succeeded.
Viewing them from:
https://github.com/bill88t/circuitpython/actions/runs/9453514997
they appear successful.
It didn't build any boards.
Here is the notes document for next Monday’s CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1QF9nIA7XxxIK3zp6KQ7hVN8nJo3L5HY0ngkQVftxuyw/edit?usp=sharing
CircuitPython Weekly Meeting for June 17, 2024 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you can’t make the meeting and would s...
Is there any reason radio.ap_info rasies a NotImplementedError on a Pico W?
I guess @onyx hinge didn't have the info available?
@willow totem you still up?
and on that topic, @tulip sleet do you see any issue moving the properties like ssid on adafruit_esp32spi to a ap_info class to be the same as native?
I don't specificially remember why I didn't implement it; I'd be happy to see it implemented. an issue can be filed since I'm not likely to get to it right away @short tendon
as usual, we'd have to change any examples or projects
@short tendon might be worth looking at the PR to see if there was any mention of that
the pico w PR?
yes, the one that implemented wifi
And I'm totally happy to update examples for that other change
great - so as usual look in the library and everything in the bundle and everything in Learn_System_Guides
i think you know that already 🙂
Sure do!
I believe this is due to https://github.com/hathach/tinyusb/pull/2253. I'm checking to see how the arguments to tud_hid_set_report_cb() have changed.
@onyx hinge found the PR, looks like it just didn't get done yet? https://github.com/adafruit/circuitpython/pull/6933
er sorry, I meant to look for an issue. Sometimes my brain says PR because in $OLD_JOB it meant "problem report".
Great, thanks for looking into this.
It was more that there wasn't any comments on the PR. I can't find an existing issue
CircuitPython version
Adafruit CircuitPython 9.0.5 on 2024-05-22; Adafruit Feather M4 Express with samd51j19
Board ID:feather_m4_express
Code/REPL
import time
import array
import math
import board
import audiobusio
import usb_cdc
import struct
# Main program
mic = audiobusio.PDMIn(board.TX, board.D12, sample_rate=24000, bit_depth=16)
samples = array.array('H', [0] * 160)
print("Program started. Collecting and transmitting data...")
while Tru...
- Fixes #9306.
https://github.com/hathach/tinyusb/pull/2253 changed the report_type value that is passed to tud_hid_set_report_cb(). Handle this change.
@dtcooper Could you test for your raw HID case? I tested this with keyboard and keyboard LED code, not raw HID. Thanks. The checks Summary page will include build artifacts.
@dtcooper Could you test for your raw HID case? I tested this with keyboard and keyboard LED code, not raw HID. Thanks. The checks Summary page will include build artifacts.
Would be happy to, however having difficultly downloading from the "checks" – I click "Details" but can't seem to find a uf2 image. A direct link for the Raspberry Pi Pico build would help!
I confirm it works on the Raspberry Pi Pico!
dave@tomato:~$ hidapitester --usagePage 0xff00 --usage 1 --open -l 64 --send-output 2,3,4,5 --timeout 1000 --read-input 1
Opening device, vid/pid:0x0000/0x0000, usagePage/usage: FF00/1
Device opened
Writing output report of 64-bytes...wrote 64 bytes:
02 03 04 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...
CircuitPython version
Adafruit CircuitPython 9.0.4 on 2024-04-16; Raspberry Pi Pico W with rp2040
Code/REPL
import wifi
hasattr(wifi.radio, "ap_info")
Behavior
Traceback (most recent call last):
File "", line 1, in
NotImplementedError:
Description
wifi.radio.ap_info was never imlemented on the Pico W
Addition...
#9322 appears to fix the issue. See pull request for more info. :)
Thanks for testing!
@hathach This fixes the issue I asked you about.
However, I am unable to send data through the code above. By adding a timesleep, I am able to send but having a different sample rate.
- Could you elaborate? What exactly fails with the code above?
- Where did you add the
time.sleep()and for how long - What do you mean by "having a different sample"?
- By using the code above on circuitpython, I didn't receive anything from my PC side.
For example
WARNING:root:Expected 320 bytes, received 0 bytes.
2,3. By using
mic.record(samples, len(samples)) data = struct.pack('<' + 'H' * len(samples), *samples) print('something') usb_cdc.data.write(data)
or
mic.record(samples, len(samples)) data = struct.pack('<' + 'H' * len(samples), *samples) usb_cdc.data.write(data) time.sleep(10)
I was a...
However, I am unable to send data through the code above. By adding a timesleep, I am able to send but having a different sample rate.
- Could you elaborate? What exactly fails with the code above?
- Where did you add the
time.sleep()and for how long- What do you mean by "having a different sample"?
- By using the code above on circuitpython, I didn't receive anything from my PC side.
For example
WARNING:root:Expected 320 bytes, received 0 bytes.
2,3. By us...
I someone actively working on the SPI portion of circuitpython_register? Are there any gotchas why it's not a straightforward implementation relative the I2C version?
I don't know that anyone's actively working on https://github.com/adafruit/Adafruit_CircuitPython_Register_SPI/issues/1. I think the short reason why is: adafruit makes a lot more sensors/devices with i2c than spi, so it hasn't been an important goal for them. Secondarily, I'm not sure there's as much standardization around a "register model" in SPI. The most common SPI devices Adafruit sells are TFTs and those are covered by displayio. Second most common might be SD cards and those are covered by sdcardio (or sdioio, where available).
thanks for that, it looks like it should be pretty straightforward though I'm not a big fan of the several levels of abstraction that seem to be in place busio->bus_device->devicedriver->i2c_register, not to mention it seems odd to have a bcd_alarm and datetime builtin
my use case is the TMC4361a SPI stepper controller
Instead of trying to read 320 bytes at once with a 10-second timeout, try reading much smaller chunks, or read with timeout=0.
I am thinking that the reader on the PC side might get out of sync and miss some of the initial bytes. That would make it be out of sync from then on, waiting and waiting, when the microcontroller side has already sent everything. To test this, I would change the microcontroller side to send some known test data, and not do PDMIn for now. Instead, send some packe...
Just tested the first developer beta of macOS 15 Sequoia with an Unexpected Maker Bling board and it's still slow. From the command line, roughly one second per file (tried with three different sets of files) for modestly sized files (like Python source code). Larger files took > 1s/file
The good news is it does work, so they didn't totally break it this time (yet)! Ejecting is also still very slow.
With 24 files:
<img width="545" alt="Screenshot 2024-06-11 at 11 12 46 AM" src="https:...
@romkey Thank you for testing! Do you alreadyhave a Feedaback issue open with Apple about this? I would like to come up with a simple portable test that shows what @eightycc 's OP in this issue shows: slow on 1GB or smaller, much faster above. I tried a multi-volume USB stick but that failed in various ways. It seems difficult to create a disk image of a small size natively on macOS. I just want to make it as easy as possible for them to reproduce the issue.
@dhalbert I haven't opened an issue yet, really should.
I tried putting together a demo of the problem a few months ago and had some issues with it. I'll see if I can find what I had and share it.
I see, thanks! I tested on a Mac and a keypress does in fact wake it up. Side-note: I'm using a Pico W for this project.
My current problem is with waking a Linux host. I've tried the solution explained in the SO post:
$ lsusb | grep Adafruit
Bus 003 Device 018: ID 239a:8120 Adafruit Pico W
$ cat /etc/udev/rules.d/10-wakeup.rules
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="239a", ATTRS{idProduct}=="8120" RUN+="/bin/sh -c 'echo enabled > /sys/bus/usb/devices/usb3/power/wa...
@gitcnd Is it still a draft?
Features of each chip is documented in this spreadsheet: https://docs.google.com/spreadsheets/d/1NyKzHOWeWMb8UttDDugeeOANZ4m-idMHM6kiTlUUVIg/edit?usp=sharing
Fixes #9056
Here are some other apparently related issues. These are about running the ADC tight loops, it appears, that cause watchdog errors. The original test in this issue does 20ms waits between reads, but still has problems.
https://github.com/espressif/esp-idf/issues/12466 (as mentioned by @jepler)
https://github.com/espressif/esp-idf/issues/8753
https://github.com/espressif/arduino-esp32/issues/6549 (same author as 8753)
The BLE workflow will broadcast publicly when the web workflow isn't activated.
This CI will need https://github.com/adafruit/circuitpython/pull/9325. I didn't realize esp_sleep_enable_ext1_wakeup_io was introduced in 5.2.2.
Update: It looks like it was just a matter of getting the devpath correct in the udev rule. I figured out a more rubust way to set the power/wakeup attribute (since the devpath can change between boots):
ACTION=="add", \
SUBSYSTEM=="usb", \
ATTRS{idVendor}=="239a", ATTRS{idProduct}=="8120", \
ATTR{power/wakeup}="enabled", \
RUN+="/bin/sh -c 'echo set attributes for %p >> /var/log/wakeup-device.log'"
The idVendor and idProduct are what I found in lsusb. Not sure if ...
I see it's possible to use wildcards in udev rules: https://unix.stackexchange.com/questions/752425/writing-udev-rules-wildcards, so you could wildcard the idProduct if you need to.
Is it possible to increase the range that the BLE workflow will work for?
Some minor comments. This is still marked "Draft"; did you want to change that?
The _api_password + 1 was pretty mysterious until I looked at the other place the password was fetched.
// Fetch the web api password the same way it's fetched in web_workflow.c.
char _api_password[64];
const size_t api_password_len = sizeof(_api_password) - 1;
os_getenv_err_t result = common_hal_os_getenv_str("CIRCUITPY_WEB_API_PASSWORD", _api_password + 1, api_password_len);
wifi_workflow_active = result == GETENV_OK;
Could you add a **Limitations**: note in the shared-bindings start_advertising doc if the user should know about this?
I hope BLEIO_PACKET_BUFFER_MAX_PACKET_SIZE is always a multiple of 4; otherwise these will be too small.
I think we may have good news! I tested the Metro ESP32-S3 build from PR #9325 (Espressif BLE), but upgrades ESP-IDF to 5.2.2. My test program no longer fails. I put back 9.0.5 and it fails again as usual. This is very encouraging!
There isn't something in the ESP-IDF release notes that points out a fix, but I'll take it :slightly_smiling_face: .
ADC issue in #9291 seems to be fixed by this 5.2.2 update! See https://github.com/adafruit/circuitpython/issues/9291#issuecomment-2161938330
Add a new board Seeed Studio XIAO ESP32C6 from Seeed Studio.
Purchase: https://www.seeedstudio.com/Seeed-Studio-XIAO-ESP32C6-p-5884.html
Pinout: https://wiki.seeedstudio.com/xiao_esp32c6_getting_started/#hardware-overview
Schematic: https://files.seeedstudio.com/wiki/SeeedStudio-XIAO-ESP32C6/XIAO-ESP32-C6_v1.0_SCH_PDF_24028.pdf
Already done testing LED, digital input, Wi-Fi, analog reading, and IIC, but the UART seems a little trouble. More info and .bin file [here](https://github.com/Z...
@lboue I'm planning to build a display controller using this in the next week or so, at which point I'll check all those other features are working properly, pick all the correct naming, maybe write some examples to make it easy to get started, then do the submission.
If you need it now - what I've done so far is good enough to work from. I can post the firmware build if you just want to try it out without the hassle of pulling this and building yourself.
Hello.
Does anyone have a file transfer client library such as ftp/tftp/scp that works with blinka?
do you mean works with Blinka on a Raspberry Pi or other single board PC that runs linux?
Yes, that's right.
In that context you should have access to existing "Normal" CPython libraries and built-in modules. It seems that there is ftplib builtin for interacting with FTP Servers, I've never used it so I can't say much more specific about it, but you should be able to use that from your Python code running on the RPi even if / when that code is using the Adafruit_Blinka library to also interact with other hardware (or whatever it's doing)
This would be something you can only use in that CPython context on a Raspberry pi or other linux computer though. CircuitPython microcontrollers will not have access to this built-in module nor are they likely to work with existing libraries made for normal python.
thank you.
I'll look into ftplib.
This fixes the temperature thing too. It's a complete fix as far as I can tell. Will leave my cardputer running watch -n 0.01 sensors all day.
I merged it downstream to the adc_paranoia branch and it played nicely with massive sample sizes too (65500 samples per poll).
Fixes #9291.
BLE works, perfectly actually, however reloading with the ble workflow connected leads to a crash.
Only tested on ESP32-S3 so far.
Will test on the rest of the chips.
Tried uploading firmware 9.0.4 9.1.0 and 8.2.10....but seems failed at boot....i used thonny....
As in distance? There is a slower phy that should go further but I haven't tried it.
Yeah it mentions "This public broadcast is done at a lower transmit level so the devices must be closer. " in the docs here https://docs.circuitpython.org/en/latest/docs/workflows.html#ble. I've noticed that I don't see my CPB in the list of results from discover if it's on my desk but if it put it down next to my PC cast near the antenna's (which I assume one of is bluetooth, but not certain) then it does show up in the list of devices discovered.
But in my case that is out of reach, so I have to get up and reach over the desk to get it to press the reset button or do anything else.
I guess part of my problem though might be that I haven't got the pairing / bonding process working. Maybe after that it switches back to higher power that is usable from further away?
right, once it is bonded it broadcasts stronger
it is intentional that it has to be close
though we could hack it for your testing if you want
When you press reset button during the blue blinks in order to enable BLE workflow does it ever "timeout" and disable itself? I was finding that sometimes it was disappearing and would come back if I reset twice again. I wasn't sure if that was intended behavior or perhaps just BLE flakiness on my computers part (I was seeing some other weird behaviors with the bluetooth and in the settings window)
While I'm at it, should I maybe add a property for configuring sample size after the object has been created?
As is, the sample size can only be set during object creation like a so:
adc = analogio.AnalogIn(board.ADC_PIN, samples=5000)
I kinda think like adding a adc.samples property would be helpful both for visibility and ease of use.
Also one other question, are the mobile Glider app and this Circuitpython library: https://github.com/adafruit/Adafruit_CircuitPython_BLE_File_Transfer/ the only existing implementations that interact with BLE workflow? I don't have too much experience with BLE generally so I'm trying to find any other existing implementations to look at and learn from.
okay, thank you. Nice I'll look into that one.
kk
I think we were using 5.2.1. We just failed to update this branch.
I'd rather not. Instead I'll file a bug. It should be fixable.
Does this fix #9304?
I haven't tried it. I was hoping @tyeth would test for me. I did fix some issues with characteristic current_value.
Some minor comments. This is still marked "Draft"; did you want to change that?
I was planning on undrafting once the CI is green.
BLE works, perfectly actually, however reloading with the ble workflow connected leads to a crash.
Only tested on ESP32-S3 so far.
I've reproduced this and am looking now. Thanks!
Should get a look at it tomorrow most likely (retesting #9304), but only got an ESP32v2 not s3 this time (away on vacation / working holiday).
Saw this today in a PR build:
mpy-cross-mac
A brownout will take place on June, 8:00 AM – 2:00 PM EST to raise awareness of the upcoming macOS-11 environment removal.
@tulip sleet I can bump the version but what do you think I should choose -- 12, 13, 14 or latest? https://github.blog/changelog/2024-05-20-actions-upcoming-changes-to-github-hosted-macos-runners/
Actions: Upcoming changes to GitHub-hosted macOS runners
we want mpy-cross to be most broadly compatible so should we bump to 12? or is 12 as old in dog years as say ubuntu 20.04 ?
this will also rename the binary so that the name contains macos-12 instead of macos-11 which is likely to cause problems for other sw. 😕 I don't know enough about the mac development environment to know how forwards & backwards compatible binaries are.
(or if the -12 should come OUT OF the binary name as long as we have the pain of change)
Move from 11 (deprecated) to 12 (the oldest non-deprecated)
Because the artifacts formerly had the macos version number in the
mpy-cross binary filename, we have to change the binary name anyway.
Rename it without the macos version (e.g., mpy-cross-macos-x64 instead of
mpy-cros-macos-11-x64)
https://github.blog/changelog/2024-05-20-actions-upcoming-changes-to-github-hosted-macos-runners/
Closes: #9328
I agree on removing the version number. I think 12 is fine, assuming it can run on newer versions. No one has complained about that so I think we're fine. THanks for doing this.
https://github.com/search?q=mpy-cross-macos-11&type=code the mpy-cross-macos-11 name has propagated across around 2 dozen repos 😕
many are just circuitpython forks so that's not terrible
I filed several bugs with various non-fork repos about this.
no idea what's going on with GH actions, some of the PR jobs just fell over with no logs
issue with virtual env and a bad version of filelock
I did a little more testing.
Please, please, please, please, do not enable this for boards without psram.
ESP32-S3 doesn't have the memory for this..
Current main branch: 195k usable
This PR: 125k usable
ble takes 70k. 35% of all memory...
It will break a lot of applications.
If ble has to stay, can we please at least have a CIRCUITPY_NOBLE flag or something like this so that all the memory doesn't get allocated?
Or at least can we check as to if something is paired befor...
Issue here: https://github.com/pypa/virtualenv/issues/2735
This actually PR actually has me sweating bullets rn.
I have never gone from liking a pr to being scared of it so quickly.
We absolutely do need a way to turn ble off.
I'm actually hopping on S2 rn
it's probably going to be not-fine TM, since it has even less ram
oh wait it doesn't have ble
I don't have a C3 with 8MB flash, so I can't test there either
it has 120k usable
so -70k = 50k usable?
calling 50k usable is a bit of a stretch..
If we did have a way to not have this brick in ram unless needed, it would be fine on S3 probably.
C3, no, I don't think so.
Wait does og esp32 have ble too? Huh, well the goes into the same camp as S3.
samd21 has less
💀
but yeah, it seems like there will be a need for images with optional functionality, also for the pico w
@brazen hatch Please add comments to the PR or open an issue. Thanks.
did
For your AnalogIn PR, I will not be merging that in for 9.1.0, in the interest of not generating new churn.
so don't rush
I cannot rush either way since exams are coming up next month.
It's low prio either way since it doesn't fix anything.
I was hoping that the RAM wouldn't be impacted until ble was imported. I'll take a look at it but may want this merged in the meantime.
It may be displayio with the status bar is triggering the import.
One request to remove custom string.
I don't think this enters safe mode. I think it'll enter the bootrom. Please remove this. The default message should work.
Recently micropython dealt with the difficulty of getting the right uncrustify version by creating a micropython-uncrustify package. This looks like it'll install on windows, linux & mac.
we could do mpy-cross the "same way", probably having an mpy-cross- package so that different mpy-cross binaries are co-installable.
then, use this in circuitpython-build-tools, get rid of all the hard coding of download paths in various tools, etc.
just a random brainstorm ..
Looks like we could call esp_bt_mem_release() when ble hasn't been used and we're out of memory. That releases all of the BLE code so bleio can't be used afterwards.
opening a discussion might be appropriate, but I'm not going to do it in haste
mpy-cross-multi seems to be built on various mpy-cross pypi packages like https://pypi.org/project/mpy-cross-v5/ which are not on github (but there is a source distribution on pypi)
Finding nearest RP2040 board cousin for porting my board to CP, based on ext. Flash type
Okay, should be ok now?
Best Regards,
Matthew
I also stumbled across this issue. IMHO, there is a misunderstanding and the CP-documentation is wrong about what VREF is. It is not the maximum measurable voltage as stated by the docs. For many MCU this is the case, but not for all.
ESP32 is one case, the VREF is in the range 1000mV-1200mV, the measurable voltage range is documented in the Arduino docs, see table in https://docs.espressif.com/projects/arduino-esp32/en/latest/api/adc.html.
I also think there should be consistency acr...
Does this fix #9304?
Sorry not yet. Hard fault to safemode (tested on lilygo T-Display S3 which I forgot I'd brought with me). I ran your latest CI assets from this PR.
I can see the values for accelerometer characteristic changing when viewed with Nrf Connect app.
@slender iron do you want to keep debugging in the open BLE PR 9325, or should we merge this and then work on the remaining BLE bugs? If we merge now, then we can merge the sleep PR and people can test that. We'll leave 9.1.0 issues open.
I'd like to merge as-is so I can do the follow up
and you can help with the bugs
that's exactly what I thought. I'll do that now.
Remember we can always follow up with improvements after a PR is merged
It'd be easier to debug this if we had CircuitPython client code that trigger the issue.
moving code from flash to ram as-needed would be super helpful but also really tricky
code is usually assumed to be at a fixed address
its the same thing that'd help rp2040 usb_host and picodvi
@willow totem thanks for testing my BLE PR. Sorry it doesn't fix your issue
Please remove the old comment and run pre-commit: https://learn.adafruit.com/improve-your-code-with-pylint/check-your-code-with-pre-commit
Thanks for removing the message!
Why do we need this file? It looks like boilerplate.
@tulip sleet any idea what's up with this failure? It's affecting my 9.0.x PR, which doesn't touch silabs. https://github.com/adafruit/circuitpython/pull/9329 https://github.com/adafruit/circuitpython/actions/runs/9489365651/job/26153337808?pr=9329
Traceback (most recent call last):
File "/home/runner/work/circuitpython/circuitpython/ports/silabs/tools/slc_cli_linux/slc", line 21, in <module>
from lib.slc_run import _entryPoint
File "/home/runner/work/circuitpython/circuitpython/ports/silabs/tools/slc_cli_linux/lib/slc_run.py", line 24, in <module>
from slc_common import (
File "/home/runner/work/circuitpython/circuitpython/ports/silabs/tools/slc_cli_linux/lib/slc_common.py", line 9, in <module>
from distutils.version import StrictVersion
ModuleNotFoundError: No module named 'distutils'
make[1]: *** [Makefile:170: slc-generate] Error 1```
disutils was removed in python 3.12 right?
yes, that's right
oh did "python-version: 3.x" change recently to be 3.12?
yes, but not yesterday or anything
it was a while ago
i'll look at the beta.3 build
Python 3.12.4 (main, Jun 7 2024, 19:06:40) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils.version import StrictVersion
```huh that import works in the python 3.12 docker image, oddly enough.
https://github.com/adafruit/circuitpython/actions/runs/9376811190 (last 9.0.x build was successful on june 4) OK, so, a 9.0.x build doesn't build all platforms, just what it guesses is affected via scheduler. My PR built all platforms because it changed a workflow yaml file.
beta.3 used 3.12.3. They might have updated the build p[latform and distuilts is no longer in the system image. You could try adding it requirements-dev.txt
@tulip sleet do you want me to try that in my PR? since it'll demonstrate the problem, I think
2024-05-22T14:56:34.000Z 637.2 kB adafruit-circuitpython-explorerkit_xg24_brd2703a-en_US-9.0.5.bin
last build of silabs explorerkit for 9.0.x was weeks ago
Runner Image
Image: ubuntu-22.04
Version: 20240516.1.0
Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20240516.1/images/ubuntu/Ubuntu2204-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240516.1
in 9.1.0-beta.3 build
Runner Image
Image: ubuntu-22.04
Version: 20240609.1.0
Included Software: https://github.com/actions/runner-images/blob/ubuntu22/20240609.1/images/ubuntu/Ubuntu2204-Readme.md
Image Release: https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240609.1
in the failed build ^
I don't see distuils explicitly, but various tools were updated and maybe distutils is no longer installed as a dependency somewhere
it might fix the problem, until silabs makes their stuff more up to date
I'll give that a try
This plays mp3s off https now, about as well as non-https
Awesome! Looks good to me.
Will this be fixed under the next beta release? 9.1.0-beta.4 or 9.1.1 or whatever the next release will be?
You can download the "Absolute Newest" build from the downloads page for your board.
That will have the fix, along with any future 9.1.x releases.
Will this be fixed under the next beta release? 9.1.0-beta.4 or 9.1.1 or whatever the next release will be?
Yes, and it is already fixed in builds with PR3925 in the filename or later. Download from https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin
PR9325, not 3925
You can download the "Absolute Newest" build
Oh ya, totally forgot about that link on those pages. Duh! Thanks.
@slender iron the Unicode for the BLE heart rate monitor I think may be related to the other characteristic errors. It is not the HRM itself: it's trying get the manufacturer string from the DeviceInfoSerivce.
... it's getting the manufacturer characteristic, but the value is a long bunch of garbage.
hey scott, do you mean with the circuitpython client code that you want to recreate with something instead of bluetooth web dashboard? I think it just subscribes (excuse my terminology) to the notify Accelerometer characteristic, and immediately then changes the notification period to 500ms. I half read recently there was a much lower recommended threshold, like 8-2xx ms, but can't remember if that was nrf related or where it was. No idea what the code would look like for circuitpython client BLE stuff, but might have a go anyway as the examples were fairly informative. I'm not able to get on device right now, probably tomorrow night or over the weekend.
The Adafruit project page should probably also be updated to indicate that there is CircuitPython support but I don't know how to make that update.
Hi! I've been very slowly working on getting this ESP32 added, got a question about the onboard neopixel: The color order is GRB for whatever reason, and I added what I thought was the appropriate way to mitigate that here: (direct link to the line https://github.com/adafruit/circuitpython/pull/9274/files#diff-5afc6bbdd15add58d62e8e910fa425b7a0685267148ab24980173d54acf15da4R14) but when I try setting the color in a sample in code.py, the color order is still off. Does that line that I linked to only affect the status light that CircuitPython uses to indicate statuses (i.e., blinking green when the code finishes without error, or yellow for safe mode) (answered my own question, yes).
Is there any way to make the color order behave as expected for code in code.py, or should I just document what the correct color ordering is in the description of the board?
you should just document this. The order is defined by an argument to the NeoPixel constructor, and no other code knows the order (including the neopixel_write module, which is what is used at a lower level.
Tested with the most recent firmware built by the CI and everything seems to work properly.
Something to note about this board is that the onboard NeoPixel has the color ordering of GRB. CircuitPython's status LEDs will still work as expected because of this line, but the color order will need to be set when writing CircuitPython code for this board.
The Adafruit project page should probably also be updated to indicate that there is CircuitPython support but I don't know how to make that update.
Add the product URL under board_url:
@slender iron are you really on, or are you busy packing, etc.?
i have a diagnosis of the Characteristic read problem (maybe you already figured this out)
Reading the characteristic works in 9.0.5 and earlier. common_hal_bleio_characteristic_get_value() hasn't changed. It has this code.
CHECK_NIMBLE_ERROR(ble_gattc_read(conn_handle, self->handle, _read_cb, &read_info));
int error_code;
xTaskNotifyWait(0, 0, (uint32_t *)&error_code, 200);
CHECK_BLE_ERROR(error_code);
return read_info.len;
It does the ble_gattc_read(), waits 200 ticks, and then returns. in main, 200 is not enough time, 2000 works. We changed the ms per tick from 10 to 1 in https://github.com/adafruit/circuitpython/pull/9134. So any ticks-based wait needs to be *10. And it shouldn't be ticks anyway, it should be ms. I will start with this and keep debugging the other problems.
Sorry @makermelissa, I thought I was being clever and skipped re-reading the instructions. Hopefully this is what you need 😁
Is there any trick to, or information about the Service Discovery process during BLE workflow connection? I have tried a few different ways to use bleak python library to make a connection to a CPB that has been reset twice to enable BLE workflow but thus far my script is always crashing when I try to connect. It seems that upon connection bleak is attempting to run service discovery, but the device is immediately disconnecting instead of allowing that to happen bleak.exc.BleakError: failed to discover services, device disconnected
I got that error when trying to use bleak directly, and when using https://github.com/adafruit/Adafruit_CircuitPython_BLE which is using bleak internally with Blinka bleio I believe.
This also adds a new dependency on setuptools, needed for the silabs port when using python 3.12 and newer, which removed distutils
are you trying this on Espressif or on nRF? Try it on nRF first.
All testing on nRF. Circuit playground blue fruit specifically
try an older version that has BLE workflow, in case something has been broken. Which OS?
I tried 8.2.10 as well but same results. I can get successful connection to the same device with code circuit python org and glider so I think it's okay on the device side just bleak doesn't seem to play nice
Going to bed for now
goodnight! The bleak version is important. I haven't tested with later than the version pinned by blinka bleio
it's quite out of date
and might not work on newer OS versions
CircuitPython version
Adafruit CircuitPython 9.1.0-beta.3 on 2024-05-22; FeatherS3 with ESP32S3
Code/REPL
import time
from adafruit_ble import BLERadio
from adafruit_ble.advertising.standard import ProvideServicesAdvertisement
from adafruit_ble.services.nordic import UARTService
from adafruit_ble.uuid import StandardUUID
from adafruit_ble.services import Service
from adafruit_ble.characteristics import Characteristic
from adafruit_ble.characteristics...
Ah~ I got it. The pre-commit is OK now.
which binary do you suggest to flash on this board?
it is still not listed in the downloads page.
This PR is pretty much ready, it just need testing.
Please refer to the opening comment.
I will test on nordic and atmel-samd when I have some free time.
it looks like bleak isn't currently pinned to a version that I can see. https://github.com/adafruit/Adafruit_Blinka_bleio/blob/main/pyproject.toml#L29 and here: https://github.com/adafruit/Adafruit_Blinka_bleio/blob/main/requirements.txt#L6 are the only references I found.
You're right, I had pinned it, but then removed the pin here: https://github.com/adafruit/Adafruit_Blinka_bleio/pull/58/files#diff-4d7c51b1efe9043e44439a949dfd92e5827321b34082903477fd04876edb7552. So maybe never mind about that. What os and version are you using?
Bleak has to keep up with a lot of churn in host OS's, especially on macOS, but Windows has been a problem too.
The commit message for this https://github.com/adafruit/Adafruit_Blinka_bleio/commit/a15a1e7e05c819de093b4891e65e4736cc7569eb mentioned support 0.19.0 and up and the change itself was removing the pinning of 0.11.0
I do think the two versions of bleak I tried were newer than both of those though. I tried 0.22.2 and I think 0.20. something, but I'm not certain of the minor digit.
I am on Linux (Ubuntu)
I tested with 0.20 and it was OK in the past: https://github.com/adafruit/Adafruit_Blinka_bleio/pull/58#issue-1651163274
I will go back to something in the 0.20 range when I get back to it.
Have you ever used bleak to connect with the BLE workflow? I wondering if there may be some incompatibility between them (or at least with the way I am trying to connect)
no, I never tried that
You mentioned some things about timeouts in that PR as well. When it does fail for me it's almost instantaneous upon trying to connect I think. I'll try to validate that with additional logging and see if there is anywhere I can try increasing it.
I am testing the Espressif BLE stuff now and having to do hard resets sometimes after an error. The persistence needed for the workflow may be causing it to stay in a bad state sometimes, but I'm not sure about that.
I am not testing workflow yet at all. There are other things to fix.
I do think I've seen issues with the persistence of it as well. I have not pinned it down to a specific pattern just yet, but it does keep "disappearing" from the scan list and I can get it to re-appear by another 2x reset of the MCU, and a few times I've had to toggle off / on the BLE on my computer as well because it refused to even find it in the scan anymore, but did after that power cycle of BLE.
@onyx hinge thanks for the heads up on the mpy-cross thing
By the way, I have been away from CP things for a few months, for various reasons, but I plan to come back and get up to date on things soon hopefully
You're welcome! And of course, when you're able to come back to the community we'll be happy to see more of you!
which binary firmware do you suggest to flash on this board?
it is still not listed in the downloads page.
EDIT: the board seems to have wifi issues with the Esp32 firmwares i've tried (not from circuitpython) . Not sure if it is fixable at firmware-level.
According to @mirkokral above:
UPDATE: Looks like if i use the Adafruit Feather HUZZAH32 board it works like a charm. Should i close or not?
CircuitPython version
CircuitPython 9.0.5
Feather RP2040
Code/REPL
import storage
# Remount the filesystem as writable with concurrent write protection disabled
storage.remount("/", readonly=False, disable_concurrent_write_protection=True)
Behavior
Still seeing drive mounted as read-only when laptop is rebooted, but Feather is powered from USB hub.
Description
In this case the desired behavior is to override the write_protection so de...
It's now possible to use the core ssl module with sockets implemented in Python (#8954); this actually works with wiznet. However, nobody's checked whether this actually works with airlift; it might require changes in the airlift socket implementation to correctly align with the standard socket. If it doesn't, the esp32spi github repo is probably the right place to open issues.
Additionally, few or no builds for board with an airlift include the core ssl module. If there are combos for whi...
Can you please leave both URLs? It's a list, so it can have multiple URLs like this:
board_url:
- "url1"
- "url2"
Leaving this open as it's not resolved by #8954: Using read/write/ioctl "protocols" is a possible enhancement to the existing ability to use wiznet sockets. In particular, "ioctl" is needed to make select.poll (& therefore asyncio) work properlyl
Is the remount in boot.py? Could you check boot_out.txt and see that no errors were written there?
By having both, we can use the data in other ways in the future.
Also please try 9.1.0-beta.3.
sklarm@grazie CIRCUITPY % cat boot_out.txt
Adafruit CircuitPython 9.0.5 on 2024-05-22; Adafruit Feather RP2040 with rp2040
Board ID:adafruit_feather_rp2040
UID:4545373038057E2C
boot.py output:
I will try 9.1.0-beta.3.
same same w CircuitPython 9.1.0-beta.3
initial state (rw on CIRCUITPY)
sklarm@grazie CIRCUITPY % cat boot_out.txt
Adafruit CircuitPython 9.1.0-beta.3 on 2024-05-22; Adafruit Feather RP2040 with rp2040
Board ID:adafruit_feather_rp2040
UID:4545373038057E2C
boot.py output:
sklarm@grazie CIRCUITPY % mount | grep CIRCUITPY
/dev/disk4s1 on /Volumes/CIRCUITPY (msdos, local, nodev, nosuid, noowners)
disconnect laptop (or reboot or power off):
sklarm@grazie CIRCUITPY %...
I just looked at your linked forum post and it looks like you're using a powered USB hub? If that's the case, I'm wondering if the CircuitPython device is simply not restarting when you're rebooting the laptop. The boot.py wouldn't re-run in that case and perhaps the storage.remount command needs to run after the OS initially mounts the drive.
boot_out.txt
Adafruit CircuitPython 9.1.0-beta.3 on 2024-05-22; Adafruit Feather RP2040 with rp2040
Board ID:adafruit_feather_rp2040
UID:4545373038057E2C
boot.py output:
import storage
# Remount the filesystem as writable with concurrent write protection disabled
storage.remount("/", readonly=False, disable_concurrent_write_protection=True)
# SPDX-FileCopyrightText: 2021 Kattni Rembor for Adafruit Industries
# SPDX-License-Identifier...
CircuitPython version
Adafruit CircuitPython 9.1.0-beta.3-29-ged5591c5cb on 2024-06-14; NodeMcu-ESP32-C2 with ESP32C2
# Aka latest as of the time of writing
Code/REPL
# Wifi creds & web-workflow passwd set in settings.toml
# No code.py
Behavior
Crashes into safemode, then crashes again since wifi-autoconnect and web-workflow run even in safemode.
The board cannot be stopped, since neither wifi-autoconnect nor web-workflow check for keyboard in...
Removing the version name from the file itself but not the folder isn't ideal.
I know there is a macos folder already, but can't that be renamed to something else so that macos is used for this?
Yes, both @b-blake and I are using powered USB hubs so the controller continues to run when the attached PC goes away.
Everything works as expected when the Feather RP2040 is reset. Things don't go well when the PC goes away and comes back. It is either read-only mount or no mount of the CIRCUITPY drive.
Thank you for working this out. I won't merge in case we want to stage this with other PR's that will adjust the names and paths accordingly.
Would it be possible / super difficult to have a way to specify the brightness of the startup RGB led blinking? Specifically the Red, Yellow Blinks, Blue blinks / solid on the nrf devices is what I am interested in making dimmer.
you mean per board? One issue we've had is that the brightness of different RGB leds we've put on boards has varied between board runs
I my mind a setting inside of settings.toml or something inside boot.py that configures the brightness would be ideal so that the user could set it to whatever they're comfortable with based on the LED on their device + their environment.
I don't know if having it be dynamically setable like that is feasible, or worth the space it might take though.
but you are talking about pre boot.py.
how's the brightness in the UF2 bootloader? Maybe we should match that
the bootloader brightness does seem like a better level. Quite a bit less piercing than the circuitpython startup blinks to my eye on a Circuit Playground Bluefruit.
it's difficult to compare for certain since the bootloader is more steady instead of blinks from on to off. But to me the yellow and blue blinks during startup are entering uncomfortable territory.
minor little issue and PR (plus a bonus for the issue number?) for y'all to look at https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_SSD1306/issues/42
reviewed, merged and released
CircuitPython version
Adafruit CircuitPython 9.1.0-beta.1-24-g24f2e4f994 on 2024-05-18; S2Mini with ESP32S2-S2FN4R2
and
Adafruit CircuitPython 9.1.0-beta.3-28-g03e42a8c0c-dirty on 2024-06-15; AButton V3 with ESP32
and
Adafruit CircuitPython 9.0.5 on 2024-05-22; S2Mini with ESP32S2-S2FN4R2
Code/REPL
Connecting to my cpy boards delivers the "welcome!" screen. They include a "serial terminal" [sic] link which is a websocket (not serial) connection to the ...
I don't think there's anything we need to take care to do at the same moment. Until changed, for example, circuitpython_build_tools will always use mpy-cross from 9.0.0-alpha.2 (!) for creating its 9.x mpy files.
If we can drop 8.x from circuitpython_build_tools at the same time as we add 9.1 or 10, we can change it then to simply use the new path. If we need to keep 8.x support we'll need to add some version dependent checking for the mpy cross location. but I think this can all be handle...
Hey Dan, Still testing. I have JP project working on a nRF52840 with the sound files from JP project. Still no luck with using an RP2040. Waiting on some other feathers to try when they come in. Thats what I get when I use the US Postal system. but it gets here. UPS has lost to many of my orders.
Thank again. I'll try changing the bit rate down. I would not have thought it would stop the directory display of the SD card but what do I know.
Have a super week..
Dale
______________...
Appreciate everyone's help, but I am still experience problems. Back to the Wavershare S3 Zero board, I downloaded adafruit-circuitpython-waveshare_esp32_s3_zero-en_US-20240613-main-PR9325-03e42a8.uf2 and installed it. Did it a couple times due to still having problems. The boot_out.txt reads:
Adafruit CircuitPython 9.1.0-beta.3-28-g03e42a8c0c on 2024-06-13; Waveshare ESP32-S3-Zero with ESP32S3
Board ID:waveshare_esp32_s3_zero
UID:437BAD9541C4
There is a more recent version by o...
Sorry to hear that. Which pin are you using, and do you know whether it's an ADC1 or an ADC2 pin? The UF2 you're downloading is correct. PR's (pull requests) are not merged in order so the order is not significant.
D7 & D8 so IO7 & IO8 which go to GPIO7 & GPIO8 of the S3 (fortunately Waveshare kept numbers the same on the board vs the ESP32) which according to the datasheet for the ESP32-S3 is ADC1
(cut & pasted)
ADC1_CH6 GPIO7
ADC1_CH7 GPIO8
My full code that I running at this moment where I am seeing this is...
`import gc
import time
import board
import neopixel
from random import randint
import busio
import displayio
from fourwire import FourWire
from adafruit_st7789 import ST7...
Using main (after #9325):
Run ble_uart_echo_test.py on an nRF52840.
Run ble_uart_echo_client.py on a Metro ESP32-S3.
Traceback (most recent call last):
File "", line 1, in
File "ble_uart_echo_client.py", line 36, in
File "adafruit_ble/__init__.py", line 316, in connect
_bleio.BluetoothError: Failed to connect: internal error
This works on 9.0.5. I am debugging this.
Testing on main (after https://github.com/adafruit/circuitpython/pull/9325):
Run ble_heart_rate_simpletest on a Metro ESP32-S3. Does not work on 9.0.5 either.
Fixes and diagnoses already done:
xTaskNotifyWait(0, 0, (uint32_t *)&error_code, 200);used several times.200is ticks. We changed ticks from 1 per 10msecs to 1 per msec in #9134. I changed to usepdMS_TO_TICKS()to make it tick-length independent.- xTaskNotifyWait() above may return
error_codeBLE_HS_EAGAIN, whi...
this wouldnt allow to have multiple deviced having different names right ?
from my understanding thats where the VID (vendor )and PID (product) parts come in
if i would like 4 devices with different names i would need 4 unique PID's
still under same vid/pid so its for all the devices then
@MariuszCwikla you think we could do something with the pid and vid some how to make devices unique for local machine
No, there is only one VID/PID, becuase there is only one device presented.
No, there is only one VID/PID, becuase there is only one (composite) device presented.
i found it in mpconfigboard.mk of my board thank you
Waveshare has a ESP32-S3R2 based board that has a SIM7670G-4G Cellular modem. It seems to share many elements with Waveshare's ESP32-S3-Pico board. They both have 2MB PSRAM and 16MB of flash memory. Wiki page for the ESP32-S3-SIM7670G is here.
The pin mapping appears different from ESP32-S3-Pico but I can't identify the relevant pins from the [pinout diagram](https://www.waveshare.com/img/devkit/ESP32-S3-SIM7670G-4G/ESP32-S3-SIM7670G-4G-...
The display is 240w x 320h. We could swap the width and height, or rotate it by 270 degrees.
Question on where to put some request based methods:
For HTTP_AIO, a method is needed that will send base64 encoded data to a AIO webhook endpoint.
To do this, requests will need to be able to handle a file object (easy).
But we also need a wrapper that will do the encoding, let's call it Base64FileEncoderStream. My question is where does that class live? I can imagine people wanting to use it outside of HTTP_AIO, but it feels strange to put it in requests...
thanks a lot Dan i was already almost done making custom builds in github ci..
how can i not have seen that ...
my solution
from hid_gamepad.simple.boot import gamepad_descriptor
import usb_hid
import supervisor
# Define custom VID, PID, product name, and manufacturer
CUSTOM_VID = 0xDDFD # Non-registered VID
CUSTOM_PID = 0x5050 # Non-registered PID
PRODUCT_NAME = "SUNSHINE"
MANUFACTURER_NAME = "Good mood"
# Set USB identification
supervisor.set_usb_identification(vid=...
CircuitPython version
Main branch (see commit ids below) on espressif_esp32s3_devkitm_1_n8
Code/REPL
import busio, board
import displayio
displayio.release_displays()
# The issue is reproducable whether there is something connected to these pins or not. The exact pins used here also don't matter.
spi = busio.SPI(board.IO5, board.IO4, None)
display_bus = displayio.FourWire(spi, command=board.IO3, chip_select=board.IO2, reset=board.IO1)
print("\nDone ...
This is more of a RFC than a ready PR.
I made an initial version of a fix for https://github.com/adafruit/circuitpython/issues/9305, making microcontroller.cpu.frequency settable on espressif boards. I followed micropython's implementation of the same feature.
Question 1
This requires enabling CONFIG_PM_ENABLE in esp-idf, which is allows for a uniform API (se...
IMO I think it should be outside of requests unless CPython requests has the that functionality too. Maybe we make a circuit python implementation of https://github.com/aws/base64io-python if I'm understanding correctly that looks like a similar component, maybe there is some chance that will even work on Circuitpython already, I have not tried it.
@tannewt Please let me know if there are any concerns with this PR.
It's similar. Looking it wouldn't port over directly. Also if the goal is light weight would probably build out something smaller.
But I agree it shouldn't be in requests.
I'll get everything working locally and then figure out what PRs to open.
Can Adafruit libraries depend on community bundle libraries?
Can Adafruit libraries depend on community bundle libraries?
No, not right now at any rate. Besides the question of whether we want that or not, the "bundlefly" system that builds downloads for learn.adafruit.org doesn't know about other bundles and can't fill requirements from the community bundle.
Removing the error message and instead just jumping to the nearest frequency is also possible to save space.
cpu.frequency = 220_000_000 sets it to 240Mhz.
cpu.frequency = 190_000_000 sets it to 160Mhz.
However this approach would not really work for overclocking.
Gotcha
What would people think about creating Adafruit_CircuitPython_Stream and moving adafruit_json_stream into there and adding adafruit_base64_stream to it?
they don't seem super related to me, other than being related to streams
I think the general preference is to have separate small libraries, because then it's easier to fit only the needed ones on resource constrained boards
Makes sense. Although, you can always remove the mpy files you don't need.
Once I get everything working will make PRs and such and see what people think
@CDarius it looks like you contributed this board in #7113 and #7144, are you able to check and confirm whether it's working for you?
I think MicroPython is doing asyncio http already. Where did they do it?
This is working for me, on Matrix Portal S3, in both the latest Firefox and Chrome, on Linux. I can click Send or press enter.
Tried pressing btn A (9.0.5 9.1.0 and 8.2.10) no avail and notice that the power button seems not functioning ON OFF function....
Even trying to turn ON/OFF the display has a bit of background light......
I'm away from home for a couple of weeks, I can't make any test at the moment
What are the first things to disable to save flash compile size? I'm trying to get a debug build for the C6 4mb flash with BLE, but even disabling DISPLAYIO and FRAMEBUFFERIO wasn't enough. Are there any other large obvious ones?
CIRCUITPY_ULAB
I had not thought about ULAB. While I don't currently have a space issue I am curious to determine the size different. Thanks.
for future fun followers, the build flags I've gone for: (I'm aware one framebuffer is wrong)
CIRCUITPY_DISPLAY_LIMIT=0 CIRCUITPY_DISPLAYIO=0 CIRCUITPY_FRAMEBUFFERIO=0 CIRCUITPY_FRAMEBUFFER=0 CIRCUITPY_ULAB=0 CIRCUITPY_SYNTHIO=0
Got 9k left and a debug build for the c6 4mb, score!
(Versus 179k over) See here for some other flags: https://docs.circuitpython.org/en/latest/docs/porting.html#porting
However, not all ports are fully functional. Some have limited limited functionality and known serious bugs.
@dhalbert;
Is the remount in boot.py?
Could you check boot_out.txt and see that no errors were written there?
There is no remount in boot.py
There are no errors in boot_out.txt
This is the output of CircUp.exe this morning from my Windows 10 PC after having it off all night. It was the first thing run at boot-up. If you want specifics about any device. please ask.
` Volume in drive C is Windows SSD
Volume Serial Number is B984-5BB6
Directory of C:\Users\Bruce\AppData\Lo...
Blocking delays are observed when setting duty_cycle in the samd port of CircuitPython (see https://github.com/adafruit/circuitpython/issues/7653), behavior which interferes with some applications of PWM, and which differs from from that of other ports. Investigation of this issue revealed another problem: In some cases, the API will round a non-zero duty cycle down to zero, causing the PWM signal to stop cycling at all. The changes proposed in this PR address both of these issues.
De...
@slender iron I may be a bit late to the meeting please read my hug reports if I'm not there in time (but I most likely will be)
kk
<@&356864093652516868> We'll have our weekly meeting in about 5 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/1QF9nIA7XxxIK3zp6KQ7hVN8nJo3L5HY0ngkQVftxuyw/edit -- I look forward to everyone's updates!
CircuitPython Weekly Meeting for June 17, 2024 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you can’t make the meeting and would s...
Thanks
Thanks All 😁
@lone axle I think that this is the specific protocol change that scott was mentioning. the listDir respose changed from a list to a dict with a "files" entry... https://github.com/circuitpython/web-editor/commit/3aab78cb02c2d0f87a7177a65124a29e206c25b6?diff=split&w=0
Thanks for hosting Scott, have a great week everyone!
thanks @slender iron !
oh, hm
I don't have a specific change in mind. I just know the library got most of its use as the protocol was being developed
yeah nevermind
Thank you anyhow. I'll dig and compare the web and mobile app implementations with the library. I was able to use both web and glider successfully so they've got whatever is needed to get it working.
Once I get it worked out I'm hoping to add more specific info to the documentation. Today it's mostly just a pointer to the file transfer library. The web workflow implementation has lots more specific documentation available.
now I'm sweating it that I can't find the bluetooth listDir implementation in that repo. where is it?
I believe it gets linked in from here: https://github.com/adafruit/ble-file-transfer-js/blob/main/adafruit-ble-file-transfer.js
it imports here: https://github.com/circuitpython/web-editor/blob/a0f4b7c78493a6baa13c3f0a87de46c55216fb8b/js/workflows/ble.js#L5 and I found reference in the package.json file pointing to that other repo.
ah thanks, it was going to bother me
Did you read the readme: https://github.com/adafruit/Adafruit_CircuitPython_BLE_File_Transfer?tab=readme-ov-file#protocol
No, I missed that, I guess I never scrolled enough on the repo page. Thank you. I wonder if it's possible to dynamically include that here: https://docs.circuitpython.org/en/latest/docs/workflows.html#file-transfer-api
It is separate because my intention was for it to be more general than circuitpython
You could change the CP link to go to that bullet point
Here is the notes document for next Monday’s CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/144fIOxqiH-xJLrzGLr7FSjrF0y5hylkiNM5iMPc7vpU/edit?usp=sharing
CircuitPython Weekly Meeting for June 24th, 2024 Here is the notes document for next Monday’s CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable t...
I got a bit further along, watching BLE traffic in wireshark I saw that code.circuitpython.org BLE workflow implementation sends the listdir command "header" in one write, and then in a subsequent write packet sends the path that it wants to list.
The ble_file_transfer library seems to write only a single packet with the path appended to the end of the header section.
After changing to use two subsequent write operations I can see in wireshark now that the device is sending back all of the information about files in the directory, however the code inside blinka_bleio / ble_file_transfer library is still seemingly stuck in an infinite loop trying to read. It doesn't seem to be actually "seeing" the data that I know (from wireshark) is being sent.
the basic version characteristic read succeeds and gets proper data, but the more complex transfer characteristic read is just looping forever never seeing any data. My best guess is it's something with bleak, blinka_bleio causing trouble. I've tried a few versions of bleak but no luck so far.
I did actually get the MCU to MCU one working with two nrf52840s though so I am no longer having the same infinite loop issue on the microcontroller side. It's successfully completing the listdir.
I'm going to try removing blinka_bleio and ble_file_transfer library from the mix for now and just try to get some code that uses bleak to read and write characteristics directly. I manually prepared the list dir command and am able to see that I got back some real data, I'll just need to parse it more manually without the helper library for now.
@lone axle are you doing a read instead of subscribing to notifications?
With the manual one I did use a read, not notifications. With the blinka bleio / file_transfer lib I'm not sure how it does it internally
I changed the manual code to subscribe for notifications and use a callback to receive them. Thanks for the pointer.
Hmm, I seem to be getting duplicated callbacks, every two callbacks to the notification subscription contain the same data.
I've seen a variation of that in a completely different context. I had managed during copy, paste, debug stuff to subscribe the same callback twice.
I went down that train of thought as well and added print("calling start_notify") just before I use start_notify() to register for the callback. As far as I can tell the register is only happening once.
I thought maybe it could be related to using two different write commands, so I changed that back to a single write and I still get the duplicate callbacks. But it is actually sending data in the callbacks so now that is working successfully in with the single write.
I think I've got the basic bits needed to make it work with bleak directly so I'm going to head that direction for now.
It's possible there is something in the adafruit_ble, blinka_bleio, or adafruit_ble_file_transfer layers that is leading some different behavior when using adafruit_ble_file_transfer on a PC vs. MCU. I don't have a clear idea where to look within those libraries to start tracking down the difference.
Hey devs!
Unfortunately, I've had to migrate away from CircuitPython for my current project (interpreter too heavy), but I was hoping someone could help me ID where in the source code certain file system behavior lives?
I'd really like to implement a refresh-on-modification feature. Specifically, file system modification causes (soft) reset. And I'd like to do it close to bare metal. I think CircuitPython handles it well and I'd love to use it as a reference. Sadly, my lack of experience is making that functionality hard to find in the source code. Anyone have a pointer they'd be willing to share?
Thanks a million,
- Finn
the function autoreload_trigger (in supervisor/shared/reload.c) may let you start to get a handle on how the functionality works. basically, it's called from shared/usb/usb_msc_flash.c when the drive content is changed; it has a timer that is intended to wait for the drive activity to quiesce, then it initiates the reload reload_initiate(RUN_REASON_AUTO_RELOAD). Elsewhere in the code this occurs as a Python exception that is ultimately handled by tearing down and restarting the interpreter (top level main.c)
Thank you very much Jepler!
This makes a huge difference - I was trying to grep for what I assumed were relevant keywords and hit a point where "There has to be a better way!"
I appreciate it a lot, have a great day.
dont cross-post questions next time 🙂
Apologies, won't do it again. For future questions, which channel is more appropriate?
im not sure, but definitely stick to a single one
probably fine to ask on either one
Will do, thank you.
Thanks for the thorough testing and fixes.
I think the tools/pwm contents would be better hooked up in docs/ so that it ends up on docs.circuitpython.org OR as an Adafruit Playground writeup. In tools, it won't be very discoverable.
You can make the docs.cp.org contents with make html at the top level. It ends up in _build IIRC.
this one seemed right for your question
since it is about circuitpython internals
@tulip sleet S3 is waking up immediately. I'm looking into it
may be correct because I'm not requesting a pull
false alarm. works once I set pull
Tested on Feather ESP32-S3 No PSRAM and it works. (I thought it didn't because I hadn't set pull.)
I managed to read and parse the full listdir response 🎉. The data buffering ended up different from adafruit_ble_file_transfer, and there is probably room for improvement. But I was able to take some of the struct un-packing and logic in the reading / parsing loop from adafruit_ble_file_transfer and put into this script that is using bleak directly.
(Personally I would prefer option 1, as the code would be more maintainable than with option 2)
Option 1 sounds good to me.
Question 2
I think it makes sense to inform the user about the possible frequencies that can be set, as there are not many valid ones (e.g. 20, 40, 80, 160, 240 MHz for the original ESP32). For now I created a (rather long) new error message for each esp variant containing the valid frequencies, which is consistent with the settable frequency for `po...
The previous implementation would always start BLE and rely on advertising logic to make the workflow not available when on USB.
This change removes the "always enable" call in favor of a default value that is on if 1) we determine we should be discoverable or 2) we're already bonded over BLE.
@bill88t This should improve the RAM impact of BLE workflow. It won't match 9.0.x though because of the BLE related code in IRAM.
The board addition guide is the right place to start. Discord is a good place to ask for help implementing it.
What browser are you using? Are there errors in the browser's developer tools?
C2 support isn't a priority for Adafruit funded folks.
Yup! Looks good. Thanks!
Seems fine to me. Thanks!
I have good news and bad news.
Good news first, from a quick test, this seems to bring back the ram usage back to normal.
It won't match 9.0.x though because of the BLE related code in IRAM.
I entered an optimization frenzy and now I'm at a net-negative ram usage.
Bad news, brings back #9291.. somewhat.
It no longer produces a crash.
The IO clock or whatever it's called is just slowing down instead of the system clock.
This means, the neopixel goes white (wrong frequency), ...
I have an irk that's it's also affecting esp32 (og)
I need to test a bit more
I hopped between builds a couple times now
Ahh - you use the IP address, right?
Try again using the DNS name:
http://cpy-eaf90c.local/cp/serial/
I notice it works with the IP address, but not with the name.
I'm using Chrome on Windows; windows does properly resolve mdns so the web page at http://cpy-eaf90c.local/ loads and works fine, but not the /cp/serial/ part.
ymmv with ubuntu; I never figured out how to get that understanding mdns (at least not in WSL anyhow)
update - I notice it intermittently returns some parts of what got sent, after a multi-minute delay, if you leave the browser open for a long time.
It works fine for me with both IP and cpy-nnnn.local names. I'm assuming your browsers are up to date. I've tested with all three operating systems. My LAN is running on a Verizon FIOS router.
Have you set the DNS server for your OS's to be your router (e.g., 192.168.x.x) or have you set DNS to directly go somewhere else, such as 8.8.8.8 (Google)?
Are you running a code.py that is doing something? If so, try removing code.py and see if it makes any difference.
CircuitPython version
Adafruit CircuitPython 9.1.0-beta.1-24-g24f2e4f994 on 2024-05-18; S2Mini with ESP32S2-S2FN4R2
and
Adafruit CircuitPython 9.1.0-beta.3-28-g03e42a8c0c-dirty on 2024-06-15; AButton V3 with ESP32
and
Adafruit CircuitPython 9.0.5 on 2024-05-22; S2Mini with ESP32S2-S2FN4R2
Code/REPL
Same as issue https://github.com/adafruit/circuitpython/issues/9336
Behavior
Using the name (e.g. http://cpy-eaf90c.local/code/ ) instead of IP ad...
Thanks for the merge! Hope can see the board alive on the Downloads Section on you guys websites.:)
Best Regards,
Matthew
Thanks for fixing this, and doing the detailed differences between the chips. This might be docuumented in shared-bindings in a Limitations: section, but we don't have to do that now.
code.py is default.
http://cpy-eaf90c.local/ loads and works fine.
http://cpy-eaf90c.local/cp/serial/ does not work properly.
Nor does the serial console from http://cpy-eaf90c.local/code/
both works OK as an IP address only.
Regardless of whether or not my network settings are involved, since http://cpy-eaf90c.local/ works fine, there must be a problem that needs fixing, even if there was something I could do to work around it. Fixing the cause is always better than covering...
I cannot replicate the problem locally, so I want to try to figure out what's different about your setup.
Do you have any extensions installed? Could you try Chrome with no extensions? See https://www.howtogeek.com/779557/how-to-start-google-chrome-without-extensions-on-windows/
What are your DNS servers?
What version of Windows, and what version of Chrome?
Could you try Firefox, and Opera?
Closing in favor of #9336, as it would be the same problem.
I got this board over the weekend and was unable to get anything out of the display in CircuitPython (8.2.7, 9.0.5, and 9.1.0-beta.3) but I knew the display worked fine because both the UF2 boot loader and Arduino example code for the board could display things. I ended up figuring out that the Arduino board definition was forcing the I2C power pin high, but the CircuitPython was forcing the NeoPixel power pin high. I confirmed this using the [pin assignment diagram](https://learn.adafruit.co...
I think the S2 Reverse needs the same change but I don't have one to test on. Let me know if you want the change proposed anyways.
This is a quick addition to define a couple of interrupt pins only available on the second revision of the Arduino Nano 33 BLE Sense. In a way, this is to close my own issue, #7991.
I figured that since there weren't any pin-related breaking changes between the two revisions, it was better to add to the existing definition.
This is only based on pin diagrams since I don't have the actual hardware to test this.
CircuitPython version
Adafruit CircuitPython 9.1.0-beta.3 on 2024-05-22; Ai Thinker ESP32-CAM with ESP32
Code/REPL
>>> import time
>>> import wifi
>>> import ipaddress
>>> ip1 = ipaddress.ip_address("196.1.56.26") # this is deliberately a very slow server in S.A.
>>> print(wifi.radio.ping(ip1))
None
>>> print(wifi.radio.ping(ip1,timeout=2))
0.0
>>> ip1 = ipaddress.ip_address("1.1.1.1")
>>> print(wifi.radio.ping(ip1))
0.0
>>> print(wifi.radio.ping...
Setting up tooling for CircuitPython builds, particularly for ESP32, can be confusing. This PR contains tools which enable setup-free containerized building of any CP port with the one-liner sudo tools/docker-build/build .
There is doubtless a lot of room for improvement in these scripts, in particular in the way file ownership is fixed up at the end of build, but they seem to work, and I thought I'd share in case you're interested.
Hope can see the board alive on the Downloads Section on you guys websites.:) Best Regards, Matthew
If you want to speed up the process, Adafruit is always grateful for help updating the download site :grin:
https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website/overview
@gitcnd Make sure you are not trying to reach https://cpy.....
I thought I was seeing the same issue but google chrome was hiding the https://, by clicking on the URL line and removing the "s" so it was just http://cpy... things started working fine.
I think the S2 Reverse needs the same change but I don't have one to test on. Let me know if you want the change proposed anyways.
I've been using an S2 reverse in a project for a year or so (running 8.0.5) and the display has always worked fine so maybe not an S2 issue :grin:
I think the S2 Reverse needs the same change but I don't have one to test on. Let me know if you want the change proposed anyways.
I've been using an S2 reverse in a project for a year or so (running 8.0.5) and the display has always worked fine so maybe not an S2 issue 😁
That's weird, because the board definition for the S2 Reverse definitely has the wrong pin being forced high next to the "make sure the TFT is on" comment. That leads me to wonder if maybe different builds of t...
That leads me to wonder if maybe different builds of the UF2 boot loader initialize and leave the pins in different states
Possibly, at one point the ESP builds did switch from defaulting to pins pulled low to pins floating. I'll update the firmware on the board to the latest build later tonight and see if there's any issue with the display.
I'm thinking that maybe CircuitPython should be putting both 7 and 21 high, which is what both TinyUF2 and Arduino are doing.
- https://github.com/adafruit/tinyuf2/blob/master/ports/espressif/boards/boards.c#L221-L225
- https://github.com/adafruit/tinyuf2/blob/master/ports/espressif/components/lcd/lcd.c#L295-L299
- https://github.com/espressif/arduino-esp32/blob/master/variants/adafruit_feather_esp32s3_reversetft/variant.cpp#L34-L37
I'll push up a revised change later.
- Fixes #9348
- Fixes #7940
The ping time gets lost if it's not retrieved during a ping callback, because the storage used is freed quite early. Set up a callback to retrieve the time instead of fetching it directly.
I fixed #7940 while I was in the code, by waiting a couple of seconds and trying again if esp_ping_new_session() fails. Interestingly, I had to wait at least two seconds, not the one second that is the task timeout.
@gitcnd
I'm thinking that maybe CircuitPython should be putting both 7 and 21 high, which is what both TinyUF2 and Arduino are doing.
The NeoPixel power is handled by CIRCUITPY_STATUS_LED_POWER, defined in mpconfigboard.h and checked in supervisor/shared/status_leds.c. So you don't need to add that to board.c.
However, the pin is alos wrong for ESP32-S2 Reverse TFT. Could you fix that as well as part of this PR? Thanks.
The non-reverse S2 and S3 TFT boards look OK to me.
The content of the headers of the board files has changed. Please see the tip of main for the new standard headers.
Please rebase your branch from main. You're changing the commits for a number of existing frozen modules.
Where did you get this VID and PID? Are you the manufacturer of this board?
For MatrixKeypad, consider using the keypad module instead.
You are duplicating some modules that are already frozen. Please check in .gitmodules.
(sorry if this appears twice; github seems to have eaten my comment)
I'm not super confident about this change.
- I don't relish the idea of explaining to the user: yes, ping takes 2 seconds in time.monotonic but claims the ping response time is 0.1 seconds.
- esp_ping_new_session might fail for other reasons (e.g., all sockets are in use) and now ping will wait 10 seconds before returning failure. before, it would fail prompt.y
If others think the change is fine, please go ahead and put it in, but I have misgivings about this change as the way to close #7940.
Yes, I am part of the team that developed that board, that VID and PID are the ones that gave us the raspberrypi foundation for this board
Thanks for doing this. It's a one-stop shop for someone who doesn't want to set up a build enviornment.
I don't know how docker works. Does the Dockerfile run on every invocation, or are you just including it to show how you built timchinowsky/build_circuitpython?
Rather than put this into the circuitpython repo, I am thinking that it could be left as a repo that you control, since you control the docker image anyway. Otherwise we become ultimately responsible for maintaining it. We...
This gets the requirements files from the tip of main, but I think you want to get them from the repo?
Is it typical that docker usage runs things as root? It seems like the whole build will be run as root in the docker container.
Aha, I see. But I think you've reversed the VID and PID. The RPi VID is 0x2E8A. (https://github.com/raspberrypi/usb-pid)
Thanks, I hadn't noticed that. :)
I've reworked this to wait a maximum of two seconds on failure, and also documented this.
I agree a slow call that returns a fast ping time is weird, but without rewriting the underlying ping implementation (which should probably be done, but I'm not going to do now), I think this is better than the current situation, which also requires explanation.
The Dockerfile is only used to build the image. I'm including it so that folks can see what it is doing (basically the same steps you would need to do on the command line to install the tools) and be empowered to create their own images.
This gets the requirements files from the tip of main, but I think you want to get them from the repo?
You mean the repo that CP is being built from? Can't do that because the image is given access to that repo at runtime, but the requirements need to be available at image build time so that the python built into the image can be configured. If you wanted to do it the other way, you'd need to have python pull in the requirements every time it is asked to build CP.
This changes ownership of the files created by the container back to the owner of the repo (as cribbed from the metadata of Makefile
Yeah this is one of the things that could probably be improved. The container doesn't have to be run with sudo but the processes inside the container run as root so the owner of anything created by the container ends up as root which makes git unhappy. The reason I'm having it run as sudo is so that I can patch this up after the fact and change the owner back to who it should be.
Thanks @johnnohj @Xfox20 @wtuemura!
I also do not think this belongs in the repo.
Also the current approach, other than completely breaking permissions (cough cough, add --user $UID:$(id -g)), cannot do specific languages, which sometimes we need to test flash size.
I feel like having it separate would be better since then it could work as is with a local clone of the repo, but it could also be told to just clone it (or a fork, specific commit, etc.) on the fly and discard everything other than the output folder.
Adding this here to note how the bug looks with #9344.
(Link goes to the Adafruit Discord server)
#circuitpython-dev message
Thanks for the typo fixes in the description.
I think it would be better for this to be a new board definition. It's a new product with a new stock number: https://store.arduino.cc/products/nano-33-ble-sense-rev2. A new entry (by PR)would be added to circuitpython.org as well. Assuming so, take the _V2 off the pin names.
I also think quick failures are better than long timeouts.
The code looks good to me. Haven't tested yet.
Another place to put the tests is in tests/circuitpython-manual. I'm not sure we should put the very detailed testing screenshots and discussion in the repo. I'd suggest putting it in this PR and putting a link to it somewhere with the tests.
I also do not think this belongs in the repo.
Also the current approach, other than completely breaking permissions (cough cough, add
--user $UID:$(id -g)), cannot do specific languages, which sometimes we need to test flash size.I feel like having it separate would be better since then it could work as is with a local clone of the repo, but it could also be told to just clone it (or a fork, specific commit, etc.) on the fly and discard everything other than the output fold...
Thanks for doing this. It's a one-stop shop for someone who doesn't want to set up a build enviornment.
I don't know how docker works. Does the
Dockerfilerun on every invocation, or are you just including it to show how you builttimchinowsky/build_circuitpython?Rather than put this into the circuitpython repo, I am thinking that it could be left as a repo that you control, since you control the docker image anyway. Otherwise we become ultimately responsible for maintain...
Another place to put the tests is in
tests/circuitpython-manual. I'm not sure we should put the very detailed testing screenshots and discussion in the repo. I'd suggest putting it in this PR and putting a link to it somewhere with the tests.
tests/circuitpython-manual is certainly on-point. I'd want to put a couple images there to illustrate what "good" and "bad" look like. I put the test data in the repo bc it's hard to wrangle a lot of images if you just "attach" them. Probably...
For test documentation, seems like the repo issues and PRs are the defacto places for this, but I'll add some lines to the online docs for PWMOut to clarify the rounding behavior.
@dhalbert - This should be good to go now for both ESP32-S2 Reverse TFT and ESP32-S3 Reverse TFT.
I saw that ESP32-S2 TFT didn't duplicate the integer pin_number in this function so I also propagated that change to the Reverse variants and the ESP32-S3 variant to reduce a little magic number duplication.
The build failed because tools/ci_check_duplicate_usb_vid_pid.py noticed that this PID is the same as the original board. I looked at the latest Arduino Board Support Package and that has not included the Rev2 as a separate board. So I'm guessing that the USB PID is still the same, though having one in hand would verify that. For now, you can add this new board to the exceptions list in tools/ci_check_duplicate_usb_vid_pid.py.
It still makes sense for this to be a new board, because it...
Could you also prepare a PR to add this new board to circuitpython.org? See https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website. Thanks!
You'll need to add these as frozen libraries to .gitmodules. Do a git submodule add.
Note that for Adafruit_CircuitPython_LED_Animation, the LED is all capital letters.
You had NeoPixel here before. Did you want to add it back? It's already in frozen/.
Hi, one minor thing, and one comment about the frozen modules.
This is not used for RP2040 boards.
Use the original capitalization:
[submodule "frozen/Adafruit_CircuitPython_LED_Animation"]
path = frozen/Adafruit_CircuitPython_LED_Animation
url = https://github.com/adafruit/Adafruit_CircuitPython_LED_Animation
I have already corrected it
we take out the Adafruit_CircuitPython_Led_Animation
Sure. It is still in .gitmodules in the latest push, though. Also did you want NeoPixel in or out?
You changed copyrights in the files in ports/raspberrypi/boards/odt_rpga_feather. But that is not your board. Did you mean to do that?
Add a comma
"0x2341:0x805A": ["arduino_nano_33_ble", "arduino_nano_33_ble_rev2"],
CircuitPython version
9.0.5
Code/REPL
# SPDX-FileCopyrightText: Kattni Rembor for Adafruit Industries
# SPDX-FileCopyrightText: Limor Fried for Adafruit Industries
# SPDX-FileCopyrightText: 2019 Liz Clark for Adafruit Industries
#
# SPDX-License-Identifier: MIT
"""
Prop-Maker based Darksaber
Adapted from the Prop-Maker based Master Sword code
by Kattni Rembor & Limor Fried
Adafruit invests time and resources providing this open source code.
Plea...
Hi, this is really a support issue. Could you ask the question in https://forums.adafruit.com/viewforum.php?f=60 ? Include a closeup showing your wiring, and describe how you are powering the strip.
I touched up the duplicate PID list by adding a comma to fix the build error. Looks fine now. I'll merge, and you can go ahead and submit a PR to the circuitpython-org repo.
Maybe you should try amending NUM_PIXELS = 34 to NUM_PIXELS = 140? Could just be that the existing code doesn't take that into account.
CircuitPython version
Adafruit CircuitPython 9.0.5 on 2024-05-22; Adafruit PyPortal with samd51j20
Code/REPL
from collections import deque
a = deque((), 5)
len(a)
a.append(0)
a.append(1)
a.append(2)
a.append(3)
a.append(4)
len(a)
a[0]
list(a)
Behavior
0
5
Traceback (most recent call last):
File "", line 1, in
TypeError: 'deque' object isn't subscriptable
Traceback (most recent call last):
File "", line 1, in
TypeEr...
Board def is already merged on the CircuitPython side, see https://github.com/adafruit/circuitpython/pull/9347.
I've opened a PR for the website - see https://github.com/adafruit/circuitpython-org/pull/1426
We inherit the implementation from MicroPython. There are separate MICROPY_PY_COLLECTIONS_DEQUE_SUBSCR and MICROPY_PY_COLLECTIONS_DEQUE_ITER flags, which should be on, but apparently are not. I'll investigate.
Aha, this was fixed already by #9065. The new functionality is in 9.1.0-beta.3 and later. Looking at the latest documentation a bit confusingly tells you about 9.1.0-beta.3, not 9.0.5
tests/cpydiff/modules_deque.py says "Deque not implemented"
This is a problem from upstream MicroPython, I think.
tests/cpydiff/modules_deque.py says "Deque not implemented"
This is a problem from upstream MicroPython, I think.
Looking more closely at this, I think that test is invoked only when deque is turned off.
Sorry for the delay, I tried using the REPL and reflashed my board with the latest version of circuit python and the problem went away. It is working fine now. Thanks a lot for the reply.
CircuitPython version
CircuitPython 9.1.0-beta.3 (https://circuitpython.org/board/ai-thinker-esp32-cam/)
Code/REPL
import espcamera
import board
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....
it turns out it was documented in the PR, I'd be nice if this could make it in the official documentation and have a unit test for this board.
Hey all, I've encountered this issue (https://github.com/adafruit/circuitpython/issues/9235) with my QTPY ESP32-C3 and while the work around is effective, I don't like adding it every time I refresh my QTPY. I'm willing to help get a more permanent fix implemented into Circuit Python for this (and possibly other) C3 boards. However, I'm not sure where to start. I've looked at the board.c code and several of the radio.x files found in common_hal and shared_bindings folders, but I'm still not sure on how to implement that same (wifi.radio.tx_power=) call in the c code for the board. Any pointers to get me moving in the right direction?
The tx_power setter is this:
void common_hal_wifi_radio_set_tx_power(wifi_radio_obj_t *self, const mp_float_t tx_power) {
esp_wifi_set_max_tx_power(tx_power * 4.0f);
}
in ports/espressif/common-hal/wifi/Radio.c.
It takes a uint8_t arg, so you can pass 34. So is the idea that this is necessary for C3 boards in general? Is there something about their default tx power that is different, from say, S3? Then I'd say do this in the wifi init, not in board.c for each board.
Then I'd say do this in common_hal_wifi_init(), conditionalized for C3 only.
I only have the QTPY C3. I see the issue posted was for a board with the C3 mini, so I'm not sure how wide spread it is.
so for testings sake, if I set it using esp_wifi_set_max_tx_power(34) in board_init(), i shouldn't need the boot.py code anymore?
It's not C3 in general, it's the smd capacitor style antennas, the ceramic ones
Beetle c3 (c3-mini pcb ant) works fine as is, c3 supertiny (ceramic smd ant thing) needs tx_power=8.5
Also, I have one specific network that doesn't work on just 3D antennas.
I have yet to find time to find the value that would work for it
So yea, this needs to be done in board_init().
Alternatively, we could have a build flag for every antenna type.
To make it a bit more abstract and updatable.
I did a bit more digging.
The reason tx_power=8.5 is needed is not because of C3, but because of the type of antenna the board is using.
The common PCB antennas commonly on esp modules are what we most have.
However here and a bit of time I noticed some of my boards did not connect to one specific network.
Those boards all had 3D antennas (and are not C3's):
Then I got...
Just as a notice, I'm starting to implement this myself. I'll use this issue to keep everyone up to date with my progress.
It appears from reading the documentation, though I am not sure of this, that wifi.radio.tx_power=8.5 may be lowering the max power from its default. Would you be willing to do some testing to fetch and print out the power before and after the setting and see how its changed? It might get printed before USB is ready, so you could ESP_LOGI() it, or else turn off wifi workflow and do import wifi by hand to see the print.
@dhalbert The current default is 20.0, set by the "default wifi settings" from idf as far as I can tell.
So yes with 8.5 it's less than half power.
But that's what works on all the antenna types.
Compatibility vs range.
And besides, the tiny ceramic antenna did connect through closed doors to an AP 3 rooms away. It's honestly fine.
Also, as I already mentioned, for those who need the range, it's a settable value. They can crank it all the way.
However, the default should be what wor...
So, I took some time to perform some tests using the station example from the ESP-IDF. I discovered that my QTPY C3 would effectively connect up through power values of 18dBm (72 in the ESP API) but would never connect using the highest (and default) power of 20dBm (80 in ESP API). Lower values would connect fairly well, but 18 seemed to connect within 1 or 2 tries every time.
When I was digging into the [ESP WIFI API](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-refe...
I feel like what's happening is that we're overpowering the antennas. It may be too high values have bad signal reception too.
I will create a test program and test some more values, hopefully tonight.
The IO clock or whatever it's called is just slowing down instead of the system clock.
This means, the neopixel goes white (wrong frequency), but the system keeps on running.
The display curiously keeps on going fine (data updating).
_Originally posted by @bill88t in https://github.com/adafruit/circuitpython/issues/9344#issuecomment-2174683379_
Does your code include any AnalogIn objects?
Also, as a temporary workaround, you can pair your board to any bluetooth device.
This will eat a lot of ram but will make the adc bug go away and the clocks will function as intended.
It would be possible to detect error code 2 and recursively reduce power and retry.
But that would take too long (in runtime) and take flash space.
No AnalogIn, no wifi. Just plain displayio with labels and images:
def show_colors():
clear_display()
N_SHADES = 4
N_COLORS = N_SHADES*N_SHADES*N_SHADES
COLOR_STEP = 256/N_SHADES
stripe_width = display.width // N_COLORS
i = -1
for red in range(N_SHADES):
for green in range(N_SHADES):
for blue in range(N_SHADES):
i += 1
color = ((min(int(COLOR_STEP*red),255) << 16) +
(min(int(COLOR_STEP*green),255) << 8) +
...
@karlfl
discovered that my QTPY C3 would effectively connect up through power values of 18dBm (72 in the ESP API) but would never connect using the highest (and default) power of 20dBm (80 in ESP API).
Nice insight. A few hours too late for me: I just replaced shortly before your post the onboard ceramic antenna on my QTPY C3 with a (very!) cheap external antenna and had a good and stable connection at once. Before it didn't even find all available networks when trying a scan.
I wonder what the reason for the problem with the chip antennas is. I did some websearching and did not find any clear discussion. Maybe:
- chip antenna has losses, is heating up, causing reduced performance
- chip antenna is mismatched and higher reflected power due to higher SWR is affecting RF output stage
@RetiredWizard @dhalbert
Yes! (kindof) Looks like it might be an extension issue? Chrome without extensions "half works" (and - weirdly - when working also fixes the other problem whereby any connection attempt from chrome locked up the serial console on the board making it unusable). Chrome does not work in that same --disable-extensions browser in incognito mode however (the IP address did load, but not the mDNS one).
The ESP32 required rebooting if connections failed (even the...
The chip antenna itself cannot be the problem. I have some Waveshare ESP32-S3 boards with an "C3"-ceramic antenna very similar to the one in the image above and they are working just fine. But the boards have a large ground-plane for the antenna (I guess 3-4 times the area of the antenna).
I've been tinkering around with the audio infrastructure and, while it's fun to do stuff like playing WAV files of an SD card, am kind of missing the functionality to get audio streams to and from my computer over USB.
Ideally I'd like to be able to expose a number of sources/sinks to the host and perform mixing on them together with the audiobusio module.
@tulip sleet at my desk for an hour or two. need anything?
Testing ble_ibbq_simpletest. I've diagnosed and am fixing problems with descriptor discovery.
I am doing ok. I just had a breakthrough on debugging descriptor discovery: some off-by-one errors. I do need to change to something more specific than the task notification mechanism for synchronization. Things are happening in the wrong order.
there are some PR's that could be reviewed if you are so inclined, but not rush
I have some tabs open to do so. Not sure how far I'll get
That'd be neat! Our audio subsystem is pretty complicated but would benefit from USB support. This be especially useful on USB high speed devices.
TinyUSB already has audio support IIRC so this would involve hooking that into CP's audio subsystem.
@tulip sleet ok if I merge the pwm testing PR 👆 ?
I wanted to get the documentation images out of the repo and into the PR or something. They are a megabyte total.
author proposed a pdf, but that's still large, and in the repo
he removed most
it's still 1060kB for two images. I dunno. Maybe I shouldn't worry.
I worry more about some of our submodules
yeah, but they are other repos. well maybe it's not worth worrying
right now a zip of what's in the repo is 14.7MB
can you compress the images?
they are helpful in understanding the test because the script generates those images
let me try to compress them. I might be succeeding if it twiddle some settings.
@tulip sleet I'll let you follow up on the PR
I shrank the PNG images by about 70% using https://tinypng.com, and pushed them. I see little if any visible change.
I shrank the images, and will merge.
CircuitPython version
since PR#9325
Code/REPL
def send_file_to_host(src_filename, dst_file, filesize, buf_size):
import sys
import binascii
try:
with open(src_filename, 'rb') as src_file:
bytes_remaining = filesize
buf_size = buf_size // 2
while bytes_remaining > 0:
read_size = min(bytes_remaining, buf_size)
buf = src_file.read(read_size)
sys.stdout.write(binascii.hexlify(buf))
bytes_rem...
TinyUSB already has audio support IIRC so this would involve hooking that into CP's audio subsystem.
I did check that before I submitted the request, to not put in an unreasonable FR.
Is there anything I can do to help with implementation? I realize it might be a bit of a tough nut to crack as a first contribution, but I would gladly help out with testing or documentation.
I communicated with @ladyada about this. She is inclined to think it is mismatch and therefore reflected power, given that there is little room on some boards for an adequate layout.
@bill88t We started with choice of 8.5 dBm was from @askpatrickw on a particular board: #6540.
@askpatrickw It's been a while, but did you choose that value as the maximum practical for the board, or was it a quick choice that worked?
@karlfl's experimentation (https://github.com/adafruit/circuitpython/issues/9235#issuecomment-2181890602) where 18dBm seems like the max. I would be inclined to use a somewhat lower value, but I'm not sure about choosing 8.5 dBm, which is quite a bit less....
I also had another find.
The other boards with ceramic antennas, like the Waveshare ESP32-S2 Pico (and probably the same S3 board) do not ground the ceramic antenna. There is a ground plain keepout area.
On the supertiny however, the antenna is grounded to the plain, intentionally.
What I don't understand now is why the 3D antennas connect to that one network with the reduced power.
They aren't grounded.
The SuperTiny schematic, such as it is, is here: https://www.aliexpress.us/item/3256806297878595.html?gatewayAdapt=glo2usa4itemAdapt.
Chip antennas are fed at one end and aren't meants to be grounded at the other end. But they need to be near a ground plane, at a particular orientation and distance: https://www.globalspec.com/learnmore/semiconductors/communication_ic/chip_antenna. Sometimes there isn't room for this or the designers are sloppy.
Ah? So in the schematic it isn't showing it as grounded?
But the physical thing is.
I desoldered the antenna.
The pad is connected to ground with a perfect 0Ω reading.
I would wanna just wanna say it's just a defective sample, but it's certainly not the only one.
And wait, the WeMos C3 Mini does keep (from the image of i...
The schematic doesn't show the "WIFI" antenna grounded. Which pad are you measuring? The one that's connected to UC8 and UR9?
Doesn't mean that there isn't some problem with the board.
the circuitpython_setboard command currently supports python 3.10+ only due to a change between py3.9 and py3.10.
Here is an example of the traceback that results from trying a version below 3.10:
$ circuitpython_setboard adafruit_feather_esp32s3_4mbflash_2mbpsram
setting board: adafruit_feather_esp32s3_4mbflash_2mbpsram
Traceback (most recent call last):
File ".../.venv/bin/circuitpython_setboard", line 8, in
sys.exit(set_board())
File ".../.venv/lib/python3.9/si...
The schematic doesn't show the "WIFI" antenna grounded. Which pad are you measuring? The one that's connected to UC8 and UR9?
I was wrong. My horrible memory was remembering the WeMos ESP32 Lite (pcb ant).
The whole ant on that is shorted all the way to the usb-c shell.
That one works perfectly fine btw.
On the supertiny the antenna itself is shorted. It's not shorted to ground.
I started testing (on the supertiny) by constantly switching between two networks, one really close (10cm) and one that is purposefully barely in range (about ~25m diagonally, vision obstructed).
I started from tx_power=18 and climbed down 1.0 at a time.
While some values did work once or twice, once the board heated up (due to the wifi transmission power), the reliability plummeted to 0.
The board was let to cool before every value swap.
I decided 11 is fully reliable at normal ope...
No, this doesn't actually fix the 3D antennas. It makes em worse.
Furthermore, the only boards actually benefited from this are just the supertiny and the wemos c3 mini.
We should just add an override for those boards.
In the present 2024 is _thread or another mechanism for threads available in circuitpython?, well I am using a pico w and it would be great to get the maximum resources for an automation project with AI.
CONFIG_FREERTOS_UNICORE=y, so that only one core is used: problem seems to go away. That would explain why ESP32-S2,which has only one core, doesn't have the problem.
Circling back to this comment, which was before you thought it was fixed only for us to find it may not be, is this statement still true? And if so, is this something that can be done through CircuitPython?
I ask because as I try to decide which single configuration to use going forward on my project using S3 modu...
Do you understand which part of the code is dependent on 3.10? importlib.resources.files is listed as being in 3.9
however I found at least one other project having trouble with importlib.resources.files in 3.9, without much explanation: https://github.com/jupyter/notebook/pull/7016
Alternative to #9357.
Fixes #9235.
How about a CIRCUITPY_DEFAULT_WIFI_TX_POWER, so that different values can be set for different boards? I've included change suggestions.
Let's make it more general so we can specify other values.
#define CIRCUITPY_WIFI_DEFAULT_TX_POWER (11.0)
#define CIRCUITPY_WIFI_DEFAULT_TX_POWER (11.0)
This is tricky. The C preprocessor can't dp #if with floating constants. So in order to conditionalize this so the common_hal_wifi_radio_set_tx_power() is not compiled if the power is not specified, we use a constant expression which will be optimized.
if (CIRCUITPY_WIFI_DEFAULT_TX_POWER != 20) {
common_hal_wifi_radio_set_tx_power(self, CIRCUITPY_WIFI_DEFAULT_TX_POWER);
}
// 20 dBm is the default and the highest max tx power.
// Allow a different value to be specified for boards that have trouble with using the maximum power.
#ifndef CIRCUITPY_WIFI_DEFAULT_TX_POWER
#define CIRCUITPY_WIFI_DEFAULT_TX_POWER (20)
#endif
This works like a charm:
import socketpool
import wifi
from adafruit_httpserver import Server, Request, Response
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,
powerdown_pin=board.CAMERA_PWDN,
reset_pin=None,
i2c=board.I2C(),
external_clock_frequency=20_000_000,
...
I like the idea of automatically "rounding down" to the next lower supported frequency. As far as I can tell, overclocking is not supported by esp_pm_configure anyway, so that would not be an issue.
Regarding the size of the build: Instead of disabling the feature on C3 builds, would it be acceptable to modify the partition sizes to make the changes fit?
I think it's only partitions-4MB-no-uf2.csv that would require a small reduction in user_fs size, in order to increase the size of...
Touching the partition tables will wipe every existing c3's filesystem on upgrade.
Right now the documentation for usb_cdc.serial.read() gives the signature as usb_cdc.serial.read(size = 1). That is, it reads a at most a single byte. This does not match the implementation: it actually tries to read as much as possible, because it uses the standard stream operation read(), which has those semantics.
Pyserial's read() has the same signature and does read only one byte if no argument is given. I think our original intention was to match pyserial.
So rather than c...
I'll test tomorrow, thanks!
@Bob837217
Apologies for commenting here, but it is the only place I have seen a similar issue to what I am having.
Hi, did you manage to solve this at all?
I've tested this on all major and latest beta releases of CircuitPython since 8.2.8.
Running the layer assignment before appending Layer(), ends up with the keyboard not working due to Invalid LT key, adding it after the assignment there is an Invalid HT key both of which stop the board working. removing the new layer result...
Hi @tannewt @DLBPointon
It has been a while since I last did any work on that keyboard project. I have not tested the latest beta etc and do not know if this is still an issue or not. I did things in a different way in KMK to avoid any issue for my project in the end. I also note that for my final version (last I looked at it), things were stable for a couple days uptime, then the rp2040/firmware would freeze and need to be power cycled to regain functionality. I have moved onto other pe...
I don't necessarily understand the reason behind the issue, everything underneath our code in the stack trace is a bit cryptic to me. Something is resolving to None, but it's unclear to me what specific thing is actually None. I searched around for a bit with different parts of the stack trace and was able to find references to the same or similar issues, but nothing really stood out as a cause or way to change the code to make it work.
The crux of it is that `resources.files("board-stubs...
OK, here's the reason. Because it does not contain a init.py, board-stubs is a "namespace package". Support for namespace packages was added in 3.10: https://github.com/python/cpython/issues/86295
pip-installable "importlib-resources" supports namespace packages https://github.com/python/importlib_resources so it could be used as a substitute across any supported python version. I don't know if simply adding board-stubs/__init__.py could be a better solution.
With `/tmp/t1/__ini...
@tulip sleet, sorry to bother, but is there anyone else I can tag to review some open library PRs?
If we wanted to keep the check we should do a fabs(20 - default) > 0.1, but the check is not really needed.
Tested on cardputer and supertiny.
resolves: #9363
Removed usage of importlib.resources opting for os.path.join, os.listdir, and site.getsitepackages to serve the same function in the code.
Ahhh I see, thank you for tracking that down and sharing the cause.
I refactored it to use os and site instead of resources.files and didn't see this until I created that PR.
Knowing the real cause now though, I do think adding __init__.py in the necessary directories is probably the best solution.
I will test that locally in a little bit and close that PR and make a new one.
I think it depends on what versions of python you want to support. resources.files wasn't added until 3.9
@justmobilize I don't think we intent to support anything lower than 3.9. Although it seems the issue isn't whether resources.files exists at all, but rather whether it supports those "namespace packages" which changed between 3.9 and 3.10 it seems.
The check removes an unnecessary call at compile time (assuming optimizer is working). It was previously done with #if in your original PR.
Knowing the real cause now though, I do think adding init.py in the necessary directories is probably the best solution.
I will test that locally in a little bit and close that PR and make a new one.
I tested that by manually adding a __init__.py inside of both board-stubs/ and board_definitions/. I was worried that the one inside board-stubs/ would take precedent over the __init__.pyi file which is the only other thing in that dir, but inside the IDE it does still c...
Well, maybe never mind, since it could be that in the future some other default was chosen.
@FoamyGuy it might be worth adding a version check at the very top of the file (before specific imports), giving a clean error if they are on anything less than 3.9
Or specifying the minimum version so it can't be installed on 3.8 or below
I'm always seeing users with random versions
Oh I didn't know the optimizer caught these things. I'll keep it in mind next time.
resolves: #9363
Prints a more sensible error message for python version too low (supports min version 3.9)
Creates __init__.py inside of circuitpython-stubs/board/ at the end of the stubs build which allows resources.files("board-stubs") to succeed during circuitpython_setboard
closing in favor of #9368
The check could be just sys.version_info < (3, 9)
Not commenting on github cuz im on phone 😅
Makes sense to me, I added an explicit check version in the new PR.
This one also uses touch to create the __init__.py files inside board-stubs and board_definitions.
Hi - In general, you can assign the group "CircuitPython Librarians". I'm in that group. Otherwise, it's only me who's going to look at it. I actually thought it was assigned to the group, so I didn't take a look immediately.
I think since I'm not a team member I can't. I can only see it once you add it.
Hmm, you're right. We'd have to pay for a seat for you for you to be on a team. OK, go ahead and tag me and I'll add the team as appropriate.
Configures the QT Py ESP32-C3 to use a reduced radio TX_POWER by default. Fixes connectivity issues when using WIFI and Web Workflow out of the box.