#circuitpython-dev
1 messages · Page 24 of 1
product is out of stock right now
Right but that won't affect the guide. Or the folks that already ordered one.
ah ok, it did ship some, ok. I will get ready for an rc.2 with new release notes (which are minimal and I can add to)
Thank you!
@tulip sleet How are we looking for 8 stable? There's a thing I wanted included, but haven't had the time to do, and am not sure I ultimately will.
Just as the title says.... I have been running into this issue.
not sure what you mean by "How"? You mean what will determine we are stable? I think in the guide you could just refer to circuitpython.org and say download 8.0.0 or later.
This isn't related to the guide I'm working on now. By "how" I meant do we have some idea when it's going to happen, or is it still a bit out.
we really don't have more to add to 8. We are picking up things like new boards because they are standalone and are in the rc period. I think we are waiting for any showstopper issues to show up, and none have yet.
Thanks for all the help with this. I will make the changes you have outlined. At the moment I am going to pull my request for my board as I am having problems with serial mode on my board. I think it is related to a recurring VID/PID issue I have been encountering. If I uses VID 0x0239A/PID 0x80C8 my board works perfectly in MU etc. But this was rejected for CP inclusion as a duplicated VID/PID was found. When I switch to 0x303A/0x90C8 it passes the PID verification but the I get a serial e...
Good to know. Thanks!
@proven garnet I continued digging the problem of the missing __version__ information in the files. I made a list using a basic GREP search. here. Think we have more files missing the info... https://gist.github.com/jposada202020/3d20534385c434577b3e50cf7bfc28c1. warning, some __init__ files could be wrongly reported, as some libraries have empty __init__ let me know if there is something that we would need to work on. ☺️ thanks
Got it. Mu uses https://github.com/adafruit/Adafruit_Board_Toolkit (which we developed) to find the serial ports. How that is done varies per operating system.
If this is Windows, try Uwe Seiber's USB Cleanup tool, which can get rid of stale devices: https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting#device-errors-or-problems-on-windows-3094694
oh there's an issue with mission __version__ ?
I did one this morning for displayio_layout I did not know all the files missing it at that time
And not sure if it matters or worth the effort to correct them 🙂
yeah a library only needs one file containing the version
I found trying to understand why circup was saying that displayio_layout needed a major version ergo last night question..
I only found 3 or 4 libraries that circup could not find the version and I think one of them was displayio_layout,
That is good, I think we will need to put a note somewhere here for folks to know https://github.com/adafruit/circuitpython/blob/main/docs/design_guide.rst
I'll PR an update to circup
Good Ill will make the PR for the design_guide and the three libraries that could be a quick fix. Thanks Neradoc!
before
❯ circup freeze
Found device at /Volumes/CIRCUITPY, running CircuitPython 8.0.0-beta.6-62-g7522522a0-dirty.
adafruit_displayio_layout==None
after
❯ circup freeze
Found device at /Volumes/CIRCUITPY, running CircuitPython 8.0.0-beta.6-62-g7522522a0-dirty.
adafruit_displayio_layout==1.19.10
yay 
sorry did not want to get you into a rabbit hole.. 😦
nah that's good
also note that putting the version and repo strings in more than one file uses more disk space than necessary
maybe we could have a pre-commit check installed by cookiecutter that looks if there's a valid __version__ ? Is there something like that ?
Thanks Dan:
I tried Uwe's tool but no luck. Deleted USB VID keys etc etc. It's a real
head scratcher. I think this is a case of my dev machine (Windows) having
some record of the previous VID/PID. I've tested two other Windows systems
and they were fine (they had never seen that board before). So it is
looking like a VID retention issue I think. Weirdly MU works perfectly fine
other than the serial window. If I put the older firmware on it works
again. It's odd to say the least, but we did...
Hi Dan:
Holy Bats! I uninstalled Mu and re-installed it. Now the serial console
works! I'm not even going to try
and guess what happened. Caches boards or something? But, it might be an
option to look at if people are having issues. I'll make the changes to my
code and do a re-submit. Sorry for all the trouble, it's been an
adventure! 🤕
On Tue, Jan 31, 2023 at 6:37 PM Jeremy Littler @.***>
wrote:
Thanks Dan:
I tried Uwe's tool but no luck. Deleted USB VID keys etc etc. It's a ...
Adding information in the design guide to include the version for correct libraries packaging.
Thanks :)
@lone axle I tried the IS31FL3741 on 8.0 rc.1 and like you it does not work. Not sure offhand why that would be
+1 on circuitpython support. Is there a plan for it?
Alternatively, any pointers as to how to modify support for VL53L4CD to make it work for VL53L4CX as well?
https://github.com/adafruit/Adafruit_CircuitPython_VL53L4CD/blob/39fc7df54af911b7e4206a46c21bf4952e02f7f1/adafruit_vl53l4cd.py#L196
The CD library works on CX as well, but only for values up to about 160cm, so I'm assuming it's a simple change to include support for CX as well.
Hi There:
I've sorted out the VID/PID issues (it was actually just a re-install of MU!). I've applied the changes that were requested on the Seventh Commit . Checked the firmware and all work fine. Thanks for all the help with this!
CircuitPython version
Circuit Python 8.0rc1
Code/REPL
import ulab.numpy as np
variable=np.arange(61,61)
Behavior
CircuitPython completely crashes and the board becomes unresponsive, at least on my Challenger mk1 rp2040 board.
You must reboot into safe mode to return functionality (unless you can stop execution before the offending line). The board will not even be recognized by USB (as per error, "USB Device not recognized" in windows system...
The same is true for the following as well:
- [ ] ADC
- [ ] GPTIMER
- [ ] I2S
- [ ] PCNT
- [ ] RMT
This looks good!
As mentioned, please don't open a new PR for each commit. Just push a new commit to the existing PR with your changes. If you close a PR you can reopen it.
Also in the future please write descriptive commit messages, not "Fourth Commit", etc.
Now that this is merged, please submit a PR to https://github.com/adafruit/circuitpython-org to add the board to https://circuitpython.org.
This looks OK. I didn't know the M5Stack boards had such a complicated naming scheme.
The black version has changed:
- black==22.12.0
+ black==23.1.0
+1 from me.
I already tried to modify the CD lib for CX, but ST not having a proper datasheet/manual and instead telling people to use their provided arduino library makes it quite tricky. Off course their code is like 20 files, many with thousands of lines, with abstraction over abstraction and really (intentionally?) difficult to parse.
I had to set I2C to 1 MHz to work initially, and then I got measurements up to 2.2 m or so. I then dug through the ST library to find the parameters the...
I have a question. For singletons, what is the reasoning for implementing them in either of the following ways:
- A static object available as a sole instance. (e.g.
wifi.radio,microcontroller.watchdogetc.). - A dynamic object with only one instance creation allowed at a time. (e.g.
wifi.Monitor(),espulp.ULP()etc.).
@tulip sleet I wonder if we shouldn't update ulab before final release of 8
That is fine with me. Go ahead with a PR
(I think 7531 is fixed)
I too thought that was fixed
@onyx hinge it looks like something changed out from under pre-commit last night. I did an innocuous PR merge and got this (ran twice to make sure): https://github.com/adafruit/circuitpython/actions/runs/4060983872
I have not had a chance to look at it in detail yet. Looks like black
never mind, MicroDev found it; I hadn't finished reading my email
@tulip sleet is it related to this? The black version has changed:
- black==22.12.0
- black==23.1.0
ah because we pip-install black and don't pin it
that is a lot of churn
it is.
lots of new white space. I like the """ on its own line; other than that, not sure why they did it
https://ichard26.github.io/blog/2022/12/black-23.1a1/
If you’re surprised we’re doing this, our stability policy allows us to update the stable style in the new year. This minimises disruption while keeping the door for improvements open.
We just released Black 23.1a1 with the first draft of the 2023 stable style, please try it out and let us know your feedback and concerns.
happy january
Yeah that sounds like a good plan
Some kind of build CI or pre-commit check at least so we can catch it before release.
@tulip sleet I'll hold off pushing this ulab thing until 7532 is merged
i am mostly ok with the change, only silliness, it seems to add an extra blank blank line before methods/functions that have a # comment before the def line.
we might consider excluding the upstream test .py files, if they are not already excluded... will look at that
ok, never mind, it's not methods, it's that top-level functions are separated by two blank lines, not one, and it has nothing to do with comments
I am impressed it moved this """ onto the next line and preserved the comment style:
//| :param int rotation: The rotation of the display in degrees clockwise. Must be in 90 degree increments (0, 90, 180, 270)
//| """
One motivation is what @deshipu said, but I'm not sure we're consistent. If you never use wifi.Monitor(), then why create it (saves RAM)? But there are other things where we just made it static.
Another motivation is garbage collection. We either have to write an explicit gc routine if the object is in static storage, to have the gc marker mark any Python objects in that object, or we have to include in the ROOT_POINTERS list.
A third reason is whether the object needs to save state...
Thank you for handling this! I saw it just before going to to sleep.
There might some argument that we should not mess with the upstream MicroPython Python code, but these are innocuous changes that merging should handle easily, so I think it's fine to go ahead.
Processing the inline comments via black is my doing and I feel like it ended up working pretty well.
it did; I thought it was black only that fixed up those files, but it's the whole pre-commit process, yes?
the tools/codeformat script does a number of sequential steps
one of them involves running a separate script, tools/black_bindings.py. It changes the file from being "C with Python inside //| comments" to being "Python with C inside ##| comments", blacks that Python file, then does the reverse comment-swapping to create its final output
I should also contribute the script that does the swap but doesn't run black; this lets you use normal Python indenting and syntax highlighting while working on the in-line docs
you could put that in tools/
I'm not sure how many folks would discover to use them, but it doesn't mean I shouldn't put it there
Hi Dan:
That's great! Thanks for all the help. I'm going to work on the PR for the
circuitpython-org and on the website over the weekend.
bye for now,
On Tue, Jan 31, 2023 at 11:33 PM Dan Halbert @.***>
wrote:
Merged #7530 https://github.com/adafruit/circuitpython/pull/7530 into
main.—
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython/pull/7530#event-8406292438,
or unsubscribe
<https://github.com/notifications/unsubscr...
https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/mpy-cross/ is hard to navigate. Create subdirectories for each architecture.
Yeah, I just named the M5Stack boards according to the names they used in their shop.
Hi all, I wrote another doc about async, this time with a different focus. As always, I would love to hear your thoughts about it.
https://docs.google.com/document/d/1xlzTEdP8ovTtz5Sx8voP8R9M8fY88LuyiWBYu0muiRc/edit?usp=sharing
Lightweight Asyncio Support for CircuitPython Goals Allow drivers to schedule a callback from an ISR into the main async loop in a way that is composable with other drivers/libraries and does not depend on a specific asyncio module implementation. Allow native libraries to define Python-callable ...
@onyx hinge your ulab PR just needs a make translate
When using a HID keyboard and the code stops (crash, end code or reload) while a key is pressed, the key will remain pressed until the board is fully reset, or the code happens to release_all() or something similar.
Is it possible to "empty" the HID output reports on code end ?
Such a script will hold the space key until the board is reset.
import usb_hid
from adafruit_hid.keyboard import Keyboard
from adafruit_hid.keycode import Keycode
keyboard = Keyboard(usb_hid.devices)
...
@timid bolt we have a "light sleep" until interrupt function here: https://github.com/adafruit/circuitpython/blob/135a2ba681d5cf1ef5330ec7380189a9ebc9c111/supervisor/port.h#L89-L91
thanks for running that @tulip sleet ! I just got back
i realized today you would have gone out; np
@jaunty juniper @still zephyr I mentioned your issue to one of our Learn devs. A suggestion for now is to try enabling "Reduce motion" in your Learn Account Settings. This should stop the guide preview GIFs from animating. That said, it also stops all of the other non-critical GIFs from animating as well. There are a set that still run because they are considered "instructional". If nothing else, enabling this setting could tell you whether that is your issue or not. Log into your Adafruit account, go to "Account" next to your name in the top right, click "My Account" from the dropdown, then click on the "Account Settings" tab (in the black bar above "My Adafruit"), choose "Accessibility" from the left menu list, and then check the box.
Thanks I will try it. Thank you very much 🙂 I have already changed the settings,
Excellent! Let me know how it goes.
When native code crashes (e.g., hits an assert) what is meant to happen in the REPL? Should it just hang or can it print the assert 🤞🥺
it resets and goes into safe mode. But asserts are not normally enabled in non-DEBUG builds
there are various reasons shown for safe mode
some crashes cause a hard reset, some do not. It also depends on the underlying layer: e.g., ESP-IDF may hard-crash due to watchdog timeouts
Looks like I'll need a jtag adapter. Do you have any recommendations on which one to get?
j-link
verygood sw support
it comes with a cable, but get this breakout too: https://www.adafruit.com/product/2743 -- very convenient
any thoughts on this one https://www.adafruit.com/product/3839
it doesn't have as complete coverage of the chips we use
there are more chips listed on black-magic.org than on the adafruit product page 🤷♂️, but I'll try to get the first
they have added support for more chips, but the J-Link folks are extremely good at covering a wide range of chips.
J-Link is kind of the "standard". Expensive for commercial use, but the edu models are not crippled
they also respond well to bug reports
on the other hand, a dap programmer is like $10, and you can flash a black magic probe on a $2 blue pill board
The edu models also recently came back in stock but at a price increase ($19.95 —> $38)
From Segger directly that is
I recently picked one up
STlink's and clones don't work properly on non-ST boards.
stlinks are ancient
at segger it's now $60, which is the price of the old full-sized Edu
we have things like dapcat and daplink now
some people have been tempted to try to debug SAMD's with them, no go
Wow just noticed they’re $60 now
still $38 at our store, so buy 'em while they're hot
I programmed my samd21 ones with them successfully
Guess I lucked out getting it for $38
one weird thing with them is the vcc pin is output, not input, so you don't want a separate power for the device, like with jlink
or simply don't connect the vcc
It is interesting how the price of things is just jumping seemingly month to month
it's the invisible hand of the market
“The market”
it's still a market, even if it's a monopoly
I know, just smoke and hand waving to make it seem more complicated to keep prices low
On one hand, I at least have tools now to debug properly
CircuitPython version
Adafruit CircuitPython 8.0.0-rc.1 on 2023-01-30; Kaluga 1 with ESP32S2
Board ID:espressif_kaluga_1.3
UID:C7FD1AB0FD6D
Code/REPL
# SPDX-FileCopyrightText: Copyright (c) 2021 Jeff Epler for Adafruit Industries
#
# SPDX-License-Identifier: Unlicense
"""
This demo is designed for the Kaluga development kit version 1.3 with the
ILI9341 display. It requires CircuitPython 8.
To fix the MemoryError when creating a Camera object, Pl...
are these debuggers expensive because of ARM licensing?
I’d guess that and increases supply chain costs
so would a daplink work on all the boards? I've seen CMDIS-DAPLINK that do JTAG/SWD (and using openocd) from AliExpress for < $10
You could probably do most boards I’d imagine
@timid bolt one thing to note is that we haven't succeeded in getting gdb to work all that well via J-Link or openocd on the Espressif chips. We tend to just use print statements to UART, via the ESP_LOG macros. There is a very limited number of hw breakpoints on these chips, and there seem to be other problems as well. gdb via J-Link works quite well on SAMD and nRF. Not sure about i.MX.
i am not sure that is it -- it's a very software-intensive support thing, and they support thousands of chips. Just look at the J-Link release notes.
not inherently, just how well it works or not
does j-link work for rp2?
It seems NXP likes things well supported so hopefully that ends up being the case 🙂
Yup
Generic M0+ last time I tried
They may have added it with the most recent update though
you can also use one RP2040 to debug another -- they set that up, i think via openocd
Yeah, that’s true
You don’t even need another RP2040 to debug, you can use the other core to run the debugger
if you don't want to buy anything now, you could just try the RP2040 debug stuff, which the creators use themselves, and for testing aysncio stuff, that should probably be fine
wow, is there a link to this rp2040 debug stuff?
Nice thing about the RP2040 is being able to run your debugger on the same chip without really affecting resources too much
websearch for "picoprobe", and I htink skerr is talking about https://github.com/majbthrd/pico-debug ... but the repo is archived ?!
Straight from the Adafruit blog 🙂
Oh wait
Darn I thought it was different
Maybe it still works 🤔
I love finding comments that give you hints that the code you are looking at was copied from elsewhere (which is exactly why I noticed it). OnDiskBitmap has the line // load the wave
Lol
picoprobe sounds great! I guess I'll try that before ordering a debugger. Thanks!
Well that window closed fast, looks to me like Adafruit just adjusted their price to match 🙂
Wow, that fast
almost as if someone was listening...
I don't know but I image that Segger would notify their resellers of the price increase and perhaps require them to match it
I think I saw it at $38 when I first looked on the segger site, and then it went up!
yikes, it was still sitting in my cart. I guess I shouldn't discuss these things here. 😅
the "pico-debug" project is not super convenient because it seems it consumes the usb port, so then I can't also run the python repl
we didn't rat on anyone 🙂
i think it's a coincidence
I guess I could tell CP to use the hardware uart instead of usb for "stdout", but I think I should just bite the bullet and get a hardware solution. Then I'll be set up to work on multicore CP 😉
The change happened around 5pm, likely when price changes/new stock would regularly be pushed
btw, just curious, what hardware do you use for debugging risc-v?
print statements
OpenOCD has limited RISC-V support
Nothing Espressif though
Mostly just major RISC-V platforms
does the j-link adapter work with OpenOCD/RISC-V?
the "driver" stuff mentioend there is Windows-specific. I don't think there'd be any issue on Linux
tbh, I'm usually fine with printf debugging, but in this particular case I'm getting random crashes, (probably in the gc I guess,) so a debugger would be handy
which board /chip is it?
adafruit_feather_rp2040
i have not actually had a bad enough bug to have to use gdb on the rp2040 yet, so I can't say what the best choice is. But I think the openocd with another RP2040 will work fine
Don't throw the exception and return zero. This addresses the incorrect behavior in the issue, and doesn't cause other problems because a 0-length buffer is still unusable.
@timid bolt I'm a fan of pyocd. i think it does have rp2040 support already
Got a GIF loading! 🎉 now to get it to display
YAY
Automated website update for release 8.0.0-rc.2 by Blinka.
New boards:
- brainboardz_neuron
with the imageload library?
Trying in the core for animated GIFs in displayio for speed.
with bitbank's C library?
Yup
I ended up ordering a pico w for 'picoprobe' debugging. Funnily enough the swd cables and headers cost more than the board!
Adafruit doesn't seem to have their own pico w board. Is one in development?
there may be contractual limitations on the driver
what do you mean by their own pico W ? An RP2040 board with the CYW43439 module ?
although, this seems OK https://github.com/georgerobotics/cyw43-driver/blob/main/LICENSE.RP
I don't know if the module is available for 3rd parties
and the price is probably not as good as for the rpi foundation
you can buy some dev board forms of the module, but yeah not sure about the module itself
oh I see, the pico w is just a regular pico with a CYW43439 bolted on. I was wondering what all this #ifdef CYW43 in the code was about. 😀
yeah that's the metal box that is not on the regular pico 😉
There’s just magic smoke under it is all
CYW43439KUBGT modules on digikey $7.73 quantity 1, $4.20 quantity 1000 ...that's double or more of espressif modules
Yuuuup
RPi pays like $1.80 or $2 for each of the CYW43 modules because they bought like half a million
Adafruit would be hard-pressed to do an under-$10 board, but maybe a $20-$25 Feather
I barely eeked out a $7 RP2040 board
but dang, a BFF with u.FL would be pretty sweet :-p
Back when the RP2040 was $0.50 a piece on a 500 piece reel
Goood times
glares at $500 reels from Digi-Key
At least Adafruit gives us a price break on 100+ qty
So did the RPi foundation pay to have every RP2040 ever made, then sell to distributors, or do distributors order them from the fabs themselves?
the former
Ahh… imagine standing in a warehouse with every RP2040 ever made, before they scatter across the world…
there were multiple batches
Sadly their blog appears to lack search…
In the REPL, if I start typing in multiline code, then it automatically indents lines, which is nice. However if I paste "pre-formatted" code into the REPL, the auto-indenting messes up the proper indenting. Is there a way around this?
paste mode with ctrl-E
note, it isn't the foundation that does the rp2040 and raspberry pi SBCs. There is a commercial entity, raspberry pi trading for commercial stuff
Ohhhh…. I didn’t know this
also raspberrypi.org vs raspberrypi.com
I didn’t realize there was a split
they've been more formal about it recently
Makes sense
Ok, initial code upload is there. After further testing, we have fixed the CORS issues and I have updated tinyuf2 (https://github.com/adafruit/tinyuf2/pull/278, https://github.com/adafruit/tinyuf2/pull/279, and https://github.com/adafruit/tinyuf2/pull/280) so it now uploads the bootloaders to amazon S3 on new releases, which makes it available to downloads.circuitpython.org.
Is there any relatively easy way to see a diff between the state of two different builds linked on S3? I'm attempting to find the differences between these two
state ? what do you mean ? you can do a diff on github
Finally got an uncorrupted backtrace:
? Backtrace: 0x40038b0b:0x3ffdcff0 0x400396ed:0x3ffdd010 0x4002cfdd:0x3ffdd030 0x4002cff1:0x3ffdd060 0x4002d01e:0x3ffdd080 0x4003ad31:0x3ffdd0a0 0x400f4e18:0x3ffdd0c0 0x400f4e96:0x3ffdd0e0 0x400f4ef9:0x3ffdd100 0x400f3d90:0x3ffdd120 0x400f3a54:0x3ffdd140 0x400b7600:0x3ffdd180
got ['0x40038b0b', '0x400396ed', '0x4002cfdd', '0x4002cff1', '0x4002d01e', '0x4003ad31', '0x400f4e18', '0x400f4e96', '0x400f4ef9', '0x400f3d90', '0x400f3a54', '0x400b7600']
/...
in git in general
@crimson ferry thank you for that backtrace!!
by state, I'm hoping for a list of commits and/or a list of which files have differences and what the differences are.
I know git can probably make this comparison but I don't really know how to do it beyond a new branch like for a PR compared with the current main.
(starting at https://github.com/adafruit/circuitpython/compare)
Yes! thank you.
do you know if it's linked in the front end anywhere? I can bookmark it if not, but If I know where to find it I can probably remember the path to it
even the github docs says to "append /compare to your repository's path" so... 🤷
Anyone know have thoughts on memory structure alignment in a library Vs main code base?
Short example is in the gif library is does (summarized) ‘memset(gif, 0, sizeof(GIFIMAGE))’ where gif is a passed pointer to the gifimage variable in the python object. But that line is overrunning it’s memory and wiping my file object pointer.
If I run the exact same line of code in my shared-module .c it works properly.
Or offhand does someone know what memory alignment is used?
(If this doesn’t make much since I’ll try to post a gist later)
I have narrowed the version a bit further. 8.0.0-beta.1.uf2 which is the first build linked in S3 after 7.3.3 exhibits this behavior as well.
There are a fairly large amount of commits between those two. In the coming days I'll work on bisecting between them to try to find the commit where the behavior changes.
Changes from rc.1 are pretty minor
I have reworked the API. There are still some changes to be made in the underneath implementation and a few checks to be run but the API will largely remain the same and I'd like to get your opinion on it.
I did not have long to look at this but I am wondering if there is something with the memory allocation that changes (in displaycore.c I think?). I was(am) a rookie about memory allocation for CircuitPython when I did that and wrote that and mostly copied it from the RGBMatrix code. Just an idea of where you could look first.
🎉
Fix for issue #7419. According to the espressif docs at https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32c3/api-reference/peripherals/rmt.html;
"The RMT has four channels numbered from zero to three. The first half (i.e. Channel 0 ~ 1) channels can only be configured for transmitting, and the other half (i.e. Channel 2 ~ 3) channels can only be configured for receiving."
This fix for peripherals/rmt.c ensures that a proper channel is returned for either mode.
I will look if you post the gist.
Hey this is cool, thanks @MicroDev1 and @glenn20 for picking it up and running with it!
(also g'day to @tannewt and @dhalbert !)
Did we lose a socket?
import time
import wifi
import socketpool
from secrets import secrets
time.sleep(2) # wait for serial
wifi.radio.connect(secrets['ssid'], secrets['password'])
time.sleep(0.1)
print(f"{wifi.radio.ipv4_address}")
pool = socketpool.SocketPool(wifi.radio)
socks = []
while True:
socks.append(pool.socket(pool.AF_INET, pool.SOCK_DGRAM))
print(f"{socks}")
[tio 15:56:54] Connected
192.168.6.205
[<Socket>]
[<Socket>, <Socket>]
[<Socket>, <Socket>, <Socket>]
Traceback (most recent call last):
File "code.py", line 15, in <module>
RuntimeError: Out of sockets
web workflow disabled: espressif correctly shows 8, I thought we had 4 in raspberrypi
how do we have enough for web workflow:
https://github.com/adafruit/circuitpython/issues/7333#issuecomment-1349491317
Clarify the text about releases on board download pages.
I tried testing this locally on Ubuntu 22.04 per the README, but could not get a working version of ruby. The regular package does not have OpenSSL support. rvm compiles fail for various versions, and snap installs don't work either: the compiles of statemachine either have version issues or gcc compilation issues. It was kind of a nightmare. Perhaps if someone has a setup that works they could pull this and see that the comp...
Not sure if this is something worth to write an issue or not, but this code..
Adafruit CircuitPython 8.0.0-rc.1 on 2023-01-30; Adafruit Feather RP2040 with rp2040
>>> import displayio
>>> bitmap = displayio.Bitmap(-40,40,1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
MemoryError: memory allocation failed, allocating 10485600 bytes
>>>
🤔
I already have the poster and am ready to hang it 
🎊
is it documented to accept a negative number there?
I guess not, :), I stumbled upon this after trying to set a tilegrid.
width (int) – The number of values wide
arguably, it could be a doc bug
good point
Could raise me a nice ValueError:)
Could you open an issue? It should validate the args to be >0. Thanks.
Yes. Will do 🙂
CircuitPython version
Adafruit CircuitPython 8.0.0-rc.1 on 2023-01-30; Adafruit Feather RP2040 with rp2040
Code/REPL
>>> import displayio
>>> bitmap = displayio.Bitmap(-40,40,1)
Behavior
Traceback (most recent call last):
File "", line 1, in
MemoryError: memory allocation failed, allocating 10485600 bytes
Description
- Error while using the REPL, however similar behaviour was observed running a script
Additional i...
Not sure this really affects us because I think we typically have used API tokens as secrets where applicable, but just a heads up the $GITHUB_TOKEN is moving to read-only default: https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/
Compared to most boards / examples, this is using two less used features:
StateMachine.background_writeandbitops.bit_transpose.
Would either of these spend time in a tight loop and freeze out USB task handling?
Do you feel this is a showstopper for 8.0.0?
206 /* Remove a free block from the free list.*/
207 static inline __attribute__((__always_inline__)) void remove_free_block(cont rol_t* control, block_header_t* block, int fl, int sl)
208 {
209 block_header_t* prev = block->prev_free;
210 block_header_t* next = block->next_free;
211 tlsf_assert(prev && "prev_free field can not be null");
212 tlsf_assert(next && "next_free field can not be null");
The esp-idf allocation heap is corrupted, su...
I don't think we really use it, the exception being adabot, but adabot uses tokens in secrets instead.
The only exception is the new replacement action in the core, but it gets write access for issues explicitly
Also doesn't affect existing repos
it wouldn't hurt to report it as an issue. Probably carefully choosing the incorrect numbers could cause a hardfault as well, similar to https://github.com/v923z/micropython-ulab/issues/576
This backtrace may reflect a DEBUG=1 error only, as I was unable to get this to work at all with DEBUG=1. Or perhaps it's an earlier indicator of what the other error is.
Hi, I am watching John Gallagher video on how to setup a PicoW for his class ( https://www.youtube.com/watch?v=ND5UhTQlfWw&t=308s ). And he goes on listing all the library he will use and how to copy them from the bundle.
So I was wondering if there was a way for him to provide a mini-bundle like the learn guide are doing, to have a single zip file that contain everything he need for his student.
If not possible as such, maybe he could have a learn guide (or user page on learn) and a demo code that use all those library for the "system" to generate that zip file for him.
Also, if you know his Discord handle, maybe you could ping him about your response?
Start here to learn CircuitPython on a Raspberry Pi Pico or Pico W. We'll add CircuitPython to the Pico board, copy over the lib (library) files that we need to complete a series of assignments using a variety of sensors, motors, neopixels, and input devices. And we'll download the free Mu IDE so we can create, edit, and save CircuitPython progr...
He could always just make up a .zip by hand. He is @JohnG here and is also active on Twitter as @Gallaugher. Note the "U" in his name.
The "problem" is to have obsolete library version if doing that. Not sure how the "all project files" work behind the scene in the learn guide, but that use case of user provided list of file was discuss at the time.
The .zip file is generated at download time (maybe it's cached a little bit), but yes, it would be updated as versions change. How it works is pretty specific to the Learn Guides. One could imagine a web-based "zip creator" that had URL's specified for it that were fetched individually and then zipped up.
I don't think that the script used in the learn guides is available anywhere right now ? But it would really be easy to write, even using circup (which can be run on local directory instead of a drive, as long as there's a valid boot_out.txt in it)
circup --path some_directory install --auto
I also made a web "bundler" where you can drop a file and get a zip with it and all dependencies
https://neradoc.me/bundler/
Learn uses ruby behind the scenes
Thanks, I'll stop solving a problem that @broken hedge did not even express, but I think there are great solution above.
The video is still useful as is, because going to the bundle and downloading what you need is good knowledge.
Would either of these spend time in a tight loop and freeze out USB task handling?
I looked for that, as it's the first explanation that occurred to me too.
background_write has one place where it loops (based on the status of an ongoing DMA transaction), but it calls RUN_BACKGROUND_TASKS every loop.
bit_transpose is a tight loop, but it runs with interrupts enabled:
static void bit_transpose_8(uint32_t *result, const uint8_t *src, size_t src_stride, size_t n) {
for ...
Using the build-mpy action could be applicable if you also wanted to compile .mpy files from some while you're at it. Making zip files for projects automatically is its goal!
You would just have a repo with the files. If you didn't want to compile any .mpy files at all you should still be able to use it with:
on:
release:
types: [published]
jobs:
upload-mpy-zips:
runs-on: ubuntu-latest
steps:
- name: Checkout the current repo
uses: actions/checkout@v3
with:
submodules: true
- name: Run MPY Action
uses: adafruit/build-mpy@v1
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
circuitpy-tag: "7.3.3"
mpy-manifest-type: "exclude"
that doesn't retrieve the dependencies though ?
No, you're right, it doesn't. I made the actions assuming projects would add dependencies within a lib/ folder in the repo. But no, no auto-fetching deps.
That way dependencies were static (it wouldn't accidentally pick up an API-breaking change)
Slash that seems like where circup already is the best solution 😄
CircuitPython version
Adafruit CircuitPython 8.0.0-rc.1 on 2023-01-30; Raspberry Pi Pico W with rp2040
(but same all the way back to the first raspberrypi build)
Code/REPL
import time
import wifi
import socketpool
from secrets import secrets
time.sleep(2) # wait for serial
wifi.radio.connect(secrets['ssid'], secrets['password'])
time.sleep(0.1) # wait for raspberrypi IPv4 to become valid
print(f"{wifi.radio.ipv4_address}")
pool = socketpool.S...
CircuitPython version
Adafruit CircuitPython 8.0.0-rc.2 on 2023-02-02; Adafruit NeoPixel Trinkey M0 with samd21e18
Code/REPL
# SPDX-FileCopyrightText: 2021 Kattni Rembor for Adafruit Industries
#
# SPDX-License-Identifier: MIT
"""
Blink example for boards with ONLY a NeoPixel LED (e.g. without a built-in red LED).
Includes QT Py and various Trinkeys.
Requires two libraries from the Adafruit CircuitPython Library Bundle.
Download the bundle from c...
Thonny writes files by sending invisible Python statements to execute to the REPL. We shouldn't hard-crash, but given the size of the code files, I can see that we might run out of RAM in this case. However it should not hard-fault.
You can work around this for now by just using another editor or copying the files directly (as you may already know).
tested and works great :)
Thank you for the updates! @glenn20 and @nickzoic please let me know what you think of my API suggestions.
//| """A packet retrieved from ESP-NOW communication protocol"""
I'd move this all to common-hal
Will this list grow forever? Maybe we want scanning like bleio instead?
//| """The time in milliseconds since device last booted when the packet was received"""
If the peer has e then you could do:
//| peer.send(str(i)*20, True)
Removed in a newer version as the python code can choose to maintain it.
Not sure what exactly you meant here. Only the sender needs to know the peer.
@jepler can we increase this? But as mentioned, I'm confused why web workflow + other stuff works at all
This three-socket limit is true only of SOCK_DGRAM sockets. If I remove pool.SOCK_DGRAM, I can create five sockets (without web workflow).
I see what you are suggesting here with auto-add peer to peers list and peer.send().
Here are my thoughts:
- My concern is that most folks would approach this with the perspective gained from
esp-idfdocs and that is the reason I don't want to diverge away from theESP-NOWC implementation. Also, since this is a esp specific module. - How to handle
e.peers.remove(peer)and then apeer.send()?
That's curious, I went with DGRAM assuming it would have the lowest resource requirements.
In the ESP-NOW packet the message comes after a wifi_promiscuous_pkt_t and a espnow_frame_format_t.
Currently only the rssi is parsed from wifi_promiscuous_pkt_t, thoughts on exposing it entirely as a wifi.Monitor packet?
HI David. Glad you found the video useful! Yes, I did want my students to be comfortable exploring the original "lib" files, finding what they need, and copying these over. I encourage students to work with components that we don't cover in class, so my hope is that this helps them understand how to work with libraries they need so that if they use something we haven't covered, they'll be able to dive into the libraries & get what they need in the future. This might also help them decide which libraries they can delete if they don't if they run short on space. There are also some cool tools out there like circup, which I haven't used yet, but that seem really great at keeping "lib" directories up to date. Others might have more insight on circup. Cheers! https://learn.adafruit.com/keep-your-circuitpython-libraries-on-devices-up-to-date-with-circup
Don't worry, I know CircUp and Discotool. I am not new here, but I still discover things. It is just that some times ago, before the zip files from learn guide even existed, I described that need to get just the files you need rather than to describe getting the full zip, copying over the mpy files and folder. I was testing many guide to see if they were still working with a new CP version, and picking the library was the slowest part of the process.
I have only watched one or two videos, but there is really a lot of content. That's great.
well that's weird. (local build but all should be as normal)
Adafruit CircuitPython 8.0.0-rc.1-12-g80d961292-dirty on 2023-02-03; Adafruit Feather ESP32-S2 TFT with ESP32S2
>>> import wifi
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
espidf.IDFError: Invalid argument
I have some out of date submodules, maybe that's it
I found that these changes improved i2s sound playback on esp32s2 though honestly it was still kinda marginal with pops and crackles still occurring during wave file playback from in-device flash. Weirdly, connecting to the device REPL makes it markedly worse.
@onyx hinge interesting PR -- I will defer it past 8.0.0 if that is OK with you
@slender iron how do you load the bangle.js device once you've got a build from your PR branch? Does their 'app loader' page allow you to select the firmware file, or load via some other means?
I used nrf connect on android to load it
FOSDEM 2023... It is so close (in less than 12H) and I am so unprepared (trying to select what I want to see). Anybody from the community going there?
Grand, tnx! Have a good one. H
Hi hamishcunningham. We have similar problem. We made our own board with ESP32-S3 (FN8 Model with 8 MB Flash internal). After looading bootloader.bin (and many different *.bin files) we get the following messages from COM port. We use Windows CMD for esptool.exe. How did you solve the problem?
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x40043ac8
SPIWP:0xee
mode:DIO, clock div:1
l...
resolves #7516
Tested successfully with:
Adafruit CircuitPython 8.0.0-rc.2-dirty on 2023-02-03; Adafruit LED Glasses Driver nRF52840 with nRF52840
Board ID:adafruit_led_glasses_nrf52840
UID:4D43A3F73BE5AE3A
Does anybody has problems bulding the packages for a library release?
This adds the Hack Club Sprig to CircuitPython. It's a Pi Pico-based handheld game console.
Depends on https://github.com/pidcodes/pidcodes.github.com/pull/815
For PyPI?
Everything should be working within the release workflow, what issue are you experiencing?
Ah, I looked at your repo you submitted to the Community Bundle and see the error. It looks like a permissions error - the Adafruit org might have a setting on by default that you may not. The solution is probably to explicitly allow permssion to upload a release asset.
It does look like (I think) you have a GitHub token with the correct secret name in the repository. Does it have the repo scope, with write permissions?
I think for fine-grained tokens its "Contents", and for classic tokens it's "repo" (or the finer "public_repo" since your's is public)
Ok going to look into that. I guess is in the library setting, right?
Tokens can be found in your settings under "Developer Settings", but the secrets can be found in the repository settings. You can't see a secret value after adding it, so you're best bet is to generate one with the correct permissions and then add that. Alternatively, you should be able to modify the workflow to use $GITHUB_TOKEN and add permissions to that in the YAML file, but if you want to keep it consistent with the Adafruit-style, use the other way.
@still zephyr 
Thank you very much I will take a look at that 🙂
Thank you very much for your help, it worked 🙂 I really appreciate it !!!!!!
No problem! Glad it worked!
I'm trying to keep a record of common issues like this so thanks for making me aware of it!
Leaving this comment her for posterity:
Mu can be a culprit sometimes. When I start Mu, it seems to write something to the CIRCUITPY filesystem every few seconds - causing the reload. @kwpodolsky You've probably moved on, but in case you still have your set up, can you kill Mu and see if the reload still happens?
I am probably missing something fundamental about types in C. This this code / behavior doesn't really make any sense to me. Does anyone know why this evaluates to false, or what could be an appropriate change to make in order to have it evaluate to true like it should numerically?
uint32_t negative_val = -1;
if (negative_val < 1){
// This does not print, condition evaluates to false seemingly
mp_printf(&mp_plat_print, "negative_val is < 1:\n");
}
u means unsigned
I am assuming that uint32_t means unsigned int 32 bits. And it does make sense that -1 would not be a valid value for an unsigned int. But it seems to allow the value to be stored in it none the less. If you print it's value with %d string format it will print out the -1 showing that it is indeed storing that value. But then when you go to make a logical expression with it things get very weird.
why does this line suceed then? shouldn't it be some kind of error for type / value mismatch?
uint32_t negative_val = -1;
yeah that's C, it converts it to a positive value
C is always trying to be "helpful"
and %d is signed, while %u isn't
The short answer would be the only valid value you can check on a uint32_t would be 0. The concept of -1, -2, etc. does not even exist for a uint
I believe the value actually stored will be the 2-complement
Anyone offhand know of an example of a native class creating another native class in code?
or something like that
It doesn't seem like it's flipping to positive though.
uint32_t negative_val = -1;
mp_printf(&mp_plat_print, "negative_val is %d:\n", negative_val);
This prints
negative_val is -1:
The %d auto converted it back I believe
use %u
auto converted back to what though? if -1, -2 etc don't exist as concepts I don't understand how it could have done that?
Thank you! this one printed negative_val is 4294967295:
so %d flips that back around then I guess
C really just treats everything as bytes in memory. Your code tells it how to interpret that byte in memory. There is no type safety involved.
So if memory address 0x1000 contains 0x20
%c will return a space
%d will return 32
%x will display 0x20
There is no meaning to it. So when you say uint32_t tmp = -1 the compiler auto converted -1 to uint32_t because that is what you said it was. Hope that makes some sense
Okay I think I'm following what is happening with the variables now at least. Thank you both!
The next, more practical question though. These areguments: https://github.com/adafruit/circuitpython/blob/5f43a63a701447595e5647621769e1ca9289ac85/shared-bindings/displayio/Bitmap.c#L65-L67 are all uint_32.
I'm trying to add validation that will raise an error if the user passes in a negative value. Since the logic can't be trusted when the values are negative, my next thought is to make these arguments into signed int's so that they can exist as negative and behave as expected. But that feels kind of awkward since my ultimate goal is specifically disallowing negatives.
despite feeling awkward does that seem like the correct / only way for us to actually validate that user passed a positive value successfully?
So in that case the get_int returns a signed value. if you look under the hood. Those variables are converting it to unsigned
you can take them as ints and then convert back to (uint32_t) when you pass them later ?
actually, is there a test for positive integers ?
for two's complement, just test the most significant bit
I thought Dan made some common checks to save on translation space that does it all at once. Not sure if this was one of them
I think that would work by the way
uint32_t width = mp_obj_get_int(all_args[0]);
if( (int_32_t) width < 0) ...
@lone axle use mp_arg_validate... functions defined in py/argcheck.c
Hmm my example on the issue in the IS31 code is being blocked when I try to post it. Not sure why
blocked here ? on github ?
No discord blocking message... But just noticed it exists in that code as well
it got filtered out due to a string that it interpreted as a bad word. I can see it in the "recycle bin"
yeah that bot goes a little too far
I think I missed the ticks to mark it as code. Not a big deal. Just was wondering
I think the tick marks may not hav ehelped in this case. It found a substring in the code that it didn't like. I think it would filter it whether or not it was in code. But not certain.
nope, didn't like it with the ticks
This change includes validation for arguments to Bitmap constructor, fill(), __get_item__ and __set_item__ to raise errors if users pass in negative values for things that can't really be negative.
How to return a str object from a QSTR?
qstr_str(qst)
I found this:
mp_obj_t mp_obj_new_str(const char *data, size_t len) {
qstr q = qstr_find_strn(data, len);
if (q != MP_QSTRnull) {
// qstr with this data already exists
return MP_OBJ_NEW_QSTR(q);
} else {
// no existing qstr, don't make one
return mp_obj_new_str_copy(&mp_type_str, (const byte *)data, len);
}
}
so I think MP_OBJ_NEW_QSTR(q) can do the job
it works!
The only real difference between signed and unsigned ints is the meaning of comparison operators (< and >). All other operations are the identical.
Re-opening based on:
#help-with-circuitpython message
and issue discussions on Discord:
https://github.com/adafruit/Adafruit_CircuitPython_Requests/issues/126
#help-with-circuitpython message
In displayio_bitmap_obj_blit, the use of int16_t truncates the high bits of the input. So if the caller passed 65,537, it would actually get interpreted as 1. You should probably replace all these occurences with int32_t or mp_int_t.
Initial proof-of-concept of native animated gif support for displayio. Rough at the moment but it works with the below example code. A few decisions should be reached on how to handle memory though the main performance issue seems to be blitting so many pixels to the screen vs any gif processing. The current code loads the gif from disk (like OnDiskBitmap). It could be read from memory but I'm not sure if that will speed the process up noticeably.
The library used is the [AnimatedGIF Libra...
I suspect there may be some marginal timing (perhaps variable) where sockets aren't ready at code start, and the perception of persistence is just the code not working. but once it doesn't work, it will continue to not work until some delay is added and the device is reset.
This works after a reset and ongoing, but if STARTUP_WAIT = 0 it will fail with the OSError: (-29312, 'MBEDTLS_ERR_SSL_CONN_EOF').
import wifi
import time
import socketpool
import ssl
STARTUP_WAIT = ...
A few comments on various questions/performance/future ideas.
Memory usage
Currently a Bitmap object is allocated to store the current decoded frame. This allows the user to access the pixels if desired. It also allows GIFs with transparency to work. My guess is without a current frame in memory to skip transparent pixels would require very complicated dirty area handling that likely is slow and would no longer allow the user to access the current frame easily.
Palette
The B...
Tested on a the KB2040.
import displayio
from adafruit_st7789 import ST7789
import time
import board
import busio
import gc
displayio.release_displays()
start_memory = gc.mem_alloc()
spi = busio.SPI(board.SCK, board.MOSI, None)
spi.try_lock()
spi.configure(baudrate=31250000)
spi.unlock()
tft_cs = board.D10
tft_dc = board.D9
tft_rst = board.D8
display_bus = displayio.FourWire(
spi, command=tft_dc, chip_select=tft_cs, reset=tft_rst,
baudrate=312500...
Some performance statistics, all done on a KB2040 with SPI at 31,250,000 Mhz
120px wide 93px high
- Decode and display: 0.065ms / frame (15.3fps)
- Decode only: 0.0074ms / frame (135fps)
- Display only: 0.058ms / frame (17.2fps)
240px wide 188px high
- Decode and display: 0.253ms / frame (3.9fps)
- Decode only: 0.0225ms / frame (44 fps)
- Display only: 0.233ms / frame (4.3fps)
You are not reading the time between the frames from the file? I see it's hardcoded in the example code. This may be a problem with some files, which use different delays with different frames.
You are not reading the time between the frames from the file? I see it's hardcoded in the example code. This may be a problem with some files, which use different delays with different frames.
Good point. The library does return that information. I will look at adding it in as an optional parameter to play_frame()
I wonder if play_frame could just return the delay to the next frame.
I wonder if play_frame could just return the delay to the next frame.
It could but right now it is returning success, success/last frame, or failure. It's probably helpful to have both returned in some way.
@jepler Is there something we need to wait for when starting up the co-processor?
I have prepared this firmware following the tutorial as best as I could. Please let me know if there are any issues and I will try to resolve them as soon as possible. The Pysquared board is a satellite flight computer developed by Bronco Space at Cal Poly Pomona. The board utilizes an RP2040 and is heavily inspired by the PYCUBED
hyde00001 confirmed on Discord that a delay at the start of the code works as above, once the board is then reset.
BroncoSpace is developing another circuitpython board called the pysquared. This board utilizes the rp2040 and is heavily influenced by the pycubed. The files added reflect the firmware now operating on an rp2040 currently
@kmatch98: Probably not allowed to ask this question here, but I could not find any other way to get in contact with you.
I see that you are running your screen at 10MHz, and still on the video it looks like you are not experiencing any flickering.
I have a RGB LCD that I am trying to use with a ESP32-S3 16MB Flash, 2MB PSRAM, but I am experiencing visible flickering, especially when running at low DCLK. Do you have any tips or tricks to get rid of it?
It’s been a while since I worked on this so I am rusty on some of the details. From what I remember unfortunately there are many different ways to cause flickering.
May be helpful if you add a video so folks here might have ideas. Also, are you actually running CircuitPython or are you just using the ESP-IDF example code? I do know there are quite a few LCD display based peripheral code updates in the latest version of the ESP-IDF, so whatever observations you have may be affected by whi...
One more thing I remember is that with using a single buffer I was getting tearing when updating the buffer (depending upon what you are displaying, this may appear as flickering). The original version of the ESP-IDF did not have a way of preventing tearing, the display was set to just automatically redraw at the fastest rate possible. I think it was designed to trigger a redraw interrupt after the screen was redrawn.
I had to turn off the interrupt and change the trigger for redrawing so...
Does anyone know what hardware goes with the MCP2515 library? https://github.com/adafruit/Adafruit_CircuitPython_MCP2515 The description says it's a CAN bus controller. So my best guess was maybe it could be used with the CAN M4 devices like https://www.adafruit.com/product/4759. But I didn't find any reference to that driver chip or usages of the library in the product pages or learn guides for CAN stuff. It looks like there is a core module for interacting with CAN on those device. Perhaps this is a library that is/was for a piece of hardware that didn't end up coming to be, or it was superseded by the core implementation?
maybe something like https://www.sparkfun.com/products/13262 ?
Thank you.
I'm using the ESP-IDF RGB Panel example code, not anything CircuitPython related. I have been using the latest esp-idf 5.0. Also, I have been using double buffer.
The screen drawing is working fine, and the flickering is also present when no new drawing is done, meaning the screen is static. The flickering appears as "visible lines" going vertically down the screen, like old LCD TV's.
I took a video of it the other day: https://www.youtube.com/watch?v=7I9NJPrJ3JY
I have not seen a documented need for such a delay.
I do not understand how to check the latest reproducer script to see the resulting exception, since without a delay I won't be able to connect and see the printed exception.
What exception does the non-tls version produce?
It doesn't make sense that a delay would be needed here, because the wifi is up. communication with the dhcp server and dns server apparently succeed. even opening (but not reading from) the tcp connection apparently succeeds. I wish instead of me you had a networking expert.
No exception, it just times out with zero bytes received. Try your TLS loop but with no TLS right at the top of code, no delay, right after a reset. You'll miss the first prints, but subsequent loops will print.
This works with 5 seconds delay after reset, but not with 0 seconds delay after reset:
<details>
<summary>EXPAND...</summary>
import time
import socketpool
import wifi
import ssl
import traceback
time.sleep(5) # wait for serial (and maybe wait for sockets)...
yes, wifi seems to be fine, and some level of socket operations also seems ok. but at the level of TCP, something is not quite right without delay.
(I am not a networking expert either)
I, yeah. I appreciate that this is a vexing issue but I need to not get too deep into it right now due to other priorities 😕
there is a workaround 🙂
but I am still confused about the script for reproducing the problem, too. how do I see the results, if it runs 0 seconds after boot? Or does re-running code.py exhibit the same problem each time? (so it's not just after boot)?
yes, once it doesn't start up right, it stays broken until: working (delayed) code is used and board is reset
btw I do appreciate that you distilled it down into a version that doesn't use adafruit_requests, it eliminates a lot of stuff
In
displayio_bitmap_obj_blit, the use ofint16_ttruncates the high bits of the input. So if the caller passed 65,537, it would actually get interpreted as 1. You should probably replace all these occurences withint32_tormp_int_t.
I wonder if we could use the arg_check_max function to limit the valid values that can be passed rather than using a larger int size to accommodate the larger values. I think it's possible a that it wouldn't be able to successfully operate on a Bitma...
@tulip sleet Thanks for clarifying that sound levels were possible on the CPX - my understanding previously was that it was a hard "can't".
Specifically due to the buffer
it might be that it fits now; we had a lot of trouble with frozen libs being too big. I am not sure from the dialogue in the issue exactly what was wrong.
but even if it fits now it might not fit in the future
@lone axle what do you think about allowing a configurable Python version for the CI workflows? Default would still be latest but it would give community contributors the ability to use CI with the intended version (e.g., they may not want to support 3.11 on Blinka platforms)
I'd be in favor of that I think. It may depend on how difficult it is to configure, but assuming it can be made fairly straight forward, that seems like a nice option to give folks. I could see posibilities for an issue that is present under whatever is brand new and used by the CI. But isn't present in their local environment and could be hard to fix if they can't easily try whatever version is needed locally.
I wonder if we could use the arg_check_max function to limit the valid values that can be passed rather than using a larger int size to accommodate the larger values. I think it's possible a that it wouldn't be able to successfully operate on a Bitmap of that size for other reasons as well.
There's already range checking code on lines 242-52.
Happy to see someone work on this. I think it can be better still, though.
it'd be nice if these two checks can be consolidated too. The upper bound would be something like (1u << value) - 1.
this doesn't support negative indexing but that's not an issue to be solved right now. I'm not sure why someone would try to depend on accessing bitmap[-1] but if they did it'd be nice if it conformed to the usual rules of indexing in Python.
These should be validated for maximum as well. Surely 32767 is a reasonable maximum (as we have 16-bit types anyhow), and it ensures that width * height * bytes_per_pixel cannot overflow a size_t, so there are no potential overflows when computing how much memory to allocate.
should this be validate_int_range with the low as 0 and the high of get_width()-1, removing the existing test just below the added lines?
I could look at this in a few days. (I have a Pico W in the mail.)
If you're motivated to that'd be great.
It may not be possible to reproduce it in MicroPython since it's really more like the non-web-workflow case in CircuitPython (where it's likely that the time to set up and connect to the AP is enough). This code works across resets:
<details>
<summary>EXPAND...</summary>
import time
ITERATIONS = 10
# Connect to network
import network
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect('ssid', 'password')
# Should be connected and have an IP addres...
I have not seen a documented need for such a delay.
Sorry - I missed that is with the web workflow only.
@crimson ferry you seem to use the term "web workflow" for "auto connect". To clarify, I seem to reproduce the issue without the web workflow (CIRCUITPY_WIFI_SSID and CIRCUITPY_WIFI_PASSWORD defined but no CIRCUITPY_WEB_API_PASSWORD)
or at least it should be disabled in that case
Yeah, it's simple to make optional arguments with defaults. I'll go and handle that this week (honestly probably today)
Thanks for the input!
For sure. Thank you for always working to improve the infrastructure!
you're right, I conflate the two in my head
(auto-connect necessary for web workflow, I think, but could be used on its own, though I don't)
well to be fair it looks like the web workflow is enabled anyway, which I'll verify and open an issue about, because that's a problem
I mean, theoretically, you could connect to wifi later, and then use web workflow, not sure if the code supports that... there are quite a few things set up for web workflow
and serves empty pages instead of asking for password
<@&356864093652516868> hi! we'll be having our weekly meeting in a bit over an hour. Now's a great time to add your notes to the document. https://docs.google.com/document/d/1BAM7-G2YJIgL8ptZG8rY5rKig1ptj1nfbDeuzX6dQzA/edit?usp=sharing
CircuitPython Weekly Meeting for February 6, 2023 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to pa...
@jaunty juniper https://docs.circuitpython.org/en/latest/docs/workflows.html#web seems to have the two concepts a bit co-dependent (1st paragraph)
web workflow = auto-connect + web server + mDNS + websocket +...?
yeah maybe I'm wrong and we don't intend to support auto connect on its own
🤷♂️
I think that auto-connect will start mdns and the webserver
currently it does yeah
we could add another key to cause it to start
or one that would prevent it from starting
and urls like http://cpy-007331.local/fs/ return a blank page
ya, when the password isn't set
so I would just say no password = no workflow, which was what I assumed all along
that's reasonable but not how I implemented it 🙂
Could add some plain text to the response too. or a link
Sorry, skipping the meeting I am wasted by my FOSDEM week-end (maybe I am too old for this). I had a long "report" in a notepad, but not on this phone. 😉
There where two MicroPython talk, 1H00 + 30 minutes. And the usual MicroPython stand (or half table).
No worries! Take care of yourself. You can do your long report anytime. We'll be back next Monday. 😉
(Or Tuesday. No idea if it's a holiday.)
We're still wrapping our internal meeting so we'll probably start a few minutes late today.
brb
BRB.
I'll be in the same boat next week 🙂
On it.
@stuck elbow mute please
sorry, I didn't notice
wow major undertaking, nice project.
Find My Cat -- the GPS Tracker for Pets: I love my cat, Pumpkin, a lot. There were a couple times over the last two years of having him that he went out of my sights (outdoors) and I was really frightened that he had gone missing. If you own a pet, I'm sure you relate.
I wanted to do somet…
It uses a for loop inside a with.
From CPython to circuit python back to C. Abstraction inception.
I try all sources, it can be hit & miss, please email it in for sure
yup, happy to
Only 2 issues for 8.0, getting close.
i just pushed those forward
With Scorpio out the NeoPxl8 library seeing some action makes a lot of sense.
NOTE: Please be advised that this is a change to the document only the product has not been changed.
are the buttons just on/off? Maybe a switch scanning matrix would be cheaper
like a mechanical keyboard
yes, i don't know enough to know how to do that yet 😦
16 switches would need 8 gpio. 4x4 matrix. You would just pay attention to directionality to prevent ghosting with diodes.
It's not too bad once you wrap your head around it. I set a small one up via breadboard to learn and practice.
Hi, I design keyboards and I just so happened to click over when that was suggested. If you can't figure it out, let me know.
Ahh I didn't think about a 4x4 diode matrix in that way. That's neat. Will definitely look into that thank you.
I am still convinced it's only a marginal issue, that you might simply never encounter for a keyboard design
We just revived a couple of air plants after finding a great source for care information. They are happy again.
What is this source?
There's no word on expected behavior if you do use GPA7 as an input. Would it just crash or be glitchy? Who knows.
I haven't even had these for very long, I was wondering if they weren't getting enough water at the place we bought them from.
but to be fair, Microchip hasn't given any clear info
1N4148 diodes are less than a penny each. 16 cents to prevent any chance of issue is worthwhile. For computer keyboards, it does happen because of the speed of the scanning.
Air plants are quite fragile and tempermental, don't feel bad if you kill them.
That's fair. I seriously hope I don't kill them, a. because I only got them recently, and b. they're sooooooo fascinating. And the new ones I have coming, some of them have bonkers flowers. I hope to eventually see them.
Air plants?
They are plants that do not need soil.
Ahh… they do sound fascinating
Thank you!!
The last page of the .pdf has some other useful links.
Perfect.
The closest I’ve gotten to air plants is doing aeroponics
Zoom zoom logic analyzer, neat project.
Air plants were supposed to be the no-maintenance felines of the plant kingdom.
I've helped more than a few people in the circuit python discord using Wokwi instead of breaking out a physical device. Can highly recommend it.
Thanks for hosting Jeff!
thanks all!
Thanks
Thanks!
lol
Thanks
Let's go 8.0 
Thanks all!
ugh my audio today sounds like it was recorded inside one of those weird huge food-service tomato sauce cans. oh well, it's the audio we have.
I have a backup recording if you want to see if it's any different?
you're welcome to check but I'm assuming that's just how my audio sounded.
Skipped around a bit, not listened to the whole thing. But sounds normal in my recording as far as I can tell. https://www.dropbox.com/s/fbharug8ksnw390/circuitpython_weekly_meeting_2_06_23.mkv?dl=0 should be available to download from here if you want to use it.
maybe on the loud side, if anything, I should drop the input volumn a tad in OBS next time.
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/1qKQK-hmTK52jADRMLvGza0wRwAt7R3cGG8Cr0u6xrxY/edit?usp=sharing
CircuitPython Weekly Meeting for February 13, 2023 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to par...
@lone axle yeah it sounds pretty similar to what I was hearing .. a bit metallic-echoey
thanks for running the backup recording, it's good to have a safety net for any number of reasons
@onyx hinge At least you had audio for everyone. My favorite is the one I posted with only my audio. 🙄
has your newer mac stopped sabotaging your audio quite so much?
Entirely.
As soon as he said "I haven't used OBS in years" my first thought was someone should do a backup.
I almost started one but was like nah someone else will hear that and do one. 😛
Automated website update for release 8.0.0 by Blinka.

I don't have an ESP32-EYE board; but tested adafruit-circuitpython-espressif_esp32_eye-en_US-8.0.0-rc.2.bin on a similar board (AI-Thinker ESP32-CAM). It ran successful MQTT wifi tests for over an hour on 3 separate runs.
I found my laptop and notepad and my excuse message for not having notes, and some report about FOSDEM:
I have not done much except going to Fosdem.
Maybe I am too old for this... maybe I am not ready for the in person stuff.
But that was crowded and almost no one wearing mask.
So I only went to day one and followed day two in streaming.
(also in between I had an unrelated party until 2AM and maybe that is why I am wasted today)
For @turbid radish I have a picture of the MicroPython stand: https://hostux.social/@NOeVoting/109806087336088426
The stuff presented were very PyBrick oriented with LEGO bricks everywhere (globe, train, robot).
But I don't know, I did not even talk to them, I don't know if there was something new or if they were selling stuff.
What I can say is that usually there is that lady, maybe from Swizerland, holding the stand, and this year they were two.
(Pine64 was next and maybe had a watch that can run MicroPython, but I did not go there either)
I am sure I missed opportunity for meeting interesting people, and I am sorry if anybody from the community was present.
I saw a few old friends, even a co-worker, (and then the party), and that was maybe enough social interaction for me.
There were two speak about MicroPython, the first one very active with demo, remotely it was not always possible to see the LEDs:
https://fosdem.org/2023/schedule/event/python_micropython_intro/
https://fosdem.org/2023/schedule/event/python_hacking_esp32/
The FOSDEM team is still working on checking the video before publishing, so that could be advertised next week in the CPnews.
Hey, I am trying to build a circuit python firmware.uf2 for a custom board. But I keep getting some errors when building the firmware.uf2 file. Even with some already established boards.
I am not to familiar with this type of programming, so pls be lenient.
Errormessage: Makefile:403: *** unknown IDF_TARGET . Stop.
Could maybe someone more experienced have a look at it?
we tend to do this when we branch off
so that S3 builds are labeled with 8.1
@limpid flame can you post more of the error?
There is not much more
circuitpython/ports/espressif$ make -j8 BOARD=sensebox_MCU_2_1 TRANSLATION=es
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
Makefile:403: *** unknown IDF_TARGET . Stop.
did you install and export from the esp-idf directory?
at least i think so
WSL Ubuntu 22 on Windows 11
/tmp/circuitpython/ports/espressif$ git status
On branch main
Your branch is up to date with 'origin/main'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
../broadcom/
../cxd56/
bindings/espcamera/
bindings/espulp/Architecture.c
bindings/espulp/Architecture.c:Zone.Identifier
bindings/espulp/Architecture.h
bindings/espulp/Architecture.h:Zone.Identifier
boards/brainboardz_neuron/
boards/espressif_esp32s3_devkitc_1_n32r8/
common-hal/espcamera/
esp-idf-config/partitions-32MB.csv
esp-idf-config/partitions-32MB.csv:Zone.Identifier
esp-idf-config/sdkconfig-32MB.defaults
esp-idf-config/sdkconfig-32MB.defaults:Zone.Identifier
../litex/
../mimxrt10xx/
../nrf/
../raspberrypi/
../stm/
nothing added to commit but untracked files present (use "git add" to track)
hrm. I don't see anything suspicious about esp-idf
it does seem like you checked out a newer version and it left some files behind
Do you mean a newer version of the repo or some dependences?
In the biginning i forked the repo and added the custom board to the /boards.
what does that mean for me? Can i just delete the "messed up" repo and glone it again?
no, tag 8.0.0, branch 8.0.x, and tag 8.1.0-alpha.0 are all at the same commit
its probably not the problem
but I'm not sure how it got that way
the next step I'd suggest is adding V=2 to your make command to see what its failing on
like this?
make -j8 V=2 BOARD=sensebox_MCU_2_1 TRANSLATION=es
that should work
did you do source esp-idf/export.sh before?
try it without -j 8 too
I think this is a responsibility for the individual classes to enforce themselves. In make_new classes should validate their type parameter and disallow the sub-classing as needed (by throwing TypeError).
you cannot just run the shell script, you have to source it.
all the same error code
I do not know what you mean tbh
do you have IDF_TARGET in your board file?
looks like its in mpconfigboard.mk. did you typo it?
https://github.com/A-Spork/circuitpython/tree/main/ports/espressif/boards/sensebox_MCU_2_1
That´s the added boards code, if you mean that
I see IDF_TARGET in other boards: https://github.com/A-Spork/circuitpython/blob/main/ports/espressif/boards/microdev_micro_s2/mpconfigboard.mk#L6
Hi @BrainBoardz, were you able to work on a PR for circuitpython-org? If you need help, we have a guide at https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website.
I was going to throw something up on circuitpython.org in its place for now, but I'm really not sure if this is for the Neuron Z3, Neuron M3, both, or a completely new board. I may just end up hiding it for now until you can get around to working on this.
Okay, then this should be the problem. Let me add and try it again.
To create the new board i just compared a old board with the same pins etc and one board with the same chip.
Not to sure if it even possible to work that way
ya, that should work
CHIP_VARIANT and CHIP_FAMILY are not used for ESP builds, you might have copied from a non-ESP board ?
likewise pin_PA04 etc are atmel and stm pin names
I coppied form the lolin s2 mini as it should use the same chip and and older version with atmel https://github.com/adafruit/circuitpython-org/pull/669
I just saw that you also helped a collegue of mine too
I could fix this issue. Does that sound like a good idea?
https://github.com/adafruit/circuitpython/issues/3913
Okay, getting a different error message with the updated version
circuitpython/ports/espressif$ make BOARD=sensebox_MCU_2_1 v=2
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
mkdir -p build-sensebox_MCU_2_1/genhdr
GEN build-sensebox_MCU_2_1/genhdr/moduledefs.h
make: *** No rule to make target 'boards/sensebox_MCU_2_1/sdkconfig', needed by 'build-sensebox_MCU_2_1/esp-idf/config/sdkconfig.h'. Stop.
I think you'll want to start from another ESP board
sure! looks weird
Okay, but even if i try to build this board it does not work at the end😅
what's the error then ?
you need to do those after enabling the ESP-IDF environement:
https://learn.adafruit.com/building-circuitpython/build-circuitpython#install-required-python-packages-3086211
that should install the missing modules
I did, but it did not work.
ERROR: Could not open requirements file: [Errno 2] No such file or directory: 'requirements-dev.txt'
ERROR: Could not open requirements file: [Errno 2] No such file or directory: 'requirements-doc.txt'
they are at the root of the circuitpython repo
I think i messed that up. Thx
so like pip3 install --upgrade -r ../../requirements-dev.txt
Okay, i went threw th tutorial again and everything finished without error, but when i try to build the example board, i get the error messages again
make BOARD=circuitplayground_express
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
MKMANIFEST ../../frozen/Adafruit_CircuitPython_CircuitPlayground/frozen_cpx ../../frozen/Adafruit_CircuitPython_HID ../../frozen/Adafruit_CircuitPython_LIS3DH ../../frozen/Adafruit_CircuitPython_NeoPixel ../../frozen/Adafruit_CircuitPython_Thermistor
(cd build-circuitplayground_express/frozen_mpy && find * -name *.py -exec printf 'freeze_as_mpy("frozen_mpy", "%s")\n' {} ; )> build-circuitplayground_express/manifest.py.tmp && mv -f build-circuitplayground_express/manifest.py.tmp build-circuitplayground_express/manifest.py
find: ‘*’: No such file or directory
make: *** [../../py/circuitpy_mpconfig.mk:589: build-circuitplayground_express/manifest.py] Error 1
did you do make fetch-submodules at the top level? If you did esp-idf/export.py in this terminal window, it will have an incorrect environment, set up for espressif builds only. Start a build in a fresh terminal window (you don't have to repeat the setup steps). Also do a make BOARD=circuitplayground_express clean first
@limpid flame ^
I ran make fetch-submodules and it ran without any errors
I will try it in a fresh terminal
In the new terminal i get the error above
Hi Mellisa:
If you could hide it for now I would really appreciate it. It won't be for
long! I'm waiting for final pre-production boards to come in before
submitting my PR to circuit python.org. I'd like to use a
photo of those production units on the site as they are the correct board
color etc. If it can wait a little bit that would be great as the boards
will be arriving soon (they typically take a week or two at most). I was
going to work on the content for the page in the meantime. A...
did you do the make clean?
all make clean does is delete the build-<BOARDname> directory for that board
Okay. No I did not do that in the fist try, but even if ido that in a new terminal and try to build then, I get the same error
what is your version of make ?
$ make --v
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
ok that should be good
I hope that´s the right way to do it
well pip install semver then
I would think it would be in the requirements or as a dependency, but maybe not ?
do not think so. it was not installed by now at least
it worked
make BOARD=circuitplayground_express
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
247980 bytes used, 5460 bytes free in flash firmware space out of 253440 bytes (247.5kB).
12060 bytes used, 20708 bytes free in ram for stack and heap out of 32768 bytes (32.0kB).
Converted to uf2, output size: 496128, start address: 0x2000
Wrote 496128 bytes to build-circuitplayground_express/firmware.uf2
Had to install a few packages but now i get this, which is how it should be, I guess
@tulip sleet looks like we need to add semver to the requirements ?
yeah that looks good
those are in the requirements
then i messed sth up
I tested making a venv and installing requirements-*.txt and importing semver in python, it was not found
That is odd, I thought it was there, or implied by something else.
yeah, maybe some module removed their dependency to it
Okay, so the example runs now, and the errors i get should be from the custom board. Any recommendations how to compare or create the code for the new board?
I am really sorry to bother you that much, but i really do not know how to do sth like this, but need the new board for my Bachelors Thesis
you can build the lolin S2 ?
sadly no
did you forget:
source esp-idf/export.sh
sure i did forget it👍
might have to reinstall semver in that environement
oddly, that's not the content of bitmap_font.py for me. Is it possible you ran some git commands that changed (updated) that submodule beyond the version that we've commited in git? the version we have is quite old [2019] at this point, from before we added type annotations.
Currently the extend method of array (which includes bytearray) only accepts arguments that support the buffer protocol. CPython also allows iterable arguments to this method. Adding that support here.
Now as you ask, i did ran apt-get update in a different folder.
but no git commands
could that have caused this problem?
that should not matter at all
did you run esp-idf/install.sh before source esp-idf/export.sh
ran both
However, running pip3 install ... after source esp-idf/export.sh does matter, because you are using a different python environment. After you do source esp-idf/export.sh, you may need to do pip3 install semver. It would not hurt to do that.
so in a new terminal? Not sure if i understand that right
sudo apt install python3-pip
pip3 install --upgrade -r requirements-dev.txt
pip3 install --upgrade -r requirements-doc.txt
esp-idf/install.sh
source esp-idf/export.sh
pip3 install semver
not yet
those after export for espressif builds though (but once)
pip3 install --upgrade -r ../../requirements-dev.txt
pip3 install --upgrade -r ../../requirements-doc.txt
The "fatal error" at the top is not good
btw, not so great to use /tmp for this: it can be cleared. Better to use your WSL homedir or something underneath it
also /tmp might not be big enough
So i should set it up fresh in homedir? Was a trip to get it running.
well, eventually.
Okay. Gonna do that tomorrow. Big Thanks for helping me this time. Hope its okay if i may ask again. Good night
Hi, I am making a library but am having problems with making the docs. In the Learn Guide https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/sharing-our-docs-on-readthedocs, it says to do this:
cd docs
sphinx-build -E -W -b html . _build/html
but it appears that cookiecutter does not create the "docs" directory and all the files needed for that.
What is the recommended way to generate the "docs" directory?
there should be a docs dir, maybe underneath where you are looking?? https://github.com/adafruit/cookiecutter-adafruit-circuitpython/tree/main/{{ cookiecutter.__dirname }}/docs
I used cookiecutter yesterday and it created the doc directory
cookie cutter asks whether to create docs, the default is n iirc
hmm wonder why it didn't work for me
I just used it
I will try again
and copy the files over I guess to my repo
just checking if you have installed Sphinx in your .venv/.env
perhaps I didn't have it installed at the time of running cookiecutter? (because it didn't mention it until the rtd section)
oh I see. There was a "sphinx docs [no]" option question that I just next'd through because it was after a bunch of adafruit-specific questions
okay, nevermind I am good now. thanks!
oh that would explained it 🙂
this pip error makes no sense to me: The conflict is caused by: The user requested pc-ble-driver-py nrfutil 6.1.7 depends on pc-ble-driver-py>=0.16.4 The user requested pc-ble-driver-py nrfutil 6.1.6 depends on pc-ble-driver-py>=0.16.4 ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts The user requested pc-ble-driver-py nrfutil 6.1.5 depends on pc-ble-driver-py>=0.16.4 The user requested pc-ble-driver-py nrfutil 6.1.4 depends on pc-ble-driver-py>=0.16.4
@slender iron further up it did this:
Collecting pc-ble-driver-py
Downloading pc_ble_driver_py-0.11.4.tar.gz (8.0 MB)
this is windows, so maybe there is no pc_ble_driver_py for Windows (in particular) newer than 0.11.4
unfortunately
pip says there is. could be a cache thing
I'll look tomorrow. gotta get garbage out now
ok I don't know what happened in the circup CI:
An unexpected error has occurred: CalledProcessError: command: ('/home/runner/.cache/pre-commit/repoaqv54v2u/py_env-python3.7/bin/python', '-mpip', 'install', '.')
return code: 1
stdout:
Processing /home/runner/.cache/pre-commit/repoaqv54v2u
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'error'
stderr:
error: subprocess-exited-with-error
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [1 lines of output]
error in pylint setup command: 'python_requires' must be a string containing valid version specifiers; Invalid specifier: '>=3.5.*'
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> See above for output.
pylint 2.6.0 does have python_requires=">=3.5.*" which is weird (using >= with a * wildcard), is it like no longer supported by setuptools or something ?
yes they changed something in the upper levels of python packaging, let me find you a reference
it looks like we use pylint 2.15.5 in other repos, maybe I can do a PR to update pylint in circup and the pylintrc accordingly
I'm not finding my reference. But yeah I think the solution is going to be to bite the bullet and update to newer pylint. how widely is this going to affect stuff? (i.e., if it's learn that's bad news)
learn does pip install --force-reinstall pylint==2.7.1 in the CI it seems, which doesn't use the * version (but "~=3.6")
@jaunty juniper https://github.com/pypa/setuptools/issues/3772 is what I ran into, the message is different but I think it's the same "removal of behavior people relied on a decade but hey we told you so" that underlies both..
I mean maybe not the same exact code change but the same philosophical impulse.
Your code has been rated at 9.50/10
Is that a passing grade ?
❯ pylint circup/__init__.py | wc
105 1401 15294
oh but mostly pylintrc hmmm
why is "Consider using {} instead of dict()" a thing ? Consider using symbols instead of english words ? ugh
there's a few "good" ones:
Missing timeout argument for method 'requests.get' can cause your program to hang indefinitely
Iterated list '_requested_libraries' is being modified inside for loop body, consider iterating through a copy
Where's the best place to document differences between ports? Thinking at the moment about wifi diffs between espressif and raspberrypi. We already know of some. Just playing around with mDNS again... looks like raspberrypi has a limit of one advertised service, and if web workflow is enabled, that's it. espressif can do multiple regardless of web workflow, haven't gone beyond four yet.
maybe we can change that in mpconfigport.h ?
https://github.com/adafruit/lwip/blob/239918ccc173cb2c2a62f41a40fd893f57faf1d6/src/include/lwip/apps/mdns_opts.h#L58-L61
maybe, not sure about side effects
I thought at first it was the limited sockets, but appears independent of that (at least to a point)
lol, on espressif, I can advertise more mdns services than there are available sockets... I assume it would fail when trying to connect to too many
I have added "Limitations:" sections to various places in the Python API doc. These document what's different about various ports.
ooh, I will look and maybe suggest some additions (is that PR-able?)
oh sure; they are in the in-line doc in the C code for each module, etc.
UPDATE: Looks like if i use the Adafruit Feather HUZZAH32 board it works like a charm.
Should i close or not?
I have taken a quick read through some source files, and py/scope.h seems a good candidate for the recursion limit.
However I still have no idea how to implement it..
If it's basically the same, yes, let's close. Each board we add increases the time spent on every build and PR.
Update Spresense SDK to version 2.6.0.
import wifi has the side effect of calling common_hal_wifi_init(). If you move the delay to before the import wifi, does it affect what happens?
Actually I think mine shows a little bit of what you show in the video. Not sure what causes it.
I recommend you go look at the code that triggers a refresh and hack it to see if you can “manually” control the redraw time. Then you can actively change the redraw rate and confirm whether the redraw is what is affecting your flickering.
Sorry I don’t have more insights.
@stuck elbow Any suggestions for this user on how to debug flickering of an ESP32-S3 driving a dot clock display with the ESP-IDF?
Interesting. I didn't expect that to work, but it did. The issue appears more fundamental than wifi init.
This code works with a 5-second delay, but not with 0 seconds:
<details>
<summary>EXPAND...</summary>
import time
time.sleep(5) # wait for serial (and maybe wait for sockets)
print(f"{'='*25}")
print("Web Workflow enabled - already connected to AP")
import wifi
import socketpool
# import ssl
import traceback
socket = socketpool.SocketPool(wifi.radio)
p...
never used any of those, so no idea
I published a branch of my prototype for changes to async and PIO. https://github.com/gneverov/circuitpython/compare/main...gneverov:circuitpython:async
There is a lot of code there, but if you only read one file, look at this one (https://github.com/gneverov/circuitpython/blob/async/ports/raspberrypi/lib/test_sm.py). It is an example program that uses async/await to send/receive data from a RP2 PIO state machine.
I appreciate your feedback. Especially about what is PR-able. I think that some sort of "design review" of these changes would be helpful. If you have a use case for async or PIO that is not currently feasible on CP then we should talk.
@timid bolt please make a draft PR so we can comment inline
@timid bolt How would you feel about having an audio or video chat at some point soon? I would find that a lot more efficient to get the background on your thoughts on this, and to tell you where we are coming from.
Totally agree. 😁
We are in US ET (-5 GMT, me), CT (-6, @onyx hinge), and PT (-8 @slender iron) timezones. Since this is our day job, we are pretty flexible as to timing. Even today would be fine for me at least, unless it's getting late for you
@timid bolt is in PT too. We chatted yesterday
Cool. How about 10 or 11 PT today?
that's fine for me too, 2pm ET. @onyx hinge join if you'd like. @slender iron did you text chat or audio/
@timid bolt @tulip sleet I can join at 2PM ET, sure.
@slender iron this PR? https://github.com/adafruit/circuitpython/pull/7396 I can review it if you like
I need a break from writing guide for a bit anyway
@slender iron so that PR switches espressif, nrf, and rp2040 to stackless and turns off pystack? I think it's fine (I haven't studied the details of 'stackless' in detail but not having an arbitrary limit seems nice). It feels a little weird to have it in the style of conditional-undef, that's not like we do most things. But maybe it's necessary, since we are overriding things in circpy_mpconfig.h which comes 'before' mpconfigport.h? If you're content with that style of changing the setting, and we have plenty of time to 'let it bake' on 8.1 to shake out problems, is fine with me.
I haven't looked in detail to see how its done. generally I think now is time to start getting stuff like that in
my recollection of you turning ON pystack in the first place is that it was to benefit the small samd21 boards and this leaves that in place which also seems good.
I would like to know more about the effects, it seems to me that it means that it will be harder to optimize for allocations
maybe get more understanding on what it does from the MP people
Great, see you all at 2 pm ET.
Please request a pid.codes PID for this rather than using 0x0011 if it is open source. Otherwise, you can request one from Raspberry Pi.
One request around USB PID
Afk for a walk and lunch until then
I think we'll want this in a separate module so we can enable/disable it separately from displayio.
Please update the docs here.
I'm not sure what "stackless" is. A cursory look at the code seems like it allocates python stack frames on the heap at every function call. I'm not sure what the motivation for that is; it would seem to introduce a big performance hit. For one it will be putting a lot more pressure on the GC.
If the default stack limit is fine for 90% of people, then it might be the wrong tradeoff to make 90% of people's code slower for the benefit of 10%. One can always refactor their code to not use recursion and avoid deep stacks, so the 10% have a workaround anyway. And deeply recursive code is generally not a good idea in the first place.
But wouldn't the solution then to be to increase the default stack size and not turn on stackless?
ya, that could work too but then you reducing the ram available for heap
the impact on memory fragmentation is also a concern to me, especially when using displayio libraries on pico for example
k, please comment on the pr so they proposer can see the concerns
I'm not sure why you add and remove peers so if my suggestion doesn't make sense, that is fine.
I think there is a balance between matching the C api and utilizing Python's abstractions.
Would you consider making the pystack size boot-time configurable to be an acceptable solution?
It looks like it may be possible to dynamically allocate _pystack in start_mp.
ya, that could work. we did allow changing stack size when we shared the c stack.
oh, what was wrong with sharing the c stack?
large call frame end up on the heap (iirc)
Why have this? This feels weird. Are you trying to abstract for sharing the success and failure statistics? Its probably clearer to just duplicate them in ESP-Now.
async may end up being stackless anyway
I doubt the pystack is used for multiple concurrent threads
I think that moving from "pystack" to "stackless" would be a step backwards. "Stackless" allocates a stack frame on the heap at every function call, which is not the most efficient way to implement a call stack. Besides the overhead introduced on every function call, another cost is the emergent impact it has on the heap: it will cause the GC to run more often and produce a more fragmented heap.
I think a better solution would be to make the size of the "pystack" configurable at boot time....
yes, coroutines are effectively stackless, but there are still a lot of function calls that happen between "awaits"
You would need a pystack for every thread. FWIW, it don't think CP should ever have preemptable threads; there would only be hardware threads, so that's not a large number of stacks. But if it were up to me, I would not even share a heap between hw threads, in which case there would not be a memory saving of multi-thread "stackless" anyway.
DmaChannel.c was a little experiment to get DMA running outside of PIO. It's still useful for debugging, but not part of the "public API".
This allows the following:
e.send()
e.send.success
e.send.failure
I think that it'll be weird for folks to have attributes on something callable. How about e.send_stats and e.receive_stats that are tuples of (success, failure)? Or you could have 4 properties on e.
I'm slightly delayed, will join in a few minutes
where do you join?
do you want to do private or not?
I'm not sure what that means
in a public channel or in DM's
public is fine
can go to Amelia Earhart voice channel
Configuring pystack size with something like settings.toml would pretty much share the same benefits as stackless.
Users could lower it for more ram, or raise it for massive recursion levels and nested funcs.
However I have to say, I have not noticed any slowdowns due to stackless.. (and my code is absolute bloat)
Thinking about it, with an original stack size of 1.5k, one frame should be couple a dozen bytes, so what are the odds even of that frame bonking OOM?
Sure it could happen...
this probably didn't do what you intended. the 2nd argument states whether the object should be allocated in the long-lived portion of the heap. it's not giving you NUM_PIO_INTERRUPT_SOURCES objects of type rp2pio_pio_irq_t.
I too am in the chat (semi afk) if you guys want to talk about stackless more.
I just spotted @anecdata 's discord question: #circuitpython-dev message
Any chance this issue is related to the number of advertised services on the PicoW?
GC may be less of an issue than fragmentation, consider nested functions that do a of of heavy lifting so the small stack frames get dispersed through the heap.
I'm a big fan of runtime configuration of things like memory, not sure if stackless could be a runtime thing like PYSTACK = 0 or STACKLESS = True overriding the PYSTACK value.
This would kind of be the best of both worlds
something like sys.stacksize
0 for stackless
signed int for number of frames to be allocated.
realloc on set
Before you started testing stackless where you able to get the your code running well with larger stacksize settings? I may have been using the wrong parameters but when I started troubleshooting the pystack errors I didn't have much luck adjusting the stack size. I did find the stackless option before working too long on the stacksize parameters though.
The standard heap block size is 16 bytes.
Some discussion of performance hit of STACKLESS and PYSTACK here (and above and below in that issue): https://github.com/micropython/micropython/issues/6087#issuecomment-635697504
Yea, it all worked a-ok.
we have supervisor.runtime.next_stack_limit for C stack
not the pystack
brb, imma go read the docs
it's a bit open loop though: "The size of the stack for the next vm run. If its too large, the default will be used." https://github.com/adafruit/circuitpython/issues/4520
espcamera is not in the module support matrix, though it is turned on for a number of boards (e.g. Metro ESP32-S2). This may be due to its being not in shared-bindings, but in ports/espressif/bindings. That may be special-cased?
and we have CIRCUITPY_RESERVED_PSRAM= in setings.toml (espressif)
memory knobs are quite handy
Uhh, I have been studying parallel search algos for exam, imma just slap it onto my fat 8mb board and see what it does.
Docs pain me.
Are you sure?
#define m_new_ll(type, num) ((type *)(m_malloc(sizeof(type) * (num), true)))
tldr, no effect on static pystack. (8.0.0 stock)
I have no idea what it does.
set it to 100k and pystack exausted.
tried reload and reset
we used to have a combined c and python stack
thats when next_stack_limit was added
it didn't get switched to the pystack when we enabled it
iirc the reason to do pystack was to avoid large allocations of stack frame onto the heap
because they'd fail when memory was fragmented
Maybe if it gets reworked it would be the simpliest solution for dynamic stack size.
no fancy settings.toml, but good old next_ keys
Not a fan, but it's something I can pr myself. probably. hopefully..
Is it meant to work on reload or reset?
I didn't think this was related to https://github.com/adafruit/circuitpython/issues/7543 but given that it seems to be triggered when requests grabbing a socket (or two), it's possible.
Does it still drop with requests = adafruit_requests.Session(pool, None)?
I'm down another rabbit hole at the moment, but when I come up, I'll take a look.
I mean, I crawled through the code..
shared-bindings/Runtime.c->supervisor/stack.c
So apparently it will always boot with default stack size and then after the fact reallocate on next reload with the new stack size.
Or so it should..
Perhaps it is not then being realloc'ed on reload?
Crawling through shared-bindings/supervisor/__init.c__
Traced back to supervisor/shared/reload.c
Failed to trace port_wake_main_task. Cannot find relevant code.
Cannot find anywhere where pystack is actually realloc'ed.
It may be as simple as adding it during reload.
Hmm port_wake_main_task actually is port specific and xTaskNotifyGive feels like it slowly leads me to freertos code, so bye I have had enough. Imma yell at puter more tomorrow
Opening issue.
yets, you're right after all. I must have looked at a different macro definition.
Oh I was totally off with my horrible reversing.
I should have started from main, yea this is going very well 🥲
Yea it totally just gets alloc'ed by main.c from CIRCUITPY_PYSTACK_SIZE.
All that code was old unused code.
So that ain't going to happen without nvram of sorts, which I do not know how to use.
Perhaps settings.toml is simplier then next_stack_size
Though I do not know if that code would work so early?
If I can get the value from somewhere during boot and read it into main, it should be easy enough to override the rest.
Thanks for coming to my ted talk.
Goodnight.
ya, I think settings.toml is simpler than next_stack_size
I think it should work early
It should also be easier for code to verify as to if it has been set or not.
But whileI am at it, I will make a getter
Does CircuitPython discard module docstrings?
Discard how?
Like are they part of code size when compiled or whatever?
I'm fairly sure they're not included. Are you talking libraries or core?
Both
OK, I'm not entirely certain. I feel like yes, they're not included. But I might be wrong.
That's my thought as well, but I don't have hardware on hand to test, but also wanted to confirm.
@tulip sleet would probably know.
yes, they are discarded
Context is questioning whether adding more information to a module docstring as an adverse effect (or any at all) on anything.
Sweet thanks!
none at all
That's what I thought.
Thanks y'all!
I'm working on a CircuitPython library. So I'm editing code in a git repo on my desktop PC. Then in order to test the changes I have to copy them to a device. Is there a convenient tool for syncing library code between your PC and device? Just wondering what other people do.
if I don't just edit directly on the device, I use some variation on rsync -@2 to efficiently copy just changed files within a package. I'll just write out in a terminal and hit cursor-up enter, or if I'm really organized set it as my 'makeprg' in vim
and if there's just a single source file nothing is much better than anything else
(it helps to tell your editor not to write temporary files to CIRCUITPY if you edit files there; I know how to ask vim not to do that but I don't know about others)
Thanks. Is there a way to reload modules without resetting the board (like importlib.reload from CPython)?
you have to restart the code
ctrl-C ctrl-D or supervisor.reload() (or autoreload)
Sounds good. Thanks.
Replacing the requests = line with the pool, None version had no impact, the Pico W is still dropped from the list of devices when the call is made.
I did notice that when I was running this latest test, my board was executing a call to adafruit_ntp in the code.py which apparently didn't bother MDNS as it didn't cause the Pico W to drop from the list.
I have my own tool that does this (write PC code to board) for Linux. Just uses a process to detect changed code files from the PC and write them to the board.
Thanks for categorizing it... And thanks for having it on your todo list now!
I really appreciate it!
Heya, so I have some questions again regarding CircuitPython. My university tasked me with implementing a non blocking writer for writing to an SDCard file.
Now, this could be done either purely in Python land or also in a C module, so I'd like to know (before I start implementing lots of boilerplate code and such) whether it is possible and also a good idea to malloc a buffer in which I could store strings before writing them to the card once a specific size is reached or flushing function is called.
what if the board is restarted in the mean time?
as far as I know that should be neglectable. The reason why they want me to implement something like that is because they write a lot of sensor test data and writing lots of small data takes too long apparently.
I think that should be handled at a higher level, where you know what the data is and how to best buffer it
I guess they could also just append their text to a list and then write that list to the disk every now and then
Do they want the SD card writes to actually be non-blocking always (so the latency is known), or do they just want most "writes" to go fast (e.g. so you would mostly just buffer)
They want most writes to go fast.
you can make a buffer in Python with a bytearray. Are you being asked to extend CircuitPython to do this? sdcardio or sdio? Main idea could be to add non-blocking writes to shared-module/sdcardio/SDCard.c. Find out what the blocking operations there are and either do them. This is a lot of low-level work
Though non-blocking would also work and it would even be fine if some data gets lost because of a ringbuffer or something.
and requires knowledge of how SD cards work, their latencies, etc.
I am not exactly tasked with extending CircuitPython, just that the writes should either be faster or not block the code at all.
They would be fine with using a wrapper too I guess
"most writes should be faster", it sounds like
Hey, i am still getting the same error
`$ make BOARD=lolin_s2_mini
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
mkdir -p build-lolin_s2_mini/genhdr
GEN build-lolin_s2_mini/genhdr/moduledefs.h
IDF_PATH=/tmp/circuitpython/ports/espressif/esp-idf cmake -S . -B build-lolin_s2_mini/esp-idf -DSDKCONFIG=build-lolin_s2_mini/esp-idf/sdkconfig -DSDKCONFIG_DEFAULTS="esp-idf-config/sdkconfig.defaults;esp-idf-config/sdkconfig-opt.defaults;esp-...
yep
so just make a buffer as big as you can, append to it, and then when it gets to full, write the whole thing out, clear it, and repeat
So just a simple python bytearray as a buffer would suffice? No need to extend or create a custom c module?
Some years ago I wrote and used successfully a Python script for a Raspberry Pi to receive, unpack and display UDP multicast packets, broadcasted from an X-Plane flight simulator app running on a MS Windows PC.
In this moment I am trying to port this script to CircuitPython V8.90.0.-rc.2 on an Adafruit Feather ESP32-S2 with TFT,
however I am not able to proceed because, TMHO, the core module 'socketpool' lacks attributes I need for my project.
Ref: [readthedocs_latest_socketpool](https:...
no reason to
the actual write is still going to be blocking, but there will be fewer write operations. You may want to use some multiple of the filesystem block size (512 bytes or larger, depending on the size of the filesystem). Is this text or binary data?
at what rate are you writing data? 100 bytes/second? 100 bytes/minute??, etc.
It would be text data. 100 bytes a second sounds about right.
don't concatenate strings into a new buffer each time you add stuff, that can be costly in terms of storage allocation. Allocate the buffer once and keep track of the next free byte, etc.
what board is this?
it has a large amount of PSRAM, so you can allocate a big buffer.
Very nice. I'll get to work then. Thanks for the quick and detailed response!
use sdcardio, not adafruit_sdcard. sdcardio is native C internally
I think they also used adafruit_sdcard previously so that would also explain things
But now with sdcardio and the buffer, it should be blazing fast for most writes 😄
If you can use sdio, that would be faster
but you need the right kind of card breakout
not sure if S2 has sdio, I'll look
from what I've seen the board doesn't support sdio natively at least.
Need to take a feather with build in SDcard, those are wired for sdio.
for now they do not want to change from FeatherS2's and FeatherS3 since they would have to order new ones with another complicated batch of paper work and funding.
it probably will be fine
@dhalbert
I would really appreciate wifi.radio.is_connected or equivalent being made available.
Any idea on timescale please.
Many thanks
CircuitPython version
Adafruit CircuitPython 8.0.0 beta 3, QtPy with ESP32-S2
Code/REPL
import wifi
wifi.radio.connect(secrets["ssid"], secrets["password"], timeout=10)
Behavior
In case the DHCP server is not responding to the DHCP requests sent via the connect() call, the call does not return after 10 seconds - the timeout seems to be is ignored (assuming the timeout is specified in seconds).
My experiment lasted for about 15 minutes, p...
I can't do the configurable pystack.
It's currently a file definition
moving it elsewhere really doesn't work
and all the funcs that work with it are written in minecraft echantment language
I give up.
I have understood how the _pystack array is used and allocated.
This didn't help.
Pretty sure it would take a boat load of changes to make it configurable.
there's a decoder for the Standard Galactic alphabet 😉
@tidal kiln do you do much logic analyzer stuff?
wouldn't say "much", but have done some. for troubleshooting i2c, spi, etc. need something scoped?
I've been working on making the scorpio useful as a logic analyzer
wondering if you want to try it. Do you usually use a saleae?
yep. got an older model saleae. 8 chan. just fast enough for spi. works fine for my needs.
how fast do you usually run it?
only as fast as needed. may also have a host PC issue, as fastest setting often leads to "couldn't keep up" errors.
24MS/s is fastest possible. but i can't achieve that on my setup. 16MS/s is more typical for SPI, slower for I2C.
I think the appeal for me is that anyone with an rp2040 will have a (slowish) logic analyzer
I would love that 😉
@jaunty juniper want to try it?
for I2C i'm more at 2MS/s
I don't have specifically a scorpio though
any rp2040 will work
i also haven't snagged a scorpio yet
scorpio just has the logic level translator to protect against 5v
yep
yeah I have a pico to spare
i have several picos
kk, let me push the latest
right now it is cli capture and then you can load into pulseview to see the trace
so you can install pulseview now if you want
found an appimage i downloaded circa july 2021. think i was giving the sigrok stuff a try back then. appears to still be latest ver 0.4.2