#circuitpython-dev
1 messages ยท Page 19 of 1
This seems fine to merge now. Further testing is good but it would be good to get it out for people to try. Since it's an underscore module, we don't guarantee about the API will remain stable.
@onyx hinge in #help-with-audio, user asks about playing MP3's from a buffer instead of a file: #help-with-audio message. I'm not sure there's a way to do that, even if MP3Decoder takes a BinaryIO. Or is there a way to implement a stream.
Another idea would be to implement a RAM filesystem. I see that in several places in the MicroPython test directories. But it's a bit roundabout.
I am getting build failures on GitHub Actions. It looks like a set of their servers is down: E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/universe/m/mingw-w64/mingw-w64-common_7.0.0-2_all.deb Unable to connect to azure.archive.ubuntu.com:http: [IP: 52.147.219.192 80] etc
Interestingly http://azure.archive.ubuntu.com/ubuntu works but further down does not. This is internal to them. From outside it works, and has a different IP address.
Here is a UF2 to try with a very simple change, which just delays one second before doing cyw43_arch_init() in supervisor/port.c. @ok1rig Could you see if this makes any difference? Unzip and then load.
picow-delay-cyw43-startup.uf2.zip
Same behaviour if omitting the light sleep...
# Delete objects before powering down
#del i2c
#del bme680
#del bh1750
#del vl53
#del display
#del battery_monitor
# garbage collector
#gc.collect()
# Powering down TFT-display and sensors
p.value = False
# Create a an alarm that will trigger 10 seconds from now.
#time_alarm = alarm.time.TimeAlarm(monotonic_time=time.monotonic() + 4)
# Do a light sleep until the alarm wakes us.
#print ("4 Sekunden im leichtem Schlaf")
#...
there's not currently a way to do that.
@slender iron I looked at the generated ninja file vs our Makefile, and found quite a few differences. Here are some hand-pruned link options, sorted alphabetically. Some things are different but mean the same thing, like the libxt_hal.a and libphy/-lphy references. But there are quite a few more -us in the ninja version. I don't know what it wraps all that stuff with --wrap.
well, I can add the missing -us. Do you understand the motivation for wrapping functions?
just meld the two files for interest
you use rom.newlib-nano. they don't . They have rom.newlib-time, we don't
I will look at the missing -us and see if they are WEAK
void pthread_include_pthread_rwlock_impl(void)
{
}
```hum that's not going to work so good with -flto or -ffunction-sections but I guess we don't use those. Anyway, "include..._impl" seems to force including that source file's functions, but it's not clear why you'd need it. those functions should otherwise end up used
components/cxx/component.mk:WRAP_FUNCTIONS most of the WRAP_FUNCTIONS have to do with the case where cxx is enabled, but I don't know if that applies. CP isn't using C++ but maybe other components are.
@onyx hinge Scott and I had an audio discussion yesterday about how he diagnosed the S3 sleep problem, which was a missing -u. It turns out there are WEAK function defns that are default but incorrect. https://github.com/adafruit/esp-idf/blob/944c01eef4fbba693f991f9d033cda3f59ca82c9/components/esp_system/port/soc/esp32/highint_hdl.S#L552
Thank you both! I'll try again to replicate it today.
The collision should only happen if two devices share a hostname (which they shouldn't.) Instance names can have this happen too but it isn't critical for the API to work.
I'm not using a Pi to read the UART. I've got a USB to serial adapter board I use.
That version number matches mine.
Could you post a picture of the board?
@jaunty juniper @crimson ferry are you both on mac?
ya, it'd need that if the device had already mangled its hostname
but I'm not sure why it is mangling it in the first place
I have three devices going and have curled them from both linux and mac
and just see ```
Press enter to exit...
+++ Service Adafruit QT Py ESP32S2._circuitpython._tcp.local. added
cpy-f57ce8.local.
+++ Service Adafruit QT Py ESP32S2-3._circuitpython._tcp.local. added
cpy-1f4534.local.
+++ Service Adafruit QT Py ESP32S2-2._circuitpython._tcp.local. added
cpy-d97ebc.local.
that is weird, some network multicast echo causing confusion in some environments??
ya, that seems likely to me
I could try adding some debugging to the binary for you
(or you can)
happy to try out any uf2 or bin, I'm not in a good position to build again yet
Neradoc might be better set up
kk, have time now?
sure
that works
do you have access to the debug uart output?
I should go to the Post Office to get my new QT Pys ๐ (but I can re-purpose one easily)
oh, on a QT Py? are thjose pins exposed?
I have it output on the tx pin
I can set that up, or how about an S2 DevKit C N4R2 or N8R8 build?
I can build for whatever is easiest for you
DevKits are the most expedient ready right away
I'll have a more verbose version shortly
OK, so far I haven't seen that device mangle its hostname
poking at it from browser (other mDNS CP devices), and from a device running CP mDNS finder code
Wiring looks right to me. What does ls /dev/tty* show? I've never seen one that starts with AMA. (Though I haven't really used the built in uart on rpi.)
outputs mdns packets
I did do a loop back test to make sure /dev/ttyAMA0 was the correct UART for my wiring and I verified it was the high speed UART (PL011). I tried on 2 Raspberry Pi's (B plus and 4). I'm on the road so I don't have my scope or any USB dongles.
You'll need to delete the files for the old name (using git rm).
ls -l /dev
lrwxrwxrwx 1 root root 7 Nov 30 20:03 serial0 -> ttyAMA0
dmesg | grep tty
[ 3.325760] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
ttyAMA0 is the high speed UART.
Ok, I have no idea why you aren't seeing output then.
I'll try another QT PY ESP32-S2 when I get home. I did have some quality issues with this last batch such as a cold solder joint. Thanks for all your help!
@crimson ferry want a qtpy s2 build too?
shouldn't matter, it's easiest with the devkits since they already have both USB
ok, just thought you could replicate it there
I've got a bunch of QT Pys that I'm rebooting after the DevKit (per Neradoc's comment on the issue)
๐
I'm hoping it'll tell us where the packet that caused the name mangling comes from
wow, I'mm seeing ALL mDNS packets
haha, ya
there is a log when a mangle happens that should be orange
warning level
none of the devices are mangling hostnames right now, trying to think of network conditions or timing that would trigger it
I use the board-names to dynamically load board-specific code from files/modules with the same name as the board. I replace the "-" with "_" at runtime, but it would simplify things if this were not necessary.
RX[0][0]: From: 192.168.6.194:5353, To: 224.0.0.251, Packet[1052140]: AUTHORITATIVE
A: circuitpython.local. A IN FLUSH 120 [4] 192.168.6.194
D (1053880) esp_netif_lwip: esp_netif_get_ip_info esp_netif:0x3ffe88f4
D (1053880) esp_netif_lwip: esp_netif_get_ip_info esp_netif:0
W (1053890) MDNS: A record Probe failed. Mangling name
W (1053890) MDNS: Name mangled from cpy-96a0ca to cpy-96a0ca-2
I (1053900) MDNS: Queueing service probe
DevKit is 192.168.6.144
ah, the record is for circuitpython.local
macos seems to cache circuitpython.local for 2 minutes, then gets a new IP
so its mangling the good hostname even though the collision is on something else
apparently so
I reloaded CircuitPython 8.0.0-beta.4 from CircuitPython.com and ran the following code:
from board import TX, RX
from busio import UART
uart = UART(TX, RX, baudrate=115200)
print('UART ready')
while True:
if uart.in_waiting:
data = uart.readline()
data_string = ''.join([chr(b) for b in data])
print(data_string, end="")
uart.write(data)
I then connected using Tio on the Pi with the same wiring pictured above and typed a test:
`...
Hi there. I've been puttering adding wpa-enterprise wifi support (peap only at the moment) into circuitpython, and I have working versions for esp32s2/esp32s3 (I think also C3 but I don't remember, I have so many of these boards now since I started this hobby project). I added a couple of functions into the shared-bindings/wifi/Radio.c for accessors to be able to set flags to use enterprise mode when connecting, and passing in username/password authentication (used by wpa-peap, I don't have to worry about certificates... yet).
I got my hands on a raspberry pi pico w today to test because sure enough the stuff I add to shared-bindings to access functions in ports/espressif/common-hal/wifi breaks the build for pico-w (and likely everything other than esp32).
What's the right way to approach this? Are there conditionals I can use in shared-bindings for esp32-only builds? I could provide dummy functions into the pico-w tree but that would mean I should provide dummies into all the ports that use the wifi shared-bindings.
You can have the common-hal implementations for non-esp32nn raise NotImplementedError if WPA Enterprise is requested.
that is generally how we do it. The shared-bindings code accepts the full API, and the common-hal complains if it can't do it.
The common-hal could raise not-implemented or it could pass back an error code and have the shared-bindings code raise it
There can be a "LImitations:" setting in the in-line documentation in shared-bindings that describes what works. Checkout out shared-bindings/busio/UART.c, for example.
Okay, so yeah I would add the equivalent functions into the raspberrypi/common-hal/wifi stuff and just raise NotImplemented like it does now for things like void common_hal_wifi_radio_stop_ap(wifi_radio_obj_t *self) { mp_raise_NotImplementedError(NULL); }
@tulip sleet was there any discussion I missed about what branch we were using for adafruit/esp-idf in cp?
its set to circuitpython8 (which I set it at iirc) but it looks like the commit is release/v4.4-circuitpython
(set in .gitmodules)
I changed it from circuitpython8 to release/v4.4-circuitpython because there was stuff in circuitpython8 that I wanted to back out. I was trying to get a minimal set of changes. If .gitmodules says that it should be changed.
I think I wrote some commit messages and/or PR messages about why I did what I did.
k, I can update it when I update it to get the mdns fix
some of the fixes in circuitpython8 were fixed in upstream
slightly differently, maybe
@crimson ferry I can give you a (hopefully) fixed version
why not just move the branch then?
forcibly move the branch? I thought that might be dangerous, I think. I also wanted to make it clearer it was based on release/v4.4
looking at my commit msgs...
I was more concerned about making it clear what branch of esp-idf we're using in what version of cp
I think this change in the IDF will fix it: https://github.com/adafruit/esp-idf/pull/9
Thanks to @anecdata for finding that it is caused by a collision of circuitpython.local causing the mac based hostname to be mangled.
@slender iron https://github.com/adafruit/circuitpython/pull/7023 is what I wrote up for the reason. circuitpython8 was out of date and had superfluous commits, and I didn't want to move the branch to a new commit. But it sounds like that would have been OK with you.
I figured we would have an idf branch for each cp major version
it ran just fine ๐
happy to test, Iโll be back at my desk in a few
Looks like it did happen here too: ```
+++ Service Adafruit QT Py ESP32S2-2._circuitpython._tcp.local. added
cpy-d97ebc-3.local.
I've traced the location of the crash into esp_tls_conn_destroy during gc_deinit, when finalisers of all objects are run. The underlying socket object has previously been closed, but that shouldn't matter.
void common_hal_ssl_sslsocket_close(ssl_sslsocket_obj_t *self) {
common_hal_socketpool_socket_close(self->sock);
esp_tls_conn_destroy(self->tls); // <-- inside this call, didn't trace further yet
self->tls = NULL;
}
The pointers are ...
sslsocket cl...
Thank you. Latest commit changes to this and adds the same handling to framebuffer and epaper displays.
I was able to reproduce this on two other RPI Pico W with 2422 5.5 and 5.6 on them.
When committing to my CircuitPython fork, it's failing the formatting step. How do I find out what the specific error is, so I can fix it?
Is it giving you any message? You can install pre commit on your own repo. For me when I git commit it runs the formatting steps and will show me what is wrong
This is all I'm getting:
Check Yaml...........................................(no files to check)Skipped
Fix End of Files.........................................................Passed
Trim Trailing Whitespace.................................................Passed
Translations.............................................................Passed
Formatting...............................................................Failed
- hook id: formatting
- files were modified by this hook
I tried to use exactly the same formatting/style already used in the files, so I think I'm just missing something subtle.
Ok, I think I found it, but I would still like to know. I accidentally used a tab for indentation in a .h file. Fixing that and redoing the adds made the commit successful. I'm sure I'm going to run into things like this again in the future though, and I would really like to know how to get it to tell me the problem.
I've found that before myself. You can run the pre-commit tools by hand. Normally when it says the "files were modified by this hook" it fixed it for you and you just have to recommit the file
Yeah, I tried that (recommiting), and it didn't work. I actually tried running "uncrustify" on the files manually, but it complains that it needs a config file, and I don't know where that is for the circuitpython repo.
Anyhow, thanks! The tutorial for this is a bit outdated, so I'm having to work some things out as I go, but I'll figure it out eventually. I know exactly how to do what I'm trying to do, but working within the constraints of a pre-commit I'm not used to is...interesting.
@serene token If you run pre-commit locally it will fail the first time, but also make the required changes to the file, so subsequent runs will pass.
For some reason it didn't make the required changes. I had to fix it manually. I did try to commit a second time, because I thought it was supposed to try to fix it, but it had the same error. (I knew it was probably an indentation error, because I use tabs exclusively in my own code, and remembering to do spaces instead was a challenge.)
@tulip sleet should I switch the .gitmodules branch or force push to circuitpython8?
Whatever you want. If you do that, I just want circuitpython8 to be the same (+ your latest change) as release/v4.4-circuitpython, so that it's cleaner than the old one, which had a lot of churn and was not up to date.. Could you document this in the PR, and also ping MicroDev about it specifically, since he has a strong interest in it.
I think maybe one motivation for release/v4.4-circuitpython is that while you were way, it looked like MicroDev might succeed at getting ESP-IDF v5 going, so I wanted a branch name that made clear what we were using
I don't remember that well why I chose that, but I think it was to make it clear the branch was meant to track v4.4
we could add a circuitpython9 branch for 5.0
we are not there yet, but yes, 5.0 looked more promising initially
but there were some mysterious build problems. Also some things I hoped were fixed in 5.0 were not, so there is less motivation
Using that delay startup seems to fix the issue.
Very interesting! @jepler This was a crude attempt at narrowing down the problem. A one second delay is long and could probably be reproduced. It may simply be a power-up race condition. You probably have a better idea of what to do here. I wish we had at least one board sample that shows this problem, but neither you nor I see to have one.
@jepler The key test I think is to see whether it comes up when plugging in. Maybe you do have a sample that shows this issue but rarely unplug and replug so you don't see it?
A crash would occur if an SSL socket was not shut down before gc_deinit().
I do not fully understand the root cause, but some object deinitialization / deallocation prior to gc_deinit leaves the SSL object in an inconsistent state.
Rather than resolve the root cause, instead ensure that the closing of the user socket also closes the SSL socket.
Testing performed: on Feather ESP32S3 TFT run the reproducer script >10 times. Before, it crashed after 1 time. However, running 10 times...
The conversion of characters like _space_ in qstrs is a bit ad-hoc. Because _not_ stands for the logical negation character ยฌ the recently added message was displayed incorrectly:
>>> socket.getaddrinfo('does.not.exist', 0)
Traceback (most recent call last):
File "", line 1, in
gaierror: (-2, 'Name or service_spaceยฌspace_known')
I had noticed this, but evidently failed to include the fix in the problem in #7269.
#7280 added a single -u ... value to Espressif links to force the correct routine to be linked in, instead of a WEAK version.
I looked over the output of ninja.build and found several more things that potentially should be added to the links. I've added this in the Espressif Makefile. I tested with the usual "Internet test" that's in the Learn Guides on an ESP32-S2 and S3, and it works. ; one of the added -u symbols is relevant to I2C, so I also tried ESp-32S3 I2C with a problematic...
- read() is now readinto() and takes the buffer to write into.
- readinto() returns the number of valid samples.
- readinto() can be interrupted by ctrl-c.
- readinto() API doesn't support signed numbers because it never did.
- sample_rate is now required in the constructor because supported values will vary per-port.
- 16 bit values are full range. 12 bit samples from RP2040 are stretched in the same way they are for AnalogIn.
Fixes #7226
@latkinso42 Please review as well.
Thanks! I do not have a strong opinion about that dhcp debug message, it can be fixed in the future with a fresh PR.
cpy-MAC hostnames were being mangled on circuitpython.local conflicts.
Fixes #6869
@slender iron I would like some advice:
I'm working on a RawSample style audio object but for streams. I could use a pair of buffers and rotate between them. When the user calls a function to add audio to the buffer, it adds it to whichever isn't currently playing (copying it into the buffer), and it keeps track of how much has been added.
Alternatively, I could just directly use the buffers provided on write and not have static buffers at all. When the user writes, if nothing is playing, the buffer they provide is put in the "buffer" pointer and played. If a buffer is already playing, the new buffer is put into a "next_buffer" pointer and seamlessly played next (moving it into the "buffer" pointer and setting the "next_buffer" pointer to NULL). I think this way will require less bookkeeping, and it will avoid the need to explicitly copy buffers passed by the user. (That is, if the line mp_get_buffer_raise(args[1], &bufinfo, MP_BUFFER_WRITE); in shared-bindings/audiocore/WaveFile.c (line 90) isn't doing exactly that... Not sure what all of the Micropython functions for managing arguments are doing behind the scenes.)
Anyhow, I'm leaning toward just using the user-provided buffers for the sake of simplicity, but I'm not sure there isn't some reason I missing not to do it that way. Do you have any thoughts on this?
(That is, if the line mp_get_buffer_raise(args[1], &bufinfo, MP_BUFFER_WRITE); in shared-bindings/audiocore/WaveFile.c (line 90) isn't doing exactly that... Not sure what all of the Micropython functions for managing arguments are doing behind the scenes.)
This call is confirming the arg is a buffer, specifying R or W, and fetching the details (ptr and length) into bufinfo. If it's not a buffer, an exception is raised.
Thank you! I recognized that "raise" might mean it can raise an exception, but beyond that I had no clue. So it isn't copying the buffer, which is what I expected.
Does this mean that I should do MP_BUFFER_READ if I'm only reading it and nothing else? (I'm not to that point yet, but it would be nice to know ahead of time.)
yes, exactly
Awesome. That helps a lot!
some buffers are naturally read-only, like a bytes, so it's checking for that kind of thing
Oh, I see. That makes sense. And since WaveFile can take a buffer, it's important to check that it's writable for that reason. What I'm doing can take a bytes, but I don't need to write. Thanks for helping me understand this! The whole separation of module and bindings has been a bit of a hurdle for me to begin with. I understand the point, but the bindings code has a lot of stuff I'm not familiar with, and this is really helping.
@tulip sleet @slender iron With esp-idf v5.0, I hope that we will be able to make a PR out of our fork and upstream the changes and maintain this for subsequent changes as well.
Scott, you might want to PR the mdns changes to https://github.com/espressif/esp-protocols as in idf v5.0, mdns has been moved to esp-protocols repo.
@analog bridge yup. I filed an issue there today
Luatos Core-ESP32C3 board bringup done, PR to follow once I clean it up.
Looks good! A few changes. Did not test on hardware yet.
This comment needs to be revised, I think, because you now normalize to 16 bit, checking the error bit in the process.
Leftover debugging print?
This is more canonical, right?
//| mybuffer = array.array("H", [0x0000] * length)
#7069 implemented chained exceptions (thank you @jepler). However, https://docs.circuitpython.org/en/latest/shared-bindings/traceback/index.html still says:
chain (bool) โ If
Truethen chained exceptions will be printed (note: not yet implemented).
The "not yet implemented" should be chained, and can this actually be set to False to not format or print the chain?
Status: in my work in progress branch, a bunch of test cases pass. However, the internal interface has changed and so the shared-modules that used dotenv directly need to be updated.
# comment
string = "hello world"
number = 7
cstring = "hello comment" # comment
cnumber = 0x7f # comment
string1= "\n"
string2 ="\u00c1x"
string3 = "\U000000c1x"
string4 = "\f\"\\"
string5 = "\t\r\b"
My work is pushed to a branch, but I'll be waiting on creating a PR until it's closer to...
Do you have other similar boards you could try this on to see if it is board-specific?
This makes a lot of sense since others have reported it has a random memory leak like behavior and gc has no effect on it, even if gc is explicitly used manually.
I am going to spend a little time seeing if I can find the root cause.
@BeatArnet Please open an issue for this. Its hard to track on a merged PR.
The TinyPICO V2 is currently my only ESP32-D4 board.
I don't actually know if there is another D4 board that supports circuitpython. I have run this same code on ESP32, ESP32-S2, ESP32-S3 and ESP32C3 boards running CP without this issue occurring.
I believe the QTPY ESP32-Pico uses a similar microprocessor that I haven't tested yet, I'll go ahead and order one of those. If anyone knows of another D4 board, let me know :)
Just as a swipe in the dark I decided to look at the boards/unexpectedmaker_tinypico/sdkconfig file and I set the CONFIG_SPIRAM_SIZE parameter first to 2097152, then 524288 and finally to 2048. Each time when the board started gc.mem_free() returned 4095360. I also tried using the sdkconfig file from the qtpy pico board but that build didn't startup on the tinyPICO.
We retrieve espidf's own idea of the amount of psram present, ultimately via esp_spiram_get_size(), but through multiple layers of code. It may be that our version of esp-idf is improperly detecting the PSRAM (the early boot messages from esp-idf would be helpful here) or there's something wrong with how the data is passed among the layers. For instance, the way that ESP32 (only) starts at SOC_EXTRAM_DATA_LOW, and others end at SOC_EXTRAM_DATA_HIGH, seems weird, but it matched what I saw in...
I contacted a handful of people today to see if anyone is interested in a TR-Cowbell sequencer. Free. If I didn't contact you and you are interested in one feel free to contact me. I have a limited supply (each board requires 16 step switches and they're not cheap in that amount). It's first come first serve as there are a limited amount but I will make sure to eventually get one to everyone interested even if I run out of parts for the first free batch.
I do not understand the flow all that well, but this seems a bit fishy to me:
https://github.com/adafruit/circuitpython/blob/9e104c04aec3178b45ba70a302ad5800afad752f/ports/espressif/common-hal/socketpool/Socket.c#L609-L616
Under what circumstances is the passed in socket not a Socket object. Could it be an SSLSocket? If so then fields in it are set willy-nilly. Also the SSLSocket is not shut down. And if it's a plain Socket, it's kind of being rendered unfunctional, but the underl...
One idea, and also a question in the main comments thread.
Why did you choose not to use the _t in favor of the explicit struct?
ssl_sslsocket_obj_t *ssl_socket;
This is the first things that come through on the Thonny console:
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:12756
ho 0 tail 12 room 4
load:0x40080400,len:3024
entry 0x400805dc
Serial console setup
Device is busy or does not respond. Your options:
- wait until it ...
Interesting side note, when I started customizing the sdkconfig file the CP flash filesystem was initialized so I recopied my code down to it. Before getting the boot messages I posted in the previous comment, I restored the Adafruit build from circuitpython.org and the flash filesystem was also restored to the same state it was in prior to my loading the custom images. That probably makes perfect sense to someone that understands how the flash is handled but just in case I thought I'd mentio...
Ok, I've made the changes.
Thanks, will test on hw now.
I don't know if this will help, but I commented out the CONFIG_ESP32_SPIRAM_SUPPORT=y line in sdkconfig and added CIRCUITPY_ESP32_CAMERA = 0 to the mpconfigboard.mk file and gc.mem_free() now reports 106192 but the PyDOS code now seems to run without the variables being clobbered.
Afternoon! I see there are changes being made to analogbufio. I have no issue with API or signature changes. Do any of these inherently delay or slow the CPy function call on read (readinto)?
Here is a UF2 to try with a very simple change, which just delays one second before doing
cyw43_arch_init()insupervisor/port.c. @ok1rig Could you see if this makes any difference? Unzip and then load. picow-delay-cyw43-startup.uf2.zip
This firmware works for me, circuit python drive is now recognized 10 of 10 on my problematic board.
Would it be possible to "bundle" code.py with the UF2 at compile time, so when flashed it places the code on the device's SPI flash chip? (RP2040-based)
maybe, the solution to that depends on the purpose, why do you want to do that ?
I'm building a testing jig for a custom PCB of mine (E-Fidget). I want to flash CircuitPython to the board, and also flash code.py alongside it. Bundling it seems the most straightforward, but if there's a better solution, I'd be happy to hear it ๐
There is no reason it wouldn't work. But you would need a tool to include code.py or likely the entire CP drive (for libraries) into the UF2. May require a core change, not sure
- it it possible to dump the current content of the flash (including CIRCUITPY) into a UF2 that you can then use to flash a new board, effectively cloning your reference board
- it is possible to make a build with a frozen library that you want to be always available even if the board is erased, and import it from code.py
- it is possible to change the code that creates code.py, which it does in C write() calls, not from a existing python file
I would say you want number 1
picotool save --all my_full_board.uf2
Wow I was just going to explain my reasoning for wanting #1, but you're way ahead of me! Thanks a million!
I wonder, does C have a preprocessor thingy to include the content of a file as a string ?
Idk, but I know people store 3D printer startup logos in C header files and there's generators for that code. Something similar might work for encoded text, but I'm no expert.
picotool probably works best. CP core does have code to set up the filesystem in the designated area of flash. So that could be modified to store more files. (I think it does create the default code.py)
No, I don't think it'll slow it because it still uses dma.
Good Deal! Sorry I couldn't make the changes myself. MST very busy and we are going to use this API in a product. I hope to find time to extend to other processors as time allows.
no problem!
I tested on a Feather RP2040, connecting A0 and A1 to ground and 3.3V. I tested both 8 and 16-bit reads. The values I read are in the range I expect, but are surprisingly noisy, which is weird. I tried samples rates of 1000-664000. But plain old AnalogIn also seems to be noisy. So I think the module is working fine, but we might want to look at whether we are setting up the ADC properly in general.
In any case, thanks for the API improvements!
@tulip sleet: Can you indicate the percent of noise as related to the signal in? It might be "normal" noise.
I mean I normally see 1%
>>> abi = analogbufio.BufferedIn(board.A0, sample_rate = 32000)
>>> abi.readinto(b16)
100
>>> b16
array('H', [4785, 5265, 6145, 6417, 7217, 7409, 7937, 8177, 8354, 8834, 8834, 9346, 9266, 9730, 9746, 9954, 10146, 10050, 10418, 10274, 10578, 10498, 10626, 10770, 10626, 10946, 10658, 10978, 10850, 10978, 11058, 10930, 11186, 10930, 11138, 11138, 11074, 11218, 11026, 11282, 11090, 11138, 11218, 11106, 11282, 11106, 11218, 11154, 10962, 11154, 10930, 11106, 11074, 10978, 11138, 10978, 11106, 11138, 11026, 11250, 10978, 11058, 11170, 11026, 11218, 11026, 11138, 11106, 10882, 11250, 10850, 10962, 11010, 10754, 11154, 10706, 11010, 11106, 10786, 11202, 10818, 10978, 11026, 10770, 11170, 10786, 10930, 10978, 10770, 10930, 10786, 10754, 10962, 10802, 10850, 10946, 10770, 11010, 10962, 10914])
>>> a2
<AnalogIn>
>>> a2.value
10274
>>> a2.value
2192
>>> a2.value
176
>>> a2.value
16
>>> a2.value
7393
>>> a2.value
288
>>> a2.value
10498
>>> a2.value
4417
>>> a2.value
6913
>>> a2.value
9602
>>> a2.value
6817
>>> a2.value
400
>>> a2.value
9458
>>> a2.value
1616
>>> a2.value
11954
>>> a2.value
9794
>>> a2.value
1424
way more than 1%
did you test on a Feather RP2040?
I am just jumpering with a short jumper between 3.3V, GND, and the various analog pins
My testing was only on the Pico RP2040.
I will try that in a bit, but I'm running out of time for today. Thanks for the feedback.
ok.. will tune in later. Thanks!
Uff. Trying to build for Feather RP2040 with a change to pins.c. This is the result I'm getting. mkdir -p build-adafruit_feather_rp2040/genhdr {'sku': ['GD25Q64C', 'W25Q64JVxQ']} {'sku': ['GD25Q64C', 'W25Q64JVxQ']} text data bss dec hex filename 244 0 0 244 f4 build-adafruit_feather_rp2040/boot2.elf GEN build-adafruit_feather_rp2040/genhdr/moduledefs.h QSTR updated File "<fstring>", line 1 (offstart=) ^ SyntaxError: invalid syntax make: *** [../../py/py.mk:274: build-adafruit_feather_rp2040/genhdr/compression.generated.h] Error 1 make: *** Waiting for unfinished jobs....
Although, thinking about it, I don't know how we want to handle that there's now a user-controlled button available, because obviously folks are going to have the previous version without the button available as well.
I did a pull and a make fetch-submodules before starting any of this, it seemed successful.
Feh. I'll deal with this next week. I guess I'm done for the night.
did you try make clean for it to start?
and I get the deal with it next week, how I felt by the end of my work day ๐
I did.
A few times. After every different iteration of the board build command I tried, or to see if it was a glitch the first time.
Even remembered to before running it the first time.
Good luck next week! I'm not thinking clearly enough to really know beyond that what it could be ๐
When I have build errors at the end like that, I usually find that there's another error much earlier in the make process that I have to scroll back and find.
Deleted the busy-wait code in PWMOut.c as referenced in Issue #7224. As discussed with @tannewt, this fixes the slow update of servo position, and the deleted code is no longer required by the pulse out driver.
Tested using simple test code controlling seven standard 50Hz servos.
Sorry folks, been AWOL with production line issues for the last few weeks :(
I'll have another look over my TinyPICO board settings compared to MicroPython. Maybe I missed something, or set something wrong, though I'm pretty sure I checked them before doing the PR.
I'll also look into how MP includes the Flash/PSRAM cache issue IDF fixes, as they need to be included to have both Flash and PSRAM working together, and PSRAM to work properly.
I'll get onto this as soon as I can @Retired...
Running mDNS finder now on Pico W for comparison:
Adafruit CircuitPython 8.0.0-beta.4-68-g6e40949f6 on 2022-12-02; Raspberry Pi Pico W with rp2040
No crashes yet, but two differences in results:
- there's a debug message remaining in
raspberrypi:found service 0x******** - there are duplicate results in each
raspberrypifind, no duplicates inespressif
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.4-57-ge82a8bf8b on 2022-11-30; Adafruit Feather ESP32-S3 TFT with ESP32S3
Code/REPL
# Powering down TFT-display and sensors
p.value = False
# Create a an alarm that will trigger 120 seconds from now.
time_alarm = alarm.time.TimeAlarm(monotonic_time=time.monotonic() + 120)
# Exit the program, and then deep sleep until the alarm wakes us.
print ("120 seconds in deep sleep")
alarm.exit_and_deep_s...
Just re-upping this. safemode.py would be a welcome and IMHO crucial addition.
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.4 on 2022-10-30; Adafruit Pybadge with samd51j19
Code/REPL
anything
Behavior
Press ctrl+s in Thonny to save takes a long time with error message on display

Description
No response
Additional information
Thonny issue but no response: https://git...
I had the same symptoms when building in Debian:
make BOARD=raspberry_pi_pico_w
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity. make: cmake: No such file or directory make: *** [Makefile:95: build-raspberry_pi_pico_w/pioasm/pioasm/pioasm] Error 127
I have run:
sudo apt install cmake
cmake version 3.18.4
and now I'm able to build it.
I got a brand new QT PY ESP32-S2. I loaded your DEBUG=1 firmware above. I got a CP210x USB to serial dongle and connected it to the QT PY (TX to RX and RX to TX). I connected to the serial port using Putty at 115200 from a Windows computer. Unfortunately, I did not receive any communication from the QT PY. I tried rebooting the QT PY and nothing came through. I reversed RX and TX but still nothing.
I hooked up the CP210x dongle to my scope with serial decoding enabled and was able to...
I have small suggestion re the tone examples in the docs e.g. here:
https://docs.circuitpython.org/en/latest/shared-bindings/audiocore/index.html
If one were to up the sample frequency, it would be easier to distinguish between quality problems in audio due to low samplerate as opposed to problems in ones hardware:
import audioio
import board
import array
import time
import math
# Generate one period of sine wav.
length = 44100 // 440
sine_wave = array.array("h", [0] * length)
for i in range(length):
sine_wave[i] = int(math.sin(math.pi * 2 * i / length) * (2 ** 15))
dac = audioio.AudioOut(board.SPEAKER)
sine_wave = audiocore.RawSample(sine_wave, sample_rate=44100)
dac.play(sine_wave, loop=True)
time.sleep(1)
dac.stop()```
I'm mentioning it because it's quite widely adopted throughout the learn examples as well
The filesystem might be corrupted, causing it to be read-only. Retrieve off the files you need, then do:
import storage
storage.erase_filesystem()
and put the files back. See if that fixes it.
@slender iron Do you know what happens in audioio if a ...get_buffer() returns a NULL buffer (and len 0) and GET_BUFFER_DONE?
The problem is, it can't know if there is going to be more data available until the actual call, so it can't really determine if it is done playing until the actual ...get_buffer() call where it discovers there's nothing left. If a NULL buffer (and zero length) won't break the audio playback system, then I should be able to just return those with GET_BUFFER_DONE.
Or maybe I should have it continue to just stream empty sound when the buffers are empty and only terminate when the user instructs it to? Otherwise, if it empties because the audio isn't being generated fast enough, it has to be restarted... Is there a memory location that always returns zeroes when its read and is at least 265 bytes long? (Maybe an unmapped section of memory? But then, wouldn't this be hardware dependent?)
Either way, it would be nice to know if the audio system can handle a NULL buffer being returned without crashing.
@tulip sleet were you last looking into the plops when starting and stopping PWMAudio?
we are scoping some things on a rp2040 board and the problem could be twofold:
- RawSamples seem to be offset, so at the play of each RawSample theres a jump by half the amplitude; the hardware HP filter filters the DC offset out so that results in a big plop at the beginning and end
- WaveFiles behave like they should, but in the first 8 milliseconds the read is scrambled and the sign gets flipped for a short stretch, so there are plops when that happens; there is no offset though
would this be better posted in a github issue like this one? https://github.com/adafruit/circuitpython/issues/5136
okay we tried with a sample that has 4ms silence at the beginning, and the the first 4 ms of wave playback just have some signal inserted
strange
like there is some data in the buffer that just gets written before the actual data is being played
this is dependent on the buffersize
and the results are consistent for each buffersize
We have been looking at the output from PWMAudio with a scope, and it seems that PWMAudioOut is adding a blip of audio unrelated to the actual sample into the first 4ms of the playback.
The blip is consistent when using the default buffer size and a buffer of bytearray(512), and changes to something different but consistent with other buffer sizes.
Here are some scope pictures where you can see what's happening:
The waveform in Audacity. The sample is mono, 44.1khz, 16 bit.
<img w...
here's how the wave looks
and this is what we get on the scope
more images in the github topic
[pico w] there is some documentation on the spi protocol of the cyw43 .. https://www.infineon.com/dgdl/Infineon-CYW43439-DataSheet-v03_00-EN.pdf?fileId=8ac78c8c8386267f0183c320336c029f
I'm trying to understand what is supposed to be required by the hardware. I found a boot-up sequence timing diagram in https://www.infineon.com/dgdl/Infineon-CYW43439-DataSheet-v03_00-EN.pdf?fileId=8ac78c8c8386267f0183c320336c029f page 24

cyw43-driver implements the algorithm to poll for predefined pattern:
cyw43_spi_gpio_setup();
cyw43_spi_reset();
// Check test register can be read
for (int i = 0; i < 10; ++i) {
uint32_t reg = read_reg_u32_swap(self, BUS_FUNCTION, SPI_READ_TEST_REGISTER);
if (reg == TEST_PATTERN) {
goto chip_up;
}
cyw43_delay_ms(1);
}
CYW43...
On the topic of issues with audio:
I've noticed that when I'm not actively playing audio, I get audible white noise and sometimes quiet whistling from the speaker. I'm currently using a mixer, and if I play a "silence" buffer that is just zeroes on loop, I get very quiet white noise (only audible very close to the speaker) similar to a speaker with no input signal, but if I don't do that when I'm not playing something, there's a lot of static, whistling, and audible white noise. I suspect when nothing is playing the PWM is just being shut off completely, but it doesn't make sense to do this. If the pin (I tried several) is setup with a PWMAudioOut object, it should be assumed a speaker is connected whether it is actively playing or not, and the queiscent level should probably be played when nothing else is. Note that I'm using an RP2040. It's possible pin levels are more stable with the PWM off on other chips.
Also worth noting: When the device automatically resets when the filesystem is written, I get a ton of noise on all of the pins I've tried for audio. I've observed this on at least A0-A2 on the RP2040. It doesn't happen when the reset button is pressed or when it is plugged into a USB battery. It also only clicks slightly when first plugged into a computer. When it automatically resets though, the crunchy, kind of loud noise that comes from the speaker is pretty jarring. I have not tried programmatically resetting or waking from sleep (light or deep) to see if the same thing happens there.
I can open issues on Github for these later, if they aren't already there and if it seems like a good idea.
This may fix #7112, though the root cause is unclear so I'm uneasy about making the change.
The safe-mode wait does not always happen, is that right?
Thanks for researching this. Add all the info you have to the issue.
From the timing diagram, looks like 85 msecs or so? So maybe could use a 100msec delay before the startup. That's short in the scheme of things. Could note whether safe-mode delay actually happens and act accordingly, but a 100msec delay is simple for now. The reporters here will need to re-test.
While I can't speak to it all I think the file save/REPL reset is the fact CP itself is busy writing/resetting and the PWM code isn't getting the CPU time it requires. The core could likely be changed to somehow disable the PWMAudioOut while those tasks are happening.
I agree it is jarring though
Yeah, I kind of figured that was the case. If the PWM was shut down first, that would help. Actually, I wish there was some kind of reset hook, where you could basically make it run a callback when it resets, before the actual shutdown and reset stuff happens. At least that way, I could add code to shut down the PWM myself before it resets.
That said, I'm just very thankful that it only happens during software resets triggering by file writes. I don't know if I'm ever going to try to do a commercial product with this, but I do want to make several copies of my current project to send to family members, and it would be nice if it worked smoothly for them. A very slight click when powering by computer isn't a problem, and of course, battery power not having artifacts at all is even better for that.
There's already a 250ms sleep after turning on the regulator though: sleep_ms(250);. Unless we're messing with the regulator state accidentally somewhere.
.. and waiting with the regulator off shouldn't be able to help anything, if it's about the time from reset to usability of the cyw43 chip
To add to the confusion, I can only reproduce the problem with the released beta.4 (Adafruit CircuitPython 8.0.0-beta.4 on 2022-10-30), but when I built from source (Adafruit CircuitPython 8.0.0-beta.4-65-g082b0d1ae from git checkout 082b0d1ae) it works fine. I did build debug so there might still be some timing changes, but there might be other variables too.
CircuitPython version
CircuitPython 7.3.3 on 2022-08-29; Adafruit Feather ESP32-S2 TFT with ESP32S2
Code/REPL
import board
import busio
import digitalio
import adafruit_requests as requests
from adafruit_wiznet5k.adafruit_wiznet5k import WIZNET5K
import adafruit_wiznet5k.adafruit_wiznet5k_socket as socket
print("Wiznet5k WebClient Test")
TEXT_URL = "http://wifitest.adafruit.com/testwifi/index.html"
JSON_URL = "http://api.coindesk.com/v1/bpi/curr...
Did you try spi_bus = board.SPI()?
Thanks, that works!
At least I can work with the ethernet featherwing now.
But how can I then use the display in parallel?
Should be no trouble, the display is already set up and you can use it for REPL / terminal or displayio in code.py
btw, Discord is a great place for support-type questions... https://adafru.it/discord
speaking of support questions, it would be interesting to mention in the board guide how to use SPI on the TFT feathers. I doesn't seem to be mentioned anywhere.
I don't remember encountering that situation before, but it might be the only boards with external SPI pins that are shared with the display pins.
Dan, you around?
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.4 on 2022-10-30; Raspberry Pi Pico with rp2040
Code/REPL
import board
import pwmio
class PWMOutExtend(pwmio.PWMOut):
def __init__(self, pin, frequency=1000, slew_rate=1000):
super().__init__(pin, frequency=frequency)
self.foo_bar_baz = 0
self.duty_cycle = 0
led = PWMOutExtend(board.GP25, frequency=1000)
print('before')
led.foo_bar_baz = 0
print('after')
...
After erasing the file system on a pi pico W the issue persists. Not tested on EdgeBadge yet but seems like it's unlikely due to a file system corruption. How do you get logs like what you see on EdgeBadge's screen on a Pico W?
Just flashed the latest circuit python build available on the S3 bucket (adafruit-circuitpython-espressif_esp32s3_box_lite-en_US-20221203-a50b0a2), still the same issue.
Pending creation id PR at https://github.com/creationid/creators/pull/27
Works:
REPL via USB CDC/JTAG port
GPIO
SPI via busio (no fixed pins on board silkscreen)
I2C via busio (no fixed pins on board silkscreen)
Onboard LED and LED2 (LED used for status)
Wifi and Web Workflow
Doesn't Work:
Nothing in particular
If Thonny is trying to write the file by executing REPL commands, which it does no boards with no mass-storage USB connection, then you will see that message because the filesystem is read-only to the CircuitPython side. It is read-write to the the host computer, which has a regular USB-drive connection.
I just tried to write a file with an ESP32-S2 board, which presents CIRCUITPY as a USB drive. Thonny is able to write. I think Thonny tries to figure out that CIRCUITPY is present and writ...
Oops, noticed the daily report shaved off a couple digits of the total PyPI downloads
Whoever is hosting (or preparing the document) please tag me when I can edit it please!
I got a BOX Lite on Friday and will be testing this.
Kattni is hosting - I went ahead and copied the daily report into the doc, so feel free to edit whenever
Thanks!
No problem. @idle owl - fyi, in case you're wondering where it came from. ๐ ๐
Thanks so much!
Yes, it does work, the usb drive mode works fine. I think something is wrong with thonny's REPL.
MicroPython allows writes from the Python code and the host, which can cause corruption if the writes are concurrent.
Closed until there's more evidence it's a CircuitPython issue
Working with @LovelyA72 in discord, I could not reproduce this problem in Windows 10 using both the standalone install and the pip3 version of Thonny 4.0.1.
Take a look at atexit I believe we support it now
I'm not sure about the NULL buffer support. It may depend on what code is getting the buffer
in terms of PWMAudio, I think the PWM always has to be on quiescent_value even when the sample is not playing - because if you have the DC filter circuit, and the pin just goes low, you get a massive pop at 1/2 max volume, filtered at the cutoff frequency of the HP filter
that's what's happening here
it happens consistently on RP2040 with every PWM WAV audio play, so there's a good chance it's just a bug somewhere
maybe the buffer is completely 0 for one cycle before it gets filled or something like that
other than that the wav playback is really cool
(the swoop behind the glitch is possibly the DC filter trying to do its thing ..)
@proven garnet have you looked into adding version dependencies to pypi in the libraries, or is it already done in some way ?
Somebody was having an error caused by an old version of circuitpython typing, because the adafruit_register library uses circuitpython_typing.device_drivers.
Forcing the update or reinstall via requirements.txt would not update typing since it's not a direct dependency. Is there a better way to force updating a secondary dependency like that ?
like, can something like dependabot know that using circuitpython_typing.device_drivers requires a certain version and then add that requirement to adafruit_register ?
Typically, if something requires a version of circuitpython_typing, it's explicitly called out in that repo's requirements.txt.
Yeah, it sounds like it. The requirement for Blinka is kept open so it doesn't conflict (and it only needs base anyway)
I can add it now
thanks ๐
Oh, it was me who added type annotations so whoopsies ๐
Oh weird, I did pin it to adafruit-circuitpython-typing~=1.3
So it is a direct dependency but didn't update?
Can you link me to the issue/post? Curious if there's more information.
<@&356864093652516868> Weekly meeting in less than an hour! Please add your notes for Hug Reports and Status Updates to the notes doc if you plan to participate. Chat with all of you soon! https://docs.google.com/document/d/1ptMf7fIRq2yolUExcbnVyn5A8O00i6YRinAmMOWrUH8/edit#
oh I missed that, I think device_drivers was added in 1.7.2
I believe the person had forced reinstalled requirements.txt of the library they are using, of which adafruit_register is itself a dependency, therefore reinstalling adafruit_register but not it's dependency ? Is that how that works ?
that's the error:
#help-with-circuitpython message
that's not a force-reinstall
#help-with-circuitpython message
hmmmm
that's probably unrelated
#help-with-circuitpython message
Thanks! I'll check this out in a little bit when I get a little bit of time on my end!
@Neradoc have you heard of memory issues on smaller boards?
@PheebeUK Want to add the pin into board? We can guide you to make the change. (I don't think we have the board ourselves.)
Break now needs to be implemented in Mu and other REPL terminals.
Can someone jump into the voice channel so I can test my audio?
@slender iron Do you want to read the core?
sure!
Hanukkah Lightsaber!
Toward the Jewish month Kislev, the month of light, I built Hanukkah Lightsaber prop based on a makers project of the Adafruit company. Beside building the hardware, I made the necessary adjustments for the Hanukkah holiday. 30 colored RGB Neopixel LEDs are connected to Adafruit's CircuitPlayGround board, responsible for pr...
Attached: 2 images
First light on PicoTouchSynth and the capsense pads work better than my PicoTouch board! And the reverse-mount #NeoPixel LEDs are totally awesome. The test code is in #CircuitPython of course
๐ ๐
๐ ๐ฏ
@errant grail I feel you on the snow, that was me too last week
+1 on the snow here too
@errant grail ooh palette rotation effects in circuitpython displayio? Would be neat to see as a core PR, if that's your jam.
Ours is just a dusting compared to your neck of the woods.
That's the plan. Have to completely prove the concept then will file an issue. Want to do the same with displayio.Group objects, too.
it'll feel very 90s, in a good way
now that I'm thikning of the 90s I wonder if it's feasible to port fractint (very old, originated on DOS, fractal generator) to a microcontroller
... or the 60s, depending on your frame of reference.
I missed the 60s the first time
It was groovy, man. (a trite colloquialism lost in time)
@lone axle if you need any help testing Wiznet, let me know, happy to help
Thank you!
This came from a need to broadside load a palette from a ulab array.
@minor plume so glad you are safe! Having a tire problem while travelling at speed is no laughing matter.
@slender iron I have an opening in the workshop for a logic analyzer FeatherWing. Excellent.
what would you use it for?
Primarily for troubleshooting I2C transactions of some of my custom boards. I also have some old TTL logic designs that need attention.
Would be very useful for automated board testing if it could process / recognize waveform patterns.
Thanks! I was very lucky.
Thanks for the overview Jeff. Appreciate all the work and discussion going in and you summarizing for us.
Can't believe it's been a year already ๐
It works well
That was my thought, like what really?
@lone axle You're welcome, I hope I gave a good overview of the situation. For my part I've appreciated all the good brainstorming and finding a good solution
I love reading everyone's ideas, 2023 will be another good year
next meeting is the 12th
I just went back to look at what I wrote last year
Thanks all
Thanks everyone
Thanks!
Open source project from purely your own mind? That's pretty great multithreaded imagination
Thanks Kattni
Cheers all! Have a great one!
Thank you! Good job getting the PR going!
My build should have debug output to TX, not the REPL. Try flashing the bin with esptool. (or make BOARD= PORT= flash from within circuitpython). Perhaps UF2 bootloader doesn't change the second stage bootloader.
Do we think there should be identical duplicate behavior?
Sure thing. I'm assuming it's adding something like:
{MP_ROM_QSTR(MP_QSTR_HICHG),MP_ROM_PTR(&pin_P0_13)},
to the pin definition file, and then creating a merge request? That's my knowledge of the theory at least!
Thanks, I'll take a look! (I was kind of hoping someone would know of such a hook and correct me!)
I guess I can always just try returning a NULL buffer and see what happens. (It's possible that with len=0 it won't attempt to read, even if it doesn't explicitly check for NULL.) I might be able to figure out where it is called from by grepping the entire code base, but I'm not sure how the polymorphism is handled in C, so I'm not 100% sure what to grep... I can guess and just try things though I suppose...
in C it ends up as a function pointer
audiosample_get_buffer wraps it
@slender iron Do you want me to request graphics for CircuitPython 2023?
yes please! I hadn't thought of that
Ok, that makes sense. Thanks, that will help!
No, I have seen nothing that seems directly linked to this. I wanted to look around at issues raised since the change but I got nothing. I think we can close this and revisit it if and when it becomes an issue.
Generally native classes aren't subclassable because our C code doesn't always check to ensure it was given the native struct representation. Ideally we'd have a way to do this for everything.
In the meantime, I'd suggest wrapping PWMOut instead of subclassing.
I'm not seeing this behavior on an ESP32-S3 USB OTG board. Here is my bootloader output showing repeated 2 minute deep sleeps:
[00:02:06.793] ESP-ROM:esp32s3-20210327
[00:00:00.006] Build:Mar 27 2021
[00:00:00.000] rst:0x5 (DSLEEP),boot:0x8 (SPI_FAST_FLASH_BOOT)
[00:00:00.005] pro cpu reset by JTAG
[00:00:00.000] SPIWP:0xee
[00:00:00.000] mode:DIO, clock div:1
[00:00:00.000] load:0x3fce3808,len:0x68
[00:00:00.005] load:0x403c9700,len:0x980
[00:00:00.000] load:0x403cc700,len:0x...
Version: Adafruit CircuitPython 8.0.0-beta.4-75-gd7874e65c on 2022-12-05; ESP32-S3-USB-OTG-N8 with ESP32S3
@PheebeUK That's the idea. Let's call it MP_QSTR_CHARGE_RATE or something like that, since we are not abbreviating CHARGE on the other pins.
It seems hard to find documentation on this pin. I also cannot find a good schematic for the whole board. Do you have some links besides the link you gave in the first post?
@slender iron Requested. I'll let you know when I have it. I also requested a web-banner sized version of it, and I'll have Justin add it to circuitpython.org like we did for CircuitPython Day. (The infrastructure is already there, adding a new image is trivial.) We can leave it up until we're done with the call.
Thanks!
Who was talking about trying to combine MatrixPortal or PortalBase examples in today's Weekly meeting? Was it foamyguy?
Agreed. It's an edge case: lower-SRAM devices (ESP32-S2 and maybe ESP32-C3) boards with no PSRAM and trying to use an unusual amount of espidf memory.
Yup
Thanks!
Indeed it was. I did manage to combine the weather and clock examples to switch back and forth with button press, and automatically with a timeout. I want to brainstorm a bit and tinker with a few of the other examples to try to come up with some more general advice and documentation that would be helpful for people looking to combine multiples of them.
There are a few ways it could work with different trade offs though.
Erasing the board and then flashing my firmware.bin with https://adafruit.github.io/Adafruit_WebSerial_ESPTool/ did the trick. Thanks!
Both Putty on Windows using a dongle, and Tio on the Raspberry Pi using GPIO pins works.
I was also able to redirect the debug UART to pins 40 and 41 so I can run the debug serial cable out the side of my project enclosure.
Unfortunately, my program gets stuck right after I2S configured:
self._audio = audiobusio.I2SOut(bit_clock=TX, word_select=RX...
Hello,
I just ran into this same issue while trying to leverage the code on this adafruit guide. https://learn.adafruit.com/circuitplayground-morse-code-flasher-makecode-circuit-python/circuitpython
I submitted some feedback on the website itself already but in case anyone else runs in this issue, here is what I did:
pixels = cpx.pixels pixels.fill((0, 0, 0)) pixels.show()
@analog bridge here is my WIP for coproc rework: https://github.com/adafruit/circuitpython/compare/main...tannewt:circuitpython:rework_coproc_api?expand=1 basically moving it to an esp specific espulp module
and a generic memorymap one
It looks like it's working as intended and installing adafruit-circuitpython-register at version 1.3.0
So perhaps I pinned it wrong, but it looks correct per the release notes
register uses device_driver which requires typing 1.7.2 minimum
Requirement already satisfied: adafruit-circuitpython-typing in /usr/local/lib/python3.7/dist-packages (from Adafruit-Blinka->-r requirements.txt (line 6)) (1.3.0)
or at least I think so ? it's hard to know on github what version a commit is in
Found the issue!
if it's in 1.3.0 how come there is a missing thing error ?
Faulty import within circuitpython_typing:
from adafruit_bus_device import I2CDevice
oooooh
Should be from adafruit_bus_device.i2c_device import I2CDevice
but it's fixed so the version requirement should be bumped to a version where it's fixed, right ?
which would be 1.3.1
yeah I wrongly interpreted the error, I didn't think there could be other reasons why the import failed
It's tricky, it's one of the challenges of using the blanket ImportError catch honestly, that we lose the history of where exactly it failed during the import.
The only way I found it was by editing that to just raise the error.
Running in safe mode! Not running saved code.
You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Crash into the HardFault_Handler.
Please file an issue with the contents of your CIRCUITPY drive at
https://github.com/adafruit/circuitpython/issues
Press any key to enter the REPL. Use CTRL-D to reload.
boot_out.txt
[code.txt](https://github.com/adafruit/circuitpython/files/10163085/co...
My QT Py ESP32 Pico was delivered today. It does not seem to have this same memory issue.
Also one change to code.txt is that I was adapting the gfx_ili9341_test.py code in the examples for the gfx library and so the baudrate was set to 32000000 when it broke.
i.e. "BAUDRATE=24000000" was "BAUDRATE=32000000".
Possible cause?
Not getting the results I wanted. I've got an atexit registered function that stops the only mixer voice I currently have, and then it deinits the Mixer object and the PWMAudioOut object (I tried it in both orders). I've got a print statement at the end to make sure it runs, and it's outputting the print to the serial monitor, so it's definitely running. I'm still getting the loud, crunchy audio when it soft resets on file save.
It seems like atexit maybe isn't running before the soft reboot code, or maybe the PWM isn't being fully shut down on deinit? This isn't a huge deal for me, as it won't matter for the finished project, so I don't have time to try to debug it. I do have a few more things I can try, and I'll continue to post results here, so that if someone else wants to dig into this, they have a good starting place. I do think I'll try setting up the pin as a digital output in the function I've registered with atexit. If the PWM isn't being fully shut down on deinit, setting it up as something completely different might do the trick.
Doesn't make any difference if I set the pin to DigitalInOut after deiniting the audio stuff. Also makes no difference if I set to INPUT (with pullup, pulldown, or whatever is default (neither?)), or OUTPUT.
(I'm using pin A0 on the QT Py RP2040. I've also tried putting the audio output in pin A1, and it does the same thing, but I didn't test the atexit function that deinits stuff. The speaker is soldered to A0 now, so I have no intent to try anything else on other pins anymore, at least, unless someone can verify that some other pin does not do this and will still support audiopwmio output.)
My QT Py ESP32 Pico was delivered today. It does not seem to have this same memory issue.
That's using a different ESP32 chip and different PSRAM. So different settings and it doesn't require any cache fixes for IDF.
@dhalbert It took me a while to find them, documentation is frustrating for this board. Schematic is available in a ZIP at XIAO BLE Sense Getting Started.
@serene token you could try modifying the CP reset code itself. We are likely floating the pin now and that could cause issues
Please try the "absolute newest" version of CircuitPython too. It is possible the bug has already been fixed in newer versions.
Thanks for the discussion! We can open another issue if we change our minds later.
You may want to change the debug level in the debug sdkconfig You can change the DEBUG to INFO to do this. That will stop that message. It looks to me like it is doing the I2S output by alternating buffers.
I'd then add more prints to see where CP is getting stuck.
Hi everyone. My first message here.
Is there any plans, or is anyone working to get ANT+ on CircuitPython, specifically for the NRF52840 boards?
I am asking because I am very interested to have it, as I use it for implementing ANT+LEV EBike standard as also GPS cycling display Garmin Edge page change. The code is in C, similar to Nordic SDK code, if anyone is interested: https://github.com/OpenSourceEBike/EV_Display_Bluetooth_Ant/tree/main/firmware/display/antplus_lev
@timber mango I don't know of anyone working on it. We're happy to help folks contribute though!
I do not know if I have enough knowledge to implement a Pyhton module for the most basic ANT+ device....
the first step is to file an issue: https://github.com/adafruit/circuitpython/issues/new?assignees=&labels=enhancement&template=feature_request.md&title= that way others can coordinate and give tips
tio's timestamp diff print is super handy for "why is there 20 seconds between those prints?"
Version tested 12/6/2022 2:20 pm est
Adafruit CircuitPython 8.0.0-beta.4-77-g5cb867e85 on 2022-12-06; Adafruit Feather ESP32S3 No PSRAM with ESP32S3
This code does not even go into light sleep much less deep sleep
import alarm
import time
import board
import digitalio
board.DISPLAY.brightness = 1
led = digitalio.DigitalInOut(board.LED)
led.switch_to_output(True)
time.sleep(2)
led.value = False
Create a an alarm that will trigger 120 seconds from now.
time_alarm = al...
Latest uf2-File installed - no change in behaviour: First time: 120 seconds sleep, from then on starts immediately
#Adafruit` CircuitPython 8.0.0-beta.4-77-g5cb867e85 on 2022-12-06; Adafruit Feather ESP32-S3 TFT with ESP32S3
# SPDX-FileCopyrightText: 2021 ladyada for Adafruit Industries
# SPDX-License-Identifier: MIT
# Adafruit esp32-s3 TFT feather Board
# mit drei Sensoren:
# - Distanz vl53l4cd
# - Helligkeit bh1750
# - Luftqualitรคt, Luftdruck, Temperatur, Feuchtigkeit, ...
Here is the notes document for next Mondayโs CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youโll be attending the meeting - itโs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weโll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1R2f9muwRpn1CUUJYalfiHJexKAi3fQqJQJrsefCxQ1s/edit?usp=sharing
- Set nonblock on all accepted sockets. Not just ones for user code.
- Close an open websocket if another is accepted.
- Set debug level to INFO rather than DEBUG because DEBUG crashes on ESP32-S3 USB OTG.
This works now. Thanks @makermelissa
@tulip sleet #7309 above would be good to have in the beta
The program still freezes with the same debug output right after intializing the audiobusio.I2SOut. I changed the debug level and ran make clean before running make again. I erased and programmed the QT PY using ESPTool with the firmare.bin. Are my edits correct?
I did notice the following line in the debug output:
`E (2648) I2S: i2s_driver_uninstall(2047): I2S port 0 has not i...
I pointed you to the wrong debug level. That one is for the second stage bootloader. There is one further down in the file for the user program: https://github.com/adafruit/circuitpython/blob/main/ports/espressif/esp-idf-config/sdkconfig-debug.defaults#L76
That fixed it. Actually, the program is now up and running without any issues. For some reason the debug level was preventing the I2S from working.
I'll let it run and hopefully I'll get a core crash soon with a back trace.
Thanks for your patience!
Just starting work again; I had to install a new dishwasher and it took about five hours.
what became of the "board and port specific limitations" page ?
it is distributed into several places: where possible it's in the documentation for various things (e.g. in busio.UART). Other stuff is now in the FAQ here: https://learn.adafruit.com/welcome-to-circuitpython/frequently-asked-questions
ah ok
and some stuff about limitations of various Espressif thing (like limited BLE) (if I remember right) is in all the relevant board guides (if something is missing, I can add it)
Ok that got it thanks, much appreciated.
Also while I have you, where do I find documentation & downloads for the "machine" library or am I not meant to use it with this board?
@k1w1tim machine is MicroPython-only. The equivalent features are in other CircuitPython modules and libraries. See: https://docs.circuitpython.org/en/latest/README.html and https://learn.adafruit.com/welcome-to-circuitpython
Community support is available on Discord: https://adafru.it/discord
Set debug level to INFO rather than DEBUG because DEBUG crashes on ESP32-S3 USB OTG.
Wow, good catch!
The audio stuff I'm doing is higher priority right now, but once I've finished with the audio stuff, I'll look into this. Any idea where I would look for the reset code?
Kattni: Thanks for talking about the Feather RP2040 new rev in the meeting yesterday. Was trying to figure out what to do about the Lolin C3 Mini rev 2.1 board, which added a neopixel to the design but is otherwise essentially the same. The issues are almost identical.
You're quite welcome!
Not sure why but the program can't maintain a stable Adafruit IO connection with DEBUG=1 and also using I2S. My version without I2S ran for a day without dropping a connection. However, the 2 boards I just set up with I2S have been online for only an hour and have dropped 3 times with very unreliable service.
Here's the REPL view:
WiFi Hostname: QTPY19871
Connecting to Adafruit IO...
Adafruit IO connected. Client ID: QTPY19871
Subscribed to rdagger/feeds/test at QOS level 1
Fr...
You can hack it in common-hal/microcontroller/Pin.c usually (on my phone so I canโt link ya easily)
I wish to be able to use ANT and ANT+ on NRF52 boards. I use it for implementing ANT+LEV EBike standard as also GPS cycling display Garmin Edge page change but in C, similar to Nordic SDK code, if anyone is interested: https://github.com/OpenSourceEBike/EV_Display_Bluetooth_Ant/tree/main/firmware/display/antplus_lev
No worries. That should be enough for me to find it easily. Thanks!
Alright, got it open in a browser tab, so I'll remember to look into it once I'm done with the current stuff. Thanks again!
We have not supported ANT and ANT+ because of the licensing fee requirements:
https://www.thisisant.com/developer/components/view-all-components/nrf52-ant-stack-licensing-faq
When I was researching this a while ago, I found that some bike devices that support ANT+ also support BLE, such as the Wahoo sensors.
It is not completely clear to me if Adafruit would be required to pay the licensing fee, because we are selling boards that could load the ANT+-capable software, even if just for hobbyist use, or if the licensing fee is meant to apply only to commercial products that use ANT+.
Yes, the DIY EBike display I built have simultaneous Bluetooth and ANT+, it works very well: https://opensourceebike.github.io
But I would prefer to develop again that display based in Python code instead. And ANT+ is a MUST for cycling devices, from electronics gears shifters, tire pressure sensors and the EBike motors.


Tested and now does not crash.
Adafruit CircuitPython 8.0.0-beta.4-68-g6e40949f6-dirty on 2022-12-06; ESP32-S3-Box-Lite with ESP32S3
>>> import wifi
>>> wifi.radio.start_ap("esp32", "12341234")
>>>
``
@sean-palmer-coding This seems to fix your problem in #7254.
@dhalbert I assume you are referring to this PR?
While this sounds like an improvement - the "unexpected behaviour" for users still is not fixed - until everybody learns about this new break control signal and all terminals implement it.
What would happen if the input buffer gets flushed, or discards just enough data to at least receive one Ctrl-C signal / 0x03 character from the user? Do we have such fine-grained control over the b...
@onyx hinge @slender iron I made draft beta.5 release notes. I think these remaining PR's are of interest to include:
https://github.com/adafruit/circuitpython/pull/7303 (cyw43 init hang)
https://github.com/adafruit/circuitpython/pull/7291 (orderly shutdown of ssl socket)
thank you! I will look at those two PRs tomorrow. Today I was concentrating on completing a guide.
@Kriechi As mentioned above, if we discard characters when the buffer is full, then we could be discarding valuable data. Unfortunately, there is no way to tell that a ctrl-C is waiting on the host side without reading it over USB; it is not prioritized in any way by the host. The "break" scheme is the only "out of band" method to communicate something down to the board.
It's not the only possible way (there are other serial control lines we could have chosen) but it's what we've chosen to implement. This implementation doesn't have to be the only solution, and having a conversation to arrive at a better solution would be welcome. Dan accurately identifies why we want a solution that is not an in-band character value as the only way to generate a KeyboardInterrupt, and why we don't want to implement a solution that will lose characters.
If there's concern about this solution we also have the option of marking it as an unstable feature e.g., via our release notes and documentation (in fact I probably failed to adequately document this, because I don't remember doing it)
My vote when I reported the issue the first time was for Mu to stop spamming the serial port with cursor movements, that would remove 99% of the cases encountered in the wild IMO. I can reopen that Mu issue with suggestions.
On a side node, considering this:
Even a soft-reload via auto-reload on USB file saving does not fix the input problem: it does reload and restart executing, but Ctrl-C is still not recognized.
We could reset the buffer on reloads maybe ? Or are there situations ...
I considered, but did not implement
- discard pending data when usb cdc disconnects
- discard pending data when soft-reload is triggered
I did not know if either of these scenarios would help mu. However, at least the first alternative might also help users, because re-starting the terminal program could be a natural impulse in the case that the buffer was filled. I'm not aware of how to do this in the TinyUSB interface but could investigate it.
CircuitPython version
adafruit-circuitpython-teensy41-en_US-8.0.0-beta.1.hex
and all newer builds
Code/REPL
Not a Code issue
Behavior
After flashing CircuitPython and rebooting the board, no serial port is available and no USB drive is mounted.
Description
I've tried compiling a DEBUG=1 build and creating a UART debug console to see if there are any boot loop messages being displayed by changing mpconfigboard.h as follows
// #defi...
I found an old 8.0.0 alpha.1 teensy 4.1 build that still works:
Adafruit CircuitPython 8.0.0-alpha.1-30-g8814ee03f-dirty on 2022-07-03; Teensy 4.1 with IMXRT1062DVJ6A
@slender iron Ok, so I think I've implemented all of the functionality needed in shared-module/audiocore/RawStream.c (aside from some things that will need to be tested that require moving forward first). (I'm calling the new class "RawStream".) I'm not sure what does and does not need to go in shared-module/audiocore/RawStream.h, as RawSample does not even include all of its functions in the .h file. The big hurdle though, is going to be shared-bindings. I have added two new functions that need to be accessible as methods within Python. One checks if the object is ready for another buffer, and the other writes another buffer to it (or returns "false" if there isn't room). Basically, I'm a bit lost on the shared-bindings stuff. Are there some resources for this? Or maybe it's time to put in a pull request and ask questions there?
Also, does the function signature need to be identical to that of RawSample? Is this part of the prototype/wrapper stuff, or can I drop the buffer argument in the constructor?
This is not necessarily official documentation. But Kmatch a community member put together this PDF that outlines shared bindings / shared module in a more visual way. I still refer back to this when I am making more substantial changes to the core.
@serene token the C functions that are put into the "protocol" struct need to be the same signature and the compiler should error if they aren't
the constructor should be able to be different
we'll want to move it to a new module to
I like the name RawStream
@onyx hinge got time to talk ULP programs?
@slender iron sure -- voice/video or text?
thinking video
OK give me 5 minutes to switch stations then
๐
One of the QT PY's core crashed last night at 2AM. Here is the last REPL message:
MQTTException: PINGRESP not returned from broker.
[tio 02:27:18] Disconnected
[tio 02:27:25] Connected
Auto-reload is off.
Running in safe mode! Not running saved code.
You are in safe mode because:
Internal watchdog timer expired.
Unfortunately, I didn't notice until this morning and my terminal only had 1000 lines of scrollback. The debug console keeps outputting the following lines (about ...
The status LED blinks tend to output that. It is probably easiest to comment out that print in the IDF, clean, build and flash again.
@RetiredWizard is that the last version that works? aka is the next commit the one that broke it?
@slender iron I am looking at https://github.com/adafruit/circuitpython/issues/7284. I think you actually already diagnosed this, based on the comments. Is it something like supervisor_bluetooth_background() should not advertise if the user program is running , or just if workflow_state is not WORKFLOW_ENABLED?
if you understand this better than me, do you know the fix? Maybe I should not have assigned it to myself?
I wouldn't say I've diagnosed it
I haven't confirm it is disconnected and then reconnected
rereading it, it sounds like they may want to wipe the bonding info
is the precursor condition that the workflow was enabled at one time and there is a bonded device that will try to connect? I.e., if you disconnect the background task will just reconnect again?
if no device is connected and we have bonding info for one, then we should try to connect
- advertise
so the premise that they want to disconnect all the connected devices is actually not right
ยฏ_(ใ)_/ยฏ
ok, I will try to reproduce ๐
@tulip sleet it may be worth asking if they just want to delete the bonding info
they are doing BLE HID, so the board is paired/bonded, I would think, right? So the background task will advertise, and it will connect? I was just going to ask for more details.
From the S2 archives the date/version of the last build that worked was 2022-08-29/7.3.3,
Everything more recent that I've tested has failed and everything earlier works. 8.0.0 Beta 0 is the highest version number created before that date and does work.
ya, I think so
so that is a case where we don't want automatic connection to a bonded device, I would think, we want it initiated by the program
they could disable the workflow then
I will just check that they have never used PyLeap or File Glider
But I think they never enabled it. It looks like the background task will automatically advertise maybe even if the workflow is not on
I thought there was a disable setting
I thought it had to be specifically enabled in .env. I was looking for a write-up
supervisor_bluetooth_background() is always called in bleio_reset()
even if workflow is not enabled
in any case, I will ask some q's and ask for the program
@xorbit The BLE workflow is a way of editing files and talking to the REPL over BLE. You use the File Glider or PyLeap iOS apps to use the workflow.
I just want to narrow this down. Thanks.
- Did you ever user either of those apps?
- Do you have an
.envfile on your nRF board? If so, what's in it (minus private info)? - If you "forget" the CPB board on the host device (e.g. a phone), do you have this problem?
- If available, could you point me to the entire code for your program?
@durandom I cannot reproduce your issue, as I mentioned. If you are still tracking down this problem, could you try the latest version of CircuitPython? There will be an 8.0.0-beta.5 shortly and there are relevant changes in the "Absolute Newest" version on circuitpython.org already. I will close this issue for now but we can reopen it or open a new one.
Hi Dan,
No, we've never used the BLE workflow. We've only ever updated the scripts over USB. There is no .env file on the board and since we didn't use the BLE workflow there is nothing to forget on the phone. The code is pretty much the plain Adafruit BLE HID example as far as BLE is concerned with the code above added to attempt a disconnect when a key is held on bootup.
Is this the correct code to modify:
https://github.com/adafruit/circuitpython/blob/main/supervisor/shared/safe_mode.c#:~:text=allow for reset.-,%23if CIRCUITPY_STATUS_LED,%23endif,-if (boot_in_safe_mode) {
Specifically comment out the following lines in supervisor/shared/safe_mode.c as shown:
/*
#if CIRCUITPY_STATUS_LED
status_led_init();
#endif
*/
...
...
/*
#ifdef CIRCUITPY_STATUS_LED
// Blink on for 100, off for 100
bool led_on = (diff % 250) < 125;
if (led...
I've still not reproduced the cyw43 start-up hang. How much extra delay do you want me to add?
I'll do it without the safe-mode messing around
If we could get one of the reporters to test it immediately, you could try 100ms. Otherwise we could leave it at one second temporarily, and ask them to test some builds with shorter intervals afterwards
so you are testing by plugging in, not by resetting?
and you tested your previously unused W's?
yes and yes
i will try mine with a stock build, just to make sure I don't have a susceptible one
mine is fine
I tested with beta.4, which is what theblinkingman said caused the issue: https://github.com/adafruit/circuitpython/issues/7112#issuecomment-1336497036
let me go back to beta.4 instead of main and re-test
and use the s3 build not my own build
First board is 0622 in "7-segment" font and 4.8 below it in sans serif. Fine 10/10 re-plugs, CIRCUITPY appears promptly.
i repeated mine a bunch of times, using a hub and not
next is 0622 3.9. I wonder if 3.9 is the position on a panel? Anyway, it's also OK on 10 trials. I'm consistently using the same USB port on my laptop, should I try an un-powered hub? would low quality (low voltage?) VUSB affect 3v3 rise time?
final one is also an 0622 1.14
i notice they all have different, possibly lasered? 2d barcodes. not a type my phone recognizes
I tried two layers of unpowered usb2 hubs, still fine
you could put a big cap across the 3.3V line to ground to slow its rise time
mine are also all fine with my one unpowered hub
I would have to search
i have more ready access... back in a bit
I also wondered if ppk could be used to "undervolt" the usb bus
470uF cap is fine.
You could try turning off some of the start-up delays to see if that provokes it. And are there delays in the library code or pico-sdk code for the CYW that you could reduce or remove?
once again i wish the Picos had silk pin markings on top
yes there's the delay of 10ms with the "enable" off and then the delay of 250ms with the enable on.
I think those were the numbers
I should print out those pages of pico w schematic, looking on screen is a drag
it predates .env. it should be disable-able with supervisor.runtime.ble_workflow = False
@tulip sleet I removed the delay I know about, or, reduced it to 1ms .. and the pico example is still fine for me. ```diff --git a/src/rp2_common/cyw43_driver/cyw43_bus_pio_spi.c b/src/rp2_common/cyw43_driver/cyw43_bus_pio_spi.c
index 0fd17f4..cdb77d8 100644
--- a/src/rp2_common/cyw43_driver/cyw43_bus_pio_spi.c
+++ b/src/rp2_common/cyw43_driver/cyw43_bus_pio_spi.c
@@ -351,9 +351,9 @@ void cyw43_spi_gpio_setup(void) {
// Reset wifi chip
void cyw43_spi_reset(void) {
gpio_put(WL_REG_ON, false); // off
- sleep_ms(20);
- sleep_ms(1); // was 20
gpio_put(WL_REG_ON, true); // on
- sleep_ms(250);
-
sleep_ms(1); // was 250
// Setup IRQ (24) - also used for DO, DI
gpio_init(IRQ_PIN);
but CP is not! so maybe I do have something to debug. hum.
is calling cyw43_spi_reset() your first interaction with the CYW, or maybe you are doing some reset stuff? (like pin reset??)
it's the 2nd delay (after turning reg on) that makes CP have problems.
I don't think so. it'll just set it until reset
so that seems like it's not the same problem
yesbut why is CP having trouble but the simple pico-sdk example is not?
I don't know.
I notice the next action is to set up the IRQ. Maybe a difference in whether the interrupt occurs before the program is ready for it.
That 2nd delay isn't what your added delay affects so I'm not super inclined to dive into it right now
before CP is ready? ... I wonder why the pin is set up after turning on WL_REG_ON
The pin is shared among IRQ, and the single SPI data pin so it has to be enabled as a GPIO to do the "poll for predefined pattern" that's the next step of startup.
the line that was not in the diff context was to configure the pin as an input
We should tune this delay down, because it appears to only affect a small number of boards.
Closes #7112
This zip has a uf2 file I builtfrom the official pico-examples. git describe --tags of pico-examples shows sdk-1.4.0-7-g8be18f2. pico-sdk used was 1.4.0. It was configured with cmake -DPICO_STDIO_USB=ON -DPICO_BOARD=pico_w -DPICO_SDK_FETCH_FROM_GIT=1.
If you have an affected device, please try copying this example to your RPI-RP2. When you plug the device in, it should...
@theblinkingman @ok1rig I tested several pico w samples (0622 4.8, 3.9, and 1.14) but didn't reproduce the problem either with CircuitPython or with the pico examples. Can either of you try the example on your affected board and report back what happens?
@tulip sleet as I don't really have any good new understanding, I went ahead and added the additional 1s of enforced delay that you found worked. And I asked folks with affected boards to try the pico-sdk example that I feel like should also trigger the same problem.
I'll update that other PR soon after I test the manually closing the socket before the ssl wrapper scenario
it works fine after the fix, but that's expected. It's whether it fails before the fix that is interesting
hum, darn, it also works before the fix
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.4-68-g2326b49b24-dirty on 2022-12-07; Adafruit Feather ESP32-S3 Reverse TFT with ESP32S3
Code/REPL
import wifi, socketpool, ssl, time
wifi.radio.connect()
import socketpool
socket = socketpool.SocketPool(wifi.radio)
ctx = ssl.create_default_context()
for i in range(3):
log(i)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('example.com', 443))
sss = ctx.wrap_...
I had a theory that for an ssl socket sss created from a regular socket s, closing s first then sss could provoke the same problem without going through interpreter shutdown. However, I was not able to make this happen in practice.
@tulip sleet both my PRs are ready for your (re)review, sorry it's coming at the end of the day
The program I tried:
import wifi, socketpool, ssl, time, gc
wifi.radio.connect('<omitted>')
import socketpool
socket = socketpool.SocketPool(wifi.radio)
ctx = ssl.create_default_context()
b = bytearray(24)
for i in range(8):
print(i)
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sss = ctx.wrap_socket(s)
sss.connect(('finance.yahoo.com', 443))
print(sss.send(b"GET /quote/%5EIXIC HTTP/1.0\r\nHost: finance.yahoo.com\r\n\r\n"))
print(sss.recv_in...
The Teensy 4.1 board apparently has a FLASHing indicator LED. It lights up when you put the board in program mode and while you're flashing but that's the only time I've seen it lit.
When I have one of the faulty CP builds installed, I've noticed a sequence of (I believe) 7 quick flashes of this LED. Sometimes the sequence happens immediately following the Flash program operation but not always. I've also seen it occur at seemingly random times.
@onyx hinge ```python
import struct
import memorymap
import espulp
class StructMemory:
def init(self, address, typecode):
self.address = address
self.typecode = typecode
self.buf = bytearray(struct.calcsize(typecode))
self.end = address + len(self.buf)
def __get__(
self,
obj,
objtype = None,
):
self.buf = obj.memory_map[self.address:self.end]
return struct.unpack_from(self.typecode, self.buf)[0]
def __set__(self, obj, value) -> None:
struct.pack_into(self.typecode, self.buf, 0, value)
obj.memory_map[self.address:self.end] = self.buf
class Foo:
settingv1: int = StructMemory(0x000000ec, "I")
"""The delay between toggles a second line of comment
A second paragraph"""
def init(self,
pin_number: int = 15
) -> None:
self.ulp = espulp.ULP()
self.program = bytearray(234)
self.program[0:230] = (
b"\x6f\x00\x60\x00\x82\x80\x37\x01\x00\x08\x97\x00\x00\x00\xe7\x80" # 00000000
b"\x80\x00\x01\x11\x06\xce\x22\xcc\x00\x10\x01\x45\x23\x2a\xa4\xfe" # 00000010
b"\x05\x45\xa3\x09\xa4\xfe\xb7\x05\x00\x80\x23\x22\xb0\x10\x37\x06" # 00000020
b"\x00\x00\x83\x25\x86\x0e\x93\x96\x45\x00\xa9\x65\x13\x87\x05\x61" # 00000030
b"\x36\x97\xb7\x06\x08\x00\x14\xc3\x03\x26\x86\x0e\x33\x15\xc5\x00" # 00000040
b"\x23\xa0\xa5\x44\x6f\x00\x40\x00\x03\x45\x34\xff\x05\x89\x81\x45" # 00000050
b"\x63\x00\xb5\x02\x6f\x00\x40\x00\x37\x05\x00\x00\x83\x25\x85\x0e" # 00000060
b"\x05\x45\x33\x15\xb5\x00\xa9\x65\x23\xa8\xa5\x40\x6f\x00\xc0\x01" # 00000070
b"\x37\x05\x00\x00\x83\x25\x85\x0e\x05\x45\x33\x15\xb5\x00\xa9\x65" # 00000080
b"\x23\xa0\xa5\x42\x6f\x00\x40\x00\x73\x25\x00\xc0\x23\x26\xa4\xfe" # 00000090
b"\x03\x25\xc4\xfe\x23\x24\xa4\xfe\x6f\x00\x40\x00\x03\x25\x84\xfe" # 000000a0
b"\x83\x25\xc4\xfe\xb3\x05\xb5\x40\x37\xb5\x02\x00\x13\x05\x75\xb9" # 000000b0
b"\x63\x6a\xb5\x00\x6f\x00\x40\x00\x73\x25\x00\xc0\x23\x24\xa4\xfe" # 000000c0
b"\x6f\xf0\xdf\xfd\x03\x05\x34\xff\x13\x45\xf5\xff\x05\x89\xa3\x09" # 000000d0
b"\xa4\xfe\x6f\xf0\x7f\xf7" # 000000e0
)
self.program[232:236] = (
b"\x0f\x00\x00\x00" # 000000e8
)
struct.pack_into("I", self.program, 0x000000e8, pin_number)
self.memory_map = memorymap.AddressWindow(0x60000000, 0x8000)
self.ulp.run(self.program)
(needs to be run through black)
Looks good!
I haven't tested it yet either
๐
but is autogenerated from c source
including the comments
using clang ast output
neat! so far circuitpython doesn't depend on clang but if it's the easiest path from here to there .. you get to make a call whether it's a good trade-off.
clang would be needed to build the ulp library, not circuitpython
is clang ast stable or does it tie us to a particular clang version?
not sure
at least dwarf debug information is a stable format intended to work between software even if it might be harder to work with
Under what circumstances is the passed in
socketnot aSocketobject? Could it be anSSLSocket? If so then fields in it are set willy-nilly. Also theSSLSocketwould not be shut down. And if it's a plainSocket, it's kind of being rendered unfunctional, but the underlying lwip socket isn't decommissioned in any way.
Scott answered this in a voice chat. The routine is actually initializing a socket object for use by the web workflow. The name is not very self-documenting, so...
I like the basic idea of this: it is more robust than the previous code.
One q on a specific change, and also a question in the main comments thread.
We will put this in beta.5 and have folks try it. Thanks @jepler!
Thanks! That should help. I've written a few modules in Python 3 before, but I've never created new Python objects within C, and I've only dealt with a few types of arguments. This is clearly much more complex than anything I've done before, so the help is very much appreciated!
Ok, that helps. I thought that might be the case, but I wasn't sure.
Does it need to be in a new module? It seems to me like it's similar enough in purpose to RawSample and WaveFile that it belongs with them. I'm not opposed to putting it in a new module, if you think that's the best way to do it though. Maybe we should have an "audiostream" module that could also contain things like "MP3Stream" and "WaveStream" in the future? (Just for the record, I'm not planning to make either of those myself, but I have seen people here asking about streaming MP3, so it's something I can see a need for.)
I don't know how to make a new module, though I guess I could take the same approach and copy an existing one and work from there. I'll start by reading through that document foamyguy provided, and I'll go from there. Thanks again for the help.
new modules are best in case it can't fit in small builds
@slender iron Alright. It's not big, but I know something small can push it over the edge. I'll figure out how to make an "audiostream" module (if you aren't opposed to the name), and I'll go from there.
@lone axle That document really helps! I had figured out maybe 50% of that on my own, and this covers the other 50% in very easy to understand terms. Just having gone over the first page, I feel much more in my element! Thanks again!
@SirHormigo @lonesoac0 I tried to reproduce your problems on a Metro M4 AirLift Lite, with 7.3.3 and 8.0.0, and do not see these failures. The on-board airlift is running firmware 1.7.4. Here is my test program. Could you describe your hardware in more detail? It may be a pin choice problem.
import board
from adafruit_ble import BLERadio
from adafruit_ble.advertising.standard import ProvideServicesAdvertisement
from adafruit_ble.services.nordic import UARTService
from adafru...
@PheebeUK Shall we await your pull request?
Hooray ๐ happy it was helpful
If you happen to have anything on making new modules (specifically the __init__.c and __init__.h parts), I wouldn't mind that. It looks like I'm going to have to deal with that stuff too, and last time I looked, in was even more intimidating...
I don't know of anything that documents that portion of it in any further detail. I haven't done a full implementation myself but I've worked on a few that were started by others. I do a lot of referring to other classes when I work on stuff in that realm.
Alright. I might be able to figure it out from the audiocore one. It looks like there are references to things mentioned in that document you posted, so I might actually have most of what I need and just not know it yet.
This zip has a uf2 file I builtfrom the official
pico-examples.git describe --tagsof pico-examples showssdk-1.4.0-7-g8be18f2. pico-sdk used was1.4.0. It was configured withcmake -DPICO_STDIO_USB=ON -DPICO_BOARD=pico_w -DPICO_SDK_FETCH_FROM_GIT=1.If you have an affected device, please try copying this example to your RPI-RP2. When you plug the device in,...
Automated website update for release 8.0.0-beta.5 by Blinka.
New boards:
- crcibernetica-ideaboard
- maker_badge
- luatos_core_esp32c3
- pillbug
- weact_studio_pico_16mb
- adafruit_feather_rp2040_scorpio
Configure LED pin for STATUS display and to prevent ESP floating pins from constantly lighting LED dimly.
I'm guessing the neopixel configuration actually takes precedence for the status display but this change did turn off the led when it wasn't intended to be lit.
I haven't had a chance to implement the changes above, but the other QT PY crashed about 2 hours ago and didn't go into safe mode. Instead, it just locked up. Here's the debug output:
Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x4009361b PS : 0x00060630 A0 : 0x3ffdfc80 A1 : 0x3ffdfc60
A2 : 0xffffffff A3 : 0x00000001 A4 : 0xffffffff A5 : 0x3ffd7e54
A6 : 0x3f...
I ran decode_backtrace and got the following:
rdagger@ubuntucp:~/circuitpython/ports/espressif$ python3 tools/decode_backtrace.py adafruit_qtpy_esp32s2
adafruit_qtpy_esp32s2
? 0x40093618:0x3ffdfc60 0x3ffdfc7d:0x3ffdfc80
0x40093618: fun_bc_call at /home/rdagger/circuitpython/ports/espressif/../../py/objfun.c:337 (discriminator 1)
0x3ffdfc7d: ?? ??:0
?
CircuitPython version
7.3.3
Code/REPL
n/a
Behavior
n/a
Description
When connecting a Tiny 2040 with circuitpython installed to a Raspberry PI 2 Zero W I'm seeing issues depending on whether I boot to desktop or boot to console.
If I boot to desktop with autologin then my circuitpython drive mounts successfully and the code on it runs, but if I set the pi to boot to console (either with or without autologin) the CIRCUITPY drive mounts wit...
Previously the only other way of determining whether the Vfs has been mounted read-write or read-only appears to be to attempt a write operation and detect a possible OSError:
def is_readonly():
try:
with open('/.rw-test', 'w'):
return False
except OSError:
return True
This is not only a bit clumsy but also requires extra attention to properly clean up the potentially created files/changes, changed timestamps, etc.
It's not pos...
When using wifi.radio.start_scanning_networks(), I see many duplicates. I have two AP's with the same SSID, plus, another different one. For example (SSID's obfuscated):
Available WiFi networks:
MyHome RSSI: -77 Channel: 6
MyHome RSSI: -37 Channel: 6
Neighbor RSSI: -88 Channel: 8
MyHome RSSI: -79 Channel: 6
MyHome RSSI: -39 Channel: 6
MyHome RSSI: -37 Channel: 6
MyHome RSSI: -42 Channel: 6
MyHome RSSI: -81 Channel: 6
MyHome RSSI: -41 Channel: 6
MyHomeOther...
This seems like a user group issue, or some automount difference. I don't think it has to do with CircuitPython. I would think you would see the same issues with any USB mass storage device, such as a USB stick. Try it with a regular USB stick.
The sdkconfig files between the QT Py and the XIAO have no interesting setting differences: they are tiny and just specify the LWIP name.
The other file differences also don't seem to be significant. I am at a loss to explain the issue. It could be some strapping pin issue. Do you have a pointer to the schematic for this XIAO? I cannot find it.
I am going to move this forward to 8.x.x so that it doesn't block the 8.0.0 release.
CircuitPython version
Adafruit CircuitPython 7.0.0-beta.0 on 2021-08-24; Fomu with VexRiscv
Code/REPL
every code
Behavior
Flashing every firmware after 7.0.0-beta.0 (from 7.0.0-rc.0) using dfu-util will cause circuitpython failed to work properly. A drive named CIRCUITPY won't appeared. Though there is a serial port appeared in the Device Manager, every attempt to connect to the board (for example, using Thonny) through this port will end up in a...
I think the commit b14b2945167fd20c313e3bf8e1337b73355dc7ff may have broken something so the board can't function properly. Please check with it.
If anyone with this board would like to work on this, your help would be welcome.
But I think the number of people holding this development board is quite small. Otherwise this problem shouldn't have been discovered after 14 months.
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: Cannot remount '/' when visible via USB.
```Isn't this supposed to succeed (at the risk of allowing filesystem corruption), rather than raising the error?
Seems to work as advertised.
>>> storage.getmount('/').readonly
True
At first I thought it would be better to add this by setting the ST_RDONLY bit of statvfs result's f_flag field, but that's super-unfriendly. I think this is better.
@tulip sleet none of your efforts to make "removable storage" work panned out for all 3 major OSes did they?
@slender iron I was thinking about ccache and similar techniques. QSTR numbering is another big reason that every board build is likely to be different. In neokey trinkey, for example, 236 of 335 files include py/qstr.h directly or indirectly (70%). Percentage is similar for pico w (66%).
Thach still needs to debug it
No, Seeed hasn't (to my knowledge) released a schematic for this version.
I've been able to work around it by sending a dummy ble_radio message on
startup, then if the error occurs resetting via microcontroller.reset(),
which allows it to run without further errors. Not sure if that helps track
down the issue.
On Thu, Dec 8, 2022, 7:28 AM Dan Halbert @.***> wrote:
The sdkconfig files between the QT Py and the XIAO have no interesting
setting differences: they are tiny and just spe...
Comparing a Trinket M0 build with a previous one, this seems to take 92 bytes. Seems worth it to me.
It looks like the BPI-Bit-S2 board has an LED which should probably have the same fix. I don't have one of those boards to test but I can add that to this PR if doing so makes sense.
Thats a good point! I hadn't thought of it
Bummer. I was hoping that backtrace would be more useful. Something must be corrupting the stack. I'm not sure what.
Thank you! Another PR can be made for the other board once it can be tested.
The BLE workflow is on by default. Only wifi needs .env. You can disable ble workflow with supervisor.runtime.ble_workflow = False iirc.
I believe HID does require pairing and bonding so you'll be have data saved on both ends of the connection. After you disconnect, do you expect to reconnect to that device again without pairing? If not, you could call _bleio.adapter.erase_bonding(). This is what CP does when the reset button is pressed during the fast blink on startup.
@onyx hinge this section looks familiar: https://github.com/YosysHQ/picorv32#custom-instructions-for-irq-handling
re: interrupts on the ulp
The BLE workflow looks for a paired/bonded device and connects to it on startup. It is true the HID also requires pairing/bonding, for security reasons, so it sounds like in this case the BLE workflow code can't tell the difference. So, as @tannewt mentions, doing supervisor.runtime.ble_workflow = False early in your code (possibly in boot.py will turn off the BLE workflow, and then your disconnect should work properly.
From https://docs.circuitpython.org/en/latest/shared-bindings/supe...
Fixes #7251 by adding a pin name for the battery charge control rate pin.
Pinging @PheebeUK on this.
This PR replaces the dotenv module and the .env file with the _environ module and the settings.toml file.
Testing performed:
- on pico w, set up wifi workflow with alternate port number
- ran environ_test in build and on pico w
Would appreciate test reports of scenarios I didn't test, like
- [ ] ble workflow
- [ ] espressif wifi workflow
closes #7274
looks fine, would not mind OP's feedback and testing before merge though
Could there be an issue with running multiple QT PY's at the same time? I noticed they all use the same network hostname (espressif). I'll try giving them unique hostnames.
Also, could you please let me know what file I need to modify to disable the safe mode status LED. The edits I made above to supervisor/shared/safe_mode.c did not work.
This dotenv reference and similar ones om circuitpython.pot seem like they should not be here. Does a make translations need to be done?
Is this a debugging printf?
Thank you for taking this on!
I have not yet tested the code, but had some initial questions in the contextual comments. And, do we really need to expose _environ as a native module at all? If os.getenv() does the same thing, how about making that the sole Python interface?
I don't understand why an extra level of { } was added here.
@analog bridge were you testing ulp on s3 or s2?
Now that deepsleep is fixed for the S3 in beta 5 (thanks @slender iron ) - I'm thinking of shipping beta5 on my S3 boards now. Do we think it's stable enough for that?
@tulip sleet That was my original plan. However, the tail is wagging the dog. I use _environ to test within the unix port. Which I think is valuable, but ...
also it looks like I used up all that extra space I found us, and then some ๐ฆ
because os.getenv() is different on the unix port?
@atomic summit that's your call. ๐
you could enable _environ only on the Unix port
I haven't posted in the issue yet as I'd like to do more tests, but I was unable to use true deep sleep on my feather ESP32S3 TFT
Multiple reasons.
- To test with non-parsable files I need to select different files
osis not the shared-bindings os on the unix port
meaning it just resets when I expect a 20s sleep (which works in fake deep sleep)
that'd be helpful. I've been meaning to test on one. I'm in ULP land now though
I wanted to maybe hook a serial friend to a DEBUG build, but I can just report and do that later
I can only get the ulp to run once on startup...
I also had various problems with ulp reset
Hahah, sure, I was just wondering if folks thought it was stable enough... it passes my test jig tests (of course), and some of my other testing, but I'm not using it extensively on any projects...
@tulip sleet apprecate your thoughtful review as always
I apologize that there are "oh geez" problems in there like debug prints, and appreciate that you can just offer kind correction when you see it.
less sure what to do about the _environ module. Guard it by a separate #if so it's only in the unix port?
I am thinking about needing _environ. Could rename it to _settings or _toml or something. All the existing toml libs parse a whole file into a dict. Or we could even make it a non-underscore settings module, which might have other uses for the user.
or otherwise put it in a place the unix build sees but other stuff doesn't
if you guard it so it's only in the Unix port, then maybe you get back a bunch of space.
some space at least
does making it NOT be the "_environ" module mean I should move/rename the code again? If so, to where?
I have been looking at other toml, ini, and settings libs but haven't found a get_key style example yet
no, nobody does it that way
I just mean that _environ isn't as general a name as it could be, since you can supply an arbitrary file. Hence _settings or settings, and it might have other uses. is it turned off for SAMD21 in general?
so far I was going to turn it off 'case by case' but maybe I should
if it is only for unix, then it could be _settings_test, and be only a front for the actual implementation, which would be in the os module, or wherever get_key was actually implemented
I mean, is it useful enough that we should enable it in samd21, or will it not fit. What is true of .env right now? Where is it enabled?
I could just put the single Python function implementation in ports/unix/coverage.c
dotenv was enabled for all FULL_BUILD with no extra spots where it was turned off.
In my tests with beta 5, it never goes to deep sleep but just resets, like before I think.
Feather ESP32-S3 TFT
Adafruit CircuitPython 8.0.0-beta.5 on 2022-12-08; Adafruit Feather ESP32-S3 TFT with ESP32S3
Running that code.
import alarm
import time
time_alarm = alarm.time.TimeAlarm(monotonic_time=time.monotonic() + 20)
alarm.exit_and_deep_sleep_until_alarms(time_alarm)
Does not go to deep sleep but resets immediately instead when on power only (USB power adapter...
that makes it low overhead, so the q is whether this is useful enough to make available or not. If you leave it in, people will ask about it, even as _settings or _environ. So it may as well be useful. If we want to suppress it, then just providing the backdoor only on unix for testing is the right thing to do.
OK, I think we're in agreement. So where in terms of path & filename should the toml-parsing code currently in shared-modules/_environ in the PR go?
shared-modules/os ?
that makes sense, then os.get_key() /common_hal_os_get_key() can be the way to access it either internal or externally. I think?
OK, I'll rip it apart and put it back together again
so I have a Xiao NRF52 sense, but I don't know how I could test the charge rate pin, I don't have a power analyzer or anything, I don't think I can just put a multimeter on the battery pins ?
you could put an ammeter in series with one of the battery leads, yeah
I looked at the datasheet for the charge controller -- it's programmed by resistor vlaues, so they set up a divider to choose to currents at high and low (or at least that was what I saw at a quick glance)
Can confirm it works with my TinyS3 now, which I'm using to power an e-ink display (light sleep during minute intervals, deep sleep on hour intervals during low light so it's central to its operation). Before it actually did light/deep sleep worse than the Adafruit Feather ESP32-S3 since it would crash even on light sleep, forcing me to just use sleep/sleep-->reset. Now it seems perfect but I'll see if it does anything funky.
Hmm, how could it have been worse than the Adafruit Feather ESP32-S3 ? Behaviour should have been identical. It was a SW issue, not a HW one.
Can you explain in more detail what was different?
Yeah. It was definitely weird because I didn't change anything except the pin references but I didn't mind since the workaround pretty much did the same thing.
So in the Feather light sleep would just work, so I assumed it would work just the same on the TinyS3 but somehow it would get unstable and crash mid-hour (which is where I put light sleep). No idea why but given that I was using the latest releases at the time, it could be that.
Hmm, ok, well I'm glad it's all working as expected now ๐ Thanks for letting me know!
@atomic summit in an upcoming beta, we are going to make an incompatible change to the .env web workflow stuff. It will become settings.toml with a slightly different syntax, using a limited subset of toml.
so if you ship beta.5 it will need to be updated by the users at some point
but is it better than shipping 7.3.3? Probably.
Took me a while to figure out what's needed to build for nRF, but I got there in the end. Built the Seeed XIAO nRF52840 Sense version. Tested at the software level to confirm pin names operate. Tested at the hardware level to ensure pin name does indeed affect the charge rate.
From my perspective, this works great.
i think we are seeing the light at the end of the 8.0.0 tunnel
with Adafruit CircuitPython 8.0.0-beta.5 on 2022-12-08; FeatherS3 with ESP32S3
and:
import alarm
import time
from digitalio import *
import board
led = DigitalInOut(board.LED)
led.switch_to_output(True)
for i in range(5):
led.value = not led.value
time.sleep(0.1)
time_alarm = alarm.time.TimeAlarm(monotonic_time=time.monotonic() + 20)
alarm.exit_and_deep_sleep_until_alarms(time_alarm)
I get an instant reboot instead of sleep (I blink the LED to see the reboot happen)
Yeah, I saw that in the issues list. I've had a bit of discussion on my discord server re the DS issue, so haven't looked at shipping with an 8 beta up until now because of that, but now it's fixed, I have to decide the better of 2 issues.
Is the plan for folks to use .env and the new settings.toml for anything non web workflow? Like, just for storing wifi credentials etc?
Thanks - I would have loved to have time to deal with this, but family issues meant you got there first!
they can use it for whatever they want. os.getenv() will fetch the values
but there are certain keys that will be read on startup
Oh yeah I get it now too with deep sleep on the Tiny S3. I don't know what kind of fake sleep it's doing when connected to the computer but at least it doesn't crash anymore in all of the cases.
Before it would just crash whenever the program exits, regardless of whether it's sleep-related or not.
fake deep sleep allows testing without losing USB
Yeah, though I assume it's a form of sleep that was close to deep sleep since it would exit the program and crash before.
To note, it does work as expected when connected to the computer, just not the true deep sleep functionality that happens without USB.
Do we want to remove this from the docs? https://docs.circuitpython.org/en/latest/docs/library/asyncio.html
or at least rename "uasyncio" to "asyncio" everywhere?
Some people got really confused
we should remove that and put the doc inline in the library. I had avoided doing that before because I was worried about making merging harder, but at this point it should be treated as a regular library. There may be an issue for that already.
can't see an issue, I will create one
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.4-78-g4418f268b on 2022-12-06; Raspberry Pi Pico with rp2040
Code/REPL
# audio_click_i2c.py -- demonstrate audio clicking when update I2C display
import time, random
import board, busio
import audiocore, audiomixer, audiobusio, audiopwmio
import displayio, terminalio
from adafruit_display_text import label
import adafruit_displayio_ssd1306
displayio.release_displays()
dw,dh = 128,64
# Pico...
The modules docs include documentation for uasyncio, probably because the file is there in the repository, even though the module is not enabled on any of the boards: https://docs.circuitpython.org/en/latest/docs/library/asyncio.html
This should be removed, as people looking for information on asyncio find it and get very confused and frustrated, because it doesn't work.
I tested this again, with the following simpler program, on a MagTag, with CircuitPython 8.0.0-beta.4. I sent serial output to the D10 jack to monitor what was happening. when on battery power. I am seeing that alarm.wake_alarm now is a PinAlarm or a TimeAlarm, as appropriate, after a light sleep.
There have been various PinAlarm fixes, such as #7154, since this bug was filed. @raymond-li Please reopen or open a new issue if you are still having trouble with 8.0.0-beta.4 or later. Th...
Ok, I've spent a good chunk of time on this in https://github.com/tannewt/circuitpython/tree/rework_coproc_api. I've tried getting the ULP working on ESP32-S3 and have only managed to get it working after reset. It stops working after reloads. Furthermore, I've traced some S3 sleep issues to having the coprocessor enabled (but not used by CP) due to the ulp [falsely triggering on fault](https://github.com/espressif/esp-idf/blob/454aeb3a48ac2b92cfa9d8b6a01d1b53179ec50a/components/ulp/ulp_riscv...
Power usage should also be checked since the IDF fix for the S3 forces the ULP clock on. It may invalidate power savings without the ULP.
:thumbsup: Yes, discarding pending data would improve UX a lot - IMO an intuitive reflex in Mu and any other serial terminal, is to either close+reopen the Serial tab/panel/window or restart the connection.
If CDC disconnects, I think all bets are off, and it would be OK to discard that data. I did not want to discard data casually on an existing connection.
@Neradoc Your mu issue appears to be https://github.com/mu-editor/mu/issues/1505. I think it would be good to re-open that and point out that a running program that is not receiving input may have far too much input piled up. I also do not even see the point of the cursor movements, since the Serial window in Mu should be a stream, not an editor window. Do you understand the use case for Mu to generate those cursor movements.
I also do not even see the point of the cursor movements, since the Serial window in Mu should be a stream, not an editor window. Do you understand the use case for Mu to generate those cursor movements.
It only makes sense when in the REPL typing a command, it lets you click to move the insertion point inside your command, and there is even code to select and delete the selection. It doesn't seem super useful to me, but I'll admit to being used to moving the cursor with arrows.
- Fixes #7323.
Removes MicroPython asyncio documentation page. Also revises and renames the libraries doc page (drivers.rst -> libraries.rst). It was frustratingly difficult to find the the list of all Adafruit library documentation starting from that page, and a more direct link was added. The text on that page has also been simplified and updated.
! Package inputenc Error: Unicode character ๐จ (U+1F468)
(inputenc) not set up for use with LaTeX.``` this is why we can't have nice things
pdflatex: Command for 'pdflatex' gave return code 0.01171875 I'm running into some .. interesting .. problems building the docs locally as well. Who new there were fractional return codes in UNIX
JOSS and FOCAL had fixed point line numbers with decimal parts n.dd. Lynx Basic (I did not use that) had floating point line numbers
Just watched the show and tell - interesting issue - was interested in your progress - hope someone else takes this up. were there any examples (maybe non-CP) where ULP was used successfully in other ESP32-S3 projects?
@hollow gazelle I did think about doing esp-idf examples but I didn't see one that fully shut it down and then restarted. definitely a good next step
it just feels very immature
I tested S2 only
I found the change that broke the Teensy41 boot with 8.0.0.Beta.1.
In main.c, if you move the board_init() call to where it was in 8.0.0.Beta.0 (before the reset_port call) the Teensy41 build works. I tested the change out on 8.0.0.Beta.5 and it results in a working Teensy41 boot.
I'm sure this isn't the fix but hopefully it moves us closer to one.
reset_port() calls reset_all_pins() which appears to reset any pin that hasn't been set in never_reset_pins but board_init() is the routine that seems to set the never_reset_pins array.
Perhaps we need to separate out the pin configuration from other board_init functions, maybe create a new function in board.c called something like pin_config which could be called prior to reset_port and allow the display initialization functions in board_init to happen after reset_port?
Were you able to restart the ulp every reload?
Famous last words.
The previous link went to a version that wasn't being maintained and had a banner directing users to a different tool. Replace with a link to the version of ESP Web Flasher hosted on adafruit.github.io.
Yes, restarts worked fine on S2 when I tested. What is the issue you are facing?
On s3 the program would only run once. Furthermore itโd wake the s3 from deep sleep even if we didnโt use it
(I followed up on the coproc issue about it yesterday)
Thanks for figuring this out! I think copying the espressif port is best. It has both port level pins that it doesn't reset and has a weak function that the board can implement to reset itself.
Just glanced over the ULP section in S2/S3 technical reference manual and there seems to be slight difference in the ULP init sequence between the two
@analog bridge ya, I tried to change it to match the latest version of the idf
I tested this yesterday and found that the ULP was incorrectly waking up the S3. I'll try and sort it out today.
It is stated that on S3, RTC_CNTL_COCPU_CLK_FO needs to be cleared after being set. This is correct in v5.0 but v4.4 routine is incorrect
Can you use larger audio buffers? This is likely that the display update takes longer than playing back an audio buffer.
I was changing my copy of the idf to match 5.0
What is your ULP test program?
let me make a repo to push it to
thats the built file
import adafruit_ulp_blink
import time
import memorymap
import struct
def print_regs():
print("COCPU_INT_ST", hex(struct.unpack("I", rtc_ctl[0x0F0:0x0F4])[0]))
print("TIMER_REG", hex(struct.unpack("I", rtc_ctl[0x0FC:0x100])[0]))
print("CP_CTRL", hex(struct.unpack("I", rtc_ctl[0x100:0x104])[0]))
print("COCPU_CTRL", hex(struct.unpack("I", rtc_ctl[0x104:0x108])[0]))
print("sleeping")
time.sleep(5)
print("awake")
rtc_ctl = memorymap.AddressRange(start=0x60008000, length=0x400)
print_regs()
b = adafruit_ulp_blink.Blink()
for i in range(10):
time.sleep(1)
print(b.count)
print_regs()
b.ulp.halt()
print_regs()
idf changes: ```diff
diff --git a/components/ulp/ulp_riscv.c b/components/ulp/ulp_riscv.c
index 2c56ca119e..1cfc9c94a1 100644
--- a/components/ulp/ulp_riscv.c
+++ b/components/ulp/ulp_riscv.c
@@ -27,6 +27,10 @@
#include "ulp_private.h"
#include "esp_rom_sys.h"
+#include "esp_log.h"
+
+static const char* TAG = "esp ulp rv";
+
esp_err_t ulp_riscv_run(void)
{
#if CONFIG_IDF_TARGET_ESP32S2
@@ -56,12 +60,12 @@ esp_err_t ulp_riscv_run(void)
return ESP_OK;
#elif CONFIG_IDF_TARGET_ESP32S3
/* Reset COCPU when power on. */
- SET_PERI_REG_MASK(RTC_CNTL_COCPU_CTRL_REG, RTC_CNTL_COCPU_CLK_FO);
SET_PERI_REG_MASK(RTC_CNTL_COCPU_CTRL_REG, RTC_CNTL_COCPU_SHUT_RESET_EN);
esp_rom_delay_us(20); - CLEAR_PERI_REG_MASK(RTC_CNTL_COCPU_CTRL_REG, RTC_CNTL_COCPU_CLK_FO);
CLEAR_PERI_REG_MASK(RTC_CNTL_COCPU_CTRL_REG, RTC_CNTL_COCPU_SHUT_RESET_EN);
-
SET_PERI_REG_MASK(RTC_CNTL_COCPU_CTRL_REG, RTC_CNTL_COCPU_CLK_FO);
-
/* Disable ULP timer /
CLEAR_PERI_REG_MASK(RTC_CNTL_ULP_CP_TIMER_REG, RTC_CNTL_ULP_CP_SLP_TIMER_EN);
/ wait for at least 1 RTC_SLOW_CLK cycle */
@@ -94,6 +98,8 @@ esp_err_t ulp_riscv_run(void)
esp_rom_delay_us(20);
REG_WRITE(RTC_CNTL_INT_CLR_REG, RTC_CNTL_COCPU_INT_CLR | RTC_CNTL_COCPU_TRAP_INT_CLR | RTC_CNTL_ULP_CP_INT_CLR); -
ESP_LOGI(TAG, "started ULP");
-
return ESP_OK;
#endif
}
@@ -113,5 +119,7 @@ esp_err_t ulp_riscv_load_binary(const uint8_t* program_binary, size_t program_si
memset(base, 0, ULP_RESERVE_MEM);
memcpy(base, program_binary, program_size_bytes); -
ESP_LOGI(TAG, "program loaded");
-
return ESP_OK;
}
was testing on s3 usb otg
Why does this need to exist? Usually files here are either init or a class. This is weird to have for a function.
I am on CircuitPython 7.3.3 currently, which doesn't seem to have the supervisor.runtime.ble_workflow so I'll have to try that after upgrading some other time.
I tried the _bleio.adapter.erase_bonding() and it gets the device into a weird state where it seems to cycle between connected and disconnected state continuously. Very odd.
Not sure if it's a coincidence but all 4 boards made it through the night without crashing since I gave them unique hostnames. I also tried rebooting my access point and running deauth attacks against the QT PY's. So far, they haven't crashed. I added a fifth board and I'll let them all run for a few days. Afterwards, if there are no crashes, I'll put the hostnames back to espressif and see if the problem recurs.
I've done a little poking around the espressif port and it looks like a pretty significant rework of the mimxrt10xx port is required. I don't think I understand how all the modules interact well enough to take this one on :smiley:.
@slender iron can you test this on S3 with 8.0.0-beta.5, it has led on pin 15
import time
import atexit
import coproc
import supervisor
shared_mem = coproc.CoprocMemory(address=0x500007f0, length=1024)
with open("ulp_main.bin", "rb") as f:
program = coproc.Coproc(buffer=f.read(), memory=shared_mem)
coproc.run(program)
atexit.register(coproc.halt, program)
while coproc.memory(program)[0] <= 50:
print(coproc.memory(program)[0])
time.sleep(5)
coproc.memory(program)[0]+=10
supervisor.reload()
@analog bridge yup, let me try
(will be gone again when the baby wakes from his nap)
45 minutes or so ๐ค
@analog bridge looks like it works!
can you send me the elf too?
I'm curious to look at the assembly
Comparing your ld:
https://github.com/adafruit/Adafruit_CircuitPython_ULP_Blink/blob/main/link.ld
with the one in esp-idf:
/*
* SPDX-FileCopyrightText: 2022 Espressif Systems (Shanghai) CO LTD
*
* SPDX-License-Identifier: Apache-2.0
*/
#include "sdkconfig.h"
ENTRY(reset_vector)
MEMORY
{
ram(RW) : ORIGIN = 0, LENGTH = CONFIG_ESP32S3_ULP_COPROC_RESERVE_MEM
}
SECTIONS
{
. = ORIGIN(ram);
.text :
{
*start.S.obj(.text.vectors) /* Default reset vector must link to offset 0x0 */
*(.text)
*(.text*)
} >ram
.rodata ALIGN(4):
{
*(.rodata)
*(.rodata*)
} > ram
.data ALIGN(4):
{
*(.data)
*(.data*)
*(.sdata)
*(.sdata*)
} > ram
.bss ALIGN(4) :
{
*(.bss)
*(.bss*)
*(.sbss)
*(.sbss*)
} >ram
__stack_top = ORIGIN(ram) + LENGTH(ram);
}
and the start.S file:
.section .text.vectors
.global irq_vector
.global reset_vector
/* The reset vector, jumps to startup code */
reset_vector:
j __start
/* Interrupt handler */
.balign 16
irq_vector:
ret
.section .text
__start:
/* setup the stack pointer */
la sp, __stack_top
call ulp_riscv_rescue_from_monitor
call main
call ulp_riscv_shutdown
loop:
j loop
take a look at build configuration in esp-idf/components/ulp
I looked at it a bunch. what are you seeing?
baby time. thanks for the test code!
call ulp_riscv_rescue_from_monitor is blanked out in your start?
subvalue="cannot retrieve this using getenv"
I thought this would now be named for os.getenv()?
Similar changes throughout.
os_getenv_err_t result = common_hal_os_getenv_str("CIRCUITPY_BLE_NAME", ble_name, sizeof(ble_name));
Thanks for the refactor. I'm wondering if there are some missing checkins here, as the naming doesn't seem to have been redone everywhere. I'm not sure why it compiles.
if (common_hal_os_getenv_int("CIRCUITPY_RESERVED_PSRAM", &reserved) == GETENV_OK) {
Is getenv_int going to be here?
ah! I missed that. will try it next nap
Okay I feel like a total dummy for forgetting that audiomixer.Mixer() had buffer_size argument.
You are correct: setting buffer_size=32768 allows even the slowest 100kHz full-screen OLED update to occur without glitching. At 400kHz, only an 8kB buffer is needed. This is for for 22kHz mono 16-bit samples.
Adding the larger buffer also solves one of my most headache-inducing problems that still exists even after #6005 was closed: audio glitches caused by USB enumeration on reset.
...
I feel like I can close this issue, but is there somewhere official the tip of "if you get audio glitches, increase buffer size" can be documented?
There is no general audio Learn Guide, though there could be. This kind of info could also be in the FAQ in the Welcome guide.
Have you heard playback glitches when not using Mixer? I wonder if other default buffer sizes might be increased, at least on large-ram builds. Or we could provide optional parameters.
Have you heard playback glitches when not using Mixer? I wonder if other default buffer sizes might be increased, at least on large-ram builds. Or we could provide optional parameters.
Yes, if you update a I2C/SPI display without AudioMixer it glitches in the same way.
That can be somewhat ameliorated by doing explicit (not automatic) display refreshes. Refreshing the display from background blocks other background tasks for the whole time. I'm not sure but I thought that audio background task can take place during foreground display refresh. Ensuring refresh areas are small helps too of course
@jepler I was not able to find a way of doing explicit display refreshes that minimized the glitching at all. If you have an example Iโd love to see it.
My information may not be accurate, it's more a memory than real facts.
In the very specific case that you're
- drawing something that uses an ondiskbitmap
- and it's calling back into python code to read the disk (adafruit_sdcard)
- and you do a foreground refresh of the display, not a background refresh
you can get background tasks running during the call out to adafruit_sdcard.
It's split out because this implementation (but not the rest of os) needs to be available in the unix port.
but when I added the pattern that would pick up shared-module/os/getenv.c during build (in circuitpy_defns.mk SRC_SHARED_MODULE_ALL variable) builds failed because they refered to this filename. Do I need to list it differently?
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.5 on 2022-12-08; S2Pico with ESP32S2-S2FN4R2
Board ID:lolin_s2_pico
Code/REPL
import board
dir(board)
Behavior
hum I wanted to commit a file with the ".toml" extension but no trailing newline .. but the newline fixer wants to fix it. hum.
I can call the file .toml.bin
no that doesn't work
Uff.
can we add some kind of "do not process" checking for the newline checker? Another flag file or something?
@tulip sleet it can be customized in pre_commit_config.yaml, I found belatedly.
Ok, with @MicroDev1's help (thanks!) I've made good progress.
My program was failing because I set the stack pointer to the wrong address. :facepalm: I was also setting the wrong bit in the gpio registers (there's an extra 10 bit shift.)
I'll need to test deep sleep with it next week. (To make sure #7300 is fixed.)
Is there a way to turn off mDNS without reset? There's no '__exit__' for context manager, and can't deinit() after a reload.
This is the only board with Circuitpython support with an I2C built-in display, hence there is no example code to crib from. At some point I was going to look into setting it up but lacked the time.
I am also seeing this problem with I2S audio and an I2C screen.
Adafruit CircuitPython 7.3.3 on 2022-08-29; Raspberry Pi Pico with rp2040
Board ID:raspberry_pi_pico
import adafruit_displayio_ssd1306
Increasing the buffer_size in audiomixer.Mixer() seems to eliminate the audio glitches, but it introduces a significant amount of latency that interferes with real time operation.
Up to about 350ms of latency for buffer_size=32768 and sample_rate=44100 compared to about 15ms w...
Alright, new commit error: Translations failed.
I have added two places where exceptions are raised. They are ValueError exceptions. Referencing existing code, I wrapped the text in "translate" calls (macros?). If I understand the error correctly, the translations are supposed to reference some file that contains translations for different languages, but it was unable to find the referenced strings, because I have not added them to that file. It suggests running "make translate", which I did and which did not resolve the problem.
I believe I've found the file where the messages need to be added (py/circuitpython.pot, is this correct?), however I would like to know what is expected here. Should I just add the messages, using the same format used for other messages in the file? Should I first look for other messages that convey the same idea? (The errors occur when the RawStream audio class I'm creating is given a sample to play that has different signedness or byte width than it was initialized with.)
Or perhaps did the pre-commit or the make translate automatically update locale/circuitpython.pot, and I merely need to add that to the commit?
I had an idea for simpler testing in the unix port. Instead of adding a special coverage/unix-only method to specify the filename, I think the test program(s) could simply rewrite settings.toml over and over again, since each time os.getenv() is called it reads the file fresh:
# write settings.toml test values
# do os.getenv() tests
# write settings.toml again with different values
# do more os.getenv() tests
# ...
An alternative is to add an extra optional argument to...
Hi, I'm working through the how to build CircuitPython instructions, and mpy-cross fails to build.
macOS Monterey 12.6.1, M1 Mac.
gmake: Entering directory '/Volumes/CircuitPython-Builds/circuitpython/mpy-cross'
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
File "<fstring>", line 1
(offstart=)
^
SyntaxError: invalid syntax
gmake: *** [../py/py.mk:274: build/genhdr/compression.generated.h] Error 1
gmake: Leaving directory '/Volumes/CircuitPython-Builds/circuitpython/mpy-cross'
Any help greatly appreciated!
right, just run make translate when you add new messages with translate(). Also take some time to see if there's an existing message you can reuse. A number of them are parameterized with %q so you can insert specific names.
@idle owl had this same trouble on macOS a few days ago. I don't see a solution since that report. It might be some dependency being out of date. Also do a make clean if you haven't already, thought that's probably not it
btw, set V=2 (uppercase)
Great thanks, I started to search for an example... next step was to ask on discord.
I think the situation is fine as it is, maybe we can update circuitpython.org to do expectation management?
PS: I acquired one specimen of each of the LOLIN boards with circuitpython support, just to try, so thank you for your work.
Thanks for your prompt reply. V=2, good catch. gmake clean hasn't helped. The verbose output follows. I'm getting ready for some new boards but I doubt I'll get to them until February, so this isn't urgent for me. I'll poke around and educate myself ๐คช
GEN build/genhdr/mpversion.h
python3 ../py/makeversionhdr.py build/genhdr/mpversion.h
GEN build/genhdr/compression.generated.h
mkdir -p build/py
python3 ../py/maketranslationdata.py --compression_filename build/genhdr/compression.generated.h --translation build/genhdr/en_US.mo --translation_filename build/py/translations-en_US.c build/genhdr/qstrdefs.preprocessed.h
File "<fstring>", line 1
(offstart=)
^
SyntaxError: invalid syntax
gmake: *** [../py/py.mk:274: build/genhdr/compression.generated.h] Error 1
gmake: Leaving directory '/Volumes/CircuitPython-Builds/circuitpython/mpy-cross'
Update: using playback via the AudioMixer ( mixer.voice[0].play() ) is a workaround for now, as it only pops once when mixer.play is called and then all the consecutive plays do not pop.
So when using PWM Audio,
audio_out1.play(mixer) -> pops once at the beginning, but then mixer.voice[0].play doesn't pop
audio_out1.play pops everytime it's called
It's possible that the audio_dma_setup_playback called from common_hal_audiopwmio_pwmaudioout_play blocks the pwm being written lon...
I'm pretty disappointed that I can't use the Adafruit I2S MEMS Microphone Breakout in circuit python, I guess I should have picked up the PDM microphone. I assumed that since circuit python supported I2S out it would have supported I2S in, this would be good to make clear on the product page that there is no support in circuit python and no planned support.
Since mDNS is a component of web workflow, I assume we want it to survive reloads. But should we have a way to turn it off, or make it a Singleton so it can be accessed again after a reload?
@matthewbal you can use the recently-added analogbufio on RP2040 boards to sample with an analog microphone. It is in 8.0.0-beta.5. See https://docs.circuitpython.org/en/latest/shared-bindings/analogbufio/index.html
Should this be closed by #7272 ?
hmm... espressif seems to shut down mDNS on reload, raspberrypi doesn't
which is a problem: m = mdns.Server(wifi.radio) gets a RuntimeError even after reset if web workflow is enabled (rp2 only)
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.5 on 2022-12-08; Raspberry Pi Pico W with rp2040
Code/REPL
# mDNS finder
import time
import wifi
import mdns
import microcontroller
from secrets import secrets
MDNSFINDTIMEOUT = 5
def connect():
# to connect if no web workflow, or to reconnect if disconnexted
if not wifi.radio.ipv4_address:
print (f"Connecting to wifi AP..", end="")
while True:
try:...
raspberrypi: more on mDNS duplicates (etc.) in issue #7326
Moving this back to 8.0.0. I think it's going to get fixed by @tannewt's work?
@onyx hinge i hope the toml testing idea was not too disruptive. It does seem to have reduced complexity. So is it true that a test can't actually write a file in the regular filesystem that the Unix port can read? Your use of a RAM filesystem is clever.
I think you solved the pattern problem. The function could be moved back to __init__.c if the file still poses an issue.
@tulip sleet because the path is hard-coded as "/settings.toml" with leading "/" you can't write it
Run # "Calculating the previous and current SHA..."
changed-files-diff-sha
Verifying git version...
Valid git version found: (2.38.1)
Running on a pull request event...
Fetching remote refs...
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
From https://github.com/adafruit/circuitpython
* [new branch] main -> origin/main
branch 'main' set up to track 'origin/main'.
Fetching 40 commits...
fatal: error in object: unshallow 3940878695f2d7797fc1570d8b281ca9ffa454ff
Error: Process completed with exit code 128.``` @tulip sleet I do not know what's going on here except that it has to do with one of the "build less stuff" optimizations. If you have a clue how to poke it please let me know.
That sounds good. I seriously doubt the message I need is already there, but I'll at least grep the .pot file to check. I'm already using one %q to reference the variable itself, and I would need a second to reference the class name, because the value errors are dependent on how the object was initialized.
Anyhow, thanks! I think I'm close to finished, so this was an annoying roadblock! I'm happy to have the help I've gotten here.
I'm trying to unshallow a repository:
% /bin/git clone --shallow-since='3 years' 'https://github.com/RobertAudi/zsh-hooks'
Cloning into 'zsh-hooks'...
remote: Enumerating objects: 17, done.
remote:
no issue reported against https://github.com/tj-actions/changed-files/issues?q=is%3Aissue+error+unshallow
I re-ran it to see if the outcome's any different
I was proposing https://github.com/adafruit/circuitpython/issues/7225 which might remove some of these sshallow clone problems, if that's our issue, but it would be somewhat slower
Ok, new question: Do modules need to be explicitly compiled? Or does a reference need to be added somewhere to make them compile? I think my code is finished for a new module. Doing a general compile for the QT Py RP2040 completes with no errors, which I find unlikely given this is the first time I'm compiling after writing my new module. So how do I compile my new module?
yes, look at the py/circuitpy_* files to see how we specify files and groups of files to compile
Alright, I'll do that. Thanks!
Did you try doing a fresh shallow clone the same way the CI job does to see if you can reproduce? It's pretty mysterious, I agree
No, I didn't.
I can look at it more tomorrow or monday, I made the mistake of checking the status of that PR build even though I'm supposed to be getting ready for house guests
i will take a look but there's no hurry on this at all, no need to stew about it. Enjoy your meal!
thank you
Ok, so I did that. I added my module to the file that contained the stuff for audiocore since mine is similar to/based on audiocare. Compiling for the QT Py RP2040 does not seem to compile my module though. No build artifacts are turning up in the build tree (and I'm not sure where to look for the mpy file...). Is there some board specific place I need to add references as well?
Wait, I missed one of the all caps audiocore references! I've replicated that adjusted for my module, and now I'm finally getting a build error for my module! Now I can finally debug. Wish me luck.
Ok, anyone know where MP_OBJ_NEW_INT is defined? I need the version of this for bools, and the compiler says it's not MP_OBJ_NEW_BOOL.
it is mp_obj_new_bool like mp_obj_new_int
That's what I thought, but:
../../shared-bindings/audiostream/RawStream.c: In function 'audioio_rawstream_obj_is_ready':
../../shared-bindings/audiostream/RawStream.c:153:12: error: implicit declaration of function 'MP_OBJ_NEW_BOOL'; did you mean 'MP_OBJ_NEW_QSTR'? [-Werror=implicit-function-declaration]
153 | return MP_OBJ_NEW_BOOL(common_hal_audioio_rawstream_is_ready(self));
| ^~~~~~~~~~~~~~~
| MP_OBJ_NEW_QSTR
they are both lowercase
Not in the code I was referencing. I'll try it though!
Ah, it was MP_OBJ_NEW_SMALL_INT from shared-bindings/audiocore/RawSample.c. Maybe that's the only all cap one.
Thanks!
yeah that one would be a macro
they are in py/obj.h if I'm not mistaken
it's because small ints are optimized in a specific way I assume
Yeah, I guess my reference was the exception. Lousy luck, but thank you for correcting me! I'll look there if I come across something like this again. (Yeah, probably so.)
I use git grep or silversearcher (ag) to navigate the core source
Ok, so here's another one:
../../shared-bindings/audiostream/RawStream.c: In function 'audioio_rawstream_obj_is_ready':
../../shared-bindings/audiostream/RawStream.c:153:28: error: implicit declaration of function 'common_hal_audioio_rawstream_is_ready'; did you mean 'common_hal_audioio_rawstream_deinited'? [-Werror=implicit-function-declaration]
153 | return mp_obj_new_bool(common_hal_audioio_rawstream_is_ready(self));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| common_hal_audioio_rawstream_deinited
Where do I define the common_hal... bindings? Or do I not need to do it this way in this case?
(Yeah, I probably should have just grepped the whole repo to find the file...)
common_hal go in shared-modules/modulename and can be overridden by ports/*/common-hal/modulename (don't ask me how), you declare them as extern I think ?
Hmm, I didn't see any of that in audiocore, but maybe it's overridden. I'll dig around and see if I can find how audiocore is handling it then.
yeah I'm not clear on that
Otherwise the removed layer cannot be re-added.
Oh, it looks like in RawSample.c, the functions are just named that! I didn't realize that, because not all of them have that name. Only certain ones do.
๐ It compiles!
Now for runtime debugging. Thanks again!
The build failures you are seeing are unrelated. @jepler is seeing them too on a different PR. We will try to get these fixed.
The common-hal routines are declared in the .h file in shared-bindings, because they are ... common
@analog bridge we're seeing build errors in the past couple of days on PRs, that appear to be related to the jt-actions/change-files action that is part of https://github.com/adafruit/circuitpython/pull/7132. Here's an example: https://github.com/adafruit/circuitpython/actions/runs/3666904634/jobs/6198998390 -- look in the failed "Get changes" section. I do not understand very much at all what might be causing this, but maybe it's due to the INPUT_FETCH_DEPTH: 40, which matches 40 in this error:
changed-files-diff-sha
Verifying git version...
Valid git version found: (2.38.1)
Running on a pull request event...
Fetching remote refs...
remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
From https://github.com/adafruit/circuitpython
* [new branch] main -> origin/main
branch 'main' set up to track 'origin/main'.
Fetching 40 commits...
fatal: error in object: unshallow 98002cf0abe5019cf3c57e6c1896c4c5dd226f24
Error: Process completed with exit code 128.
I will turn this into an issue as well.
In the past couple of days, PR's are failing due to errors that seem to be caused by tj-actions/changed-files.
#7132 introduced the use of that action.
Here is a typical failure, from https://github.com/adafruit/circuitpython/actions/runs/3666904634/jobs/6198998390, with the relevant log section extracted:
Run tj-actions/changed-files@v34
with:
json: true
separator:
include_all_old_new_renamed_files: false
old_new_separator: ,
old_new_files_separator:...
Alright. So that means ones that aren't common shouldn't use that convention? (This is what I've assumed.)
like what wouldn't be common?
see for example shared-bindings/pwmaudioio/PWMAudioOut.h. I apologize for saying __init__.h. The declarations are mostly in the class .h files.
maybe a better example for you is shared-bindings/audiocore/RawSample.h, etc.
Common being deinit and such, that all objects should have?
I did end up figuring it based on that RawSample.h though.
I was kinda busy the last few days, is the code for settings.toml out?
Does it need testing?
@dhalbert Thank you for the tip, I'm trying to get audio in + audio out + a wifi connection on a Pico W, but that combination of features is turning out to be difficult! I'll pick up a few different microphone types and figure out which one will work best in micropython :)
@tulip sleet #7329 can be a temporary fix
sounds good -- thank you!! I will do some "partial clone" experimental PR's at some point. I want to do some more reading about it.
CircuitPython version
Adafruit CircuitPython 7.3.3: MakerDiary nrf52840 USB dongle
Code/REPL
import time
import random
from ble_json_service import SensorService
from adafruit_ble import BLERadio
from adafruit_ble.advertising.standard import ProvideServicesAdvertisement
# Create BLE radio, custom service, and advertisement.
ble = BLERadio()
service = SensorService()
advertisement = ProvideServicesAdvertisement(service)
# Function to get some ...
In order to support a new version of the board we have made some updates to the support package.
- A new LDO that allows the user to cut power to the neopixel LED and external I2C port (Bi2C).
- More flash variants are now supported
- Added a couple of support functions for controlling the LDO control pin as well.
The updates are fully compatible with the previous version of the board so no users are left out.
There is one more use case for IR receiver. Thatโs possible to detect IR codes on RPI Pico using CircuitPython but thatโs impossible to do something more, see for example https://learn.adafruit.com/ir-sensor/circuitpython for IR receiver only (CircuitPython code) and https://learn.adafruit.com/remote-controlled-led-candelabra/code for IR receiver plus LEDs (C code). Even block code language for MicroBit allows to use IR receiver and neopixels together via interrupts but CircuitPython doesnโt....
There are multiple MakerDiary boards. Does yours match the photograph on https://circuitpython.org for your board or dongle?
We have not had similar reports, so I'm wondering about whether there might be a hardware problem with yours. Do you have non-CircuitPython software that is successfully doing BLE?
https://github.com/adafruit/circuitpython/actions/caches?query=sort%3Aaccessed-desc not that this has been the cause of problems lately but I noticed that there's now a page where you can see & remove actions/cache caches
We have a new failure now: (See: https://github.com/adafruit/circuitpython/actions/runs/3669965941/jobs/6204173152)
Error: Similar commit hashes detected: previous sha: 66eca9c35e9da27232c67b9504b0bec6b6828dd0 is equivalent to the current sha: 66eca9c35e9da27232c67b9504b0bec6b6828dd0.
Error: Please verify that both commits are valid, and increase the fetch_depth to a number higher than 40.
Error: Process completed with exit code 1.
@jepler want to try upping the fetch depth as a new commit in #7321, as was done in https://github.com/adafruit/circuitpython/pull/7329/commits/628865b2357bd1c344757a55ffbed763dc506121 ?
or @MicroDev1 you can try that. I am just about to go out for a while.
Here is the diff of tj-actions/changed-files logs in PR 7324 Good-CI and PR 7327 Bad-CI:
diff --git ci.log ci.log
index 46903bd36..5cf9191be 100644
--- ci.log
+++ ci.log
@@ -1,131 +1,69 @@
Run tj-actions/changed-files@v34
with:
json: true
separator:
include_all_old_new_renamed_files: false
old_new_separator: ,
old_new_files_separator:
files_separator:
files_ignore_separator:
path: .
quotepath: true
dir_...
The latest working tj-actions/changed-files version is v34.5.1. Also, reverts fetch-depth change introduced in #7329.
any idea why properties in RTD sometimes are not properly layed out ?
https://docs.circuitpython.org/projects/adxl34x/en/latest/api.html#adafruit_adxl34x.ADXL345.offset
does anyone know how to patch CircuitPython 7 to enable 'uctypes' ?
There are multiple MakerDiary boards. Does yours match the photograph on https://circuitpython.org for your board or dongle?
This is my board and I use this link.
We have not had similar reports, so I'm wondering about whether there might be a hardware problem with yours. Do you
have non-CircuitPython software that is successfully doing BLE?
Bluetoot...
@young frost this isn't documented anywhere but it looks like you can add this line at the end of an mpconfigboard.mk file, make BOARD=... clean and make BOARD=...: CFLAGS += -DMICROPY_PY_UCTYPES=1
you need to clean after changing Makefile or .mk files.
Same with pico-sdk's example scanner. it's an upstream bug but I have not reported it because I doubt it'll be addressed.
ssid: rssi: -90 chan: 1 mac: xx:xx:xx:xx:xx:xx sec: 5
ssid: rssi: -96 chan: 6 mac: xx:xx:xx:xx:xx:xx sec: 5
ssid: (access point 1) rssi: -70 chan: 7 mac: xx:xx:xx:xx:xx:xx sec: 5
ssid: (access point 1) rssi: -71 chan: 7 mac: xx:xx:xx:xx:xx:xx sec: 5
ssid:...
Thats really weird. I hypothesized that possibly the table, or code formatting used in some functions and properties on that page might be somehow related. But after commenting out several chunks of the page and re-rendering I'm still get that weird wrapping that is making those go horizontal instead of down to their own line.
@lone axle The newsletter is ready to crib from for the 2pm meeting
Thank you.
Disabling 'display: inline-block' in the developer tools on the docs page makes those properties render on their own lines how they are supposed to.
However I'm not sure if that gets us any closer to understanding or having a fix. All of the properties have the same classes anyhow and only some of them are getting wrapped weird.
<@&356864093652516868> The weekly meeting will take place here on discord at the regularly scheduled time of 2pm eastern. Which is a bit under 90 minutes from now. Fill in your notes to the document ahead of time if you have the opportunity. We look forward to meeting with everyone!
I'm not sure but I wonder if it's an issue with the versions of the RTD theme that is installed, I vaguely remember having visual differences when building locally because of versions mismatch
I think I've experienced that as well on occasion. This library does seem to render the same for me locally as the RTD hosted one. I tried adding and removing a bunch stuff in the actual docstrings and found some interesting ways to influence how it renders, but never did get it to look right ๐
it feels to me like something within the hierarchy doesn't get "closed", or maybe gets closed too early. And it makes all the things that render after it have different behavior due to the predecessor still being open (or maybe closing to early?). I cannot find any actual evidence of that in the docstrings or rendered HTML though.
RTD uses a whole list of specific version numbers (that actually get contradicted by requirements.txt - at least the sphinx version) so I don't know what's going on
/home/docs/checkouts/readthedocs.org/user_builds/adafruit-circuitpython-adxl34x/envs/1.12.8/bin/python -m pip install --upgrade --no-cache-dir pillow mock==1.0.1 alabaster>=0.7,<0.8,!=0.7.5 commonmark==0.9.1 recommonmark==0.5.0 sphinx<2 sphinx-rtd-theme<0.5 readthedocs-sphinx-ext<2.3 jinja2<3.1.0
@midnight ember is this something that actually happened? ```py
try:
pixels.fill((0, 0, 0))
except RuntimeError:
print("20***************************************************pixels.fill failed")
looking at the code in https://github.com/adafruit/circuitpython/issues/6793 and wondering what is the 'essential' part of it to reproduce the behavior
if something is failing that "should never fail" it might be a clue, or maybe it's a part that can be removed...
Could be the author wasn't seeing the neopixel turn off and added those statements in their effort to figure out why?
Although simple adding print statements seems like it would have done the job better....
and a runtime catch wouldn't make sense then.... nevermind ๐
making better bug reports is something we can all improve at and it can really help maintainers. but it's also good to recognize that in our world, aside from being newer to reporting software issues, folks encountering problems might not be able to spare a whole device for testing, if they can find a workaround and get their project to "work".
that's very true, there's a trade-off between investing some small time for a workaround vs. dedicating a device and more time to hunt down the root cause or isolate it with a small clean bit of code
It looks like we need to find a different calendar viewer, the old one is gone. I think it was formerly on the heroku free tier which was recently removed.
if you know of a .ical viewer that operates as a web page, or an ical-to-html converter we could add to the meeting repo, let me know!
gotta make sure everyone sees that one
Any iCal viewer for the MagTag or the PyPortal? ๐
๐
No problem!
i marked the drafts by hand today, but look forward to tekktrik's automation!
Haha I was going to say this one wasn't me ๐




