#circuitpython-dev
1 messages ยท Page 386 of 1
os.confstr(os.confstr_names['_SC_CIRCUITPYTHON_BOARD']) -> 'adafruit_feather_rp2040' or whatever
This seems really specific and unusual:
>>> os.confstr_names
{'CS_GNU_LIBC_VERSION': 2, 'CS_GNU_LIBPTHREAD_VERSION': 3, 'CS_LFS64_CFLAGS': 1004, 'CS_LFS64_LDFLAGS': 1005, 'CS_LFS64_LIBS': 1006, 'CS_LFS64_LINTFLAGS': 1007, 'CS_LFS_CFLAGS': 1000, 'CS_LFS_LDFLAGS': 1001, 'CS_LFS_LIBS': 1002, 'CS_LFS_LINTFLAGS': 1003, 'CS_PATH': 0, 'CS_XBS5_ILP32_OFF32_CFLAGS': 1100, 'CS_XBS5_ILP32_OFF32_LDFLAGS': 1101, 'CS_XBS5_ILP32_OFF32_LIBS': 1102, 'CS_XBS5_ILP32_OFF32_LINTFLAGS': 1103, 'CS_XBS5_ILP32_OFFBIG_CFLAGS': 1104, 'CS_XBS5_ILP32_OFFBIG_LDFLAGS': 1105, 'CS_XBS5_ILP32_OFFBIG_LIBS': 1106, 'CS_XBS5_ILP32_OFFBIG_LINTFLAGS': 1107, 'CS_XBS5_LP64_OFF64_CFLAGS': 1108, 'CS_XBS5_LP64_OFF64_LDFLAGS': 1109, 'CS_XBS5_LP64_OFF64_LIBS': 1110, 'CS_XBS5_LP64_OFF64_LINTFLAGS': 1111, 'CS_XBS5_LPBIG_OFFBIG_CFLAGS': 1112, 'CS_XBS5_LPBIG_OFFBIG_LDFLAGS': 1113, 'CS_XBS5_LPBIG_OFFBIG_LIBS': 1114, 'CS_XBS5_LPBIG_OFFBIG_LINTFLAGS': 1115}
and inconvenient
and I don't see an analogue in the host computer world
how are you feeling about board.id?
I think the main "problem" with board.id is requiring edits to all the board.c files.
I could try to automate it via awk
interestingly it's hardcoded in every port without using MICROPY_HW_MCU_NAME but it seems to have the same value
I/somebody
well, the PR has already done it, we just need a sed over it
I did automate it with python to begin with
oh there's a PR? even better.
i think a no-parse solution is the easiest for the libraries and code that need to check
why do some boards use board_global_dict_table and others board_module_globals_table ?
I think there is no good reason, it was an historical accident
I like the latter better. That could be another global sed fix.
the name used in shared bindings for the module dicts is, for example, STATIC MP_DEFINE_CONST_DICT(busio_module_globals, busio_module_globals_table);
actaully it's not so consistent in modules either
well, dict_table is used in class dictionaries, but globals_table is used in module dictionaries, it looks like
since board is a module dict, globals_table follows that pattern
I fixed up some text on the last page, thanks for doing the bulk of the work @FoamyGuy !
I wonder if we could have a macro at the top of the board globals_table that would expand to zero or more entries in the globals table .. it could reduce duplication, such as by automatically adding board.I2C / board.SPI, and of course this new board.id
I misunderstood #5092 and was looking at how
PWMOutcalculates the frequency divisor and top value. It's not that accurate at low frequencies, but I'm not sure it's any worse than other PWMOut impls.
Using PWMOut to make musical notes is kind of an edge case anyway, since there are other ways to do it, and is a trade-off of frequency accuracy vs duty-cycle accuracy; the latter is what the current impl favors.
I think this bug extends to the Metro Express ESP32-S2 however I can no longer reproduce it.
Similarities:
- Metro ESP32-S2 is was using network connections
- As the
gc.mem_free()ram ran out instead of freeing memory, the board would reset.
I was using the .bin nightly build from August 21st.
This morning I moved to the 7.0 beta .bin, and experienced the same issue. In an effort to find the minimum amount of code needed to reproduce the issue, I was using a large strin...
STATIC const mp_rom_map_elem_t board_global_dict_table[] = {
+ CIRCUITPYTHON_BOARD_STANDARD_ITEMS
{ MP_ROM_QSTR(MP_QSTR_D10), MP_ROM_PTR(&pin_GPIO10) },
```something like that
I was thinking maybe replacing the whole board_module_globals_table and board_global_dict_table line with a macro
CIRCUITPYTHON_BOARD_START_PINSC
...
CIRCUITPYTHON_BOARD_END_PINSC
there are boards that only have I2C, etc.
hiding {} inside of macros doesn't make me thrilled ๐
@tulip sleet the STANDARD_ITEMS macro can be carefully assembled so that it works if there's no SPI, etc
MicroPython generates the pin dict from a .csv file. I took that out because it was harder to read than the expanded C code
but this is making work where none is really needed atm
agree
One reason to go back to a machine-readable list is to generate the IGNORE settings automatically (or turn them into INCLUDE settings). Scott and I discussed that briefly, I can't remember in what setting.
but the current list could be parsed in an ad hoc way too
how about a toml file, would that be more readable ?
oh yeah, and it could have comments, which is the big thing I missed in the csv file
[pins]
TOUCH2 = pin_PA03
NEOPIXEL = pin_PA15
something like that
without even the [pins] section actually
that info could also be used to make mpconfigboard.h, or at least part of it
i think we need a [default_devices] section.
Ultimately we want a board and its details to be described in toml, whatever those details are: name, id, pin names, crystal or not, etc.
modules to include, etc.
whatever is in mpconfigboard.mk and mpconfigboard.h
the q is how much easier would it be to do this than the current scheme, so how worth it is it?
we had several errors recently involing the IGNORE pins, so that's a slight motivation
Information about a board could also include info that would be in circuitpython-org, so more of that could be added automatically (though adding the pics is an issue)
Unfortunately, #5220 did NOT fix this
It must be some kind of object that is moved but can't be moved safely, making this change causes the crash to go away for me:
--- a/py/gc.c
+++ b/py/gc.c
@@ -780,6 +780,7 @@ bool gc_has_finaliser(const void *ptr) {
}
void *gc_make_long_lived(void *old_ptr) {
+ return old_ptr;
// If its already in the long lived section then don't bother moving it.
if (old_ptr >= MP_STATE_MEM(gc_lowest_long_lived_ptr)) {
return old_ptr;
The implementations for supervisor/shared-bindings are directly in __init__.c, instead of being factored out into a shared-module/supervisor/__init__.c, etc. I think the latter would be better.
Motivation: I wanted to call common_hal_supervisor_get_ms_ticks() to use it as a timestamp for keypad events, but it does not exist.
On PWMOut there was an argument in the constructor variable_frequency https://circuitpython.readthedocs.io/en/latest/shared-bindings/pwmio/index.html#pwmio.PWMOut is there something analogous for for that in PuseOut now that does not need the PWMOut object? I see that frequency and duty_cycle arguments do exist for PulseOut but don't see anything listed in the docs for variable_frequency https://circuitpython.readthedocs.io/en/latest/shared-bindings/pulseio/index.html#pulseio.PulseOut
Note that any data stored in nvs using 6.3.0 is not readable by 7, or vice versa.
Closes: #4030
@tannewt This error is about supplying an optional buffer that's split into two for reading WaveFiles, but those buffers is not used for playing unless no conversion is done. Propagating the buffer sizes through is not so easy, and there are some assumptions about using 512-byte buffers. Given that audio is working better, I don't really see a use case for it right.
So what do you think about just dropping the buffer parameter from the WaveFile constructor? It is not used by any Lear...
Note that any data stored in nvs using 6.3.0 is not readable by 7, or vice versa.
I should make a note of this in the release notes.
It shouldn't be an issue with current implementation of post_usb(), irq is disabled and reinstalled with cpython irq. The race condition is probably on other issue.
It is an issue for CircuitPython as-implemented because an IRQ occurs outside of CircuitPython and therefore we don't queue up a background task to handle the resulting events. A simple fix would be to queue up the usb background function after we switch to our own IRQ.
I'd still like to emphasize that IRQ settings are d...
Is this the final name? I'd prefer to wait to merge until we know the final name.
- Fixes #5167 by defining away the problem.
This error is about supplying an optional buffer that's split into two for reading WaveFiles, but those buffers is not used for playing unless no conversion is done. Propagating the buffer sizes through is not so easy, and there are some assumptions about using 512-byte buffers. Given that audio is working better, I don't really see a use case for it right now.
The buffer arg is not used by any Learn Guide or library examples.
In the long...
I think @deshipu wanted it to vary IIRC.
Why would we revamp the API? I don't remember discussing any changes.
Does your simulator do a complete reset each time?
Yes. It first creates a fat file system with the user's code, writes it to the flash, and then starts the simulation.
I'd really appreciate any kind of solution / workaround that will let the user see the output from the very beginning. One workaround that comes to mind (which doesn't require any change in CP) would be to write code.py into _code.py (or similar), and then when the user starts the simulation, wait until we see the pro...
Why would we revamp the API? I don't remember discussing any changes.
I was thinking about speaker control for
- #5136
@deshipu I do remember that now. What helped when you specified the buffer size?
Note that id is a CPython built in. It's probably best to do board.board_id even though it is redundant. I think board is the right place for it. It's meant to vary per-board (hence the name) and encompass anything board-specific.
@onyx hinge are you looking at the esp wdt crash?
Please describe the new format somewhere. I'm not sure we want to co-opt the nvs space for something that doesn't use the IDF's standard format.
@slender iron no just briefly earlier
the long lived thing is a good lead
we must be handing a pointer to the idf that we move
Please describe the new format somewhere. I'm not sure we want to co-opt the nvs space for something that doesn't use the IDF's standard format.
It does use the IDF's standard format (both the old and new code do), in the "CPY" namespace of the nvs.
Old code: Each byte is stored as a separate u8, with the key being the index into nvm. This spends almost all of the storage on metadata (way under 1000 entries of nvm could be assigned before the 20kB of nvm partition was used up) and has...
@slender iron yeah I re-tested in the hopes that the one long-lived problem we'd fixed would fix that too, because it seemed like a really good lead and nothing I'd looked at last week. when that didn't work, I reasoned that I could pretty quickly determine if the long-lived moving process was still in the chain of events, and it looks like it is.
I hadn't thought of that yet because the i2c display move is different from the long lived one. The display is moving out of the heap to supervisor allocated space
I just thought it might be the scanning structure but it's not...
Thanks for the quick reply.
I think this is absolutely everything. Are you sure you want to do this?
I'd make this 8k since nvm often aligns with 4k boundaries on flash.
Are the two copies done internally to NVS? If we do it then we could just use RAM.
@tulip sleet Are there any boards that do not have adafruit_bus_device natively?
The CP module version.
Oh it looks like a bunch don't.
Nevermind. I was going to see about having the Project Bundler ignore it, but that's not an option it looks like.
I didn't go reading the source for how nvs works, but I just have the observation that when the nvs is full you cannot update an existing key. This made me jump to the conclusion that at least temporarily, for a given key, the old & new data are both stored within the nvs partition. This makes sense, because they want to allow an atomic update of all nvs content when calling the nvs_commit function in the esp-idf's API.
nvs doesn't allow updating a part of a blob, you can only repla...
@gilded cradle Is zip file manipulation a native thing in Linux? Or specifically, on Raspberry Pi?
@tidal kiln Yeah, trying to figure out once and for all how to structure breakout guides with the Project Bundle.
Because it used to be "CP Install" "Python Install" "CP and Python usage"
but it doesn't really work that way anymore with the Bundler.
I think I'll leave it as I have it now, and assume that folks who are using this stuff on RPi etc know how to create a file and run it.
since they'll end up with a .zip from the bundler?
I'm not indicating Python folks should download the zip.
I thought I might for a minute there.
Then decided against it.
But maybe that's a better idea?
Yeah, that was why I asked in the first place though.
yah, on a pi you wouldn't really need anything but the code, right?
Right.
since you'd pip install the libs
so could be confusing...i downloaded the .zip and what do i do with all these files?
(and the libs in lib/ would not be seen anyway)
I thought about including a paragraph stating something like "Save the following as code.py where it's convenient, and then navigate to it via command line and run python3 code.py"
Honestly, if we weren't supporting 6 and 7, I'd have them download the bundle.
Because the first level would contain code.py
what about projects that have images and support files ?
but it doesn't, so it's more confusing.
Oh good point.
Ugh.
Most breakout guides don't have that though.
this is for breakout guides?
Like, this is a simpletest for a CO2 sensor.
ah breakouts
i just wget it, but not sure how easy that'd be to guide-ify
a bit clunky, but can use the "copy code" to get it into some text editor and save
Could include this in the library installation section
like "Library installation and Example download" or something
What we used to do was use the REPL for the example demonstration
but A. doesn't work with all examples and b. doesn't allow for Bundlefly downloads.
So it's not a great solution, and we haven't addressed how to handle the Python side of that.
Or add a separate Python Example Download section below the lib install section might work better.
So this would be wget https://www.github.com/url-to-simpletest ?
it'd need to be the "raw" url
Yeah but it's buried in a CircuitPython 6.x/7.x folder
For now.
which is where everyone seems to go wrong and end up with HTTP instead of python code
wget the second one and you get http
When I click "raw"
yep. or that url.
Ok.
@tidal kiln What do you feel would create less support issues? A section telling them to dig code.py out of the bundle, or a short section with the wget command listed?
dig
Ok. Will do.
could give them an unzip snippet to just extract code.py
@tidal kiln How's this? I haven't added the wiring diagrams yet, but take a look at the rest. https://learn.adafruit.com/adafruit-scd-40-and-scd-41/python-circuitpython?preview_token=pfsUJ0diT27QVNKcNzw1LQ
yah. thats probably ok.
there's a separate subfolder for CP versions, right? in the zip
Yes
Mention it doesn't matter which version you choose?
Ok
right. yah. just something that mentions it'll be buried, and doesn't matter which.
Trying to figure out how to keep it agnostic because once 7 is stable, we don't need 6 support in the bundle.
I don't really want to go back and update every guide.
At least I think that is the plan.
"Extract the resulting zip file, and navigate to the code.py file. The CircuitPython version does not matter."
then if there's no version, shrug.
Not certain I like it. But it's a start.
@idle owl unzip -o -j FooBundle.zip */*/code.py
Woah what does that do
-o to force overwriting existing file, -j to "junk" directory structure (no subfolders get created)
and then wildcards to go down to subfolder
yep
Dang. Nicely done.
a bit hacky, it'll grab all versions
and overwrite as it goes
but should all be same, so doesn't matter
$ unzip -j -o Macropad_Hotkeys.zip */*/code.py
Archive: Macropad_Hotkeys.zip
inflating: code.py
inflating: code.py
Oooh, even better, the library examples are always in a folder called examples.
I mean MacOS appends a number to them
but ideally it'll be what it is for folks on Linux.
Fair enough
let me actually verify that's all same on pi
that was tested locally
I'm getting errors 500 downloading bundles
@jaunty juniper Really?
which guide? i just grabbed that macropad hotkeys bundle ok
ah it came back
@idle owl yah, looks same on pi
Perfect.
it was there https://learn.adafruit.com/touch-deck-diy-tft-customized-control-pad/code-the-touch-deck where the link gave me 500: https://learn.adafruit.com/pages/21870/elements/3086140/download?type=zip
wait it looks like every time it's the first time the link gives me 500
or it's random
I chose the Rubber Ducky guide.
just downloaded that touch deck bundle ok
I was in a private browser window, not logged in.
Does anyone know if the nRF52840 Feather CP port initialize busio.SPI differently when the device is running on battery, rather then on USB power?
I'm having a very strange problem with running a SPI device on it, when on battery power via JST connector, and i've narrowed it down to being a matter of what the nRF is running on when the busio.SPI class is instanced.
Bit more info here: https://forums.adafruit.com/viewtopic.php?f=57&t=182604&p=887310
Turns out it's an issue. Justin's looking into it.
@tidal kiln Anne thinks it might be confusing to microcontroller folks, having all the CPython instructions in the middle. I'm not sure how else to do it. I guess I'll run it by Limor and see if she wants it done some other way.
I actually just worked around the issue, by initializing a dummy SPI instance, and then another one, which is then used.
Looking at https://github.com/adafruit/circuitpython/blob/main/ports/nrf/common-hal/busio/SPI.c i can see that the code will prefer SPIM3 first, which is 32Mhz, and then SPIM2 which is 8Mhz. So guessing there is some issue with initializing SPIM3 when running on battery?
Or maybe the frequency is being set incorrectly.. Unfortunately i don't have any equipment to verify this
Glad @tidal kiln was able to help. I wasn't sure of the answer.
Ah right on. Thanks for following up anyway!
@tulip sleet just an FYI - you might find this interesting given prior struggles you have had with SPI on the nRF52840 https://forums.adafruit.com/viewtopic.php?f=57&t=182604&p=887344#p887344
I wonder if its related to the hardware errata on the SPIM3 interface. Seems there is already some workaround implemented in CP.
Very possibly -- I vaguely recall the issue and need to revisit it. Thanks for all your effor tracking this down
Its all very weird how its related to running of a battery though
Sure is...
I have been using batteries on M4 and esp32s2 boards regularly, guess I never tried an nRF52840
Thanks for looking into it!
I was surprised how low the sleep power usage was on the nRF, so wanted to switch to this from RP2040 which is not great for low power sleep
its like 0.3ma in time.sleep on nRF
I have been using an esp32s2 (unexpected maker feathers2) for sleep with the rfm9x -- it has been working well.I don't have the numbers ofhand.
I'll be interested to try the nRF as well now that you have prodded me ๐
this is for my prototype board. use Nordic's VID and a random PID for now.
@tulip sleet do you want me to do a beta.1?
do you want to wait for some more PR's before that? I would have time to do one on Friday.
@deshipu may want to weigh in too
We won't be able to merge this without a proper pid&vid, but I've approved the workflows to run for now so we can find out about any other problems.
@tulip sleet maybe? I was thinking the HID fix would be a bit urgent
I put a note in the guide to use Absolute Newest on or after a certain commit.
also i well might have time to do a release starting tonight and finishing tomw morning
It's everything under the opened handle. This clears out the old 6.3 style data. if someone is using a different namespace, it is unaffected.
Ah, ok. I didn't see that the handle had a namespace.
Thanks for answering my questions! This looks good! Thanks for getting it in for 7.0.0
Why not do USB mass storage instead? If you have USB CDC already then it seems you are most of the way there already.
I see this is the name we want to use for now. All good
@microDev1 do you still want a change from me? I simply picked the smaller of the two messages when I decided to make them agree
You are right. I guess that during my work I got a warning (error) that says my assignment discards const qualifier so I removed it and then forgot about it.
I re-added it.
I created another function in shared-modules that updates those valuse, I hope that what you meant...
Added documentation. Also, I change the function name to be more consistent with the module.
@ember iris SCD-30 has been running on RPi for 57 hours or something. I'm going to stop it at this point. I clearly couldn't reproduce it.
Yeah after they said it was a bread board my thought was that the real issue is a connection somewhere. Clock smearing seems like a really niche bug, and if you can't reproduce it I think it might not be the root cause
what does purple blink on magtag mean?
@slender iron I think it's from tinyuf2
ports/esp32s2/README.md:-
PIN_BUTTON_UF2is gnd when 2nd stage bootloader indicator is on e.g RGB led = Purple. Note: since most ESP32S2 board implementGPIO0as button for 1st stage ROM bootloader, it can be used for dual-purpose button here as well. The difference is the pressing order:
Convert adafruit_bus_device, adafruit_pixelbuf, analogio, atexit, audiobusio, audiocore, audioio, audiomixer, and audiomp3 modules to use MP_REGISTER_MODULE.
Related to #5183.
I'm starting with the modules that are available on my pybadge, using the test procedure outlined here. I'm keeping track of the modules as I go. Once I'm done with the pybadge, I'll move to my adafruit funhouse, which has a few more (e.g. wifi, ipaddress).
Mine does that when using code that causes the issue #5021 - https://github.com/adafruit/circuitpython/issues/5021
Looks good! can merge based on CI outcome
@slender iron did you verify my finding that effectively disabling the "make long lived" machinery fixed it?
true
Here is the minimum code that still caused the crash
from adafruit_portalbase.wifi_esp32s2 import WiFi
from secrets import secrets
import gc
wifi = WiFi()
wifi.connect(secrets["ssid"], secrets["password"])
print("wifi connected")
# crashes here
gc.collect()
print("gc.collect() finished")
However, this code doesn't crash
from secrets import secrets
import gc
import wifi
import ssl
import socketpool
import adafruit_requests
wifi.radio.connec...
I wonder if @gloomy shuttle 's reduced test case will run on kaluga so we can get a debugger on it
looks like should
@slender iron the long-lived object is a copy so what if the object has a finaliser? will it run earlier than it should be permitted to?
.. when the original is gc'd
ya, maybe! I hadn't thought about double running a finaliser
that said I think one of the permutations I tried earlier was supposed to skip moving when a thing had a finaliser
none of the objects passed to gc_make_long_lived in the failing case seem to have a finaliser
diff --git a/shared-bindings/socketpool/SocketPool.c b/shared-bindings/socketpool/SocketPool.c
index bd6a2b44f..8389ca24a 100644
--- a/shared-bindings/socketpool/SocketPool.c
+++ b/shared-bindings/socketpool/SocketPool.c
@@ -47,7 +47,7 @@
STATIC mp_obj_t socketpool_socketpool_make_new(const mp_obj_type_t *type, size_t n_args, const mp_obj_t *args, mp_map_t *kw_args) {
mp_arg_check_num(n_args, kw_args, 1, 1, false);
- socketpool_socketpool_obj_t *s = m_new_obj_with_fina...
that makes no sense, so goodnight
It is an issue for CircuitPython as-implemented because an IRQ occurs outside of CircuitPython and therefore we don't queue up a background task to handle the resulting events. A simple fix would be to queue up the usb background function after we switch to our own IRQ.
I am well aware of the background task, and post_usb_init() did removed the installed ISR in the tud_init() and installed its own. There should be no issues for circuipython with current implementation.
I still prefer the 0x style but that shouldn't hold up this PR. I'll open an issue for further discussion.
I added the buffer argument to be able to reuse the same pre-allocated buffer, and avoid memory errors stemming from repeated re-allocation of that buffer when playing different sounds repeatedly. I think it's a worthy thing, and rather than removing it, we should make everything use it instead. However, I can't work on this, so it's up to you to decide.
I'm using this in the Vacuum Invaders game, and it has solved a problem of memory fragmentation there, but I am not aware of any other ga...
@deshipu that is worthy. I had forgotten the original motivation of buffer reuse. I see you use a buffer size of 128. People were trying to make the buffer really big to improve audio playback quality, which didn't really work. So I will just throw an error when the size is out of range (>1024). I will make a new PR
See this Forum thread for the details:
https://forums.adafruit.com/viewtopic.php?f=57&t=182604&p=887344#p887344
Summary:
with an RFM9x featherwing mounted on a nRF52840, all works normally when powered vis USB, but when powered via a LiPo battery, the rfm9x fails its version check.
The OP found a workaround:
create a dummy SPI instance before creating the real SPI instance that is fed to the rfm9x init.
This appears to force the nRF52840 to is an different SPIM and it works. It is not...
@timber mango I opened an issue to track the nRF52840/rfm9x battery power issue. https://github.com/adafruit/circuitpython/issues/5233
- Fixes #5167
Validate that the optional WaveFile constructor buffer argument is 8-1024 bytes long. Larger than 1024 does not work and will not improve performance anyway. 8 was empirically determined to be the lowest usable bound for a MacroPad.
As part of this, I added a new argcheck.c arg validator, and removed an unused one. The new validator could be used a few other places, but I'll defer doing that now since we are working on more general arg validation schemes. I didn't se...
Looks good to me, and meets @deshipu's use case
Just as an exercise, I verified that the same issue occurs with an rfm9x breakout board instead of the featherwing.
Is it possible to change the frequency of a PulseOut after it's created? It's done using the old API in this project here: https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/c7471f8fcf2b77c619431c87025ac3df447cdc02/CircuitPython_TVBGone/cpx_main.py#L67 Is there some way to achieve the same functionality using the new API for PulseOut that accepts the pin rather than the PWMOut object?
That is a deficiency of the new API; we should add a PulseOut.frequency. Thanks for noticing that.
@FoamyGuy points out that https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/c7471f8fcf2b77c619431c87025ac3df447cdc02/CircuitPython_TVBGone/cpx_main.py#L67 varies the frequency on the underlying PWMOut dynamically, so we need to add PulseOut.frequency to allow this.
Thanks! CI passes with your new board, so I think all we need is for this PR to be updated with a properly allocate PID/VID. If your product is open source hardware, you can apply for one at pid.codes: https://pid.codes/howto/
@neradoc how are you feeling about this now? I would also approve board.board_id, as @tannewt suggested.
I cannot give a satisfactory account of why, but the crash in #5021 goes away when this object is initially allocated in the long-lived portion of the heap.
Closes: #5021
I can think of two reasons why allocating this as long-lived accidentally fixes a problem:
- The object is not being protected against gc.
- Something is trying to write past the end of the object and is smashing something just above it that then causes a crash.
I don't see a finaliser for it. Maybe that is the issue?
I'd like to understand our fix before we merge something. This feels similar to my "allocate less long lived and the problem goes away."
I hadn't followed up on the forum post. Good to know. Regardless, it means I don't have to update the guide.
well this is a new one. it looks like you have to talk on an I2C bus to turn on the neopixel power
On what
at power on PERI_POWER_ON is floating. I don't know my mosfet symbols well enough to know if that will pass power through Q12 or block it
@idle owl this espressif "hmi devkit"
Ah
PERI_PWR_ON is on a TCA 9554 I/O expander
Huh.
@tulip sleet do you read schematics well enough to tell me if PER_VCC_3V3 is on if PERI_PWR_ON floats?
V_GS is 0v so I imagine that means it'll be off
it is a P-channel, so it's on when the gate is grounded. This is pulled up, so ground to turn off
so it looks like it's normally off
floating is not great
CORRECTED!
well, I mean, it's not floating because there's the pull
This is an article and tutorial explaining what an P-Channel MOSFET transistor is and how
it works, its basics.
wait a minute, I might be wrong
when -VGS is zero, it is off, as -VGS gets bigger it conducts.
while N-channel work with +VGS
.. right?
also need to consdier depletion vs enhancement
it's starting to look like help-with-electronics in here ๐ thanks dan
sorry, i have not used MOSFETs much and I have to look things up
It was help-with-electronics in here the other day with the SPEAKER_ENABLE pin checks because I needed Dan's help ๐
I propose that henceforth they have to put "this way up" stickers on each transistor
board_id is fine, using lowercase helps separate it from the pin-related entries.
There was a discussion of possible changes to pins.c and the way it's handled that could impact this, like having a macro inserted as the first element in the globals table instead of the direct code, as a way to insert entries like this, and maybe automatically insert board.I2C and such when default pins are defined, to reduce the amount of manual entries in pins.c to add a board (and the ambiguity of when...
@onyx hinge p-channel depletion are rare
Anyone mind taking a look: https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/1807
bootloader 0x239A 0x010F
arduino 0x239A 0x810F
circuitpython 0x239A 0x8110
Forgot how much I don't like working with Pico. This counting-the-pins-to-find-the-one-you-want-because-there's-no-labels thing gets old really quickly.
Makes me pick GP0 for everything I can.
"But the ground pins are square!" Yeah ok, I soldered headers on it, they all look like solder-blobs now, thank you.
@onyx hinge As soon as I get the code embedded into this page, I'll send it your way to take a look at it. It's the MP3 template filled in for Pico.
hmmm the factory test app comes up scrambled on the hmi devkit, I wonder if the app is busted or the device
@solar whale Thank you - I was unsure whether to create an issue on it, as i don't know if its a hardware issue or a CP issue.. But i guess it might be both
For some reason, I consistently have about a 50% chance I will type "decoder" or "encoder" as "decode" or "encode". Writing guides for MP3 and rotary encoders gets frustrating. ๐
it's all sandwiched together
I thought as much. So much for that plan.
I'll probably grab & build their default app for myself, I have experienced that often devices ship with software that isn't quite right
but I'll also open it up at some point, I have to if I want to install the battery
Ah
Adafruit CircuitPython 7.0.0-beta.0-44-gd8b3d5af0-dirty on 2021-08-26; HMI-DevKit-1.1 with ESP32S2 ok that's a good start ๐
@onyx hinge Here's the preview of the MP3 template, filled in this time, for Pico. Can you give it a read-through and tell me if I need to / should change anything? https://learn.adafruit.com/mp3-playback-rp2040/pico-mp3?preview_token=wRJvd7RoFcwFRd1Dfr9KLg
should it say "following additional hardware"?
You'll need the following hardware to complete the examples on this page.
should there be a spot to explain which pins can be used? for instance on rp2040 it can be any pin, but on samd51 it can be just one of 2 pins if I recall correctly...
or is giving an example of SOME usable pin good
Hmm.
That's valid.
I can add something in about that.
I think it's worth including.
We do it for other concepts.
I2C, PWM, etc.
the project zip is not including any mp3 files I think
this is wrapped weirdly for me in learn, 1920x monitor, default zoom level
hmm. That's Learn wrapping it weird. But I'll fix it in the file.
I think that concludes my feedback ๐ it's nice and clear overall but I found some nits to pick ๐
This is why I asked you to take a look before asking for moderation on it. I appreciate it.
you're welcome
@onyx hinge How do you know what pins are valid? For I2C, I wrote a script that tries to create the I2C object on each pin, but MP3 isn't constructed like that.
Oh. SAMD51 is limited for AudioOut then?
yeah I thiink only A0/A1
What was that thing Ladyada did for generating board pin reference printouts?
You mean PrettyPins?
I canโt remember it for the life of me
Was that the one she covered on desk of Ladyada?
Do you mean the graphical pinout diagrams?
It created like a pin reference for svg board images?
I'm the one who does most of those ๐ But she and PaintYourDragon wrote the software to do it. We called it PrettyPins, and it stuck.
Yes, PrettyPins.
It can be finicky, and requires a CSV of possible pins for a particular microcontroller, and begins with a Fritzing object. (which is a zip of SVGs, really).
Is there code anywhere which shows which folders/files are created on a default CIRCUITPY filesystem, after it's been flashed?
@prime flower yeah let me find you a link
thx, rewriting wippersnapper FS code rn and want to ensure I'm not missing anything
look at filesystem_init in supervisor/shared/filesystem.h
@onyx hinge filesystem.h doesn't exist on main?
well this is a chicken-and-egg problem: The voltage bus called PER_VCC_3V3 is off unless an I2C expander is pulling a particular output LOW. PER_VCC_3V3 powers the I2C pull-up resistors. So, CircuitPython can't create the I2C bus to turn on the pull up
filesystem.c, oops
Ah.. I donโt have a way to make fritzing images :/
@onyx hinge Perfect, this is exactly what I was looking for. Thank you!
So... We also have a repo up for the software we use for making the Fritzing objects. But it takes finicky to a whole new level.
Do you have an EagleCAD .brd file for the intended board?
And a way to edit SVGs
@onyx hinge (maybe @tulip sleet ) do you know why it creates metadata_never_index?
It's a MacOS thing.
๐
@onyx hinge I'm at my desk now if you want to sync on this esp issue
@slender iron I'll have lunch soon .. how's ....:30 (in about 40 minutes) for you?
works for me. I'll get through my email
Yeah, I use eagle
remind me to exercise after ๐
There was a discussion of possible changes to pins.c and the way it's handled that could impact this, like having a macro inserted as the first element in the globals table instead of the direct code, as a way to insert entries like this, and maybe automatically insert board.I2C and such when default pins are defined, to reduce the amount of manual entries in pins.c to add a board (and the ambiguity of when to include those or not).
I would say, in the interest of getting from beta to re...
#5234 has a message change, so we could defer merging this and wait for the next automated update.
And also yes on the svg part as well
Espressif is giving out USB PIDs of their own. Let's get some from them: https://github.com/espressif/usb-pids
If an I2C device address is written as 0'b 0100 000x do I want 0b100_000 or 0b100_0000 in Python (0x20 or 0x40)?
neither actually seems to work, mind you
I just do a scan...
scan hangs
so there's something else wrong
or else it's taking a very long time
what's "(NC)" mean on a schematic? is that like non-populated?
Ok, there's a guide on creating a Fritzing object using our eagle2fritzing software, but it's probably woefully out of date in some places. https://learn.adafruit.com/make-beautiful-fritzing-parts-with-eagle2fritzing-brd2svg/overview
Not connected.
Or no connection.
In sensor datasheets anyway, that's what it means - don't connect anything to this.
I might be wrong about what it means on schematics though.
I think you are right kattni
OK, it scans now
you should be able to find a spot on the pcb labeled that doesn't have the resistor
OK so verified that this board has NO i2c pull-up resistors, not even the ones that it appeared would be powered when the PER_VCC_3V3 rail was powered.
My script is not working like it should be.
Two more small things. The type hints should fix the build.
Type hints please.
//| def update_refresh_mode(self, start_sequence: ReadableBuffer, seconds_per_frame: float = 180) -> None:
//| """Updates the ``start_sequence`` and ``seconds_per_frame`` parameters to enable
//| varying the refresh mode of the display."""
And I don't understand why.
It's supposed to exclude certain pins, but it is no longer doing that.
this is only tested to come up to the REPL & mount CIRCUITPY. Pin assignments should be right but were not double-checked. The screen is unsupported so far.
This board depends on the I/O pull ups for the I2C bus (verified by schematic) so this adds a compile time option that enables pull ups for ANY i2c bus on a board.
Sticking this in DRAFT state briefly while I apply for a PID from Espressif.
This is not excluding the pins in exclude. ๐
I'd not use the comprehension so I could add prints
Limor wrote that part a while back. I'll try to tease it apart.
There was a discussion of possible changes to pins.c and the way it's handled that could impact this, like having a macro inserted as the first element in the globals table instead of the direct code, as a way to insert entries like this, and maybe automatically insert board.I2C and such when default pins are defined, to reduce the amount of manual entries in pins.c to add a board (and the ambiguity of when to include those or not).
I would say, in the interest of getting from beta...
what is the type of p? And what does dir(board) return?--so what is the type of an element of dir(board)
dir(board) returns a list of pins.
p should be a pin type. I think.
are they strings or of a Pin class?
not type, pin name.
Hold on.
['__class__', 'A0', 'A1', 'A2', 'A3', 'A4', 'A5', 'APA102_MOSI', 'APA102_SCK', 'BLUE_LED', 'D0', 'D1', 'D10', 'D11', 'D12', 'D13', 'D2', 'D5', 'D7', 'D9', 'DOTSTAR_CLOCK', 'DOTSTAR_DATA', 'I2C', 'L', 'LED', 'MISO', 'MOSI', 'RX', 'SCK', 'SCL', 'SDA', 'SPI', 'SWITCH', 'TX', 'UART']
>>>
Does this, pins = [pin for pin in [getattr(board, p) for p in dir(board) if str(p) not in exclude] if isinstance(pin, Pin)] have any impact?
hmmm it works though, check you are running the right file or something ?
what is the issue exactly ? could you be getting pins you don't want because they have alias names that are not in the exclude list ?
Run the USB background once after we hook our IRQ up in case we
missed one.
Related to #5212
Well, ... time to drop the list comprehension then. For whatever reason p in dir(boarrd) is not able to compare against the exclude list.
pins = []
for p in dir(board):
print('Checking ', p)
if p not in exclude:
p_attr = getattr(board, p)
if isinstance(p_attr, Pin):
print(p, ' is a pin and')
pins.append(p_attr)
else:
print('Excluding pin', p)
I don't know if the pins are appending the correct thing there--but the prints should be clarifying
@hathach I see this issue was closed, do you still need feedback from me? I see #1020 does that fix this issue? If so I assume I can pull latest and test it? I see a mention of some HW changes, but nothing specific to the RP2040, anything needed before testing?
Yes, it's returning pins that are in the exclude list.
for example if I put "A1" in the exclude list it still gets returned because it is also "D1"
wait does this mean pin A0 could also be SWITCH
This is the "proper" way to sublicense from Nordic: https://github.com/adafruit/circuitpython/issues/5215#issuecomment-904980341
in which case you could make the exclude list a list of pins (with getattr to get the base name not the alias) instead of a list of names
Ohhh.
I get it.
It was working. But we added new names for the APA pins
so they showed up
This makes a lot more sense.
thank you.
@slender iron OK I'm done with ๐ฎ
Huh, I wouldn't have thought of that, and would have gotten caught in that pitfall soon. Thanks for highlighting it!
kk
Not clear on how I would do this.
is CP's behavior for getting a NACK on a i2c write to throw an OSError? (it appears to be, but want to confirm)
something like: exclude = [getattr(board, p) for p in ["NEOPIXEL", "APA102_MOSI", "APA102_SCK", "L", "SWITCH", "BUTTON", "A1"] if p in dir(board)]
Ahh ok
and then pins = [pin for pin in [getattr(board, p) for p in dir(board)] if isinstance(pin, Pin) and pin not in exclude]
oh I wanted to use a set() for uniqueness, but Pin is not hashable ๐ฆ
๐ Yeah, there's some tweaky things that made this annoying to write.
makes you jump through hoops
@lone axle Ugh, ok, so PyCharm stopped responding, so I force quit it, and when I restarted it, the project directory structure doesn't show up on the left anymore. And I can't find where to get it to come back. Any ideas?
If you see this thing along the side still you can click it to hide/show the project pane
alt+1 is a keyboard shortcut for hide/show that pane as well.
It only says "pull requests" down the side ๐
And I'm on Mac, even this windows keyboard doesn't seem to have alt anymore.
if you don't see that along the side anymore check View -> Tool Windows and try to find 'Project' inside of there
Clicking on that in the menu should bring it back I think. Mine also shows the shortcut keys off to the ride side in that menu, maybe it'll list what you can use instead of alt.
OK thanks I'll try that.
It wasn't in the list. I tried restarting again, and now it shows up. ๐
Anyway thanks, now I know where to find the shortcuts for those things.
Also shows up in the list again.
So weird.
It's CMD+1, which I tried, and it didn't work.
yep, you're welcome. I occasionally get similar issues where stuff is weird when I open up the app and restarting tends to get it back to normal.
Huh. Ok. Good to know.
I updated the code per your suggestions. I also noticed some tests were failed because of the formatting, I fixed this as well.
I hope it's all good now. Thanks for your help!
For review/corrections. I've applied for a PID from Espressif at https://github.com/espressif/usb-pids/pull/21 and will update PID in this PR after that PR is merged.
Note that I do not work for Lolin, but am simply contributing to CircuitPython. @biglesp got his S2 Mini delivered early and may get to testing CP before mine arrives.
hii sorry for the dumb question. i (stupiidly) managed to get into a reset loop (microcontroller.reset()) in code.py. Is there any way i can break out of it without reflashing the entire device (nrfExpressbboard)
press reset, then when the status LED blinks yellow, press reset to boot in safe mode, which doesn't run user code
thx!
I think we have all done that before!
Why not do USB mass storage instead? If you have USB CDC already then it seems you are most of the way there already.
Thanks for the suggestion! This is an interesting direction, I'll take a look at what it takes to use the mass storage to write code.py after the USB CDC is ready. One thing I'm worried about is that it may slow down the start up time (which is already much slower in comparison with MP, I still have to investigate why), but the only way to find out will is to give it a go...
Sure have -- but it could be much worse -- there was a spacecraft that had a command to turn it off -- someone executed it ... https://heasarc.gsfc.nasa.gov/docs/heasarc/missions/phobos1.html
Wow. I'm keeping that one in my pocket to help folks feel better about mistakes!
Is there a phrase or word that means "not broken out" with regard to pins?
e.g. "This is not an exhaustive list of not broken out pins."
unconnected ?
Well they're connected to something, aren't they?
I mean pins you can't use on a microcontroller board because they aren't made available to you with a pin or through-hole.
Trying to comment this audio pin script I wrote in case someone wants to add more excluded pins later.
Other than me.
The pins I'm referring to are connected, they're simply not available to you to connect to directly (without a lot of effort and tiny soldering).
like NEOPIXEL and DOTSTAR_CLOCK/DATA.
etc.
i think "not broken out" is fine
"unexposed"? "unavailable"?
"unbrokenout"?
I don't have them yet, but the store page says it ships with MicroPython by default โ maybe the same VID/PID could be used as MicroPython uses?
I like unexposed. I think it works.
My code which is running on an RP2040 will consistently crash into the hardfault handler when run on the nRF. I've tried removing bits of the code to see which part is causing it, but it seems to just happen at a different spot instead. Is there anything i can do to better troubleshoot crashes to the hardfault handler?
Bear in mind, you shouldn't be crashing into the hardfault handler. So consider filing an issue on the CircuitPython repo with your code and version info. But, someone else may have better suggestions for troubleshooting it more easily.
Yeah, the hardfault handler does mention filing an issue ๐ But rather then posting a big blob of my horrible code, i would like to try narrow down the problem if all possible, and save everyones time
I know that feeling entirely. You're doing what I would do, but there may be a better way to do it that I'm unaware of.
Scott & I think we figured it out. It's a super interesting bug:
scott will put together a patch for us soon, but it was way past lunchtime for him when we finished chatting & diagnosing. :taco:
Oh that's a messy knot of a bug
@onyx hinge can I ask a question regarding that bug? I think I hit that bug with my metro esp32-s2 as well, but once I hit a crash that knocked it into safemode, I haven't been able to trigger it (more than once) again. Could it actually have been related, or was I messing something up and just thinking it was related? It would only reset when the memory needed to be freed up
I have no idea why on earth safemode would have kicked it out of the issue
It's possible
A crash should usually make you enter safe mode but something about the esp32s2 means this bug was almost always making us restart normally, not go to safe mode
I can't predict the future but Scott may talk about it on his next stream
Huh. Well what an awesome wealth of stuff I get to learn about going forward
@onyx hinge So in place of indicating which pins work for audio, because some boards have a TON, I'm including a script you can run to get a list for yourself. Like I did on the I2C/SPI/UART pages in the Essentials guide, and the I2C template. (The others aren't templatised yet.)
@idle owl neat, is it working yet?
That UART script came in handy a bit ago!
It always was, turns out it was duplicate pin names messing with me. Neradoc helped me resolve that.
@dhalbert I think I just went with the same size that was hard-coded initially.
Updated with the PIDs in https://github.com/espressif/usb-pids/pull/22 but I expect this to change as they have other pending PRs to merge first.
Changed to board_id, rebased and added it to adafruit_led_glasses_nrf52840.
Now it makes sense WHY this change could affect anything (the socketpool was the long-lived object at block 1 of the GC heap) but this is not the right fix. we all knew that.
@urish you may want to see how this works for you.
This looks good to me, especially being careful who is doing the suspend/resume.
It appears that USB_VID/USB_PID board setting support is new in MIcroPython (e.g. it's not in the UM_TINYS2 board definition), perhaps in preparation of MicroPython using TinyUSB like CircuitPython does?
Lolin S2 Mini is not yet in micropython:master (Lol...
CircuitPython version
Adafruit CircuitPython 7.0.0-beta.0 on 2021-08-24; Adafruit Feather nRF52840 Express with nRF52840
Code/REPL
import board
import alarm
import countio
alarm_pin = alarm.pin.PinAlarm(pin=board.A2, value=False)
counter = countio.Counter(board.A3)
try:
alarm.light_sleep_until_alarms(alarm_pin)
0 / 0
except Exception as e:
counter.deinit()
import traceback
traceback.print_exception(type(e),e,e.__tracebac...
@urish you may want to see how this works for you.
Thanks! Seems to do the trick. I'm testing with the following script:
import time
s = time.monotonic()
print("Hello, World!")
while True:
print(time.monotonic() - s)
and getting output around 60ms into running main.py:
PS C:\P\rp2040js> npx ts-node demo/circuitpython-run.ts
RP2040 GDB Server ready! Listening on port 3333
0.0609999
0.0609999
0.0609999
0.0620003
0.0620003
0.0630002
0.0630002
...
@tulip sleet Were you following up with others about this issue? https://forums.adafruit.com/viewtopic.php?f=60&t=182595
@ember iris This answer is excellent! Thank you for following up with this! https://forums.adafruit.com/viewtopic.php?f=60&t=182579
That is yet another one. I'll add it to the internal email thread. Thanks.
sweet! I need to follow up, I'm working on the open issue of scd4x right now, I should be able to commit code for that then write a reply to that post. Thank you for letting me know I was on track! It helps a lot!
May want to consider letting Dave Astels know that we should be notified of those.
I thought he was cc'd on the email via a list, but I will check.
Happy I could bring this bug report to you. ;-)
Oh, I didn't know. He might be.
@tidal kiln I saw you mentioning this on the forums go by - FYI it's published: https://learn.adafruit.com/adafruit-scd-40-and-scd-41
coolio. thanks!
I reproduced this.
Both countio and alarm pins use GPIOTE, so I suspect that the alarm pin handling is mistakenly messing with the countio pin setup or GPIOTE interrupt.
Both PinAlarm.c and PulseIn.c seem to think they are the only GPIOTE users, and both have code like this:
if (nrfx_gpiote_is_init()) {
nrfx_gpiote_uninit();
}
nrfx_gpiote_init(NRFX_GPIOTE_CONFIG_IRQ_PRIORITY);
I'll definitely talk about this esp bug tomorrow
Thanks for this! It will be useful for many purposes.
@timber mango attaching a debugger and getting a backtrace from the hardfault handler is usually my next step
@jepler Quick question about the bitmaptools module. I'm used to seeing the globals table for each module define a __name__ property like, for example, what is done on line 73 of __init__.c in the bitbangio module:
However, I don't see that in the bitmaptools globals table:
https://github.com/adafruit/circuitpython/blob/fa63a41fc4c9db94d95f71e3512d...
I think @timber mango has narrowed it down to https://github.com/adafruit/circuitpython/issues/5240
you had corn to harvest?
yup yup
I'm sorry, as a Nebraskan I have tuned into this portion of the conversation
๐
I think I got 6 ears before these
boiled them and cut them off the cob to freeze 'em
@jfurcean Thanks for the minimal example! We used it to debug.
Prepping and freezing corn is awesome! I need to get some and freeze it myself. I've got a tiny freezer so I've skipped it the last few years, but while it's a chore the taste later on is worth it
@onyx hinge just pushed the code I had to https://github.com/tannewt/circuitpython/tree/fix_gc_network but need to think it over a bit more while I play some games ๐
def gc_layout(size_bytes, block_size=16, bits_per_byte=8):
pool_blocks = size_bytes * bits_per_byte // (block_size * bits_per_byte + 3)
print("max # blocks", pool_blocks)
bits_per_block = block_size * bits_per_byte + 3
atb_bytes = pool_blocks // 4 + 1
ftb_bytes = (pool_blocks + 7) // 8
allocation = atb_bytes + ftb_bytes + pool_blocks * block_size
print("total allocation", allocation)
if allocation > size_bytes:
pool_blocks -= 1...
@ember iris hey, I'm in Nebraksa (Lincoln).
Well hot dog! That was where I went to college, and where my partner is from. I'm from omaha myself, and pretending to fit in while in KC. Excluding the past year and a half, I've been there once ever month or two if not more
@ember iris if the circumstance arises I'd be happy to have a coffee or other tasty beverage with you. Likewise, we would usually get down to KC from time to time but it hasn't been happening lately.
We're due a trip to lincoln shortly--maybe late October, I'd love to meet up! I'll let you know next time we're on our way up! It's such a nice city, minus O street between 11ths and 17th, but that's to be expected
Sure, we'll see where things are at in October vis a vis doing in person things. Fingers crossed.
Fingers crossed! But if not, we're up in lincoln pretty frequently, so there's no worry that 'suddenly' things won't line up
I also noticed the __name__ attribute is missing from the board module, but to add that attribute, would I have to add it to every port where the global tables are defined, right?
I think I also found some code duplication:
and
It's safe to remove one of these, correct?
I have an awful idea. what if I create a keypad with 2 keys (A and B) with the keypad module, then use python code to "decode" them as quadrature. Is that fast enough for the rates that people manually spin encoder dials, or is it too slow?
since I'd get an event anytime either A or B changed, ...
Convert bitbangio, bitmaptools, _bleio, board, busio, countio, digitalio, framebufferio, frequencyio, gamepadshift, getpass, keypad, math, microcontroller, and msgpack modules to use MP_REGISTER_MODULE.
Related to #5183.
I also added the __name__ attribute to the bitmaptools module, per https://github.com/adafruit/circuitpython/issues/5183#issuecomment-906807750.
I can also add the __name__ attribute to each of the ports for the board module, but that may take some time (unless there's a better way to add the __name__ attribute to the module).
Thanks for the mention on the adafruit blog (https://blog.adafruit.com/2021/08/23/tensorflow-lite-for-microcontrollers-in-micropython-tensorflow-micropython-esp32/).
I wonder if I can take the amazing micropython and tensorflow lite image from the article for my project?
I found out that the size of tensorflow lite micro is actually about 200-300 kb in terms of firmware size.
I turned off all 84 ops and it saved 200 kb on esp32. The other 100 kb is taken up with the base api an...
if @tannewt says this is an appropriate pid/vid for use in circuitpython, that's good enough for me. Thanks and please remember to add your board on circuitpython.org!
- Fixes #4989.
Add back ctrl-C interruption of PIO reads and writes, but make it conditional on a new flag, user_interruptible, which can be set in the constructor. By default, Python-created PIO reads and writes are interruptible, but internal PIO use is not (neopixels, etc.)
The original ctrl-C interruption code can be seen here on the left side: https://github.com/adafruit/circuitpython/pull/4974/files
Minor change: reorder fields in StateMachine object to avoid gaps due to al...
It might or might not keep up. You may need to reduce the default interval. I have a feeling it may not keep up, considering that I think we see that already with the more minimal interrupt handling in IncrementalEncoder.
Oh it also turns out the number of blocks has to be a multiple of BLOCKS_PER_ATB.
looks good to me, but didn't test.
-
Fixes #5150.
-
Explicitly stop the PIO
StateMachinebefore deiniting it. -
Also minor fix: Don't run the
encoder_initPIO program twice.
PIO is new to me, so a few notes about this:
- The
IncrementalEncoderStateMachineis created withcommon_hal_rp2pio_statemachine_construct(), while theneopixel_write()one uses the more basicrp2pio_statemachine_construct(). I don't know ifIncrementalEncodershould use the latter or not, so I left it alone. - The `Incrementa...
.. or, for !MICROPY_ENABLE_FINALISER, before the first block of the pool.
Closes: adafruit#5021
Closes: #7116
I tested this with a version of #7716 (comment) and there were no problems detected. I haven't tested it on our real HW yet. This is the same as https://github.com/micropython/micropython/pull/7722 but prepared for merging into CircuitPython.
@DynamoBen sorry, it is my bad, the comment on the PR close this automatically, we merged since it contains other useful code even though it still hasn't fixed this one. Please provide your feedback as mentioned in above comment for further troubleshooting.
look perfect, the race is extremely rare not only because the time is tight, but also the usb IRQ comes with several events such as suspend/connected/reset. Therefore it is unlikely to be the issue. To be even sure, we can force re-connect with tud_disconnect() then tud_connect() but I think it would be overkill.
Will await @tannewt review, especially for API change.
I re-tested this with 7.0.0-beta.0, and I can no longer reproduce the problem. I tried copying a 200k file several times, syncing, and then comparing, and it was not corrupted. I also copied the kmk directory tree several times, though it fills up the PCA10059 filesystem now before it completes. In addition, the slow writes I saw before are not appearing.
We have fixed a number of things about background tasks, USB, and time-keeping since this report, though I'm not sure which fix may ...
Adding EncoderPad RP2040 hardware as a new board.
Pending PID request approval from Openmoko in this PR https://github.com/openmoko/openmoko-usb-oui/pull/32
Build is successful in GHA of my fork.
Thanks
just spotted https://realpython.com/podcasts/rpp/75/ on my feeds
Makes sense, didn't test.
CircuitPython version
7.0 beta
Code/REPL
253 // Collect all the report buffers for this device.
254 for (size_t id_idx = 0; id_idx < hid_devices[device_idx].num_report_ ids; id_idx++) {
255 gc_collect_ptr(hid_devices[id_idx].in_report_buffers[id_idx]);
256 gc_collect_ptr(hid_devices[id_idx].out_report_buffers[id_idx]);
257 }
Behavior
Scott & I spotted this while working on #5021 -- We think t...
@dhalbert if you can take a look?
Yeah, that looks wrong! Thanks for spotting it!
Adding to your finding @dhalbert , initializing a PinAlarm, and sleeping on it will actually break the countio instance, which will no longer increment.
Thanks! Didn't test, but looks good.
@capellini noticed that (most?) boards don't have __name__ in the board module: https://github.com/adafruit/circuitpython/issues/5183#issuecomment-906807750
It would be good to see this added, just for consistency's sake.
I've split the board.__name__ off into its own issue so we can consider it separately.
sounds great! please keep us informed and let us know if we can help in any way :)
Looks good and tests are happy. Thank you!
Looks good to me! Thank you!
One thing I'm worried about is that it may slow down the start up time (which is already much slower in comparison with MP, I still have to investigate why), but the only way to find out will is to give it a go...
We delay for 1 second at power-on start up to give the user a chance to enter safe mode: https://github.com/adafruit/circuitpython/blob/main/supervisor/shared/safe_mode.c#L83 We're ok with that because start up usually only happens once. (It won't delay when waking from a deep ...
@tulip sleet did you start fixing the countio issue?
Looks good. Just waiting for a new USB PID from Espressif.
Looks good to me! Also waiting on the USB PID from OpenMoko.
I only just looked at the code, and put those comments in the issue to record what I saw. I thought you might have a better handle on why the GPIOTE stuff was the way it was (and whether it was wrong). So go ahead if you want; I don't think I will have a lot of time to do further fixes today.
github is trying to get me to install this .. I am pretty sure we don't want it.
I'm not a huge fan of stale bots
though I could see it being useful for specific issues where we ask for a recheck and then give the reporter a week or two reply before auto-closing
Also, make all port-level CIRCUITPY_ settings overridable.
I also checked that the only modification we had was taken upstream as well, d97b6863badec4643bf8d1d1058a65d723572882
it was ported from an RP2040 which does require a deinit to run the same code again
Can you please expand on this part? If you create a countio.Counter() and then exit off the bottom of code.py, are the resources NOT released on RP2040? If so, that would be a separate issue that we'd like to fix so please file about it. If I misunderstood, thanks for any clarification you can offer.
CircuitPython version
Adafruit CircuitPython 7.0.0-beta.0 on 2021-08-24; Adafruit Feather RP2040 with rp2040
Code/REPL
import board
import countio
counter = countio.Counter(board.A1)
Behavior
Breaking out of the above code, and reloading will output following
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Traceback (most recent call last):
File "code.py", line 4,...
@onyx hinge Wasn't actually sure if it was intended, but at least it was not consistent across ports - sorry for not being more clear
FYI -- I have implement a temporary workaround where I just check if the first two bytes in the image are 0xff. If so skip the first byte... crude but effective. Now I'll start looking for root case in the core, but I wanted to have a working version on the saola.
@solar whale basically, if it has one byte that should have come from the previous frame .. but it's supposed to clear out any pending bytes when the frame-starting signal comes. did you file an issue about it yet?
i won't look at it for 2 weeks or more so I'm happy you're peering into the core and trying to find something out
I'm looking at 5240 now
I'm not really here, I'm on vacation ๐
#5251 filed for the RP2040
@onyx hinge Enjoy your vacation!!! I'm happy to poke around. We'll revisit this when you get back.
We delay for 1 second at power-on start up to give the user a chance to enter safe mode: https://github.com/adafruit/circuitpython/blob/main/supervisor/shared/safe_mode.c#L83 We're ok with that because start up usually only happens once. (It won't delay when waking from a deep sleep.)
So far, from what I can see, there's no way for the simulator to skip this wait unless:
- The simulator detects that the code is in a tight loop, e.g. repeatedly reading
supervisor_ticks_ms64()- I as...
I think this is fixed by the led status rework plus #4236
@mrdalgaard If
keypadhad simple tick timestamps, I wonder if that would work for you. Or if countio kept some kind of simple timestamps (e.g.supervisor.tick_ms()values) of the previousnticks, maybe that would be useful. But that wouldn't help your lower-power sleep quest.Some simple external hardware with a counter that you poll often might work.
Any of those modules, with logging of simple timestamps would definitely work.
pulseio could also work, as it does log tim...
what is the current state of multiprocessing in CircuitPython?
If you are trying to do a faithful board simulation, I think there are times when the user will want the 1-second delay to be able to enter safe mode. Can someone click on the reset button on the simulated board? Right now, you create the filesystem each time, but if eventually you make it persist, the user may want to enter safe mode, to, say, avoid boot.py.
And right now do you do soft-restart when the user types ctrl-D? Then it would be same as a real board.
Threads are not enabled. We do not support the second core on the RP2040. There is a continuing discussion about concurrency and event loops here: https://github.com/adafruit/circuitpython/issues/4542 that follows on from an older issue that got somewhat derailed: https://github.com/adafruit/circuitpython/issues/1380
@tulip sleet thanks, I will check the links out. have a great weekend
am trying to strobe several PWM GPIO and play a sound at the same time and get:
RuntimeError: All timers in use
if I use less then 10 GPIOs I can get the sound, more and the error occurs. If I can put the sound onto another process I think i can bypass the timer issue??? thoughts?
I am able to get REPL on nRF to freeze, needing a hard reset to get it working, by pasting a bunch from Mu in paste mode. Doing the same on the RP2040 will not freeze.
It doesn't happen at the same spot, but it will happen eventually. Tried it by pasting ~3300 bytes over 5 lines, but it seems to happen with any amount of lines..
Should i make an issue for this? Or just stop pasting as much? ๐
I have seen that happen once today, while testing if https://github.com/adafruit/circuitpython/issues/3152 was still there (it is)
Ah, already an issue there
it's not the same issue, this one is not about a freeze
CircuitPython version
Adafruit CircuitPython 7.0.0-beta.0 on 2021-08-24; Adafruit Feather nRF52840 Express with nRF52840
library bundle: adafruit-circuitpython-bundle-7.x-mpy-20210827
Code/REPL
# SPDX-FileCopyrightText: 2020 ladyada for Adafruit Industries
# SPDX-License-Identifier: MIT
# CircuitPython NeoPixel Color Picker Example
import board
import neopixel
from adafruit_bluefruit_connect.packet import Packet
from adafruit_bluefruit_connect....
True
Fixes #5240 and fixes #5211
am trying to strobe several PWM GPIO and play a sound at the same time and get:
RuntimeError: All timers in use
if I use less then 10 GPIOs I can get the sound, more and the error occurs. If I can put the sound onto another process I think i can bypass the timer issue??? thoughts?
_Originally posted by @LarryPriest in https://github.com/adafruit/circuitpython/issues/4542#issuecomment-907488603_
There are limited number of hardware timers on any particular chip. So multiprocessing will not help you: you have exhausted the hardware resources. What board is this?
LGTM; I fast-forwarded through your stream and followed the thinking. It would be great if others could test this on hardware.
I'll be able to check the encoders on my hardware once it lands on S3.
@jpconstantineau You can test the build artifacts from this PR. They are here.
Build failure with undefined reference to 'sleepmem_wakeup_event' on some boards.
Hi, I would like to work on this. Can you suggest me ways to get started?
The BlueMicro840 built fine. Tested it with 5 and 4 encoders.
5th initialization fails and RuntimeError: All channels in use exception comes out as expected.
With 4 encoders only, all 4 work as expected.
Haven't tested with using other GPIOTE consumers but I expect rotaryio will be fine if the above test is good.
The BlueMicro840 built fine. Tested it with 5 and 4 encoders.
5th initialization fails and RuntimeError: All channels in use exception comes out as expected.
With 4 encoders only, all 4 work as expected.
Haven't tested with using other GPIOTE consumers but I expect rotaryio will be fine if the above test is good.
I just tested this on my 4 encoder nRF52 board as I was testing PR #5253 which affected encoders too.
I can attest that the dead zone is still there for EC11 encoders.
Looking at the EC11 datasheet they appear to have 2 detents per pulse. This would make them appear to have a dead zone when they are reversed. In a nutshell, it's a "hardware issue", not a software one.
I have another board with a different e...
Tested that countio.deinit() works (does not crash), and alarm + countio can run concurrently
It is however possible to initialize both pin_alarm and countio on the same pin if done in specific order
alarm_pin = alarm.pin.PinAlarm(pin=board.A2, value=False)
counter = countio.Counter(board.A2)
Will run, but alarm will not trigger on light sleep (it will on deep sleep)
counter = countio.Counter(board.A2)
alarm_pin = alarm.pin.PinAlarm(pin=board.A2, value=False)
Will error with:
Traceback (most recent call last):
File "code.py", line 7, in <mo...
FYI -- after updating to the current tip of main, I had followed my usual pull/update process git pull then git submodule sync --recursive git submodule update --init git submodule foreach --recursive 'git fetch --tags' I then also had to delete and re-install/update esp-idf since the folder was out of sync. I tried to build an esp32s2 (saola_wrover) and it failed as follows ```/home/jerryneedell/projects/circuitpython/ports/esp32s2/boards/espressif_saola_1_wrover/sdkconfig...
CMake Error at esp-idf/tools/cmake/component.cmake:305 (message):
Include directory
'/home/jerryneedell/projects/circuitpython/ports/esp32s2/esp-idf/components/mbedtls/mbedtls/include'
is not a directory.
Call Stack (most recent call first):
esp-idf/tools/cmake/component.cmake:477 (__component_add_include_dirs)
esp-idf/components/mbedtls/CMakeLists.txt:4 (idf_component_register)
-- Configuring incomplete, errors occurred!
See also "/home/jerryneedell/projects/circuitpython/ports/esp32s2/build-espressif_saola_1_wrover/esp-idf/CMakeFiles/CMakeOutput.log".
make: *** [Makefile:253: build-espressif_saola_1_wrover/esp-idf/config/sdkconfig.h] Error 1
make: *** Deleting file 'build-espressif_saola_1_wrover/esp-idf/config/sdkconfig.h'
ws ``` I then just recloned the entire circuitpython repository and re-updated everything and the build succeeded, I just wanted to pass along a warning to anyone updating...
CircuitPython version
Adafruit CircuitPython 7.0.0-beta.0-106-g707e355a6 on 2021-08-28; Adafruit Feather nRF52840 Express with nRF52840
Code/REPL
import board
import alarm
import time
alarm_pin = alarm.pin.PinAlarm(pin=board.A2, value=False, pull=True)
x = 0
while True:
alarm.light_sleep_until_alarms(alarm_pin)
x += 1
print(x)
time.sleep(0.1)
Behavior
Code will sleep untill sending any keystrokes over USB serial conso...
If you are trying to do a faithful board simulation, I think there are times when the user will want the 1-second delay to be able to enter safe mode. Can someone click on the reset button on the simulated board? Right now, you create the filesystem each time, but if eventually you make it persist, the user may want to enter safe mode, to, say, avoid boot.py.
For the online simulator, there's no way to click on the reset button at the moment. I envision most users will get a link to some...
Take a look at #5222, which added board.board_id. The author wrote a script to automate the changes.
And right now do you do soft-restart when the user types ctrl-D? Then it would be same as a real board.
Yes, it works just like on the real board. Why?
I just mean that the "play" button could start from a hard reset, or it could just write code.py, as happens on physical hardware now.
The main reason now for using boot.py is to customize the presented USB. Is the simulator able to simulate HID devices, etc.?
My OpenMoko PR just got merged.
No need to update the PID as it already matches.
Thanks
pico, i am working on several sub-modules of a K-9 project. i have the memory map ( bigclivedotcom gallium) and a binary counter but when I tried to add sound i ran out of timers. oh well, next step -> . . . thanks for the insight.
CircuitPython version
dafruit CircuitPython 7.0.0-beta.0-110-gb90a16b67 on 2021-08-28; Saola 1 w/Wrover with ESP32S2
Code/REPL
This is a modified version of the ov2640 library example. The changes print out the first/lat 10 bytes of each image and if the extra byte is present, it is stripped when the image is encoded.
board
import busio
import digitalio
import wifi
import socketpool
import adafruit_minimqtt.adafruit_minimqtt as MQTT
from adafruit_...
You could play audio with audiobusio.I2SOut, but you'll need an I2S amplifier (we have those). You could try that as a substitute for AudioPWMOut now even if you can't hear what you and see if you run out of anything.
If you need lots of PWM's, you can get a breakout board that uses a PCM9685, which has up to 16 channels on some breakouts. You control it with I2C. See https://www.adafruit.com/product/815 and https://www.adafruit.com/product/2928, for example. There are others.
I wil...
I was reading comments on a bug, and stumbled upon this comment:
https://github.com/adafruit/circuitpython/issues/5212#issuecomment-907307341
which explains why my keyboards are so slow to work when I'm switching between hosts with a KVM. I previously blamed the slow USB enumeration in general, and the KVM in particular, but this explains it.
I wonder if adding a compile-time option for skipping this wait (so that I could use it for my keyboards) would be accepted? In my case I don't p...
I took a second stab at this, first implementing MP_ARG_FLOAT and then MP_ARG_FUNC, MP_ARG_TYPE and MP_ARG_ARRAY_OF. This is at https://github.com/adafruit/circuitpython/compare/main...jepler:arg-parse-2?expand=1
I found that
- There weren't as many places as I thought to validate ranges
- On non-express m0 boards, there weren't enough uses of MP_ARG_FLOAT to justify the code bloat
- Even on express m0 boards (specifically circuitplayground_express) there weren't enough uses of MP_A...
Yeah the code we have today is heavily geared to 1 detent per quadrature cycle. Supporting other "granularities", sometimes called X2 and X4, would be a nice addition, except for the problem of making it fit on small boards like the M0s which don't have much code space left.
Hey folks - Can I please get some eyes on this pinout (for sanity reasons) to confirm I have made the Dx/Ax numbers compatible with the FeatherM4 ? After making my FeatherS2 pinout slightly different (making life hard for folks), I don't want to make the same mistake with my FeatherS2 Neo. Thanks!
@atomic summit is there psram?
Yes, 4MB Flash, 2MB PSRAM in the ESP32-S2 chip.
@atomic summit looks like the pin you have labeled IO45/D2 is D4 on the Feather M4 express
That's exactly why I need "fresh eyes on this"... totally missed that, thanks!
You're placing D0 where the Feather Specification states:
AREF - this is the Analog Reference if there is one for the chip. If there is not, keep this pin not-connected. We recommend Wings don't require this pin as not all chips have external ARef's.
If you're doing this knowingly, then do away. Note that Feather STM32F405 puts the BOOT pin where Feather M4 put "D4". That spot is
'Free' Pin - This is the pin to the right of TX. You can use it for an extra GPIO or if you have some onboard module that has a useful breakout. Sometimes we tie it to ground. Do whatever you like! FeatherWings should not require or use this pin unless there's some really good reason.
apparently nobody checked this pin list when they made the feather pico's pins go A0 A1 A2 A3 D24 D25 (i.e., they should have made it D18/D19 to match Feather M4), probably late to fix now.
Adafruit would rather your silk show the D-numbers but again that's something that you may be doing in this way knowingly
IO0 on that AREF pin is required. I do it on the FeatherS2 and I've never heard of any issues with having it there.
(I mean, instead of the IO numbers. SCK/SDL etc get labeled with their function)
That's all I got in the way of commentary. I hope some of it was helpful!
D numbers is not a thing for ESP32s. IO number is. That's a deliberate thing by me. But having the right D numbers in the CPY firmware for compatibility is what I want to ensure so CPY code works.
I can also add them in Arduino as well in the board definition.
Yes it was, thanks heaps for looking over it!
D2/D4 on IO0/45 positions was back to front... nice catch
ah, a swap
Yup - updated image..
@atomic summit I'd like to say I wish my hands were half as steady as yours manually placing 0402s and 0603s...
Just takes practice.. LOTS and LOTS of practice ๐
Or maybe I just need to lay off the coffee
Is that an LED array in the extra space left over from the flash/psram being internal?
Yup, it's a 5x5 RGB Matrix onboard - with user controlled dedicated LDO for power.
Thereโs honestly not enough #rgb bling in our lives!
#FeatherS2Neo #CircuitPython #ComingSoon https://t.co/6jGi8jgLc4
I hadn't heard what you intended to do with it, just that you had plans for the space.
Initially my plans was to make a "cheaper FeatherS2" as the silicon shortage is making PSRAM & Flash super expensive and really hard to source... but adding 25x 1515 RGB LEDs ended up costing as much as the Flash & PSRAM - hahahaha
Well, at least you only have availability of the FN4R2 to worry about, but its all eggs in one basket.
And the FN4R2 is in short supply - been in a queue for 6 weeks for more reels, no ETA yet ๐ฆ Lucky I also use it on my TinyS2 so have some stock here.
Lolin is probably buying up a ton of them.
Is the simulator able to simulate HID devices, etc.?
Nope, at least until someone asks for it. Remounting the FS read/write could come up with some use cases (e.g. users who prototype a data logger and want to experiment with code that writes to the FS).
Writing code.py when you press on play could be a possible solution. What I'm still concerned about is the first-time experience: users who open a link to a simulation project will still have to wait for the safe boot detection code t...
when re-flashed with upstream's sensor demo the screen is correct. Docs say it's a "Display interface: 16-bit, 20 MHz, 8080 parallel communication" so I suspect that talking to it is just a matter of extending the parallel-bus display to 16 bits
though the I/O pins are nonsequential, that's a wrinkle
.. leaving a backwards-compatible alias in displayio.
This saves about 1kB flash on circuitplayground_express_displayio.
I tested this on a pyportal titano and the display still displays.
There seem to be no direct uses of displayio.ParallelDisplay within the bundle or learn, for whatever that's worth; just the couple of boards that have the displays built in.
My interest in doing this right now is that for the ESP32-S2-HMI-DevKit-1, I may need to complicate the constructor to support non-consecutive pins; having this code disabled on the low-capacity boards that include displayio means less worry over code size increase.
CircuitPython version
Adafruit CircuitPython 7.0.0-beta.0-106-g707e355a6 on 2021-08-28; Adafruit Feather nRF52840 Express with nRF52840
Code/REPL
import microcontroller
import watchdog
w = microcontroller.watchdog
w.timeout = 20
w.mode = watchdog.WatchDogMode.RESET
Behavior
Code will immediately crash and return:
Auto-reload is off.
Running in safe mode! Not running saved code.
You are in safe mode because:
CircuitPython core c...
I had a look again at the A / D / busio names compared to metro m4 and didn't spot any other items to mention
I'm still having this issue on Pico RP2040, using 7.0.0-beta.0. There is a difference in the crackling between beta.0 and alpha.6. On alpha.6 it was the same crackling for the entire length of play back. On beta.0 it cycles, kinda like:
_|ยฏ|_|ยฏ|_|ยฏ|______|ยฏ|_|ยฏ|_|ยฏ|______|ยฏ|_|ยฏ|_|ยฏ|_
Code I am using:
`import board
import audiocore
import audiomp3
import audiobusio
import digitalio
import time
f = open("/music/15-03.mp3", "rb")
mp3 = audiomp3.MP3Decoder(f)
a = audiobusio...
I noticed that setting BLE up in REPL, and then connecting the app to it will allow you du send text to the REPL console from the client, but not in the other direction. So it seems to be working one way.
In CPython, 0x%p style is preferred for address, I think we should use it instead of %p for consistency.
They also have a check to ensure presence of leading 0x:
case 'p':
sprintf(buffer, "%p", va_arg(vargs, void*));
assert(strlen(buffer) < sizeof(buffer));
/* %p is ill-defined: ensure leading 0x. */
if (buffer[1] == 'X')
buffer[1] = 'x';
else if (buffer[1] != 'x') {
memmove(buffer+2, buffer, strlen(buffer)+1);
buffer[0] = '...
I'm not sure how this rates on the important/unimportant scale, but I threw together a patch anyway.
Closes #5262
The last commit is the actual change for the issue; the other 3 commits are stuff it would be good to pull in regardless, and don't have any size impact.
I'm still having this issue on Pico RP2040, using 7.0.0-beta.0. There is a difference in the crackling between beta.0 and alpha.6. On alpha.6 it was the same crackling for the entire length of play back. On beta.0 it cycles, kinda like:
_|ยฏ|_|ยฏ|_|ยฏ|______|ยฏ|_|ยฏ|_|ยฏ|______|ยฏ|_|ยฏ|_|ยฏ|_Code I am using:
import board import audiocore import audiomp3 import audiobusio import digitalio import time f = open("/music/15-03.mp3", "rb") mp3 = audi...
While weโre updating stage, have you taken a look at https://github.com/python-ugame/circuitpython-stage/pull/14?
Ouch, I missed it, even though I now have an e-mail filter specially for this. I guess I will need to make that change to all three files now.
Possible โ I donโt have a PyBadge or PyGamer so I didnโt check what keys they have and how they are handled.
Updated now to include @cwalther's fix.
@nathanielbutts Could you open a new issue, specific to MP3 (it sounds like it's only MP3?)
Got to listen to one of Scott's deep dives while I was falling asleep last night and woke up to an important discussion between Limor and Scott regarding the supported qspi flash chips for the RP2040. Is there a list of supported/known working chips so that I dont get any surprise. Digikey only had the DTR version of the W25Q128JV. Will it work? Does it need a different config? I tried looking it in the docs or in the code but couldn't find much for an answer.
<@&356864093652516868> CircuitPython Weekly meeting is in about 1.5 hours. Please remember, if you wish to participate, or want to have your notes read off during the meeting, you'll need to update your Hug Reports and Status Updates in the notes doc. Thanks! https://docs.google.com/document/d/1bO1IU2lth51Bl0pKTlVy9IYak9HuB7GFfyaRQhFISxs/edit
CircuitPython Weekly for August 30, 2021 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you canโt make the meeting and would still like to participate,...
@mortal mica I think all new winbond should be ok. worse case you need to add new config for it
generally you want something that can do quad spi
Thanks. I have parts coming from all over. Might be a while before I know for sure but it sounds like it's going to be ok... Where would a new config need to be added? ( So that I can compare with existing ones so that I know what I would need to get into)
CircuitPython version
Adafruit CircuitPython 7.0.0-beta.0/Raspberry Pico
Code/REPL
import board
import audiocore
import audiomp3
import audiobusio
import digitalio
import time
f = open("/music/15-03.mp3", "rb")
mp3 = audiomp3.MP3Decoder(f)
a = audiobusio.I2SOut(board.GP27, board.GP28, board.GP26)
print("playing")
a.play(mp3)
while a.playing:
time.sleep(.001)
print("stopped")
Behavior
I'm still having this issue on Pico RP2040...
@nathanielbutts Could you open a new issue, specific to MP3 (it sounds like it's only MP3?)
Absolutely. Opened Issue #5226
This enables the _stage library and adds stage and ugame modules to the
frozen modules, so that all Stage games should work.
I had to do several hacks:
-
Since displayio.release_displays doesn't release the pins, I couldn't
re-initialize the display inside the ugame module. Instead I changed
the default display initialization for the board to match what Stage
expects. (see https://github.com/adafruit/circuitpython/issues/3873) -
Since there is no audioio module, but Stage g...
Skipping one more time, testing aluminium tube transportation in pandemic time. ๐ญ
This PR update tinyusb stack which has update to get nRF5x port passed the USB Compliance Verification (USBCV) test. Other ports still need a bit of tweak but will eventually pass as well hopefully. It does include a decent changes especially in MSC driver due to all corner case e.g MSC READ10 with direction bit set to output, or mis-matched in command wrapper and scsi operation etc ... Please test it out if you could, I only did a few simple test with circuitpython.
- For USB Compliance V...

@tannewt i think this is the NUS thing?
@lone axle Thanks for keeping up with cookiecutter!
I was experiencing this exact problem. Some HTTPS websites worked fine and others issued a traceback originating in _get_socket. After going to Arduino's IO Cloud website (create.arduino.cc/iot) and updating the firmware for the u-blox the error went away. The device came with NINA firmware version 1.4.5. The upgraded version is 1.4.8.
same here with organizing pain, I have a good bit of it that still needs to be done as well
This is kind of what I was expecting as a response from most folks ๐
So I have most boards grouped into Feathers, Raspberry Pi Boards, Metro/Grand Central Style, and CPX/Misc
I was debating between this or by MCU.
Also have a breakouts category for add-on boards.
I have a lot of everything, so any choice will have enough to fill a bin.
I think form factor sorting works quite well.
Fair enough. I might give that a try.
The only time I have a hard time finding a board is when I forget to put it back in the right place.
Breakouts, I'm trying out doing them by concept, e.g. air quality/gas, temp/humidity, etc. So all of the air quality/gas sensors go in one container, and so on.
That's how I do it
Might need to combine a couple because I don't know if I have enough of every type to fill an entire container, but motion/IMU/accel/gyro and temp/humidity will both definitely have enough ๐
OK, thanks for the suggestions. I think I'll give this a try.
Yeah, voltage regulators and level shifters are good categories too
oh and FRAM chips
My previous breakout organisation was alphabetical by part name. Turns out there's a lot of maybe four letters of the alphabet, and hardly any of any other. It works as a concept, but I think by feature is a better way to go. I'll find out eventually!
Yeah, easy enough to locate a small pile and look through them
Thanks all!
Have a good week all ๐
@inland tusk https://youtu.be/LPPoc_0_Haw
Here is the notes document for Tuesday's CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord (just 24 hours later). 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/1Dag1KnCTNh50q5fc_ghaMdmUjNiBp5KsdF4FbKKnIEk/edit?usp=sharing
CircuitPython Weekly for September 7th, 2021 Here is the notes document for 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...
?serverinfo
What is the bitrate of the MP3? You may need to lower it.
Yup, the plan is to switch the UUIDs used for the CP serial connection.
CircuitPython version
Adafruit CircuitPython 7.0.0-beta.0-123-g89fc1890a-dirty on 2021-08-30; MEOWBIT with STM32F401xE
Code/REPL
>>> import board
>>> import digitalio
>>> digitalio.DigitalInOut(board.MENU)
Traceback (most recent call last):
File "", line 1, in
ValueError: MENU in use
Behavior
Traceback (most recent call last):
File "", line 1, in
ValueError: MENU in use
Description
No response
Additional inform...
These are the MP3 restraints for RP2040/Pico. Supported MP3 files are mono and stereo files less than 64kbit/s, with sample rates from 8kHz to 24kHz. (This info was gathered for an upcoming guide, and I thought it might be helpful here.)
Thanks. The list is a whole lot longer than I expected.
๐
Compile time option is fine with me. I wouldn't have it on by default though.
nRF will have a second wait time for the BLE workflow.
Perhaps we could add a safe mode pin to check at some point or maybe even a key matrix. Those checks would be fast but still allow for safe mode.
I envision most users will get a link to some project, the click the "play" button, see how it works, and start playing around with the code.
What if you don't have the play button and just start the simulator immediately? That way it'd be like plugging in a CP board. Are you able to blink the on board LED? That'd make it clearer that something is happening.
Can this simulator be run headless? I'd love to use it for library CI to track memory use.
I will have the boards to test tomorrow.
Sometimes we don't want the delay in the device's startup.
I used a simple flag, but now it also occurs to me that we could
instead make the wait time a define, and set it to 0 to disable it.
LGTM; I fast-forwarded through your stream and followed the thinking. It would be great if others could test this on hardware.
I was experiencing this exact problem. Some HTTPS websites worked fine and others issued a traceback originating in _get_socket. After going to Arduino's IO Cloud website (create.arduino.cc/iot) and updating the firmware for the u-blox the error went away. The device came with NINA firmware version 1.4.5. The upgraded version is 1.4.8.
Intersting @ngdrascal ... when I get a chance I will have to check that out. Have you been able to recreate both the HTTPS and MQTTS code examples from ...
*frantically adjusts pull request* ๐
๐ No worries!
frantic programmer noises
That smacks of a terrible subtitle provided for some video.
Itโs true
This will un-break examples that got confused by the presence of
two Nordic UART Services. It also adds a version characteristic
that gives the CircuitPython build tag back.
Fixes #5252
Thanks for grabbing this @tannewt !
I haven't been using MQTT/S but was having issues regarding HTTPS encountering the exact same _get_socket traceback in an error. My solution was to install the root certs for the specific domains I was targeting (which wasn't made very clear from any of the examples I could find) using the arduino-fwuploader at https://github.com/arduino/arduino-fwuploader
Thanks for the PR! One request
I'd rather have an early return and let the compiler remove the rest. It should be before line 69.
Intersting @ngdrascal ... when I get a chance I will have to check that out. Have you been able to recreate both the HTTPS and MQTTS code examples from above using or adafruit example codes since updating the ublox firmware?
@dedSyn4ps3 The Adafruit example from https://learn.adafruit.com/circuitpython-on-the-arduino-nano-rp2040-connect/wifi actually worked fine before I upgraded the ublox firmware. I wasn't experiencing the issue with all websites, just some. For example posting to ht...
Fixes a crash from trying to raise an exception when trying to
deinit a RESET wdt by not raising an exception.
Fixes a crash when raise a wdt exception in the REPL when waiting
for input. We now catch and print any exceptions raised.
Fixes #5261 (USB after a watchdog still doesn't work.)
Adafruit CircuitPython 7.0.0-beta.0-133-g8fbb3e6d2-dirty on 2021-08-30; Adafruit Feather nRF52840 Express with nRF52840
>>> import microcontroller
>>> import watchdog
>>> w = microcontrolle...
Don't let pending serial input wake us up
Fixes #5257
@ATMakersBill We've changed a number of things and this issue is likely fixed. I'm closing now but will reopen if you test and find that it is still an issue. Either way, I don't want to block 7.0.0 on this.
Moving this to post-7.0.0. @DynamoBen we'd like your feedback on https://github.com/adafruit/circuitpython/issues/4190#issuecomment-898844231
Closing this since no one is actively working on it. The branch and code will remain available to anyone who wants to pick this up.
@codetyphon Care to finish this? Otherwise I'll close it. Thanks!
No problem! Good to do in 7.0.0
Will the current patch from tinyusb still be streamed into 7.0.0?
Rainer Paskiewicz
On Mon, Aug 30, 2021 at 9:32 PM Scott Shawcroft @.***>
wrote:
Moving this to post-7.0.0. @DynamoBen https://github.com/DynamoBen we'd
like your feedback on #4190 (comment)
https://github.com/adafruit/circuitpython/issues/4190#issuecomment-898844231โ
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github...
If there is some delay, you could have a little UI delay countdown like a circle filling its edge (like the Apple download/install circle in the App store) that takes one second to complete. That would make it obvious that there was something to wait for.
Convert neopixel_write, onewireio, ps2io, pulseio, pwmio, rainbowio, random, rgbmatrix, rotaryio, rtc, sdcardio, sharpdisplay, _stage, storage, struct, supervisor, synthio, touchio, traceback, usb_cdc, usb_hid, usb_midi, and vectorio modules to use MP_REGISTER_MODULE.
Related to #5183.
This is good. Of course let's document the UUID somewhere.
Intersting @ngdrascal ... when I get a chance I will have to check that out. Have you been able to recreate both the HTTPS and MQTTS code examples from above using or adafruit example codes since updating the ublox firmware?
@dedSyn4ps3 The Adafruit example from https://learn.adafruit.com/circuitpython-on-the-arduino-nano-rp2040-connect/wifi actually worked fine before I upgraded the ublox firmware. I wasn't experiencing the issue with all websites, just some. For example posting t...
I know we are super close to a 7.0 release and 6.3.0 is stable and not being worked on anymore, but is there a way to get my FeatherS2 Neo added to 6.3.0? If I do a PR against the 6.3.0 tag?
Oops, you are completely right, there is even a comment there. I should have looked closer. Fixed now.
@ngdrascal fantastic...so you're saying that the snip above is what you ran with no errors? I just hopped on to post my own success on the arduino-side of things when I saw your update.
@dedSyn4ps3 Correct.
In my case I DID NOT upload any certs. I just updated firmware on the ublox.
@ngdrascal gotcha. The reason why I uploaded the certs was due to a 403 Forbidden when first attempting to make the API request for Initial State.
After uploading the root cert and double checking my request query everything went through just fine. ๐ค๐
@tannewt , I think we've just about got this bug squashed...I'll double check the CP version of querying my initial state dashboard to see if it goes through after the ublox update.
If it doesn't, I have not found anywhere in the docs of a way to include a root cert or .pem file into CP code like can be done through arduino. Any way to do that if there still is an issue with some endpoints?
@ngdrascal gotcha. The reason why I uploaded the certs was due to a 403 Forbidden when first attempting to make the API request for Initial State.
After uploading the root cert and double checking my request query everything went through just fine. ๐ค๐
@ngdrascal @ladyada , I re-loaded CP onto the board and TLS queries to the Initial State API are now functional as well...great success!
I don't know if the ublox update alone would have fixed this, since the arduino request generated a...
We haven't done this even for Adafruit's own boards. 7.0.0 is really better in pretty much all ways. Is it just that people will refuse to use a "beta"?
Currently, passing in a value for --extra_characters results in a crash
> python gen_display_resources.py --font fonts/ter-u12n.bdf --extra_characters ABCDEF --output_c_file ../test-output.c
Traceback (most recent call last):
File "/home/user/prtesting/circuitpython/tools/gen_display_resources.py", line 57, in
all_characters.extend(args.extra_characters)
AttributeError: 'str' object has no attribute 'extend'
This fixes that crash by converting the `all_character...
PRing to the tag doesn't automatically add it to the version. It would involve doing another release, which isn't planned because 7 is so close to stable at this point. As well, 7 includes many bug fixes and important features. We're supporting 6 at this point because it's the last stable release, but we don't have any intention of backporting anything. As Dan mentioned, we haven't even included new Adafruit boards.
my goal is to do a 7.0.0 release candidate this week and if nothing major comes up then we can make it stable next week
I thought as much, but didn't want to speak to that without verification from you.
phew, I got the keypad changes just in time then, I have been putting them off for months
@tannewt , I think we've just about got this bug squashed...I'll double check the CP version of querying my initial state dashboard to see if it goes through after the ublox update.
Great! Will close it now.
If it doesn't, I have not found anywhere in the docs of a way to include a root cert or .pem file into CP code like can be done through arduino. Any way to do that if there still is an issue with some endpoints?
I don't know of one. I suspect we'd need to add the cert loading...
I am hoping to merge #5268 for the next release.
So I'm reviewing a pull request, and because one of the other sensors it uses as an example has changed, the example has become out of date. But it's not because the pull request is wrong. So should I request a change or raise an issue, then fix the sensor in the example with a separate pull request?
@ember iris can you link to pr
Here's the pull request: https://github.com/adafruit/Adafruit_CircuitPython_SGP40/pull/9
and this is the senor that's changed: https://github.com/adafruit/Adafruit_CircuitPython_BME280
The import for the bme280 needs to be changed from:
import adafruit_bme280
to
from adafruit_bme280 import basic as adafruit_bme280
oh. in the readme?
I think it depends on your feelings on the person who filed the PR - which is to say, do you feel they're up for making the changes? Or are they new and struggled with what they submitted in the first place and you don't want to put more on them.
^^ yah. agree.
This looks like a PR in which the original author could make the changes comfortably.
Basically, if a new person contributes, and it's something little that you think should be changed, but what they submitted was already a huge deal to them, you can approve it and make the change afterwards.
Or something big you think should be changed. Either way.
I hadn't thought of that, that's a good point
You can also, always ask!
I've asked folks when I'm unsure in the PR "Do you feel comfortable making this change?" and sometimes they say no. So I'll do it either in that PR or at a later time with a new PR.
Other times, they're new, and they're totally into it, and want to make the change. And they'll stick with you as you ask for all sorts of stuff, or fight with the CI with them, and so on.
But you don't want to frighten off new folks with an onslaught of change requests without feeling it out first.
Sweet! I just completely didn't think of it from that point of view. I was focused on the, "should a PR's scope be small or larger" perspective
That's a valid perspective as well though!
Adding the change you're suggesting doesn't bloat the scope too much. But if it's something unrelated, or much bigger, you could consider a separate PR in that case regardless of how the original author is feeling about it.
Or, again, ask the author if they are willing to submit another PR with the scope-enbiggening change to avoid one PR being too big.
Ok.
In a similar vein, I have one more question regarding the sgp40--it reads a raw value, then you pass that value to the algorithm which spits out a voc index. Storing that raw value adds a small memory footprint (the size of an int plus the class overhead for it). I'm probably like one of 5 people who would be interested in that value. Is it worth adjusting the class to save the raw value, or should I just make my own fork that has that adjustment?
Hmm.
can voc index call raw? why pass it?
How about figuring out the actual memory footprint it creates so we have numbers to work with and then we can decide based on actual data.
Boy we're stretching my knowledge of how these variables and functions work: To the best of my knowledge in this case raw is a property that calls the i2c bus with a stored command_buffer bytes array, and it just returns the value in read_value[0]. Measure_raw adjusts the command buffer for the temp and humidity, and returns the raw property, which is evaluated on the return. measure_index calls measure_raw and stores the returned read_value locally in that function. I'm weak when it comes to understanding name space scopes, but I think that means that I can't access that the raw value from the sensor once that measure_index function returns.
Good idea!
if you want raw, use measure_raw?
are you wanting both voc index and raw to be returned by a single function?
I'm wanting to be able to access both, but voc index should be the only thing that measure_index returns. But I'm looking at the code and realizing I can just write a function to mimic measure index in my own program, so all of the above is moot
namespaces confuse me ๐
it looks like it's basically:
vox_index = some_voc_algorithm(raw)
?
it terms of just what is going on internally
Yeah, assuming some_voc_algorithm is a class attached to the sgp40 class so it's internal states are preserved
totally a different approach, but looks like maybe these could be kept separate? that is, don't try and make it a part of the SGP40 class.
you could import that algorithm class separately in your user code
That would work, but it would change the behavior pretty dramatically from the c implementation, and the sgp40 documentation. Functionally it's identical, but from an api standpoint it would deviate
import board
import adafruit_sgp40
import adafruit_sgp40.voc_algorithm
sgp40 = adafruit_sgp40.SGP40(board.I2C())
voc_algo = adafruit_sgp40.voc_algorithm.VOCAlgorithm()
raw = sgp40.raw
vox_index = voc_algo.vocalgorithm_process(raw)
yah, it'd be different
And now I've hit another issue. Can I ask for a second set of eyes on this?
This is a time based algorithm:
But I don't see where this file can know the time that has elapsed. Am I just missing it?
sry. i'm probably not helping here. i don't really know anything about that algorithm. looks like it's more than just math(raw).
@tannewt happy to leave this closed if it helps organization-wise, but we are still chipping away at it.
In fact, @dxstp just provided some tremendous hardware insight over in the gist . Thank you!
No worries, I was going to redo this algorithm with floating point instead of fixed point math, but the pull request was made with the fixed point implementation solving the open issue.
The only reason I caught the time issue is because I was trying to understand the distributions and estimators and there's a 2 hour switch. I'll dig in more and see if I'm missing something or if this breaks if the sgp40 is sampled at a rate other than 1 once a second
Awesome! I look forward to a new PR from you. Glad this one helped get you started.
Been looking at sleeping on the nrf52 and was wondering why it was decided to use GPIOTE instead of PIN Sense for the wake up mechanism (especially for deep sleep). Considering the limited number of GPIOTE channels and the "unlimited" number of PIN Sense "channels" and the fact that a transition on a PIN when in SYSTEM_OFF mode will wake up the chip (from datasheet: POWER Peripheral uses the DETECT signal to exit from System OFF mode). I understand if I want to wake up on a time basis. Perhaps we need a "hibernate" mode where external input is needed to wake up. (I am deciding if this something worth looking into and contributing. Would it be taken in and where/how?)
@mortal mica it's entirely possible we picked a less than ideal way to implement the sleep mode on that MCU, I don't know enough to say .. if there's a different implementation that can implement the python API but it's better in some way like lower power or additional flexibility I think we'd love to see a pull request
Great. I wonder about additional flexibility. Thinking more like different flexibility... Is the python API what's in the docs? or something else... For example, I don't think there is "Hibernate" anywhere already defined.
As for power, its lower but going from 180uA down to 60uA is something but I am more worried about when it's running (see http://pykey.jpconstantineau.com/docs/testing_hardware/sleep/). However being able to awake from more pins is the thought here. (would link to a keyboard matrix, energize it, set up the sense pins and go hibernate..)
I think I found 1k bytes for samd21 builds at the expense of slower startup
(by computing the qstr attr table on startup)
props to tyomitch for the idea
tests it
So does that shunt the qstr attr table into a different type of memory?
Morning @tulip sleet & @idle owl - Yup, that all makes sense and is totally fine. I just wan't sure if the board would just get picked up by "a build system" or not, hence me asking.
I'm shipping with my own 6.3.0 build as I've been building stock for a little while, and when I started, 7 still had that code.py reload issue on ESP32S2, but folks can upgrade them to 7 if/when they like.
The QSTR pool is a bunch of 32-bit pointers. We could store them as 16 bit offsets from a base pointer for the whole pool instead.
Doing this for the const pool built into the firmware would save ~1300 bytes of flash but require a post-processing step after the link. The linker places all of strings so it can't be done earlier. I tried to subtract the start of rodata in the initializer list but the compiler complained. Post processing it would require placing the pool as the last thing...
Hi, sadly, the board module on this board doesn't know IO9. It's the ADC the battery is connected to for measuring the battery voltage.
Anybody up on I2S audio playback? More specifically, using the UDA1334A (https://www.adafruit.com/product/3678) ? I don't have 3.5mm plug enabled speakers, and I'm trying to figure out if I can wire this https://www.adafruit.com/product/4445 to the breadboard pins on it. Says it's meant to be used with an amp, but can be used without one, so I'm unclear. ๐
The only amp breakout I have is the PAM8302, and I don't think they're meant to be used together.
I believe you can, it's just going to be somewhat quiet (wait until you know it's quiet before leaning your ear close to it though--learned that one the hard way)
Though I've only ever done that with 8 ohm speakers + a 3.5mm plug.. I think it should work none the less
Can hook that speaker up to the breadboard pins?
yeah--give me like five minutes and I'll have a picture too. Speakers ground should go to the 3.5 ground, and speakers positive should go to one of the other 3.5mm pins, it'll play the left or the right side of the audio accordingly
Oh those are the same pins. Obviously. ๐คฆ๐ปโโ๏ธ
I'm thinking, I can't wire it to the 3.5mm, I don't have the hardware.
But you're saying the breakout pins are the same pins.
yeah the rout or lout should work I think--they're the right and left channel respectively, so if you wire the red of the speaker to either one of those it should work with the other wire connected to ground AND if anyone has experience to overwrite this let me know. I'm not an audio person
Now I'm magic blue smoke second guessing it..

