#circuitpython-dev
1 messages · Page 3 of 1
I've tried screen, rshell, thonny
hmm -- I'll take a look for something like that.
Adafruit CircuitPython 8.0.0-alpha.1-91-g0c46e990f-dirty on 2022-08-03; ESP32-S3-USB-OTG-N8 with ESP32S3
>>> import wifi
>>> wifi.radio.ipv4_address
192.168.1.94
next thonny beta will show it
>>> import wifi
>>> wifi.radio.ipv4_address
10.0.0.158
>>>
``` that s a good sign....
ooops wrong board
there's something, I saw the title bar saying "no IP" or something, but now that it's connected the C3 or the FunHouse give me no title bar in tio
(when they used to)
hrm, could be a bug. I've got more changes pending for it
>>>
>>>
>>> import wifi
>>> wifi.radio.ipv4_address
>>>
``` nothing for C3
>>> os.listdir()
['.fseventsd', '.metadata_never_index', '.Trashes', 'code.py', 'lib', 'boot_out.txt', '.env']
>>> ``` same as on my other boards
and the .env is the same too?
yes
when is the title bar sent ?
if I disconnect from the board, then reconnect from a new shell, what does it take to get the title bar ? ctrl-C ? ctrl-D ? a new prompt (enter) ?
I’ve noticed sluggishness in the REPL on reset as (I think) the supervisor is trying to connect to WIFi with bad credentials or weak signal. After a minute or so when it fails, sluggishness is gone
I just verified that the .env is correct (same as working boards) could be a weak signal issue -- maybe the qtpyc3 is less tolerant -- I'll try moving it cloaser to the router.
@jaunty juniper want a build from my working branch?
meh, I'll see when it's merged, I can't spend too much time on C3 testing rn
moving closer to the router did not help 😦 seemed too easy
Wonder if it has the same need to set txpower as the Lolin C3 mini
I needed this in boot.py on the C3 mini in addition to the .env file stuff to get web workflow up and running:
import wifi
wifi.radio.enabled=True
wifi.radio.tx_power=8
@slender iron aha -- moving closer to the router did make a big difference -- it works fine when closer.
My signal in my "office" is rather weak but most boards are OK -- some are problematic -- looks like the qtpyc3 qualifies.
@spiral elk I will try that.
@spiral elk at first attempt, that did not appear to help, but I'll keep trying -- location does matter!
looks like I need to try my wifi extender again....
I wonder how I could detect that. I found some good Unicode bars for showing signal strength
- Adafruit Feather HUZZAH32 port. This is an ESP32 WROOM module -- no PSRAM. I had to do some additional conditional compilation stuff to get it working
- Touchup of board-specific
sdkconfigfiles to remove redundancies and make consistent.
Adding a "mesh pod" to my xfinity router seems to make the C3 much happier in my office. -- Now I just need to see how the overall network performs -- I have had issued with the xfinity pod in the past, but it's worth another try. Anyway CP is exonerated...
I'd like to wait until the public list is updated to match. Will merge after that.
Thanks! I like the idea of defaulting to sorted. Post another message when it is ready for review. Thanks!
Not trying to grandstand, but thought I might shared my first 'toy' extension of circuitpython (ala everyone's gracious help). One can find the CPy code at https://github.com/latkinso42/fibonacci and the extension branch at https://github.com/latkinso42/circuitpython branch fib. The README has the details of usage. This was done in preparation of an ADC through DMA project to learn the ins and outs of extending circuitpython. Comments are Welcome. Thanks!
Looks good to me! Thank you!
This has been done via suspend and resume calls for the title bar.
I'm making this change now. (To an autoreload property on runtime.)
@hidden rain you should submit this for the newsletter, looks cool.
To contribute your own news or project, edit next week's draft on GitHub and submit a pull request with the changes. You may also tag a tweet with #CircuitPython on Twitter, or email cpnews@adafruit.com.
@lone axle hey if you get a chance can you create the notes doc for next week?
icymi: ppk2s are in stock at digikey: https://www.digikey.com/en/products/detail/nordic-semiconductor-asa/NRF-PPK2/13557476
Thank You. I'll try to get (or git) to that tonight.... 😉
whoooops, yep will do.
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/1Zm1TPFm0mBhFvzQWCashMrcrBoR_d2SQMGtBrvQ7oSE/edit?usp=sharing
CircuitPython Weekly Meeting for Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to participate, add y...
git 'er done 😛
@RetiredWizard Are you still seeing this?
thank you!
@slender iron just FYI -- all of the intermittent behaviors I was having with web workflow seem to have cleared up by improving the wifi signal... It is not happy with weak signals and there are clear differnences between boards as to what they will tolerate.
I am, but I"m not sure I'm running the latest bits, let me grab them for my S2 and C3 and give it another try
It's still happening on both boards using the newest builds from the S3 site. It takes a lot of refreshing to get it to happen on the S2 but it happens pretty quickly on the C3. The C3 takes a bit to get it connected to the WiFi, I typically have to place it closer to the router and give it a couple power.
Given the less robust networking going on with the C3, I'm thinking that perhaps a network error is triggering the error.
I think @jerryn suggested that a weak WiFi signal creates some intermittent issues, and that's probably what's going on here.
I was thinking that perhaps the net::ERR_INVALID_CHUNKED_ENCODING 200 (OK) error could be caught and either a message displayed in the browser window or a partial directory listing displayed but perhaps just understanding that a poor WiFi connection = intermittent issues is all there is to be done at this point.
I wouldn't be surprised if a network error is triggering this in a similar way the file manager is being disrupted in issue #6654
@onyx hinge You was suggested I contribute my little circuitpython extension adventure to the newsletter. I have a mini article (~ 50 lines). Is that too much? Most of what I see in the news letter is very free flowing (not a traditional article format). This may not be the channel for these questions...
@hidden rain usually the newsletter is a few sentences, a photo, and a link to more info. If you don't blog or use twitter, you can do something like create a github gist with the "long version" and use that as the link.
ok. I will reduce to a few sentences, then just edit the 08-9-22 draft, then request the pull (submission) . ok.. all new and exciting.
I send in a PR every week for the podcast, Anne is great to work with on the newsletter
anne is out today and tomorrow for the most part
oh yeah, she's getting married!
OK. A title and four lines referencing the full story on my GitHub.
Nice! It'll be a few days probably until Anne has a chance to review it
ok.. Hopefully I did it correctly!
Otherwise, you may actually get a non-root filesystem.
Fixes #6575
welp, I got samd21 building with my libgcc that is smaller
can I "dibs" those bytes?
Finders keepers seems to apply here
Fix for #6576. Checks if the CS parameter is the correct type.
Looks great, it's clearer, and probably reduces code size!
That's what I did 😆
This prevents browsers from caching it. Thanks to MakerMelissa for
the suggestion.
fills up the CI
The title bar now has code execution status on all builds and BLE workflow info on those.
This PR also has a number of tweaks and fixes (hopefully not too distracting):
- It uses libgcc from my Arch install for SAMD21 builds (saving >750 bytes it seems.)
- Adds a
UID:line to boot_out.txt so to identify a device from a mounted filesystem. - Fixes BLE workflow. (It was broken by the workflow reset refactoring with web workflow changes.)
- Uses the ble name set on the adapter for the ...
Related issues: #6668, #6621, #6566, #6078, #4705, #5352, #5414, #2791
It's a very unlikely scenario but a device could have damaged flash but someone mounts an sd filesystem via the repl. This would make this function return true but the internal filesystem object would be invalid.
The rest of the PR is great though and this is an unlikely story so don't let this alone stop it being merged
Excellent idea. I looked up 302 vs 307 and now I understand that too.
Thanks for the fix. Suggestion to use one of the new validator routines.
We now have more validation helper routines that reduce the boilerplate and use a standard error message:
https://github.com/adafruit/circuitpython/blob/e0cb8ef17e294a502d3311681230e1c36ca0ce5f/py/argcheck.c#L233
mp_arg_validate_type(ARG_chip_select].u_obj, &digitalio_digitalinout_type, MP_QSTR_chip_select);
Only when the GitHub ci does the same
I made the CI use it
Yay!!
Sorry I knew there were new ones and thought I had it. Apparently I did not!
Could you retest the validation in the REPL just to make sure I did not typo the fix in some way? Thanks.
[I edited the initial comment to use the special syntax to link the issue and the PR together]
I built it locally and tested it before I pushed it from my own machine. I caught the typo.
heyya, how does CircuitPython currently handle "user wants to extend builtins from python" (i.e. the thing we currently do with the u-prefix)
(and related, how would you like it to work if we were to fix it upstream)
No, we'd inherit it from you if you did
ok. how do you currently support it?
or do you provide more stuff by default to make this less important? (os.path is a simple example off the top of my head)
@richsad - there is a MicroPytyhon Pico W build, including wifi: https://micropython.org/download/rp2-pico-w/
As mentioned above, the relevant commit in MicroPython is https://github.com/micropython/micropython/commit/50e46552c0c83b0c8570aba098a0ba4e68ae9eac
The library that supports the module is here: https://github.com/georgerobotics/cyw43-driver.git
Amended: I see Dan has provided the link I needed. Awesome.
I have two Pico-W (aka rpi2-PICO-W) boards in house and have a build system set aside on an Rpi4b 4GB or if needed an Intel linux machine. Thank you for the info @dhalbert . Maybe the fact I was searching at 3am may be partly why I couldn't find it!
I think you will vastly prefer the Intel Linux machine due to build speed. Don't forget make -j<n>: https://learn.adafruit.com/building-circuitpython/build-circuitpython#use-all-your-cpus-when-building-3086075
we don't provide it and haven't heard too many requests from folks
Coming from #4050. Is there any guide/example for OTA update?
The sort is now automatic, no click needed :). I pulled out a bunch of the original sort logic so it's a quite a bit smaller now.
CP already has very consistent libraries for display and framebuffer, but LVGL bindings would be a great addition.
There was an attempt some years ago: https://github.com/desterly/lv_circuitpython
But it did not get much attention and needs to be updated...
ok thanks. just raised https://github.com/micropython/micropython/issues/9018 if anyone is interested in this topic
We use the "u" prefix for built-in modules for several reasons (see #7499 (comment) for the full story). The primary reason though is to allow foo.py to exist on the filesystem an...
With regards to the library size discussion from weeds of this weeks meetings... I'm tinkering with some utility to clone a repo / branch, build mpy files from it, and then trying to output the most helpful measurements from that (and eventually intend to attempt loading it on a device, but not there yet).
Someone mentioned running strings some_lib.mpy to get output of all of the strings within the library that will consume RAM. Would it then be helpful to do something like strings some_lib.mpy > strings_output.txt to save that to a file and then output the size of that file? Or would it be better to somehow measure it without explicitly writing to a file? I'm not sure if that would have any impact on the measurement.
be careful that MPY files include the path you provided to mpy-cross, unless you use -s to override that
(that will affect the file size)
I'll have to look into how build-tools handles it. I'm using this to build instead of mpy-cross directly:
circuitpython-build-bundles --filename_prefix {get_project_dir_name(REPO_URL)} --library_location .
ok so there's no issue then, it should give it the correct path
Nice, thank you for the heads up. I'll double check my built versions against the one published in the bundle as well to ensure they are the same.
I think it shouldn't be too hard to have an actions task that can measure these things and output it as a comment on PRs or somewhere in the actions output info. That can give us at least a baseline quantification.
I have bigger and more complex plans to also attempt setting up a system that could load it on a device and take measurements from gc.mem_alloc() before and after importing and output those as well.
I'm pretty happy with this now, I don't think I can see any more optimizations.
Thanks @bergdahl @urfdvw @wtuemura !
@tannewt is it worth checking for this? Right now you go into safe mode if filesystem_init() fails for CIRCUITPY.
I think I will merge anyway to get this in and an issue could be opened if it's worth it.
To extend circuitpython to capture ADC using the DMA to a 'one-shot' buffer, one could extend the current AnalogIn with optional arguments or create a new interface AnalogDMAIn. The first is more universal and theoretically optional arguments would protect existing usage, yet the second although less universal forces a deliberate choice to use a new interface but at the cost of entirely new files. Please comment on the preferred choice for users since this could potentially be used across all platforms with a DMA & ADC. Thanks.
one problem is that it would need to be optional and disabled on the platforms that don't have enough flash for the extra code
that is easier done with a separate module
it's also easier to explain to the users that this functionality is missing then
The intent, at first is to create this for the RP2040 (Pico), not ambitious enough for multi-platform at this point. However, I see that it could be extended for other platforms. I think the same module, namely analogio could contain the new code, but is see the issue as altered current interface verses a new file(s) for a a new API per platform.
So if the platform does not have DMA or enough flash, then the file(s) would not be extended for that platform.
This is largely an architectual issue, right?
I think that all boards supported by circuitpython have dma
there is a similar, but separate, issue of making all the input/output modules compatible with asyncio somehow
generally we disable and enable functionality at the module level so I'd suggest a new module
I wonder if asyncio and dma support would be a good combination
you could await until the transfer finishes
Ok, so perhaps a new DMA Module which allow an interface to ADC, SPI, etc would be in order. The CPy asyncio will still not allow the data rates i'm reaching for...
I experimented with non-blocking spi for displays, and there was almost no speedup, most of the time is spent calculating the pixel data in displayio
Im glad I just read that, I was wondering about trying that out myself to speed displays up
A one-shot ADC thru DMA read to 1000 byte buffer would provide 2 microsecond sampling for 2 milisecond, which could be blocking for that time.
I might have done it wrong, I admit
Scott Shawcroft explains best practices for open interface design, using the Feather as an example case study.
I was looking at it from the point of trying to speed two independent displays up but didn’t get too deep myself
I basically just moved the while loop that waits for the transfer to end from the end of the function to the beginning of it
so it will return, but block when you call it again
Makes sense. I haven’t had a chance but also was going to look at what the max rate I can even expect from SPI is. It may not even really matter
if you look at the signal with a logic analyzer, there are long gaps between bursts of transmissions
Great! The code looks good. I noted the following things:
- The
@n ExceptionNamein the status bar does not include the filename. So for instance:
code.py:
import busio
import x
x.py:
1/0
says @1 DivisionByZeroError without saying which file it's in. If you feel there is room, I think including the filename would be good, since the error may be quite deep. The filename and the line number are more important than a possibly truncated exception name.
...
one way to maybe speed it up is to make displayio run on the second core on the rp2040 and esp32-xx platforms
but then you risk it will interfere with wifi
Interesting idea. I didn't look too much at where the real bottle neck is, the write to SPI or calculation of what to write.
I did learn calling display.refresh() twice (by accident) on the same display per update loop slows things down 🙂 oops
well, it would only makes sense with autorefresh, I think
unless display.refresh() was non-blocking
If I get a chance I should hook up an analyzer just to see how busy the SPI bus is to see what is slowly me down. Good ideas!
@slender iron For now it will be a new module, analoginfast. It can be renamed or generalized if it makes sense to do that later. Unless you prefer a different name. For the time being, it will be only for the Pico, we can extend it for other platforms later if useful. Please SHOUT if not acceptable.Thanks -lee
I think we would prefer that it be made part of analogio.AnalogIn.
you'll create an AnalogIn object, and this will be one new call that does a bulk multiple read into a buffer
@slender iron just suggested a separate module
@tulip sleet: Yes I know that what you had mentioned. Then tannewt chipped in. I am happy either way. The actual code is likely to be taken from dma_capture from the raspberrypi against the pico.
hmm, well, I would kind of prefer it in analogio.AnalogIn if the implementation is relatively small. It can throw NotImplementedError on ports where it's not done
I can talk to Scott about it. It does not matter too much for now; the bulk of the implementation is not related to where it is
Again Im easy either way. analogio would be much easier.
stuff like pin and ADC setup can be shared, which is one reason I'd prefer that
it could be shared with two modules, but would require refactoring
I think it would be less work to start with as part of AnalogIn. I am not suggesting a separate class.
Perhaps I should get it working under analogio first then move to new module if you guys decide its better later.
Sorry for all the confusion
if that's ok with @slender iron, that's what I would like, and I think it will be faster for you
it would just be probably one new API call in AnalogIn
ok... on my private build for now with analogio ..until it works
We already have a analogio.AnalogIn and analogio.AnalogOut. The original question was if i merely extend the current API to have optional arguments or create a new APi like AnalogFastIn.
I think you could do AnalogIn.read_multiple(buffer, length, rate) or something like that. It will fill the buffer with length samples, clocking at the given rate.
if it is not blocking, then there can be a .read_multiple_done attribute or something like that. I am not wedded to that name
or .read_multiple_remaining. depends on what you can know
I like that too.. so it is!
i think part of Scott's point is that we don't want to have classes appear/disappear from modules, but instead have separate modules. But in this case I think there's a convenient existing place for this functionality in an existing class.
can it be simulated on other ports ? (with less efficiency and whatnot but trying ?)
my main concern is the added code size of adding anything to analogin
@richsad glad Dan was able to provide you with the info needed and thank you for working on this :)
Do we have a timeframe for this release?
@vague tide I was thinking you could look at ulab too. It may use USER_C_MODULES
Anybody tried to compile CircuitPython with USER_C_MODULES=/path/to/ext/lib ? I´m struggling with integrating usqlite library to Circuitpython. Any hint very welcome. The closest information I found about doing this was this document: https://pi3g.com/2021/12/23/integrating-the-bsec-in-circuitpython-a-work-in-progress/
which also mentions the USER_C_MODULES= argument for the build. But one the Circuitpython I use (7.3.2) it never gets used.
oh ok, my post is already here
just replied (to you I think) on the forum
no, ulab is tightly integrated with the makefile and -as far as i dug- not using USER_C_MODULES
@slender iron @tulip sleet on https://github.com/adafruit/circuitpython/pull/6667 the issue of the exception types was raised, but those aren't new or changed in this PR. Is there anything else preventing this PR from being merged?
so, nobody here ever tried to use a third party C lib with Circuitpython ? if so, how ?
generally new modules are added into the main repo
lee just did an example module here: https://github.com/latkinso42/fibonacci/blob/Main/FibonacciStoryFULL.md
unlike MP, CP has split the Python -> C API code out of individual ports
(the shared-bindings directory)
i agree there are several examples of integration of bits of C code with CP. However, I want to integrate usqlite lib, which if perfectly functional with micropython (and easy to add thanks to USER_C_MODULES flag) and I don´t want to touch the code. I just want CP to read its micropython.mk or micropython.cmake and nicely fit it in my build.
also, nothing in this lib is port-specific
so what i need is really where in CP i should include that lib, if the USER_C_MODULES flag is not taken into account (it seems it is not, and it seems it used to be)
we don't do much with cmake so the .mk is probably the way to go
there are .mk files in py/ and in each port
yes, i saw that. But no generic way to tell the build process to grab those ?
mkdir modules
git clone --depth=1 https://github.com/spatialdude/usqlite modules/usqlite
make USER_C_MODULES=modules BOARD=adafruit_feather_rp2040 clean
make USER_C_MODULES=modules BOARD=adafruit_feather_rp2040 -j9
```I did this, and it gets errors while building the usqlite files so something is happening.
i did the same and nothing happened. and i cannot figure out why
which version are you using ?
678 | .getiter = usqlite_cursor_getiter,
| ^~~~~~~
```so usqlite will require changes before it can work with CircuitPython. we have changed how mp_obj_type_t is organized in order to reduce flash storage, which is the cause of this message.
i´m with 7.3.2
current/recent main branch
yes, usqlite will require changes, i expected that, and i´m ready to tackle these.
so the 8.0.0 ?
or 8. something
What do you think about sorting the data array in refresh_list() before it is put in the table? That should be even less code.
did you clone into modules/usqlite and then specify USER_C_MODULES=modules? One thing that initially tripped me up is that an additional directory level must be introduced.
The branch name I am using is "main".
i cloned usqlite in lib directory
in circuitpython
ok, i will give a try with the main branch, and i also stumbled upon that same "additional directory level2 thing too
before I step away I'll try it with 7.3.x branch as well
We did not knowingly break and then fix USER_C_MODULES
i wll dig that deeper and report my progress here (and on the forum)
here or an issue is a better spot
the forum can be distracting with folks asking for general support
and issue comments are posted here too
Could you try it with a curl command? I think the examples have detailed logging on. It may make it clearer what the issue is.
_mp_vfs.len isn't the length of vfs mounts. It's the length of the mount point string for the "native" filesystems vfs entry. So I think it'll be ok even when only an SD card exists.
I get the same results with main and 7.3.x branches of circuitpython
Including User C Module from modules/usqlite
and then compiler errors
weird. I spend a whole days struggling with that with no effect.
@slender iron I got the terminal working and am working on the file stuff. I currently have the hash tag params working, but realized we never really discussed what we wanted to do with regards to the password to access the file listings. Is this something we want to allow in the hash or should we just prompt the user for it?
Prompt maybe?
The browser may do it automatically
Ok cool. That's what I was thinking. Since the code is running outside of the device, it's not automatic.
Hmm, I might be able to use a slightly different approach that may automatically prompt them...
If you feel there is room, I think including the filename would be good, since the error may be quite deep. The filename and the line number are more important than a possibly truncated exception name.
Ya, I agree that'd be better. I'm not exactly sure how to get that info atm. The line number was convenient and I was hoping it was the top level, not bottom. (But I obviously didn't test it.)
I can test on the Feather S2 TFT when I get to this. I didn't try it specifically. Up to you i...
the browser should prompt I think. IIRC I saw it happen when doing local dev but calling out to the device
I think it's caused by the HTTP response code we send
Yeah, I'm going to try an xhttp request and I think that would do it.
I saw it with the new api just fine
xhttp was only interesting if wanting progress bar for upload
I didn't know they weren't new. I will approve and merge
@tulip sleet thanks!
Fixes #1010. Looks like it was a simple typo.
I will open some issues and merge now.
Thanks! Merging now and will open issues for further work.
Oops, there is a merge conflict anyway. Could you check on that, and then I'll approve and merge?
The @n ExceptionName in the title bar does not include the filename. So for instance:
code.py:
import busio
import x
x.py:
1/0
says @1 DivisionByZeroError without saying which file it's in. If you feel there is room, I think including the filename would be good, since the error may be quite deep. The filename and the line number are more important than a possibly truncated exception name.
I connected, then changed the wifi password to be wrong, did a hard reset. I see "Authentication Failure" after a 15-second or so delay. Then I changed the password back to be correct, and did another hard reset. On the device display (Feather ESP32S2 TFT), the IP address is shown, but the terminal title bar (running tio) said "No IP", and it did not show the code.py output:. This is a little bizarre because it should have come up properly and printed the usual initial text. Instead tio j...
so, we cannot guarantee being able to measure 1.5 ms on a trinket, right ? monotonic() looses millisecond precision after 1h, monotonic_ns() is not available, and ticks_ms is an int.
I tested this script on a matrixportal_m4 using CircuitPython 8.0.0-alpha.1 with 8.0 libraries and everything worked properly.
Thanks! Merging now and will open issues for further work.
Wow this is great. I have an M5stack Core 2 AWS edition, would love to try CircuitPython and the atecc library with the secure chip:
that sounds right to me
Tested this for over an hour on a matrixportal_m4 using CP 8.0.0-alpha.1 with 8.0 libraries and everything worked properly.
I'm getting my core2 branch ready to submit a PR, still fighting with the occasional freezes (I2S, might be a coincidence), but all the major stuff seem to be resolved. Since I started working on this, other contributors have been merging fixes and improvements that made some of the little changes I was making unnecessary, so thank you for that everyone :)
@scarolan They don't provide a schematic for the AWS model so it's hard to tell but I believe the crypto chip is the only difference be...
@slender iron looking at the web workflow circuitpython code, it doesn't look like there's a way to provide an offset in order to do partial file writes like we do with bluetooth. Would this be something that would be difficult to implement?
I noticed that atanf() and atan2f() were both pretty bulky functions. It's a definition that atan2f(y,1f) == atanf(y). However, the performance optimization that atan2f(y,1f) can be computed in this way has to also be removed.
On trinket_m0 this saves 488 bytes.
he's streaming, come ask in the live channel 😉
Ok, thanks.
huh but it doesn't work. I tested on esp32s3 and now atan(any arguments) or atan2(any arguments) crashes instead.
I missed that atan2f called atanf in two places, not just one.
Hey - anyone else out there running pre-commit / pylint/ black on windows? Willing to offer an opinion on why I can’t get it to work? Failing with error in cmd window, and failing silently in git bash shell…
@DavePutz - Thanks! I will close this as fixed.
The space that @tannewt recovered with the -Os libc I think will fix the arduino_nano_33_iot build? ru is overflowing slightly.
Here is a development build for the Core 2 if anyone would like to play around with it.
Also pushed it out on M5Burner 3.0, in the Core 2 firmware area.
It's is a complete 16MB flash image so it takes a little longer to write to the device.
I've been using Thonny 4.0.0b3 to interact with it and it's working pretty well here all things considered.
I was pretty pleased with myself for figuring out how to dispatch the event message to sortable_table class, but I think your right, this is a much straighter line to the goal.
I also decided to add a separate sort for folders so they show up at the top of the listing. Let me know if you don't think that's worth the extra code.
C:>curl -v -u :CPPasswd -H "Accept: application/json" -L --location-trusted http://10.0.0.206/fs/
* Trying 10.0.0.206:80...
* Connected to 10.0.0.206 (10.0.0.206) port 80 (#0)
* Server auth using Basic with user ''
> GET /fs/ HTTP/1.1
> Host: 10.0.0.206
> Authorization: Basic OkNQMTIz
> User-Agent: curl/7.84.0
> Accept: application/json
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Transfer-Encodi...
A little more detail from the dev console screen as well:

A slightly different message from curl:
modified_ns": 946686086000000000, "file_size": 4750 },{"name": "menu.txt","directory": false, "modified_ns":
946686098000000000, "file_size": 101 },{"
name": "cp","directory":
5
false
2* Illegal or missing hexadecimal sequence in chunked-encoding
* Closing connection 0
curl: (56) Illegal or missing hexadecimal sequence in chunked-encoding
These error are really pretty easy to generate on the C3, it takes a lot more work on the other boards. I have the C3 powered from a phone charger right next to the WiFi router.
This PR changes the link to the CircuitPython Day to the latest blog post, which includes the schedule of events (the original does not).
Thank you!
I've managed to make a new actions task that outputs sizes of the mpy file and strings within it. https://github.com/FoamyGuy/Adafruit_CircuitPython_SI1145/runs/7705514452?check_suite_focus=true#step:14:12
Neat!
In conjunction with https://github.com/adafruit/Adafruit_CircuitPython_asyncio/pull/25 this allows keypad-using code to await the presence of a new event:
async def aget(scanner):
await scanner.events.wait()
return scanner.events.get()
async def keeb(pin):
with keypad.Keys((pin,), value_when_pressed=False) as kb:
while True:
print(await aget(kb))
Aside from other issues (it'd be nicer to not need the aget function at all but be able to...
@onyx hinge have you looked at using asyncio.Event for keypad etc? I was thinking (a while ago) that it's a general mechanism that could be used to asyncify things without having to add async functionality to builtin functions (which is hard to do anyway)
@tulip sleet not yet. This is using the extension ThreadSafeFlag instead. btw did you make public the neopixel timing spreadsheet? over on qmk someone's dealing with an unusual neopixel like chip that I couldn't find datasheet for, and thought it might be helpful .. but maybe your document was not self-explanatory enough to be worth releasing.
the arrival of a keypad Event could set the flag in asyncio.Event, and something can await that, so no async operations have to be added to keypad itself
timings I arrived at are in https://github.com/adafruit/circuitpython/pull/6312/files
I think there's a step there that I don't follow. If keypad doesn't know anything about async, how does something happen as soon as the event arrives?
keypad is scanning in the background. If a keypad event is queued, an Event flag that is passed into keypad is set when the keypad event is queued. User code can await that Event
so all the keypad (or queue) does is call an optional callback function?
that's the general thing, but I was just going to pass asyncio.Event that would get set. I think there is _asyncio.Event??
so it could be native
I don't think there's a native event object
ok, no, I see that after looking
but an asyncio.Event is not an interrupt anyway. It's just something that's checked in the asyncio scheduler loop
so maybe it could even monitor just a shared boolean
I'm also not sure about calling back into arbitrary code during a background task. We do do this when folks use the old python-coded sdcard code.
This is almost exactly what ThreadSafeFlag does
it would be nice if it were related to the CPython features of asyncio
ThreadSafeFlag is not native either
no, it's not native, but what it does in set() is extremely limited
We can use an asyncio task that decides to run when there is an available keypad.Event. That could be done with pure polling right now that just checks the __bool__ value of the EventQueue
I am assuming that while we don't have threads, the semantics of the background task and a micropython thread are similar enough (e.g., only called between execution of bytecodes) that I can just not worry about the details
that's what my examples in the asyncio guide do already, if I remember right
but then you have to decide how frequently to sleep between checks. await asyncio.sleep(0) doesn't seem ideal, but what is?
it's just yielding, so something else can run. If there's nothing else to run, it will check again immediately. Are you wanting to light-sleep instead to save power?
It's more about how much it takes away from other computational tasks, but I guess that's not sensible; a computational task won't await anything so this await sleep will not return
I'm totally fine with this change not going in, of course. I wanted to understand a bit more about how core code could interact with asyncio and it's a bit weird
There is an open issue in MicroPython to provide some kind of native Event support, I think, for various specific native things. They were wanting to do something like select() on stream, for example. I will find the issue.
while I've got your attention ... This code frequently crashes (USB stops responding) rather than finishing: ```py
SPDX-FileCopyrightText: 2022 Dan Halbert for Adafruit Industries
SPDX-License-Identifier: MIT
import asyncio
import board
import digitalio
async def blink(pin, interval, count): # Don't forget the async!
with digitalio.DigitalInOut(pin) as led:
led.switch_to_output(value=False)
for _ in range(count):
led.value = True
await asyncio.sleep(interval) # Don't forget the await!
led.value = False
await asyncio.sleep(interval) # Don't forget the await!
async def crash():
1/0
async def main(): # Don't forget the async!
led_task = asyncio.create_task(blink(board.LED, 0.25, 10))
crash_task = asyncio.create_task(crash())
await asyncio.gather(led_task, crash_task) # Don't forget the await!
print("done")
asyncio.run(main())
It never prints `done`.
code.py output:
Traceback (most recent call last):
File "/lib/asyncio/core.py", line 214, in run_until_complete
File "code.py", line 19, in crash
ZeroDivisionError: division by zero
[tio 11:47:17] Disconnected
should I file a bug, I suppose?
no activity for 4 years doesn't bode well
gather does not catch exceptions itself
without return_exceptions=True, not sure that's implemented in MicroPyton
exception handling with asyncio is a mess, hence TaskGroups in trio and Python 3.11. Gather does not do exactly what people want
I really thought there's a more recent dicussion of what they want Event to do. Maybe it's just some TODO's somewhere in the code
I don't know what "does not catch exceptions" means, but at worst shouldn't USB stay connected and I can ctrl-c it if necessary?
i agree it is a bug, I did not test the exception handling. If you put the gather inside a try-except, does it catch it?
no, await gather seems never to return somehow
try:
await asyncio.gather(led_task, crash_task) # Don't forget the await!
except Exception as e:
print("some exception occurred, ignoring")
CircuitPython version
Adafruit CircuitPython 8.0.0-alpha.1-96-g3bff36685-dirty on 2022-08-06; Raspberry Pi Pico with rp2040
Code/REPL
# SPDX-FileCopyrightText: 2022 Dan Halbert for Adafruit Industries
#
# SPDX-License-Identifier: MIT
import asyncio
import board
import digitalio
async def blink(pin, interval, count): # Don't forget the async!
with digitalio.DigitalInOut(pin) as led:
led.switch_to_output(value=False)
for _ in...
@onyx hinge you could try gather(..., return_exceptions=True)
it is implemented in the library. There are some fixes to the library and the impl upstream which are not incorporated yet; not sure they have anything to do with this
accepted but no difference
asyncio version is
__version__ = "0.5.12"
no difference if `return_exceptions=True`` is specified.
@onyx hinge you could try disabling _asyncio and see if it still fails when the non-native impl is used
easy to do by editing the library instead of recompiling
Using the pure-Python implementation of Task and TaskQueue, the problem does not occur.
perhaps we should modify the library to not use _asyncio right now
no fixes in micropython since 1.18 look related
it could be how we do C scheduling of stuff. They way they do it is pretty different
or it could be due to the way we do async/await, which is a little different (we implement __await__ (courtesy WarriorOfWire) and they don't)
was the neopixel info useful?
I passed it on, too soon to say
the circuitpython build of micropython-coverage's async doesn't work right. It doesn't alternate between two tasks at all
I had to slightly massage circuitpython_ticks for it to work, maybe I got that wrong
using non-native for Task, TaskQueue makes micropython-coverage work as expected. I wonder if there is some mismatch between what we need from Task and TaskQueue, and what our micropython-originated C code is doing.
I feel like I learned a lot so that's good 🙂 now I should do something else with my day that is clearly NOT work 😜
i am glad you spent time on it and opened the issues, which were kind of on the back burner but I had forgotten about, esp the native vs non-native. I had a confusing time testing that stuff
You're welcome!
After building 8.0.0-alpha-1 with the stack size modification from PR #6514 the crash/hang is resolved; CP now throws an error:
from adafruit_gc_iot_core import MQTT_API, Cloud_Core
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "adafruit_gc_iot_core.py", line 42, in <module>
File "adafruit_jwt.py", line 39, in <module>
File "adafruit_rsa/__init__.py", line 17, in <module>
File "adafruit_rsa/pkcs1.py", line 20, in <module>
File "adafruit_h...
CircuitPython version
Adafruit CircuitPython 8.0.0-alpha.1-102-g01f252d12-dirty on 2022-08-06; Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM with ESP32S3
Code/REPL
import time
while True:
time.sleep(1)
print(".",end="")
Behavior
If you connect to microcontroller over the USB serial port this program can be interrupted by pressing ctrl-C:
...Traceback (most recent call last):
File "code.py", line 3, in
KeyboardInte...
Not sure if I can ask this here but it seemed like the most appropriate channel. What's the status of BLE support on the ESP32-S3? I tried finding a PR but wasn't able to locate one.
I'd say: stuck https://github.com/adafruit/circuitpython/issues/5926
Thanks.
I was curious because I have been testing cancellling tasks (catching asyncio.CancelledError after a few trials and errors) and did not notice that issue. Then again it was with never-ending loops. Anyway I did some tests and...
This causes the issue:
async def crash():
raise Exception("oops")
But this doesn't:
async def crash():
raise BaseException("oops")
Instead it leads to:
Traceback (most recent call last):
File "code.py", line 102, in ...
hey! I'm trying to compile circuitpython for BOARD=adafruit_macropad_rp2040 but I'm getting errors related to rom_hword_as_ptr function like this:
sdk/src/rp2_common/pico_bootrom/include/pico/bootrom.h:129:66: error: array subscript 0 is outside array bounds of 'uint16_t[0]' {aka 'short unsigned int[]'} [-Werror=array-bounds]
129 | rom_table_lookup_fn rom_table_lookup = (rom_table_lookup_fn) rom_hword_as_ptr(0x18);
I've tried building on main and and 7.3.x branch but the result is the same.
Can someone help me to fix it? Maybe I need some specific version of gcc?
$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/12.1.0/lto-wrapper
Target: arm-none-eabi
Configured with: /build/arm-none-eabi-gcc/src/gcc-12.1.0/configure --target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi --with-native-system-header-dir=/include --libexecdir=/usr/lib --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib --with-newlib --with-headers=/usr/arm-none-eabi/include --with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc --with-isl --with-libelf --enable-gnu-indirect-function --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='Arch Repository' --with-bugurl=https://bugs.archlinux.org/ --with-multilib-list=rmprofile
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Arch Repository)
I just tried another rp2040 board and it failed for the same reason
Is there a docker image that I can use to compile circuitpython? I have tried finding if github actions have one but it seems like no
I haven't seen that error...
to start did you follow the guide ? there's a few steps to get the right environment and things, including the version of gcc https://learn.adafruit.com/building-circuitpython
we are using gcc-arm-none-eabi-10.3-2021.07 I believe
or the github workflow seems to reference 10-2020-q4 actually
thanks, I was using whatever arm-none-eabi-gcc I had from AUR
downloaded the latest manually and it worked
Did you try this without A10, C14, or C15 at all?
I'm not using pin A10. For pins C14 and C15, I'm using this bugfix (i.e. commenting out never_reset_pin_number() here) that gets them to work (except in the situations listed below). But you're right, leaving them out of row_pins and column_pins allows to detect _som...
first time making a PR here for this. so please let me know if im missing anything or need to change anything. thank you.
When the problem occurs, task_iternext is called while the task "is done" but data is mp_rom_none.
STATIC mp_obj_t task_iternext(mp_obj_t self_in) {
mp_obj_task_t *self = MP_OBJ_TO_PTR(self_in);
if (TASK_IS_DONE(self)) {
// Task finished, raise return value to caller so it can continue.
nlr_raise(self->data);
This value (a special constant 0x6, which is not a valid pointer) ends up being checked as follows in py/vm.c:
if (mp_obj_is...
It looks like this is related to a gcc regression, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 -- You could try adding -Wno-array-bounds to CFLAGS.
I also decided to add a separate sort for folders so they show up at the top of the listing. Let me know if you don't think that's worth the extra code.
I'd rather not, I always found that terrible and confusing. For example sometimes people have a hard time finding a library in the Bundle because they have to look in 2 separate alphabetized lists. I'd prefer if it were an option in an advanced interface.
@tulip sleet Finally coming around to working on async requests. I've noticed that the .tox directory in git is not ignored. It looks to be an auto-generated directory, is there a reason why it isn't?
Also thank you again so much for the base to work on. This week I should get some testing done on my board with Sync and Async requests!
Also if you have no idea and there is a pull request I'll let whoever is the code czar make the decision 🙂
Is there a .tox dir in the repo, or in your environment? You can add .tox to your personal .gitignore. If it's already in the public repo, delete it
Learn something new every day! Will do
@lone axle was this intentional?
https://github.com/adafruit/Adafruit_CircuitPython_SI1145/commit/1f73410d5104db0e921b1abebaff22e742e3e58e
No, definitely not
I was pushing to my fork to test some changes to actions. I did end up in a weird state with my local repo, but did not intend to, or realize that anything pushed to remote
I am not certain of the proper way to revert back to the commit from before that, but that is what will need to happen I think. I am a bit scared to try pushing a fix for it in fear of messing it up further
okay, github desktop application makes the revert very simple. I have reverted and pushed. But definitely happy to have anyone else double check to ensure it's back to normal.
I was using a espressif Saola Wroom (smaller memory) for my previous test. I did some more testing using a MagTag (which has a lot more memory). It also hung without the patch from PR #6514. Compiling with that patch and running
"from adafruit_gc_iot_core import MQTT_API, Cloud_Core" gc.mem_free() reports that 73936 bytes
were used. This looks like mainly due to the import of adafruit_rsa, which took up 64080 bytes. So, a Feather S2
should have enough memory as well to work once that stac...
Hmm I am also interested in creating an i2c slave using a seeed Xaio rp2040, I compiled and loaded @kstillson 's Fork. I have noticed when running the example code: https://docs.circuitpython.org/en/latest/shared-bindings/i2cperipheral/index.html#module-i2cperipheral The loop terminates because device.request is returning an address of 0x40 in the absence of an actual request (empty body).
I guess I've gotten used to it because Windows sorts folders to the top. If I don't see the /lib folder at the top, my first thought is that it's not there.
That being said, dropping the extra sort would probably cut a third of this update out so I can certainly see a case for leaving it out.
https://github.com/micropython/micropython/issues/8440#issuecomment-1207485615 hum does this work in circuitpython now? My testing did cover i2c bus scan using the stemma qt port and I think the pins are shared. but I don't know that anyone but me has tried it. (I checked the box on https://github.com/adafruit/circuitpython/pull/6571) -- just reminded of that micropython issue due to fresh activity today.
@tulip sleet someone over on qmk made a massive list of RGB LED timings https://cdn.discordapp.com/attachments/867530715192885269/1005740259000205312/WS2812b_and_clones.ods
if you believe datasheet numbers of course
Is there a reason why MICROPY_REPL_EMACS_KEYS is not defined for circuitpython/shared/readline/readline.c? Is it just so Ctrl-B will work? I would really like Ctrl-D to delete character and Ctrl-K to kill the line https://github.com/adafruit/circuitpython/blob/main/shared/readline/readline.c#L164
ctrl-d restarts the board
not mid-line it doesn't, Ctrl-D only restarts the board if it's first char on empty REPL
yeah, a traditional Unix terminal device only recognizes ctrl-D as end-of-file at the beginning of a line (if in "cooked" or "line" mode)
(there's an explicit callout in readline.c for when Ctrl-D is midline)
You could open an issue. People would probably not find it confusing. It does make builds larger, but not by a lot. We could leave it off for the smallest builds.
Thanks. I'll look more into the history and see if there's any obvious "This is why we don't do that"
I think it was just to save space. I was the only emacs user I knew of early on; no one else requested it.
what I would like is support for whatever Terminal does to move the cursor by one word when I do alt-left-arrow, is that in there ?
ah there's ctrl-a for start of line, not practical with my tio bindings but probably good enough
on emacs-enabled terminals, moving foreward/backward by word is Alt-F / Alt-B. It doesn't look like circuitpython readline supports that
oh wait ctrl-a is already enabled ?
Ctrl-E & Ctrl-E work yes
well, you learn something every day
maybe there is an opportunity to save further space on small builds there
I use arch and haven't had a problem
I installed the latest arm-none-eabi from aur and it didn't work. Maybe I needed a different package
I'm using arm-none-eabi-gcc it is version 12.1
ah, I get the errors too
I probably fixed it last time I worked on rp2040
and by "fixed" I mean disabled that warning
I started taking a look at this myself this weekend. I think it may be close. Please let me know if anyone has any updates they haven't posted. The datasheet does have a lot of good information. I hope to take a further look tomorrow and get my logic analyzer hooked up to get a better picture of what is being sent.
I will most likely be dusting off my logic analyzer as well. Might we tweak the code to allow for a null address (just read everything going down the wire)? I feel this would prove advantageous for future diagnostics.
I will most likely be dusting off my logic analyzer as well. Might we tweak the code to allow for a null address (just read everything going down the wire)? I feel this would prove advantageous for future diagnostics.
Now that I think about it, it would also allow us to emulate multiple slaves with a little python support logic.
I was just about to file a similar issue.
On a Feather ESP32S3 running 8.0.0-alpha.1-102-g01f252d12
If I start a program executing (import foo) vi the web workflow serial terminal then I am unable to terminate the program with a control-C.
I have to RESET the board then reconnect the serial terminal to get back to the REPL.
for web workflow could be something nice with WASI there is bytecode alliance have this WASM micro runtime and wasmer have webassembly package runtime what might work some improvement so could be intereting with circuitpython way on that
https://github.com/urfdvw/cpy-ol-console huh it looks like this not very far along yet but from the part of the description that's in English it sounds interesting. the github user also contributed to the Chinese translation of circuitpython this week, which was why I was looking at their github.
CircuitPython Online Console. Contribute to urfdvw/cpy-ol-console development by creating an account on GitHub.
River Wang follows me on Twitter and tweets about it every once in a while. River was a teacher and was building it for that, but is now a software developer.
It's pretty neat
aha! I didn't recognize them by their github name.
@idle owl but also generally since it's pretty major: I think we're good to flip the libraries to pyproject.toml!
Simply wanted you to be around for it.
I have everything ready and can start tonight, I'll bring it up in the meeting, but I won't be able to listen in live today (at least for the first half)
I guess the only thing that might help is a pause on merges while it's happening, which is why I'd do it in the evening EST.
Fair enough.
Sounds good.
@proven garnet We'll mention the merges thing In The Weeds so folks know. Please come up with a timeframe.
Will do!
@tulip sleet I don't know exactly what's going on yet, and it's running code that is waiting to be merged, but on this esp32 board (espressif-esp32-eye) I'm seeing stuff that smells an awful lot like memory corruption. Everything kinda works but I get weird errors in which arguments have impossible types or values. In one case it even complains I've called a function with the same kwarg specified twice but it's in the source only once. It involves the camera too so the problem COULD be related to that. .e.g., Traceback (most recent call last): File "<stdin>", line 147, in <module> File "/lib/adafruit_io/adafruit_io.py", line 446, in publish File "/lib/adafruit_minimqtt/adafruit_minimqtt.py", line 596, in publish TypeError: unsupported types for __le__: 'int', 'type' but there's no way that argument could be a type. and it went away when I printed the value of the function parameter. Have you seen any weirdness like that with esp32?
is weird
I haven't, but this does seem like a memory problem. If you simulate camera use, with and without the reserved buffer, do you see the same thing?
no, I didn't try faking the camera. It's an obvious thing to do though.
earlier I was refering this WAMR as it might able to use those tips what foamguy have showed https://github.com/bytecodealliance/wasm-micro-runtime on the web workflow
Thank you @Lisapple, @bergdahl, and @wtuemura.
CircuitPython version
Adafruit CircuitPython 8.0.0-alpha.1-103-g0ed84486f on 2022-08-08; Adafruit FunHouse with ESP32S2
7.3.2
Code/REPL
"""
In test_mod.py
"""
import displayio
main = displayio.Group()
sub = displayio.Group()
main.append(sub)
print("In module, is sub in main ? Expecting True:", sub in main)
"""
In code.py
"""
import displayio
from test_mod import main, sub
print("In code.py, is sub in main ? Expecting True:", sub in...
Do you think this might be a manifestation of this bug?
https://github.com/adafruit/circuitpython/issues/2687
Shouldn't need to update the URL again.
Thanks for the test @DavePutz. Closing it now.
@steveatinfincia Feel free to PR it. We're happy to have follow up PRs for any further fixes.
whats CPs current state of f-string support?
On most boards. Some boards don't support it. AFAIK.
Looks like there is a mis-identation that pre-commit could fix: https://learn.adafruit.com/improve-your-code-with-pylint/check-your-code-with-pre-commit
Adafruit CircuitPython 7.3.2 on 2022-07-20; Adafruit Trinket M0 with samd21e18
>>> foo = "world"
>>> print(f"hello {foo}")
hello world
ah neat. even workin on a wee trinket. 🙂
do we have any general guidance on usage? like using in libs = OK?
I would ping Dan. Maybe it's on all boards now. He would know.
@tulip sleet thoughts on f-string usage? (see above). also asking because of this PR for more context:
https://github.com/adafruit/Adafruit_CircuitPython_MAX31856/pull/20
Dolphin in KDE also sorts folders above files when sorting by name. I think that's pretty common.
I believe @tulip sleet flipped the switch on it
So they all should have it, even the smaller boards
that's correct, f-strings everywhere now
f-strings for everyone! 🎉
I don't think our f-string support is complete though
I think folks have found things that work in CPython but not CP
Has anyone run circuitpython on an fpga soft core at all?
@gilded cradle If you're comfortable, can you approve this PR? I'd like to get it live. https://github.com/adafruit/circuitpython-org/pull/1014 (It's totally ok if you're not up for it.)
I'll look in a bit
Gotcha, that’s pretty cool. I might check it out at some point when I have a larger fpga that can run litex
Thank you! Not sure if Justin's out today, so I thought I would ask.
Thank you Melissa!
You're welcome. It was a simple change.
Yep 🙂
Plus my head has been in the web stuff space for a while, which makes things easy.
Bonus!
<@&356864093652516868> Hey all! It's a scant 18 minutes until the weekly meeting. Please add your notes to the notes document https://docs.google.com/document/d/1Zm1TPFm0mBhFvzQWCashMrcrBoR_d2SQMGtBrvQ7oSE/edit?usp=sharing and if you can, join us in the text channel.
CircuitPython Weekly Meeting for August 8, 2022 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 parti...
lurking today -- may have to leave at any time... Thanks to all for web workflow -- it is working great!
Happily lurking 🙂
did it work?
The "just one more run" followed by "OMG what time is it" moments
👍
I think I can do the core
Overall, this looks pretty good. I'd like to see a bit more info and discretion about the properties of the camera that are exposed.
I know it's annoying but these properties should really explain what the property is. That way folks don't need to look further for that info. If a property is unlikely to be used, then just remove it. It is ok to not expose everything.
<insert appropriate space analogy here>
Getting married at Kennedy Space Center Visitor's Complex was out of this world
Still time to enter the HACKtablet giveaway: https://gist.github.com/FoamyGuy/642358cf5c8193b2b4b4704d10f021c6
Wood, plastic, and luck are the key materials for the tiny consoles.
@mental nexus break beam sensor wouldn't work?
I’m looking to measure the ball position on the lane. It’s to help train folks to pay attention to where they are bowling vs the arrows.
For new bowlers they pay more attention to the pins, want to give feedback about where they are bowling on the lane.
Could you use the break beam to trigger the distance sensor measurement?
That’s probably possible, but would require something on both sides of the lane. At best case it can just sit on one side of the gutter.
Just, wondering if web workflow should be multi-lingual, and how... If string (web page) are not normal string to be translated. Maybe that is for in the weeds? But there is not urgency, it is mostly curiosity.
End goal is to cantilever an LED strip over the lane to highlight where the ball went.
Thanks! Don't know why the chat was so hard to find!
I would like it to be. I'm wasn't able to find a common way to have html translations either
it would be nice to have it work through weblate
Happy to do so if there's interest!
@onyx hinge I think I have a PR waiting for the cookiecutter
Will you need a couple of folks on standby to help if something goes awry?
but it sounds good to me
I think I should be good solo
What could go wrong? 😉
I think anything awful will be limited to a few libraries, not on the massive scale
cool, I should be ping-able after 10pm eastern just in case. I don't know much about it either but just in case
Oh, looks like I do need to PR the changes to the cookiecutter, I can get that done today
Does the change impact using pip3 install . to install a local version?
@proven garnet OK, please make sure cookiecutter is using pyproject.toml. And, consider a guide, we'll see whether it is approved. Thanks!
Thank you!
Thanks all!👋
Thanks!
thanks all
Thanks!
For anyone working on the core with tannewt off for a while and that he does a lot of reviews, feel free to tag me on any reviews you need help on. I do my best to check it but dont always remember.
I did NOT do well at taking timecodes today
we have CPy timecode gadgets if you want one
@proven garnet Does the change to using pyproject.toml impact using pip3 install . to install a local version of a library?
uses a CPX; press reset when starting record. Press button B for each timestamp
Or I have code and 3D print files for a Feather using a NeoKey FeatherWing. Same concept though.
@tulip sleet I have a hot-key I just forgot to use it
me too
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/1AQqEMgemmn7GiPWfkrGbyr3ViaGPSAtYIwdclGa3XPE/edit?usp=sharing
CircuitPython Weekly Meeting for August 15, 2022 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...
@tulip sleet should web workflow be working for the feather huzah32?
we have not tested wifi on huzzah32 yet, so I don't know if it will work
if you connect to the repl, does something interesting show up in the title bar of the terminal?
that's where the status bar goes when connected serially (it uses escape codes to change the title string)
i will try it
just rebuilt current main - mine was a day old -- still same
Cool! standard wifi_test works on the huzzah32!
CircuitPython version
Adafruit CircuitPython 8.0.0-alpha.1-104-gf1826b054-dirty on 2022-08-08; Adafruit KB2040 with rp2040
Code/REPL
### this is hypothetical
Behavior
I was trying to add the ability to await an keypad.EventQueue. Along the way, I investigated how poll works internally. I found that the request value is MP_STREAM_POLL. However, some code (such as busio.UART) uses MP_IOCTL_POLL instead. Check out the documentation or some ...
Adafruit CircuitPython 8.0.0-alpha.1-104-gf1826b054 on 2022-08-08; Adafruit Feather HUZZAH32 with ESP32
>>>
>>> import wifi_test
<Network> MYSSID -77 6
<Network> MYSSID -60 11
None
ip 10.0.0.101
8.8.4.4
ping 0.057
200
circuitpython open issues 573
circuitpython stars 3118
200
This is a test of Adafruit WiFi!
If you can read this, its working :)
200
{'url': 'https://httpbin.org/get', 'headers': {'User-Agent': 'Adafruit CircuitPython', 'Host': 'httpbin.org', 'X-Amzn-Trace-Id': 'Root=1-62f16177-0413b9a44654517004c9cd30'}, 'args': {}, 'origin': 'redacted'}
200
{'timezone': 'America/New_York', 'utc_datetime': '2022-08-08T19:18:16.125789+00:00', 'raw_offset': -18000, 'client_ip': '71.232.151.158', 'dst_from': '2022-03-13T07:00:00+00:00', 'unixtime': 1659986296, 'utc_offset': '-04:00', 'datetime': '2022-08-08T15:18:16.125789-04:00', 'week_number': 32, 'abbreviation': 'EDT', 'day_of_year': 220, 'day_of_week': 1, 'dst': True, 'dst_offset': 3600, 'dst_until': '2022-11-06T06:00:00+00:00'}
done
>>>
however I did discover the stuff to add to the core so that I can define a small wrapper class and then await keyboard events
class AsyncEventQueue:
def __init__(self, events):
self._events = events
async def __await__(self):
yield asyncio.core._io_queue.queue_read(self._events)
return self._events.get()
def __enter__(self):
return self
def __exit__(self, exc_type, exc_value, traceback):
pass
async def key_task():
print("waiting for keypresses")
with keypad.KeyMatrix([board.D4], [board.D5]) as keys, AsyncEventQueue(keys.events) as ev:
while True:
print(await ev)
ctrl-c doesn't break out of the async, that's curious
as soon as you press the button it does
This allows a small wrapper class to be written
class AsyncEventQueue:
def __init__(self, events):
self._events = events
async def __await__(self):
yield asyncio.core._io_queue.queue_read(self._events)
return self._events.get()
def __enter__(self):
return self
def __exit__(self, exc_type, exc_value, traceback):
pass
and used to just "await" the next event:
async def key_task():
print("waiting f...
Who would have imagined… an NTP synced clock on a Feather Huzzah 32 running CP. 🎉
is that the new lcd wing by Joey?
Yes -- very nice!
I am looking forward to trying some low-power projects with it. Just started playing with it.
I made a shield with the same chip, but still need to program it
@tulip sleet -- this would explain why it is not working for me https://github.com/adafruit/circuitpython/blob/main/ports/espressif/boards/adafruit_feather_huzzah32/mpconfigboard.mk#L14 I can try enabling it ...
yay! `
Adafruit CircuitPython 8.0.0-alpha.1-104-gf1826b054-dirty on 2022-08-08; Adafruit Feather HUZZAH32 with ESP32
import wifi
wifi.radio.ipv4_address
10.0.0.101`
just made these changes ```jerryneedell@Mac-mini espressif % git diff
diff --git a/ports/espressif/boards/adafruit_feather_huzzah32/mpconfigboard.mk b/ports/espressif/boards/adafruit_feather_huzzah32/mpconfigboard.mk
index 2ed08856f..620f6fafc 100644
--- a/ports/espressif/boards/adafruit_feather_huzzah32/mpconfigboard.mk
+++ b/ports/espressif/boards/adafruit_feather_huzzah32/mpconfigboard.mk
@@ -10,8 +10,8 @@ LONGINT_IMPL = MPZ
so increase it to 32.
CFLAGS += -DCFG_TUD_TASK_QUEUE_SZ=32
-CIRCUITPY_STATUS_BAR = 0
-CIRCUITPY_WEB_WORKFLOW = 0
+CIRCUITPY_STATUS_BAR = 1
+CIRCUITPY_WEB_WORKFLOW = 1
CIRCUITPY_ESP_FLASH_MODE = dio
CIRCUITPY_ESP_FLASH_FREQ = 40m
jerryneedell@Mac-mini espressif %
Having some issues with serial terminal -- file browser seems ok
nevermind --- just needed a RESET -- serial terminal working now. -- sort of ...
It was explictly disabled for huzzah32
(was in a meeting)
it is on by default for esp32
I will submit a PR
It seem to be working OK with some issues getting into and out of serial terminal -- seems to cause some problems -- still experimenting.
Thanks -- I thought there might other issues you would be dealing with so easiest for you to turn this on when you are ready. It is great the have CP working on the huzzah32. Thanks!
now to port it to the Huzzah32 breakout!
And I can dust off many old boards...
thanks for testing @solar whale
No problem -- Glad to help!
After so many years of saying ..sorry no esp32 support ... this will be fun for a lot of people!
Does the web workflow work on a PyPortal Titano as it has an ESP32 chipset?
@proven garnet While you're doing CP things tonight, can you check on whatever is involved with Adabot producing the CP Libraries report that we use in the CP Weekly, and make sure it's still good to go? It was a rate limit that stopped the report from being generated last night, so it seems unlikely that it will continue, but maybe poke it anyway, if you could. Thanks!
On the Titano, the ESP32 is not running CP -- it is using the NINA firmware, so I think it not part of the web workflow...yet
Thanks! I put the latest firmware on it and it wasn't seen, so that makes sense
web workflow depends on CIRCUITPY_WIFI https://github.com/adafruit/circuitpython/blob/main/py/circuitpy_mpconfig.mk#L486 so I think it has to be one of the boards with native wifi.
we have talked a bit about native ESP32SPI support so web workflow would work. definitely not coming soon
@tulip sleet think it should be @<line number> <filename> <exception name>? or drop exception name
Looks like there is a mis-identation that pre-commit could fix: https://learn.adafruit.com/improve-your-code-with-pylint/check-your-code-with-pre-commit
I will look into fixing that when I get home in the morning.
Thanks
Done in #6698. I don't think we need USB status.
I'd include the exception name -- you could truncate it to a dozen chars or so if you feel it would push everything else off the right end on a TFT, etc.
k, I have it included.
we can see how well it works in practice and adjust accordingly
Add the exception filename after the line number and change the
line number so it is in that file. It used to always be code.py.
Fixes #6702
I think this will be context for our meeting later: https://github.com/micropython/micropython/pull/8914
Chances are it's my doc status checker 😅
I tried to manually slow it down but maybe it's not enough
Is it possible to increase it? It may be worth silencing until we find and API friendly way of doing it, or can have the limit raised
(RTD limit, that is)
Do you have the error somewhere that I can confirm that?
I think I found it, it's actually the existing adabot code, I'll look into it tonight :)
This frequency can be set to 0 for the system (133mhz) clock speed.
Thanks! I double checked the implementation and that's exactly what it does.
Did the terminal title bar should "Auth failure" correctly? I suspect the issue may be that USB is coming up after the newest title bar updates have been sent since the display is connected from the get go.
I'll add a title bar update request when the dtr line is set over USB CDC. That way we'll send it again.
This ensures that the USB serial connection gets a copy of the
latest title bar.
Fixes #6703
@slender iron @onyx hinge I thought it was https://github.com/micropython/micropython/issues/9018 that was what jimmo wanted to talk about; maybe both
I have a similar issue to this. I imported storage correctly but the filesystem is stuck in in read-only for circuit python. I followed this guide and it didn't work. The filesystems mode was never changed. I am using the metro m4 express.
Boot.py:
import board
import digitalio
import storage
# For Gemma M0, Trinket M0, Metro M0/M4 Express, ItsyBitsy M0/M4 Express
#switch = digitalio.DigitalInOut(board.D...
I know it's early days for this chip so I'm really just curious about this. The Huzzah specs indicate it has 520KB of SRAM, 120K more than the Qt Py C3's 400KB but an initial gc.mem_free() on each shows the Huzzah has just 3K additional RAM available. The Huzzah has more peripherals so I suspect it has more build options turned on.
My filesystem isn't allowing me to write to it. I imported storage correctly but the filesystem is stuck in in read-only for circuit python. I followed this guide and it didn't work. The filesystems mode was never changed. I am using the metro m4 express.
Boot.py:
import board
import digitalio
import storage
# For Feather M0/M4 Express
switch = digitalio.DigitalInOut(board.D2)
switch.direction =...
While I haven't benchmarked this, I believe it's more efficient than an async def that would poll the EventQueue, like
async def aget(event_queue, interval):
while True:
if (event := event_queue.get()) is not None:
return event
await asyncio.sleep(interval)
because the checking for event availability happens without even entering Python bytecode, within select.poll. It's still polled internally, but just from efficient "C" code.
Did the terminal title bar should "Auth failure" correctly?
Right, exactly, I think your diagnosis is correct.
Alright, pyproject.toml switch is starting now!
Oh ok it's not special to displayio Groups. I'm surprised I didn't encounter it before.
You have some switch logic in your code.py. The read/write status of the Circuit Python Flash is determined when boot.py is run only, so any changes to the switch value in code.py will have no impact on the flash.
It looks like your boot.py should correctly set the read/write status when the Metro M4 is powered up. In order to set the flash so Circuit Python can write to it, you need to jumper D2 to ground and then power up or press the reset button on the Metro. A control-D reset will **N...
CircuitPython version
Adafruit CircuitPython 8.0.0-alpha.1-102-g01f252d12-dirty on 2022-08-08; Adafruit Feather HUZZAH32 with ESP32
Code/REPL
import board,time,digitalio
#1.6 volts on D13
time.sleep(5)
led=digitalio.DigitalInOut(board.D13)
#0 volts on D13
time.sleep(5)
led.deinit()
#1.6 volts on D13
Behavior
The voltage on pin D13 switches between 1.6V (when D13 isn't in use by digitalio) and zero volts as noted in the comments. 1.6 ...
We're all set! Everything is upgraded to pyproject.toml! I checked the CI for the builds and I fixed the few issues that popped out.
The only thing left to do is release them all (a test release of one implies that it should go smoothly!)
Please don't hesitate to ping me on GitHub or Discord if anything weird happens as a result, but so far it looks like a painless transition!
Congrats and thanks for the migration!
I'm thinking this has to do with the ESP32 floating GPIO high to avoid neopixel problems. There's no neopixel on this board though.
@tannewt I would like to work on this issue.
Thank you
hmm, not sure why pre-commit is failing here. it passed when I ran it locally.

Tested.
The disabling settings were on for debugging reasons previously, and should have been removed in the original HUZZAH32 PR.
Thanks!
How about filename.py@1 instead of @1 filename.py? That takes one less character.
Also I was thinking about using an ! instead of @ to make it clearer it was something unusual.
Oh yeah, added bonus is that libname.__version__ should now work no matter where the library is downloaded from (PyPI was the last hold out), hopefully that helps the folks doing support!
looking now to see if the chips support SDIO
looks like there is a peripheral but we don't support it yet
I was just looking at starting a board definition for the ESP32-CAM, which has an sdio device onboard
@onyx hinge is already working on the ESP32-CAM, so you might hold off
Actually looking at his repo it looks like what he's working on isn't the ESP32-CAM board but generalized camera support for espressif.
I think he may be testing with an ESP32-CAM board, though. @onyx hinge can you comment when you're on?
He seems to be working with ESP32-S3-Eye and Kaluga
I actually don't even know where I put the camera modules for my boards.
there's not currently sdio support on espressif. I'd love someone to tackle that. An in progress pull request of mine adds support for esp32-eye and esp32s3-eye boards from espressif, as well as adding the esp32-camera library as a circuitpython module.
(and kaluga but there was already a board def for that)
suspect it would be possible to use the (probably slower SPI-based) sdcardio with the sd card, since espressif is so flexible about pin assignments
and I should fess up that I've been seeing some weird behavior on the esp32 board while the camera is working, I haven't been able to figure out anything 'systematic' yet but it feels like memory corruption of either the stack or the circuitpython heap.
@slender iron Right now the property names in that PR match the esp32-camera C API. I agree that better documentation is critical, but I am not sure whether to make what I think is a "better name" in the API or stick with the underlying API name. I'll do docstrings first but your feedback about this specific item would be valuable.
@onyx hinge I think its fine to leave the names as-is. mainly I want substantive doc strings so one doesn't need to reference the C api docs
new arm toolchain: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
The API documentation is sparse about the meaning of these flags, it's a puzzle to figure it out.
as are the manufacturer datasheets
if its unclear, then omit it
anyone know what this message from sphinx means, just off-hand? Otherwise I can search about it: WARNING: Inline interpreted text or phrase reference start-string without end-string.
I remember seeing it a few times and being baffled by it, don't remember what it really meant ? Maybe a missing empty line in ..source section or similar ?
yeah it's about a .. seealso::
there's strict rules about empty lines and indentation to find the beginning and ending of stuff
like it has to be like this ?
<empty line>
.. thing::
<empty line>
the thing
<empty line>
trying it...
it's too bad the turnaround is not a little faster building the core docs
maybe there's a trick I could stand to learn
I'd love such a trick
do you mean locally?
@tulip sleet yes
it seems to take a similar length of time to "make html" as to make a firmware
and -j<n> doesn't really help
Fixes #6087.
- Renames "I2C peripheral" terminology internally to "I2C target".
- Rename
i2cperipheralmodule toi2ctarget. Keepi2cperipheralas an alias until 9.0.0. - Rename
I2CPeripheralmodule toI2CTarget. KeepI2CPeripheralas an alias until 9.0.0.
The only name I cannot alias is I2CTargetRequest, which cannot be instantiated directly anyway. So if someone is referencing I2CPeripheralRequest, in say, isinstance(), they will have to change the code. This doesn'...
It was bad syntax on a link, the fact that it was in a .. thing:: block was a red herring.
ugh
I don't write enough .rst for ````... <...>_``` to flow off the fingers. I was missing the trailing \ or something
❗ doesn't seem like the right image to use here but that's not a fight for right now.
Smoke tested on Metro M4 and Feather ESP32 S2 TFT: I created instances both the old and new names of I2CPeripheral and I2CTarget. help("modules") shows both i2cperipheral and i2ctarget.
-//| This object is usually used with a camera-specific wrapper library such as `adafruit_ov5640 <https://circuitpython.readthedocs.io/projects/ov5640/en/latest/>_.
+//| This object is usually used with a camera-specific wrapper library such as `adafruit_ov5640 <https://circuitpython.readthedocs.io/projects/ov5640/en/latest/>`_.
``` yup that was it, a missing \`
I was gonna say it might have something to do with backticks or number of backticks
thanks, I appreciated your help brainstorming it
I didn't actually think missing one
but I did battle with links for the matrix, so that might have been where I had that message ?
sphinx is so mysterious to me
@slender iron assuming it comes up green, the esp32-camera PR is ready for you to review again.
@proven garnet How's the pyproject.toml stuff going? Would now be a good time for me to do a release sweep?
EventQueue already implements __bool__(), which returns False if the queue length is zero. It calls common_hal_keypad_eventqueue_get_length() to figure that out. So could you use that existing functionality instead in your sample async class/
@onyx hinge kk, will look shortly. haven't done my sweep yet
@slender iron OK, I'll actually click to re-request your review if I see CI has finished green later
Patching a minor mishap for all the pyproject.toml files but should be good in a little bit! I can ping you :)
Cool! thanks!
Thank you! Happy to see this in 8.
@tulip sleet 1@filename is fine with me. I wanted the line first though for led matrices
that sounds good
i'm not sure, maybe it's harder to read. For instance above, it looks like an "i". Yeah, I like better @ better after all
👍 will tweak it now
I suspect it is due to pre-commit only running over changed files. I'll manually fix it for you.
I suspect it is due to pre-commit only running over changed files. I'll manually fix it for you.
Thank you!
Ok, I've changed it to line@filename.
Yup, agree. I just fixed this for feather s2 tft as well.
In board.c:
bool espressif_board_reset_pin_number(gpio_num_t pin_number) {
// Pull LED down on reset rather than the default up
if (pin_number == 13) {
gpio_config_t cfg = {
.pin_bit_mask = BIT64(pin_number),
.mode = GPIO_MODE_DISABLE,
.pull_up_en = false,
.pull_down_en = true,
.intr_type = GPIO_INTR_DISABLE,
};
gpio_config...
seems reasonable to me, error messages and tools like ag will give: file:line (which you can feed to things like the bbedit command line to open and select that line) but I agree it's better to have the line first
Please open an issue for this. It's hard to track comments on merged PRs.
@YashasviChaurasia A PR is welcome! Join us on Discord for help with circuitpython development. #circuitpython-dev on https://adafru.it/discord
Can you do data.sort(compareValues) before the for (const f of data) loop? compareValues would then also take both name and dir status into account.
That way you are sorting json objects rather than table rows.
Another suggestion. Let me know if you want me to tweak it further. Thanks!
Fixes #6649.
https://github.com/micropython/micropython/commit/f9cbe6bc47dd4f5b8e85178caecd6f0de22b4c34 is a fix to MicroPython that improves the representation of printed floats noticeably.
From the MicroPython PR:
Formerly, py/formatfloat would print whole numbers inaccurately with nonzero digits beyond the decimal place. This resulted from its strategy of successive scaling of the argument by 0.1 which cannot be exactly represented in floating point. The change in this commi...
Much better property descriptions! Thank you!
Is this also needed on the adafruit_feather_esp32s3_4mbflash_2mbpsram?
I see that the D13 LED is lit.
This is probably a general problem on all Espressif boards with board.LED or equivalent.
CircuitPython version
Absolute latest from 8/8/22
Code/REPL
N/A
Behavior
When browsing files on the device with web workflow, many of the unicode characters are missing. See screenshot below.
Description
Additional information
No response
It would be awesome if an offset could optionally be provided to support partial writes. However, this might be better in its own function utilizing the PATCH http method as this is exactly what it's intended for.
Ha! pyproject.toml fix complete, fixed the issue where dependencies weren't getting added to the built distributions.
Bonus, we're also now building wheels besides source distributions, which should cut down on time from having to build from source distributions when installing from PyPI.
@trim elm you're good to go for releasing everything in the bundle!
@proven garnet Awesome! So the thing I'm releasing them for is switching to pyproject.toml, correct?
Yup! They also now have the ability to do libname.__version__ if that's defined for the library when downloaded from PyPI.
Oh awesome
But pyproject.toml is the major change.
Seesaw is already released, just a heads up
Fixes #6404.
Redo of #6514, which updated 7.3.x. This updates 8.0.0 builds.
- Increased default main task stack to 16kB in `sdkconfig.defaults.
- Removed stack size settings from sdkconfig-esp32.defaults
. Also removed some incorrect leftover debug UART settings from the legacy section ofsdkconfig-esp32.defaults`.
Tested wifi on Feather HUZZAH32 with basic internet test. There is some concern this might reduce the number of available sockets, so more testing by users is in order.
@tulip sleet Are we still having issues with LC709203 and ESP32-S3? The page isn't published in the Feather guide, and I didn't want to add it to the TFT Feather guide if it was still iffy.
YES
Got it.
there was supposedly a fix but I did not get it to work
Good to know. Thank you!
I think we don't want to go this route due to having to support every board and manufacturer as circuitpython.org isn't Adafruit specific.
The maintenance load of supporting many product in-stock APIs would be too cumbersome for not enough value.
In addition to that, we'd have to update the board metadata of every board to either provide more information (in stock api endpoints), or do some precarious parsing of our generated HTML to poll endpoints that would be specific for every board...
@idle owl mind taking a look at this adabot patch now that setup.py is no more:
Merged once I fixed the URL 😄
Thanks!!
@proven garnet (cc:@idle owl) the libraries are all released
Great!
Running a check on the release.yml runs now!
@slender iron I'm not sure my question regarding the Feather Huzzah build size warrants an issue yet, I haven't even been using clean builds yet. I'll keep an eye on it and if it doesn't start making more sense to me, I'll either query discord or open an issue. Thanks!
👍 we have changed relatively recently how we allocate the mp heap so there is definitely room to tweak it
We're golden! All libraries are now published with the changes, thanks @idle owl and @trim elm!
Fixes #5349.
Add back some rainbowio and onewireio, and for a few boards, some other modules, deleted when space was short.
Thanks - this will be even more informative!
Otherwise busy Python code that isn't reading input characters
won't be interruptible.
Fixes #6707
Much better property descriptions! Thank you!
I canceled this CI run to make room for other PR builds.
Good heavens! this turns out to be an embarrassingly simple change. Thanks for all your guidance!
How would this impact CircuitPython? I don't think this issue is actionable as-is.
For anyone looking at this be aware of #6721 that will affect any changes. I did make some small progress and I'll post a more detailed update later.
What if we just construct the PulseOut as needed rather than requiring .frequency?
@slender iron did you deliberately push to jepler/espressif-camera-2 or was it a mistake? oh, was that merging main into the branch, that would make sense.
yup, did the merge for you
anyone have cycles to help update: https://learn.adafruit.com/circuitpython-tv-zapper-with-circuit-playground-express/circuitpython-code-2 ?
"is this something I'd have to have a TV to understand?" <-- I hardly ever get to use that line anymore
thanks for the merge, scott
Looks like we can easily decode the percent encoding in place.
Gotta love seeing a TODO in the esp idf code itself
Why is this interesting? Wifi is faster than BLE so I think this is less critical.
We should definitely go with range requests for it: https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests
Yeah, it's definitely less critical. You had asked I create an issue, so that's what I did. The description for range requests sounds like it is intended for reads rather than than writes, so I'm not sure that would satisfy our needs.
has the topic of dynamically setting pin states before/after deep sleep ever come up for CP development? I know at least the SAMD port resets pins before deep sleep
I'm not able to reproduce this on a C3. Is there a code.py running at the same time? Is there another web request occurring?
you can probably cheat it through pin alarm
not sure what you mean. wouldn't pin alarm require the pin be deinit first?
all the filesystem on web workflow i got dig deeper to WASI filessytem and now also WASI with Wagi
Ya perhaps. Pin alarm should pull in the opposite direction of the alarm, even when asleep
I don't know what WASI or Wagi are
this seems to explain more those 3 https://www.fermyon.com/blog/wasm-wasi-wagi what might be interesting for circuitpython web
and how is this related to web workflow?
interesting thought. I'll investigate.
Am I crazy in thinking this warrants more than a hacky solution? There are lots of cases where you'll want to leaving something either on or off during deep sleep (conditionally)
@lime trellis ya, its worth thinking about
you can open an issue or see if there is already one
yeah will do. Thanks for the encouragement 🙂
I typically do have a code.py application running but it's just sitting at an input statement. I bring up the welcome screen and then the file manager. If the file manager loads correctly, it usually only takes a few page refreshes for the error to occur on the C3. I'll download the latest bits from S3 and see if anything has changed.
on web workflow user could run they CPy code on device and see it in webworkflow for example perhaps
I loaded the latest S3 bits, killed my code.py application so we're sitting at the REPL prompt and then started refreshing the file manager. After six refreshes I hit an error but the console message was not one of the usual ones:

I then started hitting refresh again and after another 10 or so refreshes I got another miss-load with the typical `ERR_INVALID_CHUNKED_ENCODING 200...
Ok, I added some to mine but not 77. It'd also be helpful to see the DEBUG=1 output of CP when this happens.
Also, fix multiple file uploads from directory browser.
Fixes #6646
@Neradoc you had ideas for this right?
I can compile a DEBUG=1 image, Will the debug output show up on the serial REPL or do I need to enable debug uart pins as well?
I think I have an issue where something is being optimized out. To clear a i2c flag I have to read one of the registers (self->peripheral->hw->clr_rd_req). But I think it may be getting removed cause it doesn't "do" anything. Any idea on how to ensure that read runs?
looks that means the pr needs a fresh review approval, as well as finishing its run (gulp)
hardware registers should be marked as volatile to prevent removal
Thanks I'll check that. I tried printing the value to ensure it was read and it still didn't clear so.... 🤷🏻♂️
On C3 it is the separate UART pins.
As long as the JS fetch api is ok with it. We should copy webdav: https://www.greenbytes.de/tech/webdav/rfc4918.html#METHOD_MOVE
hmmm the auto-merge happened before the checks completed. I guess I shouldn't touch that knob. Thanks Scott, hope nothing turns out to be wrong
np, can fix later
generally you write a 1 to a register bit to clear
rp2040 shows it just being read, but worth a shot too.
Plus side I have most of the i2cperipheral working I think, just making sure error conditions don't leave things in a weird state.
I'm going to unblock 8 on this. It'd be good for others to chime in if they see this.
I'm going to unblock 8 on this. It'd be good for others to chime in if they see this.
huh, interesting
Goal
There are many cases when a user may want to conditionally set a pin high or low and then maintain that pin state during and after deep sleep.
A common example would be choosing whether to keep some external circuit enabled during deep sleep (like a GPS module searching for a fix).
- Currently, this isn't possible since pins are reset just prior to entering deep sleep (in the case of the atmel-samd port).
- On discord, @tannewt suggested
PinAlarmmight provide a hacky ...
Yeah I replaced them with emojis, which are better supported across systems. I could try researching non-emoji alternatives that are better supported, but that seems to be an area where it's hard to get any actual information.
Found out it is clearing other interrupts. I'm just getting into some error state where it is confused if you don't respond quick enough to a read request. Hoping it is something we can detect cause it is a likely error case
In order to attach the uart pins to my PC I had to move the C3 away from the router. It took a dozen or so power cycles to get the C3 to connect to Web Workflow over Wifi and when it did almost every refresh on the file manager had the error. If I refreshed enough times, I could eventually get a successful file manager display.
The debug uart output from one of the failed refreshes is as follows. The short send messages actually filled several screens but I only included the first dozen...
Fixes #6723
Emojis are better supported across systems than symbol code points.
ℹ️ 📁 ⬇ 📄

This is an entire debug output from a failed file manager refresh.
I think I have it working, probably needs a bit of cleanup.
@kstillson or @im-redactd would you like me to push into your repo so you can create a PR to the core? Or else I can create a PR myself to the core.
The basics of what I did:
- in the
is_addressedmethod found the correct status bytes to check if we have a read or write request (or nothing) - in read and write, address the
hw->data_cmdregister directly. The API does not really have good methods. - Some general cleanup in ...
Emojis should be fine. The main non-emoji alternative is HTML entities like here: https://www.freeformatter.com/html-entities.html
I've occasionally noticed no files showing as well. Interestingly enough, they were showing just fine on the code.circuitpython.org changes I was making (from a json request call) despite not showing on the local web server.
I will deploy this to my avionics microprocessor in the morning and run it through the paces, see how it goes.
On Aug 9, 2022, at 9:45 PM, Mark @.***> wrote:
I think I have it working, probably needs a bit of cleanup.
@kstillson or @im-redactd would you like me to push into your repo so you can create a PR to the core? Or else I can create a PR myself to the core.The basics of what I did:
in the is_addressed method found the correct status bytes to check if we h...
Fixes #5476 by removing auto_brightness and related support completely.
@deshipu @tannewt My understanding of the comments in #5476, particularly the later ones, is that auto-brightness never worked, and we may as well just remove it, which is what I proposed in that issue. If this is not correct, then I'll close or change this.
This PR explicitly removes the .auto_brightness attribute on Display and FrameBufferDisplay. It does not just render it inoperable in 8.0.0, to be remov...
I don't know; I just wanted to see whether we might suffer from the same issue. I didn't have time to research it and just wanted to "bookmark" it for further study.
Finally we get to do this :) Thanks!
@tulip sleet Your async code looks like it's working! I've got a little CPython test that I think shows it working with a Mocket and and will load it up with CircuitPython somewhere this week for a real test. It looks like you had merged in an experimental branch with several changes that were different from adafruit's main. I did my best to unwind them to bring it more in line with main. If I were to make a pull request where should it go to?
you mean in requests? Yes, I was cleaning up exceptions too. The exceptions fix could be done separately.
I got some pushback about whether to include this in the original library or make a separate library. There are some refactoring decisions to make.
Thank you for testing! I did not expect it to necessarily work right away. I assume you fixed some things.
Refined to use the existing common_hal_keypad_eventqueue_get_length in eventqueue_ioctl. The corresponding plain CircuitPython code would look like
async def aget(event_queue, interval):
while not event_queue:
await asyncio.sleep(interval)
return event_queue.get()
@onyx hinge the select for EventQueue looks very interesting and could be a model for other stuff. I will look at it more tomw.
@tulip sleet I'll try to prove it's faster than the Python code, otherwise it's not really super useful
and yes if we want to go that way it shows how to make many core things "nearly awaitable", with a small snippet of Python code. Too bad that Python code has to touch a non-portable part of the asyncio implementation, asyncio.core._io_queue.
there is some open PR or issue in micropython that talks about how to do select stuff for asyncio for pin waiting and maybe other things. I lost the reference and haven't refound it, but it's what I mentioned yesterday
maybe it's this discussion? https://github.com/micropython/micropython/issues/2664
g'night
CircuitPython version
Adafruit CircuitPython 7.3.2 on 2022-07-20; Adafruit Circuit Playground Bluefruit with nRF52840
Code/REPL
# NOTE: This is modified from the adafruit-irremote example irremote_transmit.py. Removed the use of the irremote library to make the issue clearer.
import pulseio
import pwmio
import board
import digitalio
import array
# Create a button object to trigger IR transmit
button = digitalio.DigitalInOut(board.D4)
button.direct...
Last job looks successful but hung on cleanup. Merging now.
quick question on board def BCP: if the onboard LED isn't broken out to a board pin should you still define board.IOxx or just board.LED?
@onyx hinge What boards and cameras are supported by the new camera stuff that you have been working on? Nevermind -- I found waht I was looking for in the PR. I should have looked there first...sorry.
I wrote a test program which runs on raspberry pi pico. It creates a separate Keys object and asyncio task for each GPIO, as well as a "logic task" which just counts how long it takes to await asyncio.sleep(0) a given number of times.
I tested with three ways of polling, and with 1 and 29 key tasks.
With 29 key tasks (all GPIOs used):
- The new core polling code. This was best, at ~2000 logic loop iterations per second
...
The work is for Espressif microcontrollers (ESP32, ESP32-S2, and ESP32-S3) and should be for "all cameras that esp32-camera supports" (13 different sensors). My actual testing was with OV2640 and OV7670.
Thanks. I’ll attempt to try it out.
Thanks for this inspired change!
- The pure python polling code, sleep of 10ms between checks. ~146 logic loop iterations per second
- The pure python polling code, sleep of 0 between checks. ~73 logic loop iterations per second
Why do you think a 0 sleep is worse? That's confusing to me.
Nope, I don't think I made any functional changes 🤔! I'll get it pushed up at work this morning and get a few more tests in there + a real test on my board at some point. My wife is out of town so I've got time to kill 🙂
As far as inclusion in the library I just ended up having it be a "peer" of the adafruit_requests.py file. I don't have any huge problems with any of it and am happy to help package it any way it needs to if people don't have the time.
Is there a good parallel anywhere in adafruit's librarys where a non-asyncio library was wrapped up and made working with asyncio for a template on what to do?
Since it really just seems like it's copy-pasted code with a few asyncs thrown in here or there it seems like it's just a wrapper that adds support for a language feature so I'd kind of err on keeping it simple? I'm also not a maintainer of anything circuitpython.
Usually cowboy code doesn't work but in your case it seems like it did 🤩
Why do you think a 0 sleep is worse? That's confusing to me.
I think that when all the tasks are doing an asyncio.sleep(0) they all get polled every time the "logic task" sleeps. When the key-waiting tasks asyncio.sleep(.010) (10ms), then MOST of the time when the "logic task" does its asyncio.sleep(0) the key-waiting tasks don't execute at all.
In #6712 a proof of concept for improved waiting on core objects in asyncio was merged. This, together with a small piece of Python code, lets asyncio code await an event from any keypad EventQueue, and it's much faster/more efficient than previous options, which involved a Python loop with an await asyncio.sleep and a test for an event being registered.
I think it would be good to ...
- Identify any other types in the core that would benefit from similar treatment (addition of an i...
See https://github.com/adafruit/circuitpython/pull/6712 and https://github.com/adafruit/circuitpython/issues/6736 for some very recent work on this. In the requests library, it would be nice to have less duplicated code between the async and non-async versions, but due to the "infectiousness" of async/await, that was not so easy to do. There's no way to have a little conditional inside that either does an await or doesn't because the whole routine has to be async if you include an await.
We freeze adafruit_requests on some boards, so kind of doubling its size to include the "peer" async version would be problematic in terms of space. At the same time, having it in the same library makes it easier to maintain the duplicated code. It's a bit of a dilemma we have to think about.
I really appreciate your testing, and that it seemed easy to use.
Yes, I'm trying to get an idea of where the non async parts are and I think it's all just in the socket code that's implemented per board maybe? It's my first time working with a microcontroller so I'm just sort of shooting in the dark. The test I'm currently trying to get running is opening 3 sockets that are mocked to have some sleep or delay in the received and then make sure all have SENT
The only problem is that it looks like the non async sleep blocks the whole thread which blocks any coroutine running. So not a silver bullet but I think it could still work pretty well.
My big concern would be how is the lower level code working, how many assumptions are being made that there's only one socket open at any time on any given board?
i don't think we assume only one socket, but the fetches are all blocking right now
@tulip sleet we had chatted a bit about how my esp32-eye board is acting flaky with impossible exceptions. I have re-organized the example that was having problems and it occurs even when the new camera module is not even used, and when esp-idf reserved memory is set to 0 or non-zero. Doing things that change memory allocations make a different weird problem happen at a different spot, or sometimes just happen to make things work right. I'm thinking I should try the other module of the same type I have.
have you tried similar tests on just a plain ESP32 board (HUZZAH32 or V2?) Does that make sense to try?
I would not be surprised if there were some memory issue
yes that would also make sense to try, right now I'm just trying to do a basic MQTT publish example now that I've started reducing my code
MQTT has been flaky on me generally, but this is "impossible errors" not "sockets are maybe unreliable errors"
Traceback (most recent call last):
File "<stdin>", line 55, in <module>
TypeError: function got multiple values for argument 'socket_pool'
print("Connecting to Adafruit IO")
mqtt_client = MQTT.MQTT(
broker="io.adafruit.com",
username=aio_username,
password=aio_key,
socket_pool=pool,
ssl_context=ssl.create_default_context(),
)
I'm gonna try and get my build environment up to date and get the ESP32-CAM up and running tomorrow. Would the new camera-code potentially run on it? The board has an OV2640
I wonder if this is a cache problem; maybe you said that yesterday
@spiral elk yes, OV2640 is supported by the library
OV2640 seems like a very nice compromise between price and features
Is this just a fact of life when looking through the circuitpython code forever?
you can apply to be part of the https://cs.github.com code search beta
GitHub Code Search (Preview)
i am in the beta; it's a very nice UI
Depending on your goals using a local search tool like "git grep", "ag", etc., can give very quick and accurate results for string & regex searches.
^^ that is what we all do most of the time. I also use emacs tags to wander around definitions and uses
Code in forks is only searchable if the fork has more stars than the parent repository
FBOFW we are not likely to ever get more stars than micropython
Attempt to Extend analogio. https://github.com/latkinso42/circuitpython/tree/adcdma
Code loaded once, then crashed Pico. After that, the Pico will not connect with that UF2. However it will connect with noraml load UF2.
I've gone over the code multiple times, and recompiled mutiple times. Still will not connect
@tulip sleet I'm not reproducing the problem on esp32 feather v2
@hidden rain you've built & loaded other circuitpython uf2s yourself?
Yes. Example the Fibonacci code just mentioned in the last newsletter
yes. but again. at this point the UF2 loaded Pico will not connect to my PC thru USB
if so I recommend booting in safe mode (refer to board docs for how), then rename code.py to something else like nocode.py. Then, to test it, ctrl-c to get to the repl and import nocode to test it.
If your code malfunctions "in certain ways" it will stop performing the activities that are needed to connect on USB or to maintain the connection. When this happens very early incode.py, safe mode is the way to get the device connectable again.
the "certain ways" can be as simple as having an infinite loop that never terminates.
Sure .. I understand. That means going thru safe mode to make the determination, then avoiding the programming error in the C-Code. OK....
by keeping the test python code in a different filename than "code.py" it's a little bit less frustrating. Another thing I've used is this snippet of code that waits for USB serial to connect & then for you to hit enter to run: ```py
import supervisor
import time
import sys
wait for serial connection
if supervisor.runtime.serial_connected:
print("serial already connected, continuing")
else:
while not supervisor.runtime.serial_connected:
pass
time.sleep(.1)
while supervisor.runtime.serial_bytes_available:
sys.stdin.read(1)
print("press any key", end='')
while not supervisor.runtime.serial_bytes_available:
pass
sys.stdin.read(1)
print()
last note for now, it's possible to set up one pico to debug another pico -- this is called picoprobe and works in conjunction with debugger software on your computer. I've done it on linux but it's been awhile. https://community.element14.com/products/raspberry-pi/b/blog/posts/debugging-the-raspberry-pi-pico-on-windows-10
IntroductionSetting up an IDE for C++ development on the Raspberry Pi Pico is covered in the Getting Started with Raspberry Pi Pico guide. The guide is not surprisingly focused on using a Raspberry Pi as your development machine, although it does cov...
Is there a high level overview of how the circuitpython code is laid out?
Do micropython updates get brought into circuitpython?
@onyx hinge Really Cool Stuff! Thanks ! Off to safe mode and or debug...
@hazy walrus https://learn.adafruit.com/extending-circuitpython/overview and https://github.com/adafruit/circuitpython/blob/main/docs/common_hal.md are some of the docs about how we organize modules and ports. Yes, we merge in micropython from time to time; I think we're based on 1.18 currently (in 8.0 alphas)
Want to contribute to the CircuitPython core? Learn how we organize ports & importable modules: https://learn.adafruit.com/extending-circuitpython/overview and https://github.com/adafruit/circuitpython/blob/main/docs/common_hal.md
Not sure how to handle this - Weblate tells me to localize the string "All I2C targets are in use", but there is already a the localized string "All I2C peripherals are in use" for this.
Am I supposed to make a pull request to the code base to change this?
@cobalt grail Please do! Fixing near-duplicate strings in the source code is appreciated.
So just a note though
I think "target" is the correct new terminology. Let me find you a reference ...
so I would think the old message about "peripherals" should have been removed when we changed
Well "target" makes more sense to me, but is harder to translate to swedish. 🙂
You can ask nxp what the correct translation is.
You may want to open an issue instead, I'm not 100% sure which message should be changed to what..
"Target" translates to "mål" which also means "goal" in swedish.
because the messages are actually about the specific peripheral/hardware block within the microcontroller, which can be used as a target or as a controller.
OK, i'll open an issue then.
I appreciate you noticing things like this! I know I frequently don't pay it adequate attention, as a developer
CircuitPython version
Any
Code/REPL
None
Behavior
While doing the latest batch of localization in Weblate I discovered the text All I2C targets are in use and that there was already translations for All I2C peripherals are in use. I was advised to open an issue by @jepler to get all messages in CP in line for the new terminology.
Description
No response
Additional information
No response
Thanks. I don't even have the code on my machine, as weblate makes localization so streamlined. Even links to the exact code line in the codebase.
I inadvertently changed "All I2C peripherals are in use" to "All I2C targets are in use" in I2Ctarget.c in #6721. This switches it back. Thanks to @bergdahl and @jepler for noticing.
In this particular message, "peripheral" means the hardware on the microcontroller chip. It does not refer to an "I2C target", formerly called an "I2C peripheral". The other changes of "I2C peripheral" to "I2C target" do reflect the updated official terminology.
.. and fix a docstring for camera.
With this, the qrio demo can be adapted to esp32-s3-eye and with better performance than the previous variant because it doesn't have to multiply process pixels for display & internal use by qrio.
The message in question is wrong and should not be "All I2C targets are in use", because the original message "All I2C peripherals are in use" referred to the hardware blocks on the microcontroller chip, not a standalone I2C "peripheral". Such a device was previously called an "I2C slave", then we changed it to "I2C peripheral" (which confuses it with the on-chip hardware). NXP in a recent revision of the I2C standard changed "slave" to "target" (probably to avoid this confusion). See https:/...
If it is labeled in silkscreen, then I'd add another name besides LED.
OK, so peripheral = part of the MCU and target = exaternal sensor. I have changed my translation accordingly on Weblate.
I disabled auto-merge since it is ignoring the CI.
oh, really, oy
looks like the branch protections weren't set
I added some status checks to them but there doesn't seem to be an "all" checkbox
i noticed that I couldn't set automerge after the fact, which seemed weird
yup
I don't think we need to support every manufacturer on cp.org. It is open source so interested non-Adafruit folks can diy.
We wouldn't need extra code here if we make a shields compatible endpoint from the adafruit shop. Here it'd just be a SVG in the body.
We could do Adafruit specifically but it doesn't seem like we want to. IMO saying things are in stock is motivating even if they are typically in stock. (Because folks expect things to be out of stock.)
Thanks for the examples. @caternuson look over too; I myself have never written a register-based driver.
This looks good to me! I think it is good to remove since it just always set to full brightness. I think I wanted it because I had dreams of adjusting brightness when the vm wasn't running.
In the case I'm looking at, silkscreen is only labeled LED so I guess I'll omit the additional name.
Tested on eather_esp32s3_4mbflash_2mbpsram -- worked fine. Thank you!
Would it be enough for the board C code implement this? Or do you want control from CircuitPython of it?
Thanks! This goes with #6734.
circuitpython-stage updated by #6740 to complete this transition for frozen modules
@wraith crow I've got a fix for the C3 that I'd love you to test when you have a chance
Looks good and thanks for the OneWire cleanup as well.
Ok, I have a theory about this. We're filling up the outgoing socket and therefore we're only partially sending data. That's this line:
E (286720) CP webserver: short send 7 11
When two of these occur, we're dropping some characters in between and are no longer correct in the response. As a result, the browser stops us.
@slender iron I've been trying to increase the reliability of detecting disconnects for the web workflow stuff. I tried using web sockets because of the ping response option, but ultimately found there's no way to directly send opcodes with the native WebSocket. I was next considering occasionally checking for one of the static files, but was curious if you had any better ideas.
Currently if I unplug the board, it still seems to think it's connected.
@slender iron back (hopefully) from power outage. looking at pr now.
@gilded cradle why not just wait until another action tries to talk to the board?
I wanted to change the disconnect button, but that is an option.
I think its ok to re-fetch the version.json
I think websocket will know it is closed eventually
Yeah, but not until I plug in the board again
It's ok. I was just hoping you had maybe already had some simple way in mind.
nope, sorry
how are you going about having the same tools on cp.org for the web workflow and the BLE workflow ? (And the USB drive)
I have workflow classes with common functions. You will choose a connection type eventually, but right now I have it so you can pass parameters in the url.
You could check out what I have so far at https://github.com/makermelissa/web-editor/tree/webworkflow, but's it's still a work in progress.
so, like a higher level API that abstracts the backend, so I can plug my library manager into it ?
Yeah, I've been abstracting it. I'd like to eventually be able to allow the library manager to work with it.
Or it to work with the library manager, whichever.
I want to look at the web-editor repo, but so far I don't understand why I need a token to npm install, that's weird
the ble library isn't hosted by npm I think
its installed directly from github IIRC
I think it was because we were using github to host an npm package. However, we should be able to use jsdelivr like I did here: https://github.com/adafruit/WipperSnapper_Firmware_Uploader/blob/main/js/script.js#L7
But this was from before I learned that.
Fixes #6654 and fixes #6689
Thanks for writing this and updating this usage guidance.
Worth adding verbiage that it's also specific to being over I2C? Add mention of the SPI version?
When possible, use it for unpacking and packing registers.
Is there an easy example that could be added for when it would not be possible?
Okay, I'll grab the PR and update it with my results 🙂
This looks good. But if sent ==0, then i think the connection has been closed? Should this handle that somehow?
thank you!
This looks good. But if
sent ==0, then i think the connection has been closed? Should this handle that somehow?
I don't think sent can be 0. It'll return an error instead.
When the constructor value reading times out, an exception is thrown, but the digital pin is not de-initialised. Make sure to run the clean up, so user could catch the exception and retry using the same pin.