#circuitpython-dev
1 messages · Page 29 of 1
micropython has https://github.com/ARMmbed/mbedtls.git while pico-sdk has git@github.com:Mbed-TLS/mbedtls.git
i thought they would be tracking pico-sdk since they were paid for the impl, but clearly not
these two mbedtls versions diverged in 2019 😕
I have no idea about the politics of any of this, mostly I tried to follow what MP was doing. note that they get their cyw43-driver ALSO not from pico-sdk via nested submodule but put it in <top>/cyw43-driver
and that is still the case? ok, I will not do what I was doing then, and follow their lead instead
i thought we did that only
CMakeLists.txt: set(PICO_CYW43_DRIVER_PATH ${MICROPY_DIR}/lib/cyw43-driver)
```I believe that they are using their own cyw43_driver
they have updated to pico-sdk 1.5.0 already or are about too. I will check out what they did. Sounds like it took a day just to track all this down.
yes a few weeks ago they updated to 1.5.0
thanks for your memory on this
You're welcome, of course.
sdk/src/rp2_common/cyw43_driver/cyw43_bus_pio_spi.pio is now .../pico_cyw43_driver/...
I assume you found https://github.com/micropython/micropython/pull/10764
i was going there, will do what they did for now
they must have had a different & more correct way to find that pio file, I don't see any change related to that relocation
i will check that
and the firmware .h include file
updates to drive repo in the past few days... https://github.com/georgerobotics/cyw43-driver/commits/main
maybe I will wait on driver repo update now until the churn is finished, and just do the minimum to get it to compile with 1.5.0.
and then test
it's in the cmake:
lib/pico-sdk/src/rp2_common/pico_cyw43_driver/CMakeLists.txt
50: pico_generate_pio_header(cyw43_driver_picow ${CMAKE_CURRENT_LIST_DIR}/cyw43_bus_pio_spi.pio)
I think we currently avoid cmake except for the step of building pioasm only; they have used more cmake during their build process
I appreciate you working on this, thank you.
looks like I will need to update the driver at least to the 1.5.0 PR above, because of renamings. I'll investigate what the latest changes are as well.
hum it doesn't seem possible to use any font but terminalio.FONT with a terminalio.Terminal. 😕
(because it must be of type BuiltinFont, but you can't create instances of it)
That's interesting. Because of this line in ko.po, which is not ever going to be shown, the non-ASCII characters are included: "Last-Translator: Michal Čihař <michal@cihar.com>\n"
ha!
i think we are not building ko now anyway?
I noticed that BuiltinFont explicitly lists each Unicode code point it contains; I thought maybe it would be helpful to allow ranges to be expressed directly (by bytes with the high bit off) but no translation actually seems to benefit after adding the required new logic to fontio_builtinfont_get_glyph_index
lines that are po-file comments are used too
as a consequence, the zh_Latn_pinyin translation includes the smart quote characters in its font. this only costs a few bytes though.
@tulip sleet we only disable terminalio for ja/ko/ru on some samd boards, I was looking at rpi builds
Ya, I think it can happen on any port. ESP using FreeRTOS means that something else is checking for stack overflows in addition to CP.
Since the Raspberry Pi Foundation released the Pico SDK 1.5.0 with Bluetooth support, do you plan on releasing Circuitpython with Bluetooth support for the pico?
Hey, is there a way to debug my board using the serial connection (with the vscode addon)?
I currently am doing things that crash the board hard (playing around with FreeRTOS tasks on my unexpectedmaker feathers2) and I'd like to know why it crashes.
I'm not sure about the vscode piece but you can definitely get the ESP_LOG output to a uart with a DEBUG=1 build
debug builds will print backtraces from the panic handler
Not any time soon. I'm sure we'll do it at some point though. Unfortunately it uses BTStack and we haven't used it in CircuitPython before. (Only NimBLE and nordic SD.)
I guess I add DEBUG=1 to the make command with which I am building the firmware?
yup, clean first too
Since there are also debug settings in the sdkconfig
DEBUG=1 will change what sdkconfig is used for the CP build
ohhh nice
Thank you @wtuemura and @bergdahl
Ok, that's what I thought. Please move RUN_BACKGROUND_TASKS; into this loop because it is the one that will take a while.
Looks great! Thank you!
I'm not sure it is necessary. It might be an artifact of using blocking sockets during development. I'd suggest moving it to the bottom of the while loop so it only happens if we go around the loop again.
I would be reluctant to introduce a finalizer since it would add code on all ports.
It's not much. The flag in the GC and a mapping from __del__ to the deinit function. Are you sure other ports handle this correctly now? I don't think we do this well in some places already.
If the code is moved to the nominally CP-independent 'peripherals' then I couldn't put the pointer table in MP_STATE_PORT.
You don't need to gc_collect the pointer table if all of the objects remove themselv...
This issue should be solved by #7684
Thanks!
Issue #7054 was caused by a recursive call to websocket_background(); due to the call to _read_next_payload_byte() in that function. That caused mismatches and overflows in the _incoming_ringbuf ring buffer. This fix will simply return if websocket_background() is already being called.
Is websocket_background a "background callback" created by background_callback_add? This API is intended to provide a guard against recursive calls already. If it is not providing this guard properly, then it would be better to fix that. However, if websocket_background can be called in other contexts than background_callback_run_all, it may be appropriate to add this kind of extra guard.
Yes, websocket_background() gets called directly by websocket_available()
and websocket_read_char().
On Wed, Mar 8, 2023 at 1:26 PM Jeff Epler @.***> wrote:
Is websocket_background a "background callback" created by
background_callback_add? This API is intended to provide a guard against
recursive calls already. If it is not providing this guard properly, then
it would be better to fix that. However, if websocket_background can be
called in other contexts than background_cal...
Thanks! I wasn't able to find that on a quick search in the source code. In that case, I think it's appropriate to add the protection.
how do I put back the original terminal Group in 8? setting the root_group to None isn't doing it, despite the documentation...
show has special handling for this but set_root_group doesn't .. why?
bool common_hal_displayio_display_show(displayio_display_obj_t *self, displayio_group_t *root_group) {
if (root_group == NULL) {
root_group = &circuitpython_splash;
}
return displayio_display_core_set_root_group(&self->core, root_group);
}
is it simply an oversight?
I think this should go in 8.0.x as well. I can backport it, or if you rebase the PR, it will go in and we can pull it forward to main.
display.root_group = displayio.CIRCUITPYTHON_TERMINAL
I overlooked that, thank you!
dunno if it's documented yet ? It should probably be mentioned in the root_group help ?
@dhalbert ; I'm not sure how to go about rebasing thru github. Do I just create a fork on 8.0.x and commit the change to that?
@dhalbert ; I'm not sure how to go about rebasing thru github. Do I just create a fork on 8.0.x and commit the change to that?
Yes, though it can be difficult to get the 8.0.x branch from upstream.
I can do a cherry-pick after it's merged -- no problem.
Can anyone explain me what the idea of the redirects.txt is? Does it influence the build process?
https://github.com/adafruit/circuitpython/blob/main/docs/redirects.txt --> This file i assume it is for generating documentation?
My issue is that I added a simple shared-module / binding, and I see the compiler having the compliation flag set to 1, but in the actual compile the files are not compiled. I followed the makefile changes made on this pull request, but maybe I'm missing something https://github.com/adafruit/circuitpython/pull/6757
Ya, thats for redirecting old urls to a new location
can you push your changes somewhere?
there are .mk files in py/ that usually need the source files added
I will upload it to my github and send you a link in a minute
@slender iron https://github.com/adafruit/circuitpython/compare/main...binloan:circuitpython:build_test_0306
my goal was to get the compiler to compile the module in order to see if my setup is correct, but as mentioned it does not seem to regard the module at all
@timber mango it looks right to me
that's weird - if I run make in verbose I get the -DCIRCUITPY_EGOBUS=1 flag, but in the list of compiled files the init.c is not showing up
did you try cleaning and rebuilding?
I will try
It does fail
mkdir -p build-adafruit_feather_huzzah32/genhdr
GEN build-adafruit_feather_huzzah32/autogen_web_workflow_static.c
make: *** No rule to make target shared-bindings/egobus/__init__.c', needed by build-adafruit_feather_huzzah32/genhdr/qstr.split'. Stop.
so does that mean the file is compiled? if I go in the built firmware REPL trying to import egobus, it does not work tho (gives me an error the module does not exist)
ya, I think it does get compiled
looks at your code again
MP_REGISTER_MODULE should be what you need to be in the module top
build-*/genhdr/moduledefs.h should have it
not sure if I understand, move it at the top of the file?
you know any module that does it that way? the ones I saw always had it at the bottom - i will try anyhow tho
I don't think it matters because there is a python script that looks for it in the whole file
ok - I will try to look inside the moduledefs.h once compilation finished
if its there then I'd expect you to be able to import it
Sorry, totally blanked on which loop would actually be the slow one. Moved the check and tested down to 50Khz and nothing timed out on me.
I don't know what happened, but I get an error in building now inside the module
seems like the make clean did not clean enough for me or some cache was still there
@slender iron thanks for your help!
yeah seems like 😅
Hi, I am looking for the name (or learn guide) of a UF2 for the Pico that turn it into a kind of FT232 or CP210x and can be used as external GPIO for a PC/Mac that would run Blinka.
I am pretty sure it exist (and not a dream) but I fail to put a name on that or to have the right search keyword to find it.
Notice that I might confuse (a bit) with similar concept by Raspberry Foundation that turned a PiZero into external GPIO accessible with GPIOZero library... same concept.
ANSWER: u2if
@slender iron looking at my previous commit I get the following build error:
In file included from ../../shared-bindings/egobus/init.c:34:
../../shared-bindings/egobus/EgoBusNodeIDs.h:7:28: error: 'tNodeId' redeclared as different kind of symbol
extern const mp_obj_type_t tNodeId;
^~~~~~~
In file included from ../../shared-bindings/egobus/EgoBusNodeIDs.h:5,
from ../../shared-bindings/egobus/init.c:34:
../../shared-module/egobus/EgoBusNodeIDs.h:61:2: note: previous declaration of 'tNodeId' was here
}tNodeId;
^~~~~~~
In file included from ../../shared-bindings/egobus/init.c:28:
../../shared-bindings/egobus/init.c:38:54: error: 'egobus_bufferedin_type' undeclared here (not in a function)
{ MP_ROM_QSTR(MP_QSTR_BufferedIn), MP_ROM_PTR(&egobus_bufferedin_type) },
^~~~~~~~~~~~~~~~~~~~~~
../../py/obj.h:312:24: note: in definition of macro 'MP_ROM_PTR'
#define MP_ROM_PTR(p) (p)
^
make: *** [build-adafruit_feather_huzzah32/shared-bindings/egobus/init.o] Error 1
I'm not sure if I can fully follow that error message. I assume based on the files I saw until now that I need to declare the type both in the bindings and modules or did I get that wrong?
@onyx hinge Anne and I are debugging memory issues with OnDiskGif. MP3Decoder has a superficially similar API: you can pass it a filename or an open file. It has a deinit(), and OnDiskGif does not. OnDiskGif probably should. But where do you close an open file in MP3Decoder? I am not seeing that. I guess it's the file destructor/finalizer?
@tulip sleet you're not missing anything. the file never gets closed. On standard computers, where there's a file descriptor / file number abstraction you have to close a file or that resource leaks. but, from what I could understand in CP, the file object can simply be collected by the GC and does not need to be explicitly closed. I felt it was OK inside core code to rely on an implementation detail like that.
sounds ok, thanks, we'll recommend the same for gif
Prob don’t want to merge this as-is, it’s an experiment as I learn the ropes.
There will be a number of incoming boards based on a common RP2040 design…very similar to the SCORPIO design, with an extra eight consecutive GPIO connected to special functions. Most of these should be very simple to add here: copy the adafruit_feather_rp2040_scorpio directory to a new name, then edit the files within to assign this board a unique USB PID and to provide names for the extra GPIOs (e.g. CKN, CKP, ...
so this is all that is done to close the file: self->file = NULL; and when opening a fresh mp3 to the same decoder object, this is all that's done: self->file = file;
@timber mango the type is in bindings and the obj_t goes in shared-modules
the obj_t is the instance
@onyx hinge @tulip sleet Anne was asking me about the GIF memory earlier today so if you spot something I may have time to fix it up tomorrow. Hadn't had a chance to look into it yet though
it looks like you'll need to add a .deinit(). MP3Decorder is superficially similar in a number of ways, and has a deinit() to free up stuff. Just removing all the references to the OnDiskGif object before gc-ing. is not good enough. Sometimes it works and sometimes it doesn't. del() is not a reliable way to remove references, I think.
oh I see, thanks
Should be easy enough to do. I'll look at MP3Decoder for reference.
Only thought is if the bitmap is currently being displayed in a TileGrid, not sure how things will react (badly is my guess)
Test prog:
import gifio
import gc
for i in range(1000):
print(i)
odg = None
gc.collect()
print("before odg =", gc.mem_free())
odg = gifio.OnDiskGif("/some.gif")
print("after odg =", gc.mem_free())
.next_frame() and .bitmap don't seem to cause problems. Or, they are not necessary to have the problem caused 🙂
memory fragmentation will probably prevent allocating the large bitmap that is required
yeah but in the above program after a hard reset the gc.collect() does not free anything. If you start the above program from the REPL (sometimes!) it works, but in other cases it does not
but since the new image could have different resolution, I'm not sure you can add 'open different image' like I was able to add 'open different mp3' to the mp3decoder
yeah, don't reuse
i was also seeing how the file was closed, but discussed above and that does not seem to be the issue
The changing resolution wouldn't allow the bitmap to be reused sadly
(it isn't closed)
n = "x%d" % i
f = vfs.open(n, "w")
f.write(n)
f = None # release f without closing
[0, 1, 2, 3, 4, 5] # use up Python stack so f is really gone
gc.collect() # should finalise all N files by closing them
``` micropython/circuitpython's own test for gc things does odd gyrations to try to ensure that other stack/registers can't continue referring to an object that is intended to be freed. I don't know why a list of 6 ints makes a difference to that test (extmod/vfs_fat_finaliser.py) but it can
I'm not seeing that test program lose memory myself. On a KB2040
i am using a pyportal
sometimes it does and sometimes it doesn't
starting it from a hard reset, it does
I'll try it on my feather M4 later. I have a ESP32-S2 set up as well (but less likely a problem there)
I am using nyan.gif, prety big
we have common_hal_displayio_bitmap_construct_from_buffer -- OnDiskGif could become a more generic multi-gif loader if it took a max_pixels constructor parameter, allocated a buffer that size, then when an image is actually opened it makes it a Bitmap of the appropriate WIDTH×HEIGHT, assuming it fits. The immediate 'leak' aside, my experience with mp3 playback makes me believe something ilke this will be needed to create player that can play multiple GIFs and not run into memory fragmentation.
the old Bitmap object would remain valid to refer to, but its content would reflect the new GIF data of possibly different dimensions
Can someone put the nyan.gif here so I can test with it? Still can't trigger the issue. Though I'll have to resume looking at it later running out of time now
I don't own a PyPortal so can't test on device but the FeatherM4 should be close
I am not an expert... but I believe the solderparty_rp2040_stamp is using a mechanism to have multiple "personalities" depending on the daughter board the stamp reside on.
Basically, there is a little python file you import to have the proper pin mapping, and that file is merged into the firmware.
I found that a "sexy" way to avoid having different firmware for different variation of the same thing (RP2040).
But there are argument like: "GitHub provide the Action for free" and "It is easie...
right, not necessary to display exercise the error. I was seeing very odd things, like adding an import board cuased the problem to go away, and then removing it again, came up. Seems like some field is uninitialized.
Thanks for the gif. I'll look the code over but likely either tomorrow or the weekend. As always feel free to tag me if you do find something.
It’s still up 🤓 https://www.nyan.cat/
There’s a st Pattie’s day nyan cat
and gameboy
One thing just to note the nyan gif is right on the limit of what the library was set for (I think max width is 320). On the base Feather M4 there is not even enough memory to load it. It takes 153K. But this may be tomorrow's problem now.
This can do proper ansi on android
This is the only one that works with ljinux
I found it today on fdroid
I hate the kb tho
@brazen hatch I swear by JuiceSSH on Android - I have you tried that?
Hmm no, never heard of it, but I have now, imma test it in a moment
Thanks for the suggestion
Aurora store says app not purchased even though it seems like a free app and it isn't on fdroid, soo... nope
Is there a way to use esp8266 as wifi for a CP board?
I am looking at ESP32SPI but that isn't for esp8266..
Deprecated library: https://github.com/adafruit/Adafruit_CircuitPython_ESP_ATcontrol esp8266 has problems including outdated certificates, unreliability, etc. Not really worth your time.
Bummer, thanks for the info though!
Perhaps it would be possible to use micropy as a stepping stone
But i'm not gonna bother
I dug up a relic of the past
2019 feels like yesterday, but it really is 4 years..
So much has changed..
I honestly feel like keeping it like this, I have no use for it anyways.
it becomes more historically interesting the older it gets
-
Fixes #7595.
-
Fixes #7596.
-
Update pico-sdk to 1.5.0. There was some renaming of directories in the cyw43 part of the tree.
There is a newpico_randAPI which we might use foros.urandomin the future. The network code is already using it. There is also a new "async contexts" API which could also be helpful. Right now these are compiled in only for CYW43 support. -
Update
cyw43-driverto the latest version, and switching https://github.com/georgerobotics/cyw43-driver instead o...
Looks fine! I added some blank lines for clarity.
Aliased pins have blank lines surrounding, for clarity.
{ MP_ROM_QSTR(MP_QSTR_D0), MP_ROM_PTR(&pin_GPIO1) },
{ MP_ROM_QSTR(MP_QSTR_RX), MP_ROM_PTR(&pin_GPIO1) },
{ MP_ROM_QSTR(MP_QSTR_D1), MP_ROM_PTR(&pin_GPIO0) },
{ MP_ROM_QSTR(MP_QSTR_TX), MP_ROM_PTR(&pin_GPIO0) },
{ MP_ROM_QSTR(MP_QSTR_D13), MP_ROM_PTR(&pin_GPIO13) },
{ MP_ROM_QSTR(MP_QSTR_LED), MP_ROM_PTR(&pin_GPIO13) },
So, just need to know, do the changes here look about right for one of these future Feathers that just need a name and PID and then names assigned to special pins? None of the weird overclock stuff, just special I/O. Thx.
I think so.
- #7694 backport to 8.0.x
@PaintYourDragon Note that it's better to create a branch for your PR rather than edit your main branch. If you do the latter then it can get out of sync with the upstream main branch. See https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github/always-work-on-a-branch#create-your-new-branch-2992239
I think maybe this should have a RUN_BACKGROUND_TASKS in the loop, to not lock background tasks, in case the transfer is large and slow. At most SPI frequencies this might not matter, but it could make a difference.
_Originally posted by @dhalbert in https://github.com/adafruit/circuitpython/pull/7673#discussion_r1126649590_
One minor doc fix, otherwise the API looks good. Thank you!
//| peer: Optional[Peer] = None,
I will just leave this here: https://github.com/lgersman/make-recipes-in-different-scripting-languages-demo/tree/main/python
Update tinyusb to latest master commit. We are almost exactly a year behind.
Initial compilation tests show compile errors in raspberrypi and stm, so this is a draft for now. I will submit TinyUSB issues about these: I think I understand them.
A smoke test on Metro M4 (SAMD51) worked.
Tagging @hathach
Yes. It's already defined up above. Without the undef it errors out.
We try not to test on defined/undefined. We use #if SOME_FLAG to test, and throw warnings if SOME_FLAG is not defined.
Two things to do:
- in
circuitpy_mpconfig.h, do:
#ifndef CIRCUITPY_SETTABLE_PYSTACK
#define CIRCUITPY_SETTABLE_PYSTACK (1)
and move it down into the conditionalized settings in that file, alphabetically.
- Here in
mpconfigport.h, do:
#if defined(CONFIG_IDF_TARGET_ESP32C3) || defined(CONFIG_IDF_TARGET_ESP32S3)
#define CIRCUITPY_SETTABLE...
I've run black on the file but CI keeps saying it's failing black.
does it say which file?
not sure if that's something that can be seen by anyone other than me?
Error: black....................................................................Failed
- hook id: black
- files were modified by this hook
Error: reformatted examples/requests_api_steam.py
i ran black on that file though. and tried to run it again but black is saying it's fine
C:\Users\Devon\Documents\GitHub\Adafruit_CircuitPython_Requests\examples>python -m black requests_api_steam.py
All done! ✨ 🍰 ✨
1 file left unchanged.
did you commit that file? it doesn't seem to be included in the modified files?
yes, submitted the file after the changes.
some other files are modified that shouldn't, though
github desktop automatically recognized file changes and creates a new one, all i have to do is submit it.
i did pip install black --upgrade before i ran it was it a mistake to update black?
hmm not sure how to understand what i'm looking at there. the github token stuff would have been with the github example.
I don't think those are the changes you want to make
yeah those are not my changes...
maybe those are differences from the old versions that didn't fetch correctly into my local repo?
i don't even see the file i actually want to commit in those changes anyway. it's weird.
i fetched origin, pushed a commit, and i don't see the commit.
circuitpy_mpconfig.h is applied before the port's mpconfigport.h, hence this change still results in error.
./mpconfigport.h:58: error: "CIRCUITPY_SETTABLE_PYSTACK" redefined [-Werror]
#define CIRCUITPY_SETTABLE_PYSTACK (0)
In file included from ./mpconfigport.h:38,
from ../../py/mpconfig.h:45,
from ../../py/gc.h:31,
from ../../py/qstr.c:31:
../../py/circuitpy_mpconfig.h:544: note: this is the location of the previous defi...
Figured it out I think. Do I have to close PR's on my side after they're accepted?
Seems like it was trying to push into an old PR somehow. Closed the PR. Opened a new one and everything went through fine.
mpconfigport.h is included before circuitpy_mpconfig.h, so circuitpy_mpconfig.h will pick up the turn-off setting to 0 and not set it to 1.
Sorry, this is wrong. I think it will work if you put this:
#if defined(CONFIG_IDF_TARGET_ESP32C3) || defined(CONFIG_IDF_TARGET_ESP32S3)
#define CIRCUITPY_SETTABLE_PYSTACK (0)
#endif
above the #include "circuitpy_mpconfig.h" in mpconfigport.h. Try it locally first.
@tulip sleet @onyx hinge is there an issue (or maybe should there be?) about the OnDiskGif memory? I've been looking into it and the short summary seems that it only occurs on the M4 and seems to be "something" with the garbage collector vs the other ports. I've never looked at that code before so really outside my expertise.
@blissful pollen I do not see that there's been a PR opened in the core about it yet.
er an issue, sorry
at my old job that I left 4 years ago, in the ticket system that was retired 15 years ago, they were called "problem reports" or PRs, so I sometimes say PR when I mean issue which is REAL CONFUSING
I'll open one up then and can put a longer post with more thoughts there.
Ha oops! Yeah I end up calling them defects because that is what I used to use. But at least that is less confusing then PR
it was just fine until Pull Requests came along
CircuitPython version
Adafruit CircuitPython 8.1.0-alpha.2-24-g26bab620f-dirty on 2023-03-02; Adafruit ItsyBitsy M4 Express with samd51g19
Code/REPL
import gifio
import gc
# Code ran at REPL
gc.collect()
gc.mem_free()
g = gifio.OnDiskGif("party_parrot_13.gif") # seems to need to be a larger size, exact size unknown
g.next_frame()
gc.mem_free()
del(g)
gc.mem_free()
gc.collect()
gc.mem_free()
Behavior
Most times the output works as exp...
In this PR:
- Conditionally run jobs on push if a valid base sha is present. All jobs are run on push of a tag or a new branch.
- The diff is done with
BASE_SHA = ${{ github.event.before }}andHEAD_SHA = ${{ github.event.after }}.
- The diff is done with
- Explicitly check for failure of jobs which have dependent jobs. If these jobs fail, the dependent jobs complete with
skippedstatus and aren't caught inbad_runswhich only consists offailedandincomlpetejobs. Earlier this was checked in `ci_s...
I have added a board_spi declaration in pins.c. I have also corrected erroneous pin definitions for the SCL and SDA pins (these are actually supposed to be GPIO 8 and GPIO 9) in mpconfigboard.h.
I tried to commit this upstream but for some reason that is not working properly.
Note that it's better to create a branch for your PR rather than edit your main branch. If you do the latter then it can get out of sync with the upstream main branch. See https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github/always-work-on-a-branch#create-your-new-branch-2992239. Don't worry about changing this now, but be aware your main branch may diverge.
I tried to commit this upstream but for some reason that is not working properly.
I'm not sure what y...
@analog bridge random q: sometimes people make a PR to circuitpython from their own main branch. Even if they have changed only some board-specific files, it seems to cause a full build. Example: https://github.com/adafruit/circuitpython/pull/7705 (building right now). Do you understand why?
#7695 is another example
or maybe the selective builds are accidentally broken at the moment
Hi Dan:
Thanks for the suggestion on not working off my main branch. I will
implement that.
bye for now,
On Fri, Mar 10, 2023 at 10:06 AM Dan Halbert @.***>
wrote:
Note that it's better to create a branch for your PR rather than edit your
main branch. If you do the latter then it can get out of sync with the
upstream main branch. See
https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github/always-work-on-a-branch#create-your-new-branch-2992239.
Don't wor...
its the merge commit, the diff is between the latest (head) commit in pr and an earlier commit in the pr head branch
if there is a merge commit in between those changes are counted as well
ah, got it, thanks, I will just keep reminding people not to do that
I think GPIO4 is missing here. The inserted line should be
{MP_ROM_QSTR(MP_QSTR_D4), MP_ROM_PTR(&pin_GPIO4)},
Can you make a PR or an issue? Thanks!
@kreier Can you make a PR or an issue? Thanks!
I have thought of compiling conditional jobs based on the merge ref alongside the current workflow and then choosing the lesser of two, just haven't gotten to implementing it.
noticeable amount of work for an edge case. Right now I sometimes just cancel the job to save time.
Awesome! Thanks again Dan.
On Fri, Mar 10, 2023 at 10:25 AM Dan Halbert @.***>
wrote:
Merged #7705 https://github.com/adafruit/circuitpython/pull/7705 into
main.—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython/pull/7705#event-8719311500,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AU2ZOBPK6JMU534ESNXO4MLW3NBVBANCNFSM6AAAAAAVWR7YAI
.
You are receiving this because you authored the thread.Message...
thinking more about it, grabbing the common files looks like a better option
it will filter out changes introduced by the merge commit and will only include commit range specific changes, best of both worlds
I managed to have it happen on S2 too, though it seems less frequent..
Stack size 7k.
So it affects all esp.
Also, the effective maximum on rp2 has changed. rp2 is still 100% stable.
def test(no):
print(no)
try:
test(no+1)
except RuntimeError:
pass
while True:
test(0)
I will look into it more.
CircuitPython version
main
Code/REPL
sm.run(array.array('H', [...]))
Behavior
According to the user report on Discord, use of .run is causing the interpreter to hang.
Description
No response
Additional information
A user on Discord asked about using StateMachine.run, and indicated observing problems when trying to do so.
While reading the source, I noticed that there's an apparent need to (A) check the run buffer for containing an ...
Things like this can happen if the pointer is stored on the stack and not overwritten.
I'll try to track this down this weekend, but basically I'm looking for something that that needs to be set to 0 after the object is deleted? And eventually something overwrites it and then the memory is returned?
This is outside of my area of expertise but something I've wanted to learn more about so I'll keep looking. Thanks.
I tried this:
import adafruit_pioasm
import rp2pio
import time
import array
import board
test = """
.side_set 1 opt
loop:
set y, 30 side 0
jmp loop side 1
in y,32
"""
in_str = """
mov x, y
in x, 32
"""
asm = adafruit_pioasm.assemble(test)
in_asm = adafruit_pioasm.assemble(in_str)
sm = rp2pio.StateMachine(
program=asm,
frequency=2000,
first_sideset_pin=board.LED,
sideset_enable=True,
auto_push=True,
)
t...
Since you are editing the core and on M4 I'd add a global variable to store the pointer that the object to the object you think should be deleted. Once you have that, add an asm('bkpt'); to gc_mark when the pointer passed in matches it. That'll stop gdb whenever the pointer is marked for keeping. The backtrace will show you what code found the pointer and where.
Looks good to me! Thank you!
Thanks, looks good to me too!
@tulip sleet @timid bolt just ran across 'anyio' which abstracts over asyncio or trio, I wonder if anything about it can help inform async work in CP or help us build the new concepts like task groups over an asyncio-ish base instead of a trio-ish base. https://pypi.org/project/anyio/
Asynchronous file I/O (using worker threads)
Well that's not going to work so hot for us
I looked at this at some length, but it was a lot of code. TaskGroup is being implemented in MicroPython and we can take that when it is done, or adapt the CPython one.
I also looked at porting trio, but it was -also- a lot of code, and I was not sure what to trim. But trimmed, it might not be any bigger than @timid bolt's asyncio.
I am not sure about the long-term viability of trio, given that asyncio now has TaskGroup
trio may have served its purpose by pushing asyncio in a particular direction
Makes sense, just wanted to share in case it was new info
i appreciate it -- this has been difficult path-finding. Lots of overgrown trails
This will filter out changes introduced by merge commits (merging pr base branch into head branch) inside the commit range.
Also, resolves #5359 by computing changes inside the script.
Resolved in #7708.
Since S2 is also affected, I suggest it's best to just disable it for all esp for now.
Can we turn off espcamera on adafruit_feather_esp32s3_reverse_tft? It is failing in main.
C3 IS CURSED C3 IS CURSED C3 IS CURSED C3 IS CURSED C3 IS CURSED
nuked it with idf, now it doesn't boot
amazing
Now it boots on it's own, but when I try to debug it, it immediately goes:
Info : [esp32c3] Halt cause (7) - (PMP Store access fault)
I'm out.
you could make it the same as the regular TFT
@tulip sleet have time to chat performance on imx?
sure
Can someone other than me try to debug esp for pystack?
I seriously am going to lose my sanity over this.
C3 is going to break me.
I have no idea how to debug S2 and rp2 is not crashing.
I felt that in my soul. Can relate.
If memory is allocated via m_malloc I know it can be cleared by the GC but is there another proper way to free it if you know it will be unused?
This is a do-over of #7695, which I’ll now close.
This is now working from a branch as requested, and incorporate’s Dan’s additions for blank lines between pin groups.
Limor clarified that this does not actually need to provide DVI out in CircuitPython, at least not initially. Mostly it’s about having a distinct CP build for this board, with its particular USB PID and pin names, and we can evaluate DVI as something later. So, if this all looks correct, merging is an option.
I could look, but (1) I only have this board https://www.adafruit.com/product/3405, will it repro on that? and (2) won't have time until mid next week.
m_free
@tulip sleet pico results look much more similar
(cp actually looks a bit faster in some cases)
Well idk if the bug is present on it, but I suppose it will, all other esp's are affected..
I cannot get it debugged anyways so yea.
That is a relief!
That will be interesting. I find its architecture so complicated.
maybe use svd to dump out the memory controller settings (and other relevant "peripherals") on both mpy and cpy
totally
running mp on the 1010evk right now
I did realize I turned off caching the regular ram
I think I needed that for usb to work though
@brazen hatch @timid bolt I'm not seeing a crash on the Huzzah32 with a value up to 15000. setting it to 20000 resulted in a memory allocation error but no crash.
def test(no):
print(no)
try:
test(no)
except RuntimeError:
print("Done.")
while True:
test(0)
let it rip for a minute
if this passes with a large pystack the board is good
this is what it takes for S2 to crash
one or two runs won't crash it
no matter how big the stack
did you mean test(no+1)?
Okay, crash reproduced
It doesn't look like you even need to loop the test(0) call to cause the hang, it seems to be hanging pretty reliably on the Huzzah32.
Interestingly, it hangs after printing "Done" and presenting the REPL prompt
then it's the same as C3
The breakpoint is somewhere between 3500 and 4000
lol
😆
Honestly, yea. If a pc can't even do .5A it's ewaste
yep, wouldn't want to trade out my $25 microcontroller, need a new computer....
Just wait till I do vga on ljinux
Make the microcontroller your pc
livin the 144p life
Have you tested on the MIMXRT boards yet?
Nope, aren't those the teensy's?
Expensive + microusb doesn't sit right with me.
My teacher also suggested me to get one. But I am still hesitant..
re the pystack issue: does the crash only happen when the stack overflows, or does it also crash at other times? Because crashing on stack overflow is not a serious bug.
I'll try a debug build and see if I the Huzzah indicates a stack overflow
it's 1:20am so idk how much more I will sit testing
I'm just guestimating at this point
without debugging i'm absolutely incapable of actually pinpointing the fault
These are various changes needed in the CircuitPython core in order to support the CPython import of the asyncio module (see PR). See inline for my comments on the individual changes.
Some random guesses for me were to try different values and multiples.
Multiples of 12 is a big nope.
I have no clue how big is a stack frame.
1536 is the stock value which works
multiples of it don't work either
so it's not that
Well I quit for today.
Goodnight.
I don't know why this was disabled, but this method is needed by the asyncio implementation.
Remove the MicroPython C implementation of asyncio. I also recommend removing moduselect.
If we didn't read any bytes, we still need to return the non-blocking error.
I move this struct to the header file so that it can be used in other modules, namely for the implementation of iscoroutine.
If no bytes were read, return a non-blocking error.
The Debug build didn't output the error message over the micro usb connection. I'll take a look later tonight and see if I'm getting anything over the rx/tx pins. I did grab the latest bits for the debug build and this build no longer crashes on every run of the test script. Looping the test call does cause the crash but it now hangs in the midst of the test routine rather than after it completes.
Well maybe not in the midst, it hangs just prior to printing Done
I still do not know how to have it print over uart, I will try that tomorrow since I can just read it from my pi400
Fix for #7703
The bitmap object created when OnDiskGif is constructed was sitting referenced in memory even after the GIF object was deleted (seemed to be if you left a while or for loop it was freed).
The new deinit() function can be called to ensure the bitmap is explicitly freed from memory when someone is done with the GIF.
@dhalbert you may also want to bump it up to https://github.com/hathach/tinyusb/pull/1947 , which just merged and removed all low-level mcu submodules. repo dependencies in tinyusb now is managed by an python script. circuitpython does not clone with recursive, though I guess there is still users to do that out of habit.
Explicitly freeing objects is generally not a good idea because (1) it's the garbage collector's job to do this so it should be unnecessary, and (2) if the object is aliased then explicitly freeing it will corrupt the heap.
In this case, the bitmap object can be returned to user code through the get_bitmap method, so it definitely can be aliased, and explicitly freeing it is not safe.
hey hey!
I've been wondering how feasible it is to write circuitpython modules in Rust… Any pre-existing projects/ideas there? I know my way around bindgen and embedded Rust, have recently picked up circuitpython again because it's just so ridiculously convenient for initial R&D, but some stuff just needs that native code speed
Should I be able to find this on the downloads page here https://circuitpython.org/downloads ?
Can someone tell me where I can download the Firmware?
Should I be able to find this on the downloads page here https://circuitpython.org/downloads ?
Can someone tell me where I can download the Firmware?
Yes, you can search for it in the downloads page. A direct link: https://circuitpython.org/board/doit_esp32_devkit_v1/
Thanks, I will, and will also pick up https://github.com/hathach/tinyusb/pull/1948.
Really excited about this functionality--- I am working my way through https://learn.adafruit.com/cooperative-multitasking-in-circuitpython-with-asyncio/handling-interrupts right now.
Is it possible to extend the functionality to read from the pin within the Counter context? I have a https://www.adafruit.com/product/3218 toggle switch connected to an M4, with the switch pins connecting a 3.3V and the input pin on the board. I want an interrupt to behave differently based on whether the sw...
I think it has been looked at but no one has done it yet. Adding a loadable module (vs compile time) is trickier as well. I experimented with that in C and if you look up the native module support you can see how it is done.
- remove unnecessary optimization flags
- shrink adafruit_feather_esp32s3_reverse_tft
Instead of freeing it, you can null out the pointer in OnDiskGif. Also make it not possible to use a deinited OnDiskGif. I think MP3Decoder might serve as a model? Various busio objects can also be deinited and check for that.
mhm. I think I'd be fine with compile time as a first POC. didn't even know you could dynamic load native code! thought that was (m)py only. Sweet!
Instead of freeing it, you can null out the pointer in
OnDiskGif. Also make it not possible to use a deinitedOnDiskGif. I thinkMP3Decodermight serve as a model? Variousbusioobjects can also be deinited and check for that.
I had tried setting it to null but that didn't seem to be freeing the bitmap. Something else must be holding the bitmap for a bit longer as it isn't consistent.
I know what you mean with the check for deinited so I will add that in too. I did look at `MP...
Yeah the native code does work though it is a limited subset (just like in micropython). From what I recall others saying Rust support for compile time is theoretically possible but just not done.
Well I will buy a knock-off esp32s3 off of ebay.
It's not a clone of another board, but a different thing entirely.
So perhaps it could receive mainline cp support.
The thing is that all sold locally are ewaste (no psram), buying from ada directly is a unimaginably more expensive due to shipping costs, and ebay is only one left.
I'm going for N16R8. It only costs a few bucks more than N8R8
Let's just hope it's not a 20€ brique.
Docs specify no uncrustify version.
Arch:latest provides version Uncrustify_d-0.75.1_f which produces the following during pre-commit run --all
Hooked up debug uart of S2 to my pi400, produced a debug build, and nothing. It doesn't crash now, even with a 12k stack.
My best guess for right now is that it's an optimisation error.

In the case it is actually an optimisation error what do I do?
- Debug uart
- Default spi/i2c
- Invert led
This has been a long standing issue that just nobody has bothered with.
It applies to all CP versions.
Under several circuimstances, CircuitPython on ESP32-C3 decides to lock up stdin or go out of sync.
Some ways to reproduce it:
- Press any key before before circuitpython has finished init.
- Press too many keys at once.
- Work with serial for more than 3 minutes.
- Use ljinux. It very heavily relies on ANSI escapes for graphics.
Ctrl+C usually makes it through regardless, but ...
@felker
I agree that there are use caes for reading the current state of the countio.Counter() pin, and that could be added to this API.
However, toggle switch (or any mechanical switch) is going to bounce. Instead of using countio for this, I suggest you use keypad to register switch transitions, as in https://learn.adafruit.com/cooperative-multitasking-in-circuitpython-with-asyncio/handling-interrupts#handling-interrupts-with-keypad-3106485. keypad has debouncing built in, and d...
Can I make CP expose the JTAG pins the same way UART is exposed?
I mean
MTDO / GPIO40 -> TDO
MTDI / GPIO41 -> TDI
MTCK / GPIO39 -> TCK
MTMS / GPIO42 -> TMS
esp32s2
We are limited by the uncrustify version in MicroPython. Changing ours will complicate a merge from upstream.
The docs mention this version limitation.
These are available as microcontroller.pin.GPIO40, etc. They are Pin objects just like board.<some-pin>
I know, but how do we expose them as jtag instead?
I can't seem to find it in any board definition
jtag pins are attached to things inside the chip. I'm not sure I understand -- do you want to emulate jtag? This is jtag in, not jtag out
do you want to attach these pins to the jtag pins on some other board, to use the ESP32S2 as a debugging probe?
Oh no, I was just hoping to debug S2..
on a Metro S2, there is an SWD connector you can hook up a debugging probe to. This works regardless of what is running on the board
Well I have ordered the S3 knockoff now anyways, so in about 2 weeks I will be able to debug that.
I have not successfully used openocd or J-Link to do ESP32-S2 debugging. It is flaky.
Why don't more boards just do swd.. it's so much simplier than jtag..
it has to be built into the chip
i don't know why espressif chose jtag over swd
jtag has a bunch of other uses as well, like debugging the hardware design
@brazen hatch might be helpful https://blog.wokwi.com/gdb-debugging-esp32-using-raspberry-pi/
Wait
@analog bridge I tried that, but not very successfully. Did it work for you?
very limited breakpoints, etc.
@tulip sleet same experience, it was flaky and limited in functionality
they are for debugging the ESP32S2
Well, I have openocd ready on my pi400 already, so I may as well test it.
rp2 is also very limited, but that didn't stop me from debugging picow-ap
I take anything over C3
Thanks and sorry for missing that.
@bill88t noticed that uncrustify 0.75 formats code differently than 0.71/0.72. Note it in the docs.
Yea the circuitpython takes the pins, so jtag doesn't work
I set the whole thing up
I needed a different openocd
compiled it
fixed bugs
made a pr
jtag is not working with it though
[bill88t@Pi400 | ~]> sudo openocd -f interface/raspberrypi-native.cfg -f target/esp32s2.cfg -c "adapter speed 1000"
Open On-Chip Debugger v0.12.0-esp32-20230221 (2023-03-11-16:50)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Warn : TMS/SWDIO moved to GPIO 8 (pin 24). Check the wiring please!
adapter speed: 1000 kHz
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 1000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: esp32s2.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : [esp32s2] Unexpected OCD_ID = 00000000
Warn : target esp32s2 examination failed
Info : starting gdb server for esp32s2 on 3333
Info : Listening on port 3333 for gdb connections
Tried flipping DI DO pins, nada
Imma just wait for my S3 board.
The last commit still does not fix the issue fully on the M4 chips but I wanted to remove the dangerous del_obj and properly add deinit checks.
I am still looking but the line that seems to be at fault in the example is: display_bus.send(44, odg.bitmap)
On the M4 the bitmap object is held until anything else is written to the display_bus (FourWire in my case). My theory at this point is something in the SPI code on ATMEL chips is holding the data part longer vs the other ports, hence ...
Anyone know anything about this? Is it hapenning? https://blog.adafruit.com/2023/03/09/free-circuitpython-workshop-saturday-march-11th-circuitpython/?
guess not ...
limited in what way exactly? (I'd have assumed whatever gets baked in at compile time still looks like a normal python module)
Oh sorry I meant the native submodules you load at run time are limited. If it is at compile time I don't see what limits there would be
I meant >>> import baked_in_mod - does this have limits?
I suppose you can't e.g. do >>> baked.some_nonexisting_attr = foo ?
@dhalbert that is actually great to hear, since I switched to keypad after getting stuck with countio and it seems to be working quite well!
I observed debounce with countio and tried to fix it by changing await asyncio.sleep(0) to await asyncio.sleep(0.01), but clearly that did not help.
Is that how I would lengthen the polling interval in the keypad approach?
It would be great to add a paragraph or example to that interrupt guide encapsulating the info in your comment.
so I am working on adding a board with a builtin OLED display that shares the same pins as board.STEMMA_I2C, and I can't instantiate the bus since it is in use. The TFT feather, which uses board.SPI, does not have that problem, do I need to do something special to enable that with the I2C bus ?
ah nevermind I got it
Is that how I would lengthen the polling interval in the
keypadapproach?
The interval argument in the keypad.Keys() constructor specifies the polling interval. A switch that bounces for longer might need a longer interval. If you see multiple events on a single switch throw, lengthen interval.
It would be great to add a paragraph or example to that interrupt guide encapsulating the info in your comment.
Will do -- thanks for the suggestion!
Free space (and total space) would be useful to show in the file list page too (or at least on cp.org via /code ?)
I don't know if we want the info to be in /cp/version.json or a separate url.
This still has an edge case:
- If a file has changed in the PR's base branch
- and also in the commit range
MB...B(whereMBis the merge base andBis the last commit with checks) - but not in
B...H(whereHis the PR head ref andBis the same)
- and also in the commit range
- It will be included in the changed files list.
I am still trying to figure out the why but sending the bitmap via the display bus seems to cause the issue. But if you assign the OnDiskGif.bitmap to a variable and pass that variable to the display_bus and then set that variable to None at the end the memory gets collected during the next run. Example below.
I am still going to try to look into why this happens (already learned a lot about garbage collection this weekend) but this is a pretty easy work around in the meantime. The exa...
Maybe I am telling you something you know already: the garbage collector looks in several places, transitively, for references to storage not to reclaim:
- "root pointers" (
MICROPY_PORT_ROOT_POINTERS), which include the the globals dictionary, and many other things. - C variables handled by the various
gc_collect_*routines. This is an alternative to making things root pointers. - The stack.
So perhaps the bitmap address is on the stack, or is left behind in something, like the...
Is it LOLIN S2 Pico by LOLIN?
I'm adding the three 01Space QT PY sized ones with oled displays (that they call LCD but...)
https://fr.aliexpress.com/store/912632218
the 0.42
Anyone ever have success debugging an ItsyBitsy M4 via SWD? Using device ATSAMD51G19A.
I cannot get it to connect no matter what I try. I did hook the JTag to a Feather NRF52840 so I know the debugger works.
I debug a Metro M4 via SWD often. That's an ATSAMD51J, but I'd expect it to work on ATSAMD151G as well. DO you ahve the reset line connected?
I do not have the reset line connected. That goes to the enable pin?
Thanks, that fixed it. Next step get this all working from my WSL environment (but at least I know the issue there)
it goes to RST
I love those tiny OLED: SSD1306,
enable might work too if there is no-broken out RST, but I thought there was a pad or pin
have to be afk now
oled + tiny + i2c + cheap
These things are awesome.
Thanks Dan. That all worked. I documented all I did to get it running in WSL too so I don't forget next. Now to remember how GDB works ha Been a while
rp2040 PIO rp2pio.StateMachine question: is there a reason why some of the state machine config settings like sm_config_set_jmp_pin() could not be made adjustable after a StateMachine is created? It's unclear to me reading the pico-sdk, rp2 micropython sdk, or the rp2040 datasheet if a state machine can be reconfigured after it's running. But it would really be handy! (I'm trying to make a multi-pin version of touchio, I have a single-pin version I call touchpio that works great but requires "jump pin")
Is there still no way to deinit the watchdog? I ended up resorting to using this kludge when temporarily disabling the watchdog in my code
# from microcontroller import watchdog as w
# from watchdog import WatchDogMode
class Nop(object):
def nop(*args, **kw): pass
def __getattr__(self, _): return self.nop
w = Nop()
A few things:
- Add
deinitfunction. - Change range validation.
- Fix watchdog
initsequence.
Hi, the following PR adds the functionality to deinit the watchdog and also reset it on VM exit. I am not sure if RAISE mode can be implemented as I don't think there is a way to subscribe a callback to the watchdog trigger event.
- #7718
The original list left D4 (GPIO4), VN (GPIO39) and VP (GPIO36) out.
Added aliases for 1, 3, 16 and 17 with their GPIO names, even though they won't be used as such since they are UART0 and UART2
@dhalbert created a PR https://github.com/adafruit/circuitpython/pull/7719 and included 2 more missing pins :)
I'm not sure this is really an "issue" since it appears to have been resolved in 8.1.0-beta.0 but I wanted to bring it to your attention.
A forum post reported an issue using rshell with 8.0.3. on a feather esp32 v2 In general, you do have to download and install shell from GitHub to get a necessary fix that has been merged but not released. I shoed the poster that shell did work OK with 8.1.0-beta.0 however they still reported an error with 8.0.3. I then reverted to 8.03 and was able to re...
@gilded cradle I used the "installer" on circuitpython.org to load CP onto a feather esp32-v2. It worked great!! That is a very nice addition.
Hi
In the tutorial post, there is a suggestion to lower the adapter clock. You could try with 500, 200 or 100 kHz...or maybe more like 2000 Khz as I see with some esp32 boards . see the example in the link: https://learn.adafruit.com/adafruit-metro-esp32-s2/debugging-with-openocd
If you see an error, check your connections. You can also try setting a lower adapter_khz value in the openocd command. 1000 works well for me, but your mileage may vary.
According to https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/jtag-debugging/index.html and based on your logs
If you see JTAG errors (e.g., ...all ones or ...all zeroes), please check your JTAG connections, whether other signals are connected to JTAG besides ESP32-S2’s pins, and see if everything is powered on correctly.
CircuitPython version
Adafruit CircuitPython 8.1.0-beta.0-4-g8a1006999 on 2023-03-13; LilyGO T-Display with rp2040
Code/REPL
# Don't get that far - compiling for rp2040 works but not if the web workflow is involved
# see below
Behavior
mk@zbook:~/circuitpython_esp32/ports/raspberrypi$ make BOARD=raspberry_pi_pico_w
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
mkdir -p build-raspberry_pi...
The import is in line 7 of https://github.com/adafruit/circuitpython/blob/main/tools/gen_web_workflow_static.py
pip install minify_html and pip install jsmin solved the problem for the Raspberry Pico W.
esp32 still fails with CMake Error: CMake was unable to find a build program corresponding to "Ninja". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
Same error for mk@zbook:~/circuitpython_rp2040/ports/espressif$ make BOARD=adafruit_metro_esp32s2
"Ninja" can't be found.
CMake was unable to find a build program corresponding to "Ninja".
sudo apt install ninja-build
New error:
COMPONENTS = esptool_py;soc;driver;log;main;esp-tls;mbedtls;mdns;esp_event;esp_adc_cal;esp_netif;esp_wifi;lwip;ulp;wpa_supplicant;freertos;bt;usb;esp32-camera
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- The ASM compiler identification is unknown
-- Found assembler: xtensa-esp32s2-elf-gcc
CMake Error at esp-idf/tools/cmake/pr...
Yea I will just wait for my S3 board. It ain't worth the trouble. Thanks though.
Hi, @kreier replying to the error in your last comment, it looks like you didn't run source esp-idf/export.sh in the ports/espressif directory. Please check the esp-idf getting started guide for more details.
To my surprise this actually works. I know that some watchdog HW blocks don't support being disabled after being initially armed, and I was confident rp2040 was one of them. Happy to be wrong.
This does not have a bearing on whether to accept this PR, but it's weird that the microcontroller.watchdog object can be used after its deinit is called; this is contrary to how almost any other CP object works. we should consider changing it for 9.
I am uneasy about changing the behavor when the program
- sets the watchdog
- subsequently exits, whether by execption or normally
If we are going to permit the deactivation of the watchdog once placed in "reset" mode via deinit then we should change it (in shared bindings) so that assigning microcontroller.watchdog.mode = None is permitted in this case, so that the nonsensical deinit call (which normally puts an object into a state where it may no longer be used) is not required.
this is a behavioral change. before, setting a watchdog and then having your program exit (whether normally or by exception) would cause the microcontroller to reset. I believe I have written code that relies on this.
this test is unneeded, unless it's not safe to clear the watchdog flag when it's already cleared.
(also it's weird that uncrustify hadn't previously normalized the indentation here, I wouldn't have noticed this otherwise)
this is a behavioral change.
I am not suggesting this change in behavour. From my point of view (coming from espressif port) this is not a behavioral change as on espressif the reset routine calls the watchdog deinit. This is different from how it is implemented on atmel-samd and nRF where the deinit of RESET mode isn't allowed.
uncrustify hadn't previously normalized the indentation here
Might be because the lines were commented out? But more likely pre-commit or...
just don't want to change it if we didn't modify it in the first place
OK, we need to harmonize the behavior across ports, I can agree with that much. The program I'm thinking of is running on a samd51 (itsy bitsy m4) fwiw.
I believe the preferable behavior is that when the watchdog is not explicitly deinitialized by user code, it remains active.
This means the watchdog will be effective when the running program terminates unexpectedly, whether by an exception or not. In the case of a reload exception, and maybe a keyboard interrupt, I could be persuad...
Why the hell is it working now?
...keep trying
What I think might happen if the instruction count is calculated incorrectly is this:
You have a buffer containing one instruction, but its byte length is 2:
>>> in_asm = adafruit_pioasm.assemble(in_str)
>>> in_asm
array('H', [16448])
>>> len(bytes(in_asm))
2
This means that 2 instructions will be executed; the first is the expected one, and the second is uninitialized memory.
The results could be different and unpredictable depending what the uninitialized value actua...
From the code editor standpoint, I would think another (similar) URL would be better because the version stuff usually doesn't change much once the board is booted and it can be a bunch to parse through. Maybe something like /cp/diskinfo.json and then other filesystem stuff could go there unless it adds a lot of overhead and makes the CP too big.
That would be from #7652 (which is in the 8.0.x branch but happened after 8.0.3)
It's not a perfect fix, since the message that rshell and ampy expect are localized in Circuitpython.
But using human readable text for a machine interface will do that.
I'm not really sure how to move this forward. I'm guessing it comes down to two high level options:
- Make the Unix port have access to
RUN_BACKGROUND_TASKSas the other builds do. That should allow it to successfully complete the build - Make the Unix port not compile bitmaptools so that it won't have a problem with the fact that it doesn't have access to
RUN_BACKGROUND_TASKS
I don't really know how to do either of those, or which would be preferred.
I guessed that the latter wou...
@bill88t I have a version of uncrustify 0.72 if you need it. I think we're also limited by what Ubuntu packages because that's what the CI uses.
Thanks Dan, I had a vague idea of some of those points but not all together. Been trying to watch some of the past videos on memory management and looking into the code.
This is very new territory for me so I'm not 100% sure what I'm looking for besides the address of the bitmap somewhere on the stack or referenced by a root pointer. The breakpoint tip Scott gave me did get me to a breakpoint but it has been a lot of years since I did much with GDB.
Quick (hopefully) question. I have GDB debugging set up and going now but I am seeing <optimized out> in a lot of places. Not sure if there is a flag I can pass to a build to remove some of these. What is confusing to me I may see a value in my current frame but the one up has 90% of the locals that seemed to generate the value optimized out so not sure where the value came from.
you can compile -Og or -O1 or -O0 and see less of that. You will probably need to do CIRCUITPY_ULAB = 0 to make room for the larger code. You can also make local variables volatile, which will prevent them from being optimized out.
Thanks. Where do I add the compiler flags? Is there someplace in the makefile for it? (I do see the if DEBUG=1). I thought I had -O0 set but then I was 189Kb oversize
optimized out can happen if you are before or after a variable is used too
<@&356864093652516868> Meeting today at 2pm US Eastern time. Note that US Daylight Savings Tme started yesterday, so if you are not in the US and have not started DST yet, you may find the meeting to be one hour earlier right now in your local time zone. Add your hug reports and status reports to the notes document
https://docs.google.com/document/d/1NZeAkPhnhUytsVP1rKAScEsxPWYmZC2s7yNt4Eqj_cU/edit?usp=sharing
1PM ?
you can edit the Makefile. For CIRCUITPY_ULAB you can temporarily change mpconfigboard.mk, or you can add it to the command line: make BOARD=foo CIRCUITPY_ULAB=0
Question: CP Library Bundle has not been release in a while, is this release weekly thing or when a library is updated thing..?
mmm
you could check the actions in the bundle repo to see if they are failing
will do thanks 🙂
Seems you don't know that Discord can display events in the user's local time zone?
https://ryps.co/discord/
Next to Twitter, Discord is the place for our NFT communities. But, while we’re all running awesome events and creating unmatched experiences for our communities, it’s difficult for people in our communities to know exactly when something is happening. NFTs are global, so we’re constantly converting time into our local time zones. Well this litt...
thanks! will take a look!!
Neat!
Last Bundle update was march 7th, two PR merged after that, #422 Adding GFX library and #421 Updating- CI, then no more auto-updates..
there has to be a release, not just a merged PR of an updated library
adabot fails
remote: error: GH006: Protected branch update failed for refs/heads/main.
looks like adabot couldn't create the bundle release for the last 5 days
Community bundle must be affected too then
dunno, looks like a permission issue on the bundle repo ?
I might have set up a branch protection rule thoughtlessly. I deleted the branch protection rule. Let me re-run the latest failed run
Thanks Danh I see the release now
great, and sorry, sorry - github keeps bugging us about unprotected branches
Attempted to ask this in the MP Discord, but seems the brain trust there are stumped as well.
I can have multiple files running while sharing the same state in the long run, and this isn't something that CP supports.
What do you mean by this? Threads?
This is the best place for MPy discussions: https://github.com/micropython/micropython/discussions
@vapid storm ^^
Aur has a nice package named downgrade, it got me to 0.71 in the blink of an eye. Thanks for the offer though.
I'll start the meeting in 4 minutes or so
Skipping the meeting without notes. Group Hug.
Also, why did I not being a barometric sensor or something that can act as an altimeter with me in vacation???
I just got back from vacation in the mountains, and hadn't even considered that, but am now asking myself the same question 😅
@tulip sleet I could take the 'libraries' section if you like
I put in the state section stats.
<@&356864093652516868> Weekly meeting is starting now (Daylight Savings Time in USA)
congrats GeekMomProjects, nice!
On March 13, we will officially begin rolling out our initiative to require all developers who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023. Read on to learn about what the process entails and how you can help secure the software supply chain with 2FA.
Not so great
@turbid radish awwww it's OK if you accept the complement 🙂
@tame grove I'd love to be able to use rust for native internal modules but I've never actually used Rust. I'm happy to help you on the C-side of CP.
Nice! I will have to try some fractal images
nRF is unaffected. So it's probably an esp-only thing. It's gonna be some optimisation thing and I will cry.
@lone axle https://www.youtube.com/watch?v=T6uR5OZ0Xtk
MIDI: https://mega.nz/file/7JZT3TQb#IT5U1_j6ugmWTtxQFG2xVEbMs_6ccWo4G31P5SAdtm4
I've interpreted the Sierpinski triangle as audio data before, but not as musical notes. This was cool. It's not a 1:1 chromatic scale; when I did that sounded bad, so I shifted the notes' pitch minimally until the scale sounded good.
if you websearch the topic, you will find more
Thank you!
thanks for hosting dan!
Thank you
Thanks for hosting Dan, have a nice day everyone!
Thank you all! Have a great week!
[based in part on discussion In The Weeds on the weekly meeting March 13, 2023]
- In shared-bindings permit assigning
watchdog.mode = Noneif the underlying hardware supports it - In a later version, remove the
Watchdog.deinit()method. (today, calling this is the workaround for setting watchdog.mode to None) - do something to make the behavior of watchdog at the end of code.py consistent; probably, only inactivate the watchdog in the case of KeyboardInterrupt or ReloadException r...
@microdev1 moving the discussion of how to make the watchdog consistent & how to handle resetting at interpreter exit here so that it does not block #7718 from being merged.
@slender iron terrible idea: At the end of shared-bindings/foo.c, #include "common-hal/foo.c" -- voila, calls from shared-bindings to common-hal can potentially be optimized better, even if no lto
ya, that crossed my mind 🙂
how many people have to have the same bad idea for it to actually be a good idea?
if it works, it works 🙂
my mind has gone to doing performance guided memory placement
ti clang doesn't support m7
😦
we can hope they PR it to upstream
Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1y7kZuukcZXC1eiStMaMsI_YlglAAoW_fMbaQysK_CAY/edit?usp=sharing
@tulip sleet looks like dtcm on ocram double the perf bench scores
🎉 is that instead of TCM or in addition?
I was wondering if you just enable write-through that it there will not be a caching problem. Maybe that is the default
I had to run the test over uart
last I tried over usb, tinyusb crashed
repr A had issues running out of memory 🙂
nqueens is 17.6k
up from 13.7k
chaos went from 1747 to 2735
yeah, I think repr A doesn't really help, because more things are boxed, and I don't there are many savings from the slightly simpler object type checking
As part of getting the CircuitPython Installer ready for learn, it's useful to have the necessary board info in a JSON file so that just the board id (or IDs) is all that will need to be provided. This PR adds a script to generate and upload the file to Amazon S3.
I plan on having these values overridable with the button parameters so that multiple languages can still be installed. After this is merged, changes to the installer to grab the info from this file will be required, which will b...
For some reason, the file is not actually uploading, so this is still being worked on.
Oh this is fun. Apparently if I change optimization level on my build the garbage collection issue goes away (not sure if I laugh or cry yet)
definitely sounds like a rogue address that is keeping it alive
could there by a long-lived not-long-lived issue here? When might a short-lived allocation be moved?
but we have had to make things like UART buffers be long-lived because their addresses are stored in non-CircuitPython places, and we don't want them to move out from under the non-CPy place
right
I'm seeing it on the stack just trying to figure out in which frame
is there some storage that you allocate for the GIF library that is passed a pointer to the large thing?
Hmm the drawing routine is passed the bitmap object to draw into
if that pointer is copied into some object that might be on the stack, then it will stick around
Rough order: next_frame -> GIF_playFrame(bitmap) -> GIFDraw(GIFImage struct that holds pointer)
this is the SPI non-displayio version, right? Does the SPI object do antying with the buffer pointer?
I don't think so, but I don't remember
GIFImage struct, who holds that?
GIFImage struct is held by OnDiskGif. This is FourWire only direct. And it does not seem to trigger if I comment out the send(odg.bitmap) line
Just my ignorance here - but does the stack not clear itself when it is being reused? So therefore if something isn't used the variable is about
I'll have to look again at FourWire. It seems to always put the bitmap in the same memory address so I can watch that manually I think
it doesn't clear itself, but it knows where the limits are so it won't look at leftover junk (or it should)
I was getting a bit perplexed by this and then I realized it probably won't actually upload a file to Amazon S3 until after this has been merged for security reasons. So this should be good to go.
Has anyone else experienced computer freezing during builds on Ubuntu 22.04.2 LTS? This is a problem that has started cropping up for me lately. I'm not exactly sure how to troubleshoot it though. It's not consistent, some builds succeeds, but other time the whole computer just locks up at some point during the build.
secondarily, where can I look to figure out specifically what happens when I run something like:
make BOARD=adafruit_feather_esp32s2_tft
I'm guessing that it's not make directly that is causing my problem but rather something that make calls to do the build process.
If I can find out specifically what software is doing work when the freezing is occuring I'm hoping to get lucky trying to search around online about the OS version and freezing with that softwares name.
Anyone know offhand where to look up all the QSTR including non-compiled ones?
is there a specific one you are looking for?
I saw 612 (decimal) and think it is a reference to a method being loaded
ah, do you have a debugger attached
Yup using GDB
I think you can do p qstr_str(612) and it'll run the code for you
Thank you! It's not a qstr because "backlight_pin" is likely not the culprit but good to know.
building ESP does bring my computer to lag at some points, it gets pretty intense
(oops it was 621 not 612... 621 is bitmap which sounds more likely to be involved!)
do you know if building esspressif port use a different compiler than building something else i.e. atmel or raspberry pi pico?
ya, espressif has their own compiler to use
its older gcc
atmel and rp2040 use arm gcc
okay, I will try a bunch of non espressif builds. The last few times that the freeze has occured was on espressif build. If I can narrow it to that port specifically I can hopefully get closer to a solution, and atleast have a potential work around to be able to do any development until I get it fixed.
I have a hunch: no clue if anyone knows this but does anything else use a property for an object. In OnDiskGif you can read the bitmap like odg.bitmap not as a function. But it is looking like something involved in that leaves the pointer on the stack unless another function happens to use that stack space before collection.
Versus changing it to odg.bitmap() as a method to return the bitmap object.
its a different code path in the vm
you shouldn't need to worry about this
it's why the MP GC is considered imprecise
displayio.TileGrid.bitmap exists as a property and returns and returns a Bitmap object. The rest of that is a bit over my head, not sure if that example is the same thing you're looking for.
I am half way through Jim's video on the GC and he just covered that.
Partly now this is learning for me, and cause it is kinda neat
Hmm yeah true. Though in that case you give TileGrid the bitmap.
had an atmel port build froze in the same way 😖
More random but you don't have any issues with overheating coming up? CPU would be burning hotter during compiles
Thank you for the tip, I will try to look into it. I'll have to figure out how to monitor it.
I haven't had any other trouble that I think would be attributed toward overheating. I bought it as a complete pre-built desktop unit not sure what the cooling is like in it tbh.
I have been running a video in a browser (and have a few browser windows with many tabs open) so the computer is definitely under a decent load when it's occuring. I'm in the process of trying to remove things that are going on to see if I can coorelate any of them with it.
So far though I've never had it occur during any operation other than building circuitpython. I can run videogames + browsers + streaming video and don't have the same problem under what I would assume is similar load.
I had been using -j 8 during builds which caused them to speed up, I assume that adds extra load. The last couple of times it's occured I've left that out though so I know it's not directly the culprit
Yeah video games generally would cause the same problem (if they're using any real amount of CPU).
I noticed that circuitpython's makefile doesn't always work well with -j, I suspect not all dependencies are properly defined, and some things build in the wrong order
During a build after it prints:
GEN build-pyportal/genhdr/moduledefs.h
and before it prints
QSTR updated
What would it be doing at that time (or is there some place I can look to find this out). The last time it froze was just after that first line was printed. (though I don't think the timing is exactly consistent every time that it does)
I have Ubuntu, in two different laptops, no freezing here, however not building ESP, only Pico and/atmel. but I do not use anything while building. And I use all the cores avalaible aka j4
The only thing that comes to mind: the palette.
Thanks. Yeah I'm 95% sure this is the issue now just trying to figure out the best way to deal with it. Also wondering if properties may be "bad" for objects and the garbage collector at times
Thank you, appreciate any extra data points I can get.
I'm starting to suspect CLion or perhaps more specifically the terminal inside of it. I had been making my builds by running the command inside of that terminal in CLion with the project open and it was freezing.
I've gotten several successful builds with just the plain terminal by itself no CLion open but with browser and video running, so the only variable at this point is the IDE. 🤞 it holds up and that hopefully I can at least have it open, having to switch out to a separate terminal wouldn't be the end of the world if it can reliably not lock things up.
Let me know if you want me to test with CLion, I do not have that installed in either laptop.
I'll let you know.
It must have heard me talking though because I did just have it freeze with a build from the terminal directly 😦
I have to write it all up but I'm convinced that a property for an object can lead to confusing the GC as the pointer gets left on the stack by the load attribute function.
The VM code could blank the problematic part after but for the 99.999% of the time it isn't needed probably a performance hit not needed.
I confirmed that a pointer to the OnDiskGif.bitmap object was still on the stack, hence the GC would not clean the object up.
The issue stems from the fact you could get a reference to bitmap by calling it as a property vs a method call (b = odg.bitmap vs b = odg.bitmap()). When you load an attribute the function mp_load_attr is called vs mp_load_method. Load attribute allocates an array of mp_obj_t two entries long on the stack. Load method is similar but adds this to the top of t...
anyone have any idea what this error is talking about?
❯ make BOARD=pyportal
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
mkdir -p build-pyportal/genhdr
GEN build-pyportal/genhdr/moduledefs.h
In file included from asf4/samd51/hri/hri_d51.h:62,
from asf4/samd51/hal/utils/include/parts.h:49,
from asf4/samd51/hal/utils/include/compiler.h:20,
from asf4/samd51/hal/include/hpl_gpio.h:56,
from asf4/samd51/hal/include/hal_gpio.h:45,
from common-hal/frequencyio/FrequencyIn.c:31:
asf4/samd51/hri/hri_mclk_d51.h:1: internal compiler error: Segmentation fault
1 | /**
|
0x7fc6c4c4251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7fc6c4c29d8f __libc_start_call_main
../sysdeps/x86/libc-start.c:58
0x7fc6c4c29e3f __libc_start_main_impl
../sysdeps/nptl/libc_start_call_main.h:392
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Looks like the compiler crashed... does it repeat?
it repeated a few times and then I eventually tried with -j 4 and it succeeded. But I tried a clean again after that and back to not using -j at all and it went back to failing with this error a few more times. I tried -j 2 and -j 4 and both failed (but not with this specific error output). Eventually I tried another one with no -j and it succeeded. So yes repeats some, but not reliably.
Starting to sound like some sort of system error 😦
but I wonder if the freezes are coorelated somehow. Maybe this segfault occurs and it isn't able to recover enough to print the error
It's feeling to me like somehow my compiler(s) have gotten wonky somehow. I haven't noticed any other symptoms doing anything else on the machine building circuitpython is the only activity I've had any issue with so far (and that only started within the last few weeks).
I guess maybe something within the system that is only utilized during the gcc builds? I feel in over my head in linux and with all of this tbh. I've gotten pretty good at getting things going when everything wants to cooperate. But when things go haywire I feel like I'm taking complete stabs in the dark trying to troubleshoot it 😦
currently I'm trying on kernal v6.x whereas my default is v5.x. So far I haven't frozen, but I've been getting that error I posted. Though I'm almost certain I've seen that error on the v5.x kernel before as well.
yeah that's getting over my linux head as well. That's a weird error (if that makes it any better - probably not!). I'm not sure why the compiler would crash randomly
Now I've gotten 3 or 4 successful builds in a row, of the exact same kind as the ones that had failed, without really intentionally changing anything. So definitely something involved that is not reliably failing the same way each time.
slightly different error, but still seems like compiler puking in some way:
❯ make BOARD=pyportal
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
mkdir -p build-pyportal/genhdr
GEN build-pyportal/genhdr/moduledefs.h
arm-none-eabi-gcc: fatal error: Killed signal terminated program cc1
compilation terminated.
If you can I'd at least check CPU temps, maybe RAM just to try to eliminate some things.
@onyx hinge should I update #7718 with the suggestions in #7722 or a separate pr is fine
a separate PR is fine, the goal was to separate my .. concerns .. about the watchdog API stop blocking 7718
Came here from Google, brand new ESP32-S3 here, just hit this problem.
Should I just wrap the call in a try/catch? Would that work?
you probably need to continue to bump up to https://github.com/hathach/tinyusb/pull/1953 :smile:
Looks fine, but there is no newline at the end of generate-board-info.py. This is hard to fix from the GitHub web interface. Can you push a commit? Thanks.
you probably need to continue to bump up to hathach/tinyusb#1953 smile
will do!
Also, fixes readthedocs CI failure.
I saw this kind of thing a long time ago with bad RAM.
like 10-20 years ago
Is the allocated attribute on the used stack, or has that function returned? Sounds like the gc is not using the correct top of the stack, if the latter is true. Tagging @tannewt.
The fix I believe to make things work smoothest is to change the bitmap call to a method instead of a property. I already tested this on the SAMD51 and the issue went away.
We should fix the real problem: this is a workaround rather than a fix.
That checks out with the symptoms. I've had it happen a few times. Stuff starts going a little haywire, it'll crash and when it boots back up things are just not quite right with the ram.
@lone axle Do some ram tests.
That is cool, congrats Neradoc!
Looks kinda similar to the bangle.js stuff scott is playing with?
Lilygo T-watch (V3): boots, web workflow works, I figured out the I2C controlled power for the display, now I need to make the PSRAM work and the display init in board.c (which works in code.py but so far caused the board to hang)
it's an ESP32
web workflow from the watch?
yup
holy s***
getting all the peripherals to work will take some work, but at least the vibration is easy: just setting it as a monochrome status LED, it buzzes the status
hello everyone, I would like to have a step by step guide to clone, fetch submodules, update frozen libraries, create a custom branch, build, push changes to the branch, and most importantly perform updates from latest branches and merge into the custom branch...
I know how to do most of the steps, but every time I need to update and merge there is always a snag especially with submodules.
I am wondering if there is just a simple guide to follow and avoid any steps that I may be doing wrong. Thank you in advance.
It is a reference on the stack that sometimes just is not overwritten and the stack is not zeroed out so when the gc runs it sees the pointer. For more detail:
in the interpreter when an attribute is loaded the main call is obj = mp_load_attr(top, qst) (vm.c:404). Withing mp_load_attr the first two lines are:
mp_obj_t dest[2];
mp_load_method(base, attr, dest);
Putting dest onto the stack. In this case base will be an OnDiskGif object and attribute will be the bitmap a...
Have you taken a look at the Learn Guide on building CircuitPython? It lays out a lot of what you mention about fetching submodules and things specific to that repo. There's another Learn Guide about contributing to CircuitPython that talks more about the Git, such as creating branches.
https://learn.adafruit.com/building-circuitpython/introduction
https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github
As far as pulling in changes to your custom branch, regular git commands like git pull should do the trick, though others more familiar with working with the core can offer more guidance (e.g., rebasing vs merging).
Do we need the windows job? It has become a bottle-neck.
I would suggest to people that they attempt to add an additional pull-up resistor in order to solve this issue. I've used my analog scope to monitor the I2C bus in the default configuration and the rise time for the I2C signals are very much out of spec (rise time is 2.5us & spec max is 1us). While the documentation for the FeatherS3 indicates a 5k pull-up, looking at the schematic seems to show that it's actually 10k (though I could be reading it wrong). In any case, the I2C bus behaves much...
I just ran black so it would fix any other formatting issues.
ok I have board.DISPLAY on the T-Watch working, and the PSRAM seems to work, but it reports 4MB, when it's supposed to have 8, which either means I got sold a V2 (??) or there's something (else) fishy
(it's not a V2, at least the brightness pin is according to the V3 pinout)
You have a buffer containing one instruction, but its byte length is 2
Maybe I don't get what you mean. pio_sm_is_exec takes a 16 bit integer as a instruction for the statemachine. And the mp_buffer_info_t could be also something other than a 16 bits integer (array).
I think I understand slightly.
What I am thinking about... Here some code snippets:
// Buffer protocol
typedef struct _mp_buffer_info_t {
void *buf; // can be NULL if len == 0
size_t len; /...
Just compiled circuitpython with this change:
STATIC mp_obj_t rp2pio_statemachine_run(mp_obj_t self_obj, mp_obj_t instruction_obj) {
...
common_hal_rp2pio_statemachine_run(self, bufinfo.buf, (size_t) bufinfo.len/2); //CHANGED BUFFER LENGTH
return mp_const_none;
}
And it works so far. I will get in touch later on.
Thank you for your reply, but as far as I know those guides are out of date.
If you think the guide is out of date, please let us know what is wrong with it. I try to keep it quite up to date.
Sure, will do. Thank you.
There might be some opportunity to add a section or page about specifically updating / merging from main. That was part of their question which I don't think the guide currently covers.
I struggle with that process over time as well so unfortunately I don't have any advice to give. Cloning, making a branch, adding a change, commiting, pushing if done all within a relatively short window all go fine with no issues.
But if that new branch gets stale behind main, or if my local repo main gets behind remote main I have trouble getting my local instance to get updated from remote main and then not show local changes that I didn't (intentionally) make. I seem to have the most trouble with some kind of MD5 hashes stored in a file by themselves, I think they're related to the submodules, but not certain.) After some time passes my local repo gets wonkier as more things get updated in main. My IDE allows me to ignore certain files when committing so I can use that for a while to keep making new commits without having to actual solve the root problem of my instance being out of sync for some reason. But it would be great to have some repeatable steps laid out that can be used to take an out of date local repo and get it up to date such that it will get back in sync with main, submodules, hashes and all, afterward attempting to make a commit would report 'no changes detected' if the user hadn't changed anything else.
I have sometimes gotten it resolved, but never with reliable/repeatable steps, when I attempt same thing again I've run into issues. I usually end up just cloning another copy of the repo to start fresh.
Thank you for rewording my concerns more appropriately.
Hi, how do I send a newline when writing to the file?
already tried
fp.write("\x0A")
fp.write("\n")
fp.write("\r")
and none worked for me
How can I read the date modified off of a file in cp?
I can't seem to find any api for it..
The only date readily available seems to be the build date
I want to have ljinux advance the rtc in case no wifi is available to the last modified thing, so that it's not too old
os.uname()[3][os.uname()[3].rfind(" ")+1:]
@brazen hatch os.stat(file)[some number]
Oh alright, thanks!
I don't know what index number is the modification time but you can probably guess or check the source
| This object may be accessed either as a tuple of
| (mode, ino, dev, nlink, uid, gid, size, atime, mtime, ctime)
Well, I will just check source, it's easier
most values are dummy on cp of course
Wait, are uid gid settable though?
Or just /dev/null
I could really use them for permissioning on ljinux..
Uhh, multiuser will be such a pain..
I may end up relying on a totally virtual filesystem, relying on files to describe the real files.
Like, every file having it's .prm counterpart describing it's perms
It's gonna be such a pain.
I don't think fat12 has uid and gid, I think you set them when mounting the filesysyem and they are all the same for all files
Yea, prolly they are just nulled
And all the virtual filesystem stuff is going to be so easily bypassable since pexec is a command that runs direct python code.
ljinux jailbrek eta wen
kernel ring 0 direct code execution directly available.
Ljinux structure is such a meme.
And I will do nothing about it.
I may make file flags like "this file can run this".
So only specific stuff can run other specific stuff.
@EricAlm GitHub is not for these kinds of support issues, sorry. Please ask in discord: https://adafru.it/discord or in the forums: https://forums.adafruit.com/viewforum.php?f=60
@brazen hatch This is what I'm using: fTime = localtime(max(min(2145916800,dStat[9]),946684800))
dStat = os.stat(filename)
Nice thanks
Well imma implement it in ls
cuz currently in ls -l it only does the files + if they are files or folders or hidden
@onyx hinge The watchdog can be disabled on atmel-samd as well
@slender iron are you the primary reviewer for https://github.com/pidcodes/pidcodes.github.com/pulls ? There is a backlog; a few of these are CPy-related.
@analog bridge it seems like we should try to re-construct the reason it was designed NOT to be deactivated ever, then
and see if those reasons still apply
17.6.2.3 Enabling and Disabling
The WDT is enabled by writing a one to the Enable bit in the Control register (CTRL.ENABLE). The WDT is disabled by writing a zero to CTRL.ENABLE.
The WDT can be disabled only while the Always-On bit in the Control register (CTRL.ALWAYSON) is zero.
if it can be deactivated on some chips, then maybe just raise an exception if someone tries to deactivate it on nRF or other chips where it's not possible? Or maybe I am late to the party and you are doing this already.
I think this should do the trick on atmel-samd: WDT->CTRLA.bit.ENABLE = 0 granted that the watchdog was initialized with WDT->CTRLA.bit.ALWAYSON = 0.
what does it mean that the pico sdk does not give a way to disable the watchdog ? does it give a reason anywhere ?
This leaves only nRF and from what I have read on multiple nRF forum posts, it can't be done and they explicitly state that.
Its also mentioned that the watchdog registers are disabled post watchdog initialization and subsequent writes aren't allowed.
There is a way to disable the watchdog when in sleep or debugging active, so I believe a hacky way might still exist.
Idk but they themselves disable the watchdog when doing some configuration internally in the sdk and then it is re-enabled.
making a PR might wake up this issue
Found a bug while trying to use the file where the bootloader was always null. Apparently it was looking in the wrong place in the bootloader json file.
Yup. I'll look today. Would you mind updating your tinyusb PR to include my imx fix from yesterday?
I did, Thach mentioned it
thanks!
nRF doesn't have any stack checking besides what CircuitPython does. ESP has FreeRTOS to check the stack as well. I wouldn't be so sure it's esp-only. nRF could have the same issue but not fail deterministically.
@cherrydev Interesting. The LC709203F datasheet shows 10k as an example, so theoretically it should be OK. It works fine on ESP32-S2, but perhaps there is something hw or sw-related on S3 that causes the slow rise time. Have you looked at the rise time on an S2 board?
How about adding #define RUN_BACKGROUND_TASKS to mpconfigport.h so that it gets replaced with nothing?
@Neradoc should we make it not translated?
@blissful pollen correct me if I'm wrong, but I don't see any code where the GC scans the C stack for root pointers. In which case the dest array you refer to is on the C stack and so it is never seen by the GC in anyway. Right?
You could add .deinit() to Bitmap so that we can control when its memory is freed. Then this dangling reference will just be to the deinited Bitmap. Probably worth doing for something that can hold a bunch of memory.
this is via mp_state_thread_t in mp_state_ctx_t. There's a comment:
// This structure holds state that is specific to a given thread.
// Everything in this structure is scanned for root pointers.
typedef struct _mp_state_thread_t {
// Stack top at the start of program
char *stack_top;
#if MICROPY_MAX_STACK_USAGE
char *stack_bottom;
#endif
a pointer to an object might only be on the C stack for a while, so it needs to look there. ... Unless I am confused.
also note if PYSTACK is enabled, it looks on that
Looks good! Thank you for updating this!
well, there's a slightly contradictory comment:
////////////////////////////////////////////////////////////
// START ROOT POINTER SECTION
// Everything that needs GC scanning must start here, and
// is followed by state in the mp_state_vm_t structure.
//
@slender iron is more familiar with the gc code
@dhalbert I do not have an S2 board to test it on. In the past, though, I've found a lot of I2C problems to go away with stronger pull-up, so it might be worth a try. While 10k might theoretically be fine, it also depends on details of the host's I2C circuit, including capacitance, which I only know how to measure with the board unpowered, which might not give an accurate measurement due to the ESP's GPIO MUX. I can test an original ESP32 using a 10k pullup and see if I get similarly slow ris...
collect over the stack is done here: https://github.com/adafruit/circuitpython/blob/main/main.c#L1150
important comment:
// This naively collects all object references from an approximate stack
// range.
@tidal kiln I'll take a look at the epd issue tomorrow when I get my epd feather and my brain into that mode
@blissful pollen note approximate above. That may be the giveaway for the problem with the gif code. Even if it has return from that frame, if it goes past the end of the current frame in that collect
@slender iron awesome. thanks! really curious what is going on there. super weird one.
do you have a Lolin S2 Pico ? I have a build to make you test with board.DISPLAY
Two unrelated fixes.
- Fixes #7661.
- Fixes #7683.
I have, somewhere at home. But I will not be there before 19th, but I will not have much time before the 23th.
well you can bookmark this build: https://www.neradoc.me/builds/lolin_s2_pico-8.1.0-beta.0-23-gbca7d6e99-add-display-lolin-pico-dirty.uf2 with this code: https://gist.github.com/Neradoc/0d5106ac93a978d8be36ecf7b8dd9683
import gc
a = list()
while True:
try:
a.append("a")
except:
a.pop()
gc.collect()
print("done")
break
b = """
for i in a:
if i != "a":
print("err")
"""
exec(b)
def test(no):
print(no)
try:
test(no+1)
except RuntimeError:
print("Done")
for i in range(250):
test(0)
exec(b)
Passes just fine.
Noted, I'll give it a try. So you also solved the I2C pin in use!
I had the plan to copycat what you were doing on the other board, but it is as great if it is already done!
well I can't test, so we might need some back-and-forth when you have time for it. I didn't know there was an I2C pin in use issue
it uses the same trick as the feather TFT, by setting up the display on the shared board.I2C(), so you can't setup the pins manually, but have to use board.I2C()
Add Deneyap Development Boards' info and images.
List of Deneyap Development Boards
- Deneyap Kart
- Deneyap Mini
- Deneyap Kart 1A
- Deneyap Kart G
- Deneyap Mini v2
- Deneyap Kart 1A v2
I have let it run for quite a while now. The pystack is not corructed and the system is stable. Uptime 6 hours.
nrf 'is' unaffected.
Do you have a PR to CircuitPython itself for support?
Do you have a PR to CircuitPython itself for support?
I would like to add a our development board to the circuitpython.org website.
@micrdev maybe I should have done a make translate in that pr
i saw your deleted message
The boards section on circuitpython.org is only for boards that have support in https://github.com/adafruit/circuitpython -- it does not list boards that are supported only in micropython, or only in a fork of circuitpython.
@tulip sleet nevermind, false warning
i think the compilation did the right thing, then, it must be weblate that doesn't like it?
@tulip sleet @onyx hinge any thoughts about me adding an #define CP_INLINE inline __attribute__((no_instrument_function))?
instead of adding it to MP_INLINE or whatever it's called?
there's no MP_INLINE, oddly
yup, just looked for that too
there are MP_NOINLINE and MP_ALWAYSINLINE
ALWAYS_INLINE is stronger??
Is no_instrument_function something to do with the profiling work you're doing?
yup, it exempts a function from -finstrument-functions. clang has an option to do that after inlining but not gcc
so the instrumentation prevents inlining
- Enable dcache for OCRAM where the VM heap lives.
- Add CIRCUITPY_SWO_TRACE for pushing program counters out over the SWO pin via the ITM module in the CPU. Exempt some functions from instrumentation to reduce traffic and allow inlining.
- Place more functions in ITCM to handle errors using code in RAM-only and speed up CP.
- Use SET and CLEAR registers for digitalio. The SDK does read, mask and write.
- Switch to 2MiB reserved for CircuitPython code. Up from 1MiB.
- Run USB interrupts ...
The boards section on circuitpython.org is only for boards that have support in https://github.com/adafruit/circuitpython -- it does not list boards that are supported only in micropython, or only in a fork of circuitpython.
That's right. If the PR will be merged, our boards will be listed in https://github.com/adafruit/circuitpython...
I followed the instruction in https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website
- Fixes #7555.
Also ran docs/shared_bindings_matrix.py through lback.
You'll need to do this first: https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython
I see. Thanks.
I added a sentence to the https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website guide to say that adding the board to CircuitPython is a prerequisite.
It's been awhile since I built an iMX image is there an additional tool-chain step I need?
../../shared-module/usb/core/Device.c:64:31: error: unknown type name 'tuh_xfer_t'
64 | STATIC void _transfer_done_cb(tuh_xfer_t *xfer) {
| ^~~~~~~~~~```
we just updated tinyusb. you'll need to make fetch-submodules
Was just doing a fresh clone 😄
Just following along as an interested observer: will this PR only work for RP2040, or will deinit() also work for SAMD51?
CircuitPython version
Version 8.0.0 on PCA10100
Code/REPL
import busio, board, digitalio, time
from adafruit_bus_device.spi_device import SPIDevice
buf = bytes([0x90,0x00,0x00,0x00])
cs = digitalio.DigitalInOut(board.P0_17)
comm_port = busio.SPI(board.P0_14, MOSI=board.P0_20, MISO=board.P0_21)
device = SPIDevice(comm_port, cs)
with device as bus_device:
bus_device.write(buf)
result = bytearray(2)
bus_device.readinto(result)
pri...
Why do you call it comm_port?
Don't forget cs.direction = digitalio.Direction.OUTPUT to set the Cs pin to output.
@default-settings:
- Did you flash the UF2 bootloader and the SoftDevice to the board?
- If you remove the print statement, does it still fail?
I tried this code (just with different pins) on a Feather nRF52840 with 8.0.3, and it works.
The artifact .hex from this PR doesn't seem to work when programming a Teensy4.1 using the Teensy Loader. I did double check with the latest S2 posted .hex at circuitpython.org and it does program properly.
@kreasteve
I tried that when I wasn't using SPIDevice and just busio and manually setting it to False. I named it comm_port because this is an almost copy/paste from the example test from SPIDevice.
@dhalbert
I've flashed the bootloader and the soft device, yes. Removing the print did nothing, it fails during the write. I was able to lock and unlock the bus, but the write makes it fail.
You could add
.deinit()to Bitmap so that we can control when its memory is freed. Then this dangling reference will just be to the deinited Bitmap. Probably worth doing for something that can hold a bunch of memory.
Sounds like a good idea. I will add the deinit to Bitmap in. Probably easier then tweaking the VM :)
@tulip sleet any plan for an 8.0.4 release ? There's unreleased fixes in 8.0.x, in particular the web workflow related non-blocking sockets thing
I added a sentence to the https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website guide to say that adding the board to CircuitPython is a prerequisite.
Now we are working on adding our boards in CircuitPython repo. Will you close the PR or wait it until its done?
I am planning to do it tonight or tomorrow.
I am testing the support matrix PR and I get empty contents when it retrieves the past files.json even though it gets the correct size in the size field
this here: https://api.github.com/repos/adafruit/circuitpython-org/contents/_data/files.json?ref=78a1c988538d65a092c319faeec357fb0a668ac5
This updates the site to point to the installer published at https://github.com/adafruit/web-firmware-installer-js. It also removes some parameters that are no longer needed because they are extracted from the esp32_boards.json file.
Between 1-100 MB: Only the raw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be "none". To get the contents of these larger files, use the raw media type.
files.json is just over 1MB
@tannewt I believe this to be resolved in the latest rebase.
https://github.com/raspberrypi/usb-pid
Should be ready for review once tests pass.If I missed anything else, please let me know. Would love to get this resolved and merged. Sorry for the delay!
Ideally the data buffer would be owned by the Bitmap and you would explicitly free it here. This gives the behavior that the large memory allocation is always freed, no matter how unlucky you are with the garbage collector.
The buffer is usually owned by the Bitmap except in one case for espcamera where it seems to borrowed from the camera driver.
When trying to test it locally, I get an error because the content is empty when trying to retrieve the previous files.json.
❯ RELEASE_TAG=8.0.0 DEBUG=1 python build_board_info.py
Not logged in
Traceback (most recent call last):
File "/Volumes/circuitpython-dev/repositories/test-pr/tools/build_board_info.py", line 268, in <module>
generate_download_info()
File "/Volumes/circuitpython-dev/repositories/test-pr/tools/build_board_info.py", line 207, in generate_download_info
...
Ideally the data buffer would be owned by the Bitmap and you would explicitly free it here. This gives the behavior that the large memory allocation is always freed, no matter how unlucky you are with the garbage collector.
I thought freeing the explicitly at this time but I'm not sure if that is best practice for dealing with the gc? The situation I ran into with it being on the stack is extremally rare. But it would work. @tannewt or @dhalbert ?
The buffer is usually owned by t...
I still don't understand if the pointer in question is in the live stack, or is in a frame from a routine that has returned. If it is the latter, then the stack gc is being sloppy and including stuff that is not in the current and previous frames. If it were made correct, then there would not be problem, because the pointer would not be found.
The problem @Neradoc observed is now happening even before this PR is merged:
https://github.com/adafruit/circuitpython/actions/runs/4421756938/jobs/7752932114#step:8:1
This is on my 8.0.4 release.
@Neradoc I tried both of the above patches to build_board_info.py by hand, but the problem I encountered is that I need response["sha"], and neither gets that. However, I may have done something wrong. Could you show me your patched build_board_info.py.
Thank you for this tip about potential bad RAM. I don't have a way to know for certain yet, but I swapped to dome different RAM and have not had the same issues arise yet after several builds. Anecdotally looking like a good theory so far.
sounds good. it could also have been badly-seated RAM. But it can be hard to test. I have used the Linux RAM tester that grub puts in the boot menu for hours and it didn't find the bad RAM.
I think when I really saw this was in the late 1990's, when I had to compile my own Linux kernel. Sometimes it failed, which was confusing. After some tedious swapping I found the bad stick.
Automated website update for release 8.0.4 by Blinka.
@jaunty juniper worked, thanks!
we'll need to PR this to 8.0.x and main. But perhaps you might go to sleep 🙂
you can add it to your PR ? It will need it anyway
I can, and I will backport it to 8.0.x.
@tulip sleet can you check why the readthedocs CI is failing? Is it something to do with #7725?
7725 isn't merged yet. But see above for a problem that Neradoc diagnosed
Revision e207106d. Last updated on 07 Mar 2023.
7725 just happened to be coincident with the files.json file gettign too big
I will look at this in the morning, is that ok?
trying to finish the 8.0.4 rlease and then sleep
thanks for noticing!
Does it run on a schedule?
it runs after each merge
Is this the intended behavior?

Good evening - should I be able to run this example on windows 11 if I change my python version to ~3.8?
https://learn.adafruit.com/circuitpython-ble-libraries-on-any-computer/ble-uart-example
I am receiving this error:
Trying to connect...
Unhandled Exception: System.NotSupportedException: Cannot create uninitialized instances of types requiring managed activation.
Log of the set-matrix step:
Run python3 -u ci_set_matrix.py
python3 -u ci_set_matrix.py
shell: /usr/bin/bash -e {0}
env:
pythonLocation: /opt/hostedtoolcache/Python/3.11.2/x64
PKG_CONFIG_PATH: /opt/hostedtoolcache/Python/3.11.2/x64/lib/pkgconfig
Python_ROOT_DIR: /opt/hostedtoolcache/Python/3.11.2/x64
Python2_ROOT_DIR: /opt/hostedtoolcache/Python/3.11.2/x64
Python3_ROOT_DIR: /opt/hostedtoolcache/Python/3.11.2/x64
LD_LIBRARY_PATH: /opt/hosted...
The best I can tell when gc.collect() is called the pointer exists in the live stack memory but was set in a previous function call that is complete. The part of the stack the pointer is stored in was never changed by future function calls when they allocated items on the stack.
The problem goes away with less optimization and does not exist on other ports. A Micropython video says that this situation, while rare, is possible. I have seen a cases where local variables exist on the stack ...
LGTM! Thanks, @dhalbert and @Neradoc.
Just following along as an interested observer: will this PR only work for RP2040, or will
deinit()also work for SAMD51?
@felker It should now, can you test.
This seems odd: I would think any change below ports/espressif would work. Do you have an idea of the problem?
It's not just bindings, I think maybe it's CIRCUITPY_* features that are not across all parts.
$ tools/ci_set_matrix.py ports/espressif/bindings/espnow/ESPNow.c
...
Building boards: False
...
$ tools/ci_set_matrix.py ports/espressif/common-hal/espnow/ESPNow.c
...
Building boards: False
...
$ tools/ci_set_matrix.py ports/espressif/common-hal/busio/UART.c
...
Building boards: True
adafruit_esp32s2_camera
adafruit_feather_esp32_v2
adafruit_f...
Backport 069a058a83ebb9fbf35bbe3c76691564a830f3ad from #7723 to 8.0.x.
CircuitPython version
Adafruit CircuitPython 8.0.4 on 2023-03-15; Raspberry Pi Zero W with bcm2835
Code/REPL
import time
import usb_hid
from adafruit_hid.keyboard import Keyboard
kbd = Keyboard(usb_hid.devices)
while True:
print(kbd.led_on(Keyboard.LED_CAPS_LOCK))
time.sleep(0.1)
Behavior
adafruit_hid.keyboard.Keyboard.led_on only reports True once and not the whole time the LED is on.
The above code should print out True **whi...
tested and same behaviour for:
- LED_NUM_LOCK
- LED_SCROLL_LOCK
Excellent -- are you skills up to making a Pull Request with the change?
I'll give that a try tomorrow.
Do you have an idea to prevent using a string for the parameter of run?
The code looks fine. Do you see any kind of noticeable performance degradation that might make it worthwhile to run the background tasks only sometimes around the loop?
re RTD builds failing: I looked at the build logs:
the issue is this:
PDF generation failed. The build log below contains information on what errors caused the failure.Our code has recently changed to fail the entire build on PDF errors, where we used to pass the build when a PDF was created.Please contact us if you need help understanding this error.
and the specific error is:
! LaTeX Error: Unknown graphics extension: .svg.
there are also a lot of warnings:
LaTeX Warning: Hyper reference `docs/index:project-structure' on page 3 undefined on input line 107.
and similar
perhaps we might turn off PDF generation for now unless .svg is easy to fix
RTD builds are failing due to a new policy by RTD of failing builds when the PDF generation fails:
example: https://readthedocs.org/projects/circuitpython/builds/19783677/
Error
PDF generation failed. The build log below contains information on what errors caused the failure.Our code has recently changed to fail the entire build on PDF errors, where we used to pass the build when a PDF was created.Please contact us if you need help understanding this error.
! LaTeX Error: Unknow...
You could check that the buffer length is a multiple of two, as is done in another spot maybe in that same file. Or, you could check that the type code is 'H' but that might be considered an incompatible change, I'm not sure. (Especially as this function in particular really didn't work at all before fixing this bug)
I am still trying my luck with S2. No matter what I do, when I build debug, it will NEVER crash.
However I discovered another way to reproduce this issue immediately (unless you are using debug builds):
def test(no):
try:
test(no+1)
except RuntimeError:
print("Done")
a = "for i in range(10): test(0)"
for j in range(20): exec(a)
It immediately crashes, after printing a single "Done".
I have tried my luck with:
#pragma GCC push_options
#pragma GCC ...
@slender iron @tulip sleet what do you think of requiring the buffers that contain PIO instructions to be of type 'H'. It's a very small potential breakage, anyone who uses adafruit_pioasm would be fine; but if you e.g., open a file and read() it you'd have a buffer with typecode 'b' instead... this is relative to https://github.com/adafruit/circuitpython/issues/7706#issuecomment-1470484705
and the fix is to memoryview(buf).cast('H') or so
and the fix is to memoryview(buf).cast('H') or so
Are instructions always 16 bits? How hard is it to just check that the length is a multiple of 2?
yes they are always 16 bits
but some strings would still be accepted, even though it would be wrong
hmm... the memoryview cast seems rather obscure.
like "in x" for instance, is a 4-byte string but is nonsense as a PIO instruction
maybe explicitly check for the type being 'str' and reject it, as well as checking length, so that "in x" would fail but b"in x" would be OK, just less likely to occur by accident
If, say, you were reading 32 bit ints from a binary file, what would be the best way of reading those ints? Would you read bytes and use struct.unpack? I'm wondering what the usual Python idiom is
if I understand this user correctly, they're saying they ran into a form of this and are wishing the problem would be diagnosed better
I think checking for factor of two is easy. But is that already being done and the message is obscure?
standard Python has array.Array.fromfile, CP doesn't.
some of the locations that work with SM instruction sequences check for multiple-of-2 but this one didn't (and it has the bug discussed in that issue, where it tried to execute 2x as many instructions as it should have)
Progress.
I got custom logs on s2 uart.
I think we could refactor the *2 check so it's small, and check everywhere. But let me stare at the api for a bit...
factoring it to do the same check at all 3 (?) relevant sites would be good
there's the 2 constructor arguments + the function being discussed in that issue
rp2pio.StateMachine(program: circuitpython_typing.ReadableBuffer, ...) I am somewhat reluctant to change this to an H array.array without doing it in a staged way
on the other hand, using 16-bit objects gets rid of any endianness questions
what about excluding 'str' even if it's nominally a circuitpython ReadableBuffer?
'str' is always wrong, 'bytes' is might-not-be-wrong
str is not a ReadbleBuffer in real python, it's sort of an accident that it is in CP/MP
yes, I think we have some similar checks elsewhere and there might be an mp_ routine or macro to check that
someday there might be an extension to PIO that has longer or shorter instructions (but maybe not)
#: shared-bindings/displayio/Palette.c
msgid "color buffer must be a bytearray or array of type 'b' or 'B'"
msgstr ""
#: shared-bindings/audiocore/RawSample.c
msgid "%q must be a bytearray or array of type 'h', 'H', 'b', or 'B'"
msgstr ""
etc.
YES! IT. IS. OPTIMISATION!
I set OPTIMIZATION_FLAGS ?= -O2 for debug too and it now crashed!
Finally!
Now I just need to find which func is the one assuming the static size.
Or I can just make it volatile.
It's not the pystack funcs though.
It updates on reload just fine.
deinit() works for me. However, I was hoping that w.feed() would still work throughout the script even when it is de-inited. Otherwise I need to wrap all the lines like so:
if watchdog_enabled:
w.feed()
Well, all the pystack logic seems to work just fine.. What is going on even..
All the functions report the same addresses and len's.
Hmm.. now what do I do?
so I just discovered this:
$ python3 -m pip install pip
error: externally-managed-environment
https://github.com/python/cpython/issues/102134#issuecomment-1445428402
As the message you're getting explains, this is actually not an issue with Python itself, but rather your Linux distribution (Kali, Debian, etc.) implementing a deliberate policy to ensure you don't break your operating system and system packages by using pip (or Poetry, Hatch, PDM or another non-OS package manager) outside the protection of a virtual environment.
This has been a long-standing recommendation from both the Python team and Linux distros, due to the severe problems that frequently occur for people as a result of using pip or other package managers directly with your system Python.
that's gonna affect Blinka
other distros just make --user the default
to be honest, I can't blame the debian maintainers for getting tired of the python developers regularly messing this up
Ubuntu has —user as the default. I’m surprised Debian doesn’t. Or does it?
they just replaced pip with a script that shows that error
I bet you could uninstall the system pip and install it using get-pip.py and it will work
python3 -m ensurepip?
least decisive api
ok, correction, they didn't completely replace pip
fwiw the full message in debian testing is:
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.
If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.
If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.
See /usr/share/doc/python3.11/README.venv for more information.
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
This feels .. extremely user hostile
that's what you get when project politics become more important than users
you can also fix it with rm /usr/lib/python3.11/EXTERNALLY-MANAGED until the python package upgrades
I am especially astounded that this applies to --user
yeah, however, it's after years of https://xkcd.com/1987/
--user has its own problems, for example, it installs all binaries for different python versions together...
aha dpkg-divert --divert /usr/lib/python3.11/NOT-EXTERNALLY-MANAGED --rename /usr/lib/python3.11/EXTERNALLY-MANAGED fixes it and will survive updates
The module is searched in SRC_PATTERNS but the modules under bindings aren't in it.
https://github.com/adafruit/circuitpython/blob/37b9f778e1017b1cc8704f50ed13a04414e20b4b/tools/ci_set_matrix.py#L215-L220
an interesting tool
I have news.
By editing ports/espressif/makefile:124 to OPTIMIZATION_FLAGS ?= -O2 the bug is reproduced on debug builds.
So it is 101% an optimisation issue. However I have not quite determined the fault just yet.
I have toyed around with the debug uart of s2 and managed to get logs from main to it.
Anyways.
With pystack allocated to
start = 0x3f78027c
end = 0x3f78327c
(CIRCUITPY_PYSTACK_SIZE=12288, I did check the sizes and addresses across funcs. It's al...
Added a heap pointer print
pystack: start = 0x3f78027c
pystack: end = 0x3f78327c
heap: start = 0x3f783284
heap: end = 0x3ff80000
***ERROR*** A stack overflow in task main has been detected.
Backtrace: 0x4002bdc6:0x3ffe2c80 0x4003309d:0x3ffe2ca0 0x40035b0a:0x3ffe2cc0 0x4003497a:0x3ffe2d40 0x40033190:0x3ffe2d60 0x40033142:0x3ffe2d90 0x4009cb79:0x00000000 |<-CORRUPTED
ELF file SHA256: e8cb997e27dd2b38
CPU halted.
I do not know how to decode the backtr...
Some things to read about this pip change:
https://peps.python.org/pep-0668/
https://discuss.python.org/t/10302
Also not directly related to this, but interesting:
https://justinmayer.com/posts/homebrew-python-is-not-for-you/
Now we are working on adding our boards in CircuitPython repo. Will you close the PR or wait it until its done?
I'll convert it to a draft PR and you can update it and fix the failing checks when you're ready.
in particular, they say pip install --user is still bad, because you're mixing user-installed and system-installed stuff due to sys.path, possibly causing an inconsistent mix of versions and it can cause problems for you (though not for stuff run only by the system).
it sure seems like the concentration of baby in this bathwater is suspiciously high
@slender iron there are 4 flags for increasing code alignment across the board: -falign-functions=, -labels=, -loops=, and -jumps= -- I don't know that there's one for data. https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-falign-functions
Optimize Options (Using the GNU Compiler Collection (GCC))
I assume you don't have the .elf or .map that goes with it 😕
offset 0x60000400
nope 😕
its not that dissimilar from something you'd compile from my branch
branch is get_perfbench_running
@slender iron out of curiosity what tool are you using to get those performance/benchmark stats (just saw some of last week's show n tell). Haven't been able to follow much lately. (this isn't related to what Phil and Limor just said either on SnT ha just was interested).