#circuitpython-dev
1 messages ยท Page 411 of 1
I was mildly confused by the mix of #ifdef DEBUG and #if DEBUG in the code but the second one doesn't compile so that's easy. (And poor CIRCUITPY_DEBUG only used once)
thank you!
I'd rather not. I think the multi-line version is easier to read. They should compile to the same thing.
it's the old LISP programmer in me
๐
(()((())((())))) (or is that scheme)
@tulip sleet is your magtag handy? I've got a fix for the speaker enable
sure, let's try it
no clicks on USB or on battery
๐
I am just running a sleep every few second program
it's a simple change so it should be fine
I changed the ESP32S2 TFT stuff too
this simplifies it
excellent
[adafruit/circuitpython] Pull request opened: #6057 Allow ESP boards to customize how a pin is reset
This allows board code to override the default pull up reset state.
It is useful for pins that are already externally connected, pulled
or otherwise used by the board.
Fixes #5931
Looks good to me! One question that doesn't block the merge.
Just indicating I don't expect it to change. If someone wants to change it further down they have to change this and it will make them consider why. Sometimes I use const for such safety, and in languages where it's really easy (e.g., let vs var) I'd consider each one.
I seem to be in a programming-language mood today.
CI failure is an unrelated network issue.
@slender iron I am going to restart the build. CI is not doing very well.
your pin-reset PR 6057 had two CI failures
kk
I tried this with 3.x, 4.x, 5.x, and 6.x, and the last adafruit_irremote in each of the corresponding bundles.
The 5.x bundle adafruit_irremote (version 4.0.2 of the library) works with CircuitPython 6.3.0. The 4.1.1 version of the library fails with 6.3.0.
... AND, @lstein just fixed this yesterday with https://github.com/adafruit/Adafruit_CircuitPython_IRRemote/pull/51, which I didn't see until just now. Moving this issue back to the library.
Looks good! It's too bad we have to do this even on these big chips, but there's a lot of code.
Just another observation. This happened to me on a feather_m0_adalogger running 7.1.1.
Auto reload stopped. I tried copying code.py several times. No auto reload, but on control_d the new file ran.
The issue was resolved by a hard reset.
I don't have any other details, sorry.
Should I also add -N8 to MICROPY_HW_BOARD_NAME and USB_PRODUCT ?
7.2.0 milestone 100% complete, after triage on Monday and fixes since then
PID from Espressif. Already on circuitpython.org
https://circuitpython.org/board/hiibot_iots2/
cc @BradChan
@0hotpotman0 are you all set on this now?
@aziascreations Shall we leave this open? It's been a long time, and I wonder if you still have this problem with 7.x.
Closing this for now. Please reopen if this is unresolved.
Closing this for now. Please let us know if you are still having trouble, or ask in https://adafru.it/discord in the #circuitpython-dev channel, which is a good place to ask for build issues.
- I'd say this is handled by #5954.
@proven garnet if you leave out the Python>=3.7.0, what kind of error do you get when adafruit-blinka>7.0.0 can't be satisfied? I wonder if it's worth bothering with the Python prereq or not
if it's clearer specifying the python version, that's probably better
Ok I played with the new SAMD alarm features implemented in this PR.
- [x] power consumption is on-par with what I was measuring with my initial samd Alarm implementation. Tested deep_sleep_until_alarms with
TimeAlarm,PinAlarmand both at once. - [x]
alarm.wake_alarmstill properly distinguishes between time and pin alarms. - [x] max deep sleep timealarm is still ~1500 days since prescalar is still 1024. That's good, thanks for not changing this.
- [x] fake deep sleep still wor...
Whoops just seeing this. Based on the error from that Issue, it sounded like it failed to pip install. In that case it was Python 2 so I see how they hit that issue, but I'm not sure what would happen, I can try it.
either it will fail immediately due to the python min reqt, or it will fail due to the blinka reqt. I was just wondering if one was clearer than the other. The blinka reqt implies the python min reqt, so it would be one less reqt
I tried to install an old version of python to check, but I'm using ubuntu 22.04 and the deadsnakes ppa doesn't have builds ... it was late, so I gave up
not a really big deal
Hmmm, I'll check and post. My guess one fails just slightly earlier than the other haha
i am mostly interested whether one is more obvious to the novice user, that's all
ok, good night! thanks for all the work!!
Confirmed correct behavior in 7.2.0-alpha.2. Thank you!
[2] It is an empty function by default. In Wio Terminal, the hook function is used to turn off RTL8720 coprocessor. (RTL8720 is enabled on board reset, and draws considerable amount of power.)
Did you try using
board_deinitfor this? I think it's meant to be used in the same way.
You are right. I'll try to move the hook stuff into board_deinit.
The board_deep_sleep_hook was intended to be called only before true deep sleep, because the touched pin is left dirty on wake up ...
I'll try to use "%q in use", and roll back circuitpython.pot.
@tannewt Sure I'll kick the tires on this PR tonight.
@t-ikegami your comment adding edge support for PinAlarm reminded me of this SAMD5x errata. Did you run into this? <img alt="" width="400" src="https://user-images.githubusercontent.com/29153441/154559182-16533ef8-e47f-46fd-a426-d34bdd3edab6.png">
I have tried to check the errata condition, by using a Wio Terminal in hand and PA02 pin. As far as wake up from BACKUP sleep is concerned, the tamper pin interrupt is triggered only...
@tannewt Sure I'll kick the tires on this PR tonight.
@t-ikegami your comment adding edge support for PinAlarm reminded me of this SAMD5x errata. Did you run into this? <img alt="" width="400" src="https://user-images.githubusercontent.com/29153441/154559182-16533ef8-e47f-46fd-a426-d34bdd3edab6.png">
I have tried to check the errata condition, by using a Wio Terminal in hand and PA02 pin. As far as wake up from BACKUP sleep is concerned, the tamper pin interrupt is triggered only...
- It seems to me that your
board_deep_sleep_hook()should really be done by the user in software (i.e. CP). If you want things turned off during deep sleep, that should be performed in software before callingexit_and_deep_sleep_until_alarmsright??
Unfortunately, cleanup_after_vm is called befre deep sleep, where pin states are reset. Actually, I first tried the scheme, and got surprized that the power consumption bumps up in deep sleep.
What would replace secrets.py? A .json file perhaps? Would it be something 'encrypted at rest'? A first estimate at the work involved includes:
- Write code to retrieve keys etc. from the new secret store (medium)
- Update the learning guides (large)
- Update libraries that currently use secrets.py (medium)
- Update applications that directly use secrets.py (??)
(stretch goal) Add tools to manage secret store.
(Using Python 3.6.0) Currently it will download BusDevice v5.1.5 and Blinka v6.15.0, so it won't fully update BusDevice to v5.1.6. That means, it doesn't pick up circuitpython_typing because that requirement is only in BusDevice v5.1.6 so it gets that cryptic I2C error. But I can't tell if it would be any clearer, because I can somehow run setup.py with 3.6 and it doesn't throw a fit.
I'm now a bit confused. There are signs of LOAD_ATTR_FAST_PATH in main, which is enabled by default, but no supporting code for it. So this has become enabled during this merge of v1.18 -- see 53c5bde9246853f8968ca299afebcbbc11d1f370. I can go ahead and enable the cache on FULL_BUILD targets; it costs another ~264 bytes of code and 128 bytes of RAM.
@blissful pollen hey two questions .. which microcontroller were you using with your natmod shennanigans, and did you have a gist or something with the code in it?
I used the Itsy Bitsy M4 only. And I do not but I can put it up in a few minutes
It looks like micropython / "the core" don't have support for the M0+ of the RP2040, which is where I was excited about the idea of loading native code. bummer!
It has support for the M0 though right? I hadn't tried but if the arch setting is different but compatible may be able to just add a new arch string to match the M0+
But that was just a guess I never tried
Thanks, I'll take a look. it's set up so you just have to "make" and get the .mpy file?
Should be, worked for me. The code.py has some AHRS code in python (from my community bundle) but you can remove that. Was just to compare
I noticed that the size of uzlib is 3232 bytes when built as an extmod for armv7m. This made me curious, as a ballpark figure would we be better off in terms of code size zlib-compressing the messages.
zlib-compressing messages individually is not going to work as well, but compressing the concatenation of all messages + offsets to find each message in the decompressed string could work.
Currently we have (numbers for adafruit_rotary_trinkey_m0, russian translation):
- total mes...
A colleague of mine pointed out that there's not a displayio graphing library, is that true? I'm tossing around doing something like that but wanted to check before diving in.
Do you have to decode all the messages up to message i because they don't start at byte boundaries? I have looked in the past for a zlib-like scheme where multiple compressed strings shared a common dictionary, but haven't found one.
Can you expand on 'graphing library' -- you want charts and graphs?
a secrets.json file does seem like the easiest thing to replace it with to me. Perhaps more difficult would be figuring out a way that Environment variables could be used or mocked on CircuitPython devices. My understanding is those are the best practice for secure credentials and things in CPython projects. That would mean code could ultimately be shared between CircuitPython and CPython in a more standardized way.
I don't think it should be encrypted at rest by default. It would more secure, but also more complex for new users. Maybe it could be added as optional?
Your list of steps look correct to me. The one thing I would add is that it will probably be good for libraries to continue supporting secrets.py in addition to the new way for a while so that everything does not break immediately and people have time to update their projects.
I think starting in the libraries and adding the new way as an option is probably a good first step so that the other things be updated more gradually.
It depends a bit what kind of graphing you're interested in. There is this Cartesian widget: https://docs.circuitpython.org/projects/displayio-layout/en/latest/api.html#cartesian which draws axis' and can plot points and lies in them.
Looks good! It's too bad we have to do this even on these big chips, but there's a lot of code.
Agreed, I think optimizing the portal libraries would help. I have an issue open to do that.
@tidal kiln FYI -- re: forum post. The Pyportal_5x_demo code is from here https://learn.adafruit.com/adabox011/updating-your-pyportal
@solar whale thanks!
I downloaded it and updated all the libs and it seems to work OK with a few changes as noted in the forum.
Oh sweet thanks! I'll take a look and figure out whether what I'm think should be new or feature additions to that library
@solar whale double thanks for checking. so luckily nothing has changed since 5.x to break the old code.
New features to that widgets really should get submitted over in the CircuitPython org repo: https://github.com/circuitpython/CircuitPython_Org_DisplayIO_Cartesian
We originally added a few widgets to that Layout library, but decided that they should live in their own repos and can go in the CircuitPython Org. So if you end up making a different typing of graphic widget it could get it's own new repo in the CircuitPython org as well.
No -- I was surprised
Eventually the widgets that aren't layouts can get removed from DisplayIO_Layout library.
Sounds good to me!
@lone axle just a FYI that I haven't forgot about the decompression stuff and hope to start on it later today, this week has been busy
Sounds good, happy to have you take a look whenever you have time.
You're quite welcome! Thank you for joining the review team!
@lone axle I see that the first repo and the second one aren't the same for Cartesian, should I cherry-pick the commits into the one under CircuitPython?
In particular it looks like the first one has functions for plotting actual lines
Didn't know if the difference was intentional or not
The one in CircuitPython Org should get updated to match the one in DisplayIO_Layout. The latest enhancements were done in the DisplayIO_Layout repo but haven't been moved to the CircuitPython org one yet.
@proven garnet Iโve started work on https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_Layout/issues/63 to add some functionality it Cartesian. Please go add any suggestions there. It may take me a couple of weeks to get the PR ready. At the same time should I extract Cartesian from DisplayIO_Layout and restart it over in the CircuitPython_Org?
What I'm suggesting is, there'd be a single zlib stream which simply concatenates all the messages: c becomes "%q in useDivision by zeroNot Implemented". And lengths gets content like [9, 16, 15].
Now, say you need to print message 2. You start decompression of the single stream. Discard 9 bytes from the stream, then discard 16 bytes, then output 15 bytes, since you need to skip over the initial messages.
It's gloriously inefficient but I think it could work.
@lone axle @mental nexus I'm happy to merge main from DisplayIO_Layout into main CircuitPythonOrg if that should be done, then the changes you're working on @mental nexus shouldn't need to get altered at all other than perhaps then the upstream repo I don't think
What problem is replacing secrets.py meant to solve? (Sorry that I'm missing the context here.)
And thanks for letting me know about those features, those look like awesome ones! Looks like you've got auto-scaling on the list, the other one was filling area under graphs (integral). I can add it and see if I can potential submit a PR for it if I can crack it ๐
Oh, it seems the files are not as 1:1 as I thought they might be ๐
The way that you get data from the secrets.py file in circuitpython is by using imports like from secrets import secrets But "normal" CPython has a build-in module that is called secrets (https://docs.python.org/3/library/secrets.html) so in CPython you import that built in module with import secrets The names collide so if we ever wanted to have a subset of the CPython module secrets in CircuitPython we would either have to choose a different name for it (thus making code less shareable between the two), or have already migrated away from using secrets.py for storing credentials so that the name would be free to be assigned to the built-in module.
I don't have any experience merging from one repo into another... If you know of a way to do that and want to make a PR with those changes in the CircuitPython Org repo to get it up to date that would be awesome though.
I don't know if I can do it through git, or at least easily, it does look like it should merge clean via PR though upon looking at everything. I can merge them in one big commit and run the example tests to confirm
Awesome, please go ahead and move it over to CircuitPython_Org and Iโll submit the PR there. Can you move the issue to over there too?
You got it boss!
Yep I think we can migrate the issue.
sounds good. If it gets to crazy with git you can probably just copy/paste the file from the newer one in displayio_layout to the org repo and then start a PR from there.
@proven garnet Hey! Are you up for doing a few more releases? I have three other repos that could use one.
@lone axle, @mental nexus Here's the PR - https://github.com/circuitpython/CircuitPython_Org_DisplayIO_Cartesian/pull/5
GitHub
Merges in code from https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_Layout v1.17.0
Adds the new example file for plotting lines
Fixes example to use the updated library name
Sure! Love me some practice!
Thank you! I'll check it out tonight. Do you have any interest in joining the graphics team over on CircuitPython org? https://github.com/orgs/circuitpython/teams/graphics
@tulip sleet are we ready to branch 7.2 and do the 1.18 merge?
Oh sounds fun! DisplayIO is one of the things I'm excited to learn more about, now that I have more screen capable boards
Should be all set, let me know if I botched it haha
I can go ahead and enable the cache on FULL_BUILD targets; it costs another ~264 bytes of code and 128 bytes of RAM.
Sounds perfect! Thank you for looking into this.
I was going to update the frozen libs one more time. I think the atmel-samd alarm fixes can wait
kk
Looks great! Thank you!
I think joining the team will allow your CI actions to run automatically (waits for approval for non-members I think). It's similar to the CircuitPython Librarians team, but specifically for displayio and graphics widgets.
The simplest type annotation is probably a Union of BytesIO and FileIO. I'm not too aware of the type options though.
@slender iron when you have a sec can you invite Tekktrik to https://github.com/orgs/circuitpython/teams/graphics/members
yup!
adafruit_irremote has a significant fix
done!
@lone axle how does march 4th sound as my last stream where we can chat if you have time
Done! ๐
Sounds good to me I should be available.
Bruce, our graphic artist, is pretty much amazing.
There's a bunch more, but I wanted to pass that one on since you came up with it.
It captures what I was thinking so much more than I could describe
He does that every time!
Hats off to Bruce
I always try to describe what I'm looking for and he always comes back with something better.
Yeah, all his blinka work has been amazing and all the other graphics too
I think those stickers should go out with CPX kits sold to schools. Imagine a student opening and the first thing is blinka greeting them in their first step
Blinka is pretty great ๐
Thanks for reproducing this @DavePutz! Nothing looks out of ordinary there. Maybe it isn't ticking and counting down?
Should I also add
-N8toMICROPY_HW_BOARD_NAMEandUSB_PRODUCT?
Sure! It's easy to change those after the fact. The board name is trickier since we use it as an id.
I'm ok with it being slower to print the exception. I doubt it'd be painfully slow. We could sort the string so that non-Exception messages go first.
I am wondering if it's possible to restart the compression at a byte boundary for each message, using the combined dictionary, and then decode only that message starting at that boundary.
Another much more complicated idea would be to have multiple zlib'd combined strings, instead of one single long string. You'd put the ones most alike together, so they would compress a lot. The compressed string index would specify the sub-group and then the index in the sub-group.
Ran into a similar "typing causing import issues" on the PR, basically it looks like adafruit-display-text can't import fontio which I don't think (?) has a Blinka equivalent, so the import fails in the typing block. Is this something that should go into a library like circuitpython-typing?
it could go in circuitpython-typing, or you could be cheap and just use quotes around the type?
Oh, good call!
but I'd think we need fontio for adafruit-blinka-displayio ?
Ahhhh so it does exist, just needs to install it
2. @tannewt can you confirm that CP doesn't need/use that address space? BKUPRAM starts at 0x47000000 per samd51j19a.h
I don't believe we do. Sleep memory is the best use of this space anyway.
Unfortunately, cleanup_after_vm is called befre deep sleep, where pin states are reset. Actually, I first tried the scheme, and got surprized that the power consumption bumps up in deep sleep.
My intention was that board_deinit would be used to put things in a low power state.
You can...
Thanks for testing this @maholli!
ugh I'm encountering PWM issues with a NRF52 board, confirmed on other boards, except the feather I updated to latest bootloader a few months ago (I believe it's a matter of the version of softdevice)
we have not updated the softdevice past 6.1.1 except on nrf52833 boards, which need 7.0.1
"confirmed on other boards" you mean other nrf52 boards?
I'm trying to add the status LED (which is PWM) on the Xiao NRF52, and I noticed that the PWM are not properly released on reload, making it run out of timers after a few reloads
I confirmed the same issue on the Clue
but not on the feather I updated
there was a bootloader bug that didn't load large UF2's, I think, but that usually just caused crashes
I updated the feather a few months ago for the PWM bug https://github.com/adafruit/circuitpython/issues/5397
the softdevice version is in INFO_UF2.TXT
what is the version of the bootloader on the Xiao
hmmm the Clue says UF2 Bootloader 0.3.0 lib/nrfx (v2.0.0) lib/tinyusb (legacy-1500-g23df777b) s140 6.1.1 but the latest bootloader is 0.6.3 not 0.3.0
oh the Xiao is
UF2 Bootloader 0.6.2 lib/nrfx (v2.0.0) lib/tinyusb (0.10.1-293-gaf8e5a90) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)
Model: Adafruit Feather nRF52840 Express
Board-ID: nRF52840-Feather-revD
SoftDevice: S140 version 6.1.1
Date: Sep 10 2021
0.3.0 is past 0.2.9, which I say I tested and fixed the #5397 problem (not that i remember very well)
ok, maybe the bootloader version is a red herring
@runic crest it looks like the usb on the zync is the same as the imx rt. so it should be easier to get tinyusb going on it
does the xiao use a neopixel?
I hadn't checked the version on the Xiao, I was first on the track of updating the Clue for comparison
I could believe the rgb status code is not freeing something properly
it's a PWM LED
so certainly not as well tested
but it works on the Tiny2040, with which I can't repro the issue
no, all seems the same
oh wait, but it's not related to the LED, this code:
pins = [board.D0, board.D1, board.D2, board.D3, board.D4, board.D5, board.D6, board.D7, board.D8, board.D9, board.D10,]
pwms = []
for pin in pins:
print(pin)
pwm = pwmio.PWMOut(pin)
pwms.append(pwm)
gives me:
Adafruit CircuitPython 7.2.0-alpha.2 on 2022-02-11; Adafruit CLUE nRF52840 Express with nRF52840
board.P0
board.P1
board.P2
board.P3
board.P4
board.P5
board.P6
board.P7
board.P8
board.P9
board.P10
Code stopped by auto-reload.
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Hello World!
[board.P0, board.P1, board.P2, board.P3, board.P4, board.P5, board.P6, board.P7, board.P8, board.P9, board.P10]
board.P0
board.P1
board.P2
board.P3
board.P4
Traceback (most recent call last):
File "code.py", line 16, in <module>
RuntimeError: All timers in use
I noticed the effect when testing the status LED, I had a rainbow code.py to test that the pins were not reserved, after a few reloads I had all timers in use
but the code above is on the clue
I think that is "just" a CircuitPython bug.
we are not doing resetting some internal bookkeeping on VM restart we should be resetting
I'll open an issue
I saw similar crash on finding UART pins on an Espressif (a not very useful exercise anyway since it should yield TONS of combinations)
oh, I misread your output, thought it was a crash
there is a similar problem on the stm32 port
I was having a crash too on the xiao, but I think that one was related to the status LED
Are dictionary keys normally ordered in CircuitPython?
Running on a Clue, I get "All timers in use" error when using PWMOut after a few reloads.
I originally noticed that on the Xiao NRF52 using adafruit_rgbled, and reproduced it on a Feather NRF52.
Couldn't reproduce on other ports.
This code takes 4 reloads to error. Less if more pins are used.
import board
import time
import pwmio
pins = [board.D0, board.D1, board.D2, board.D3, board.D4,]
pwms = []
for pin in pins:
print(pin)
pwm = pwmio.PWMOut(pin)
pwms.append...
@slender iron https://github.com/adafruit/circuitpython/pull/6060 is done. I can fork after you approve. I wonder if we should try to fix #6061 (above) or not before 7.2.0
maybe not -- it's like other existing bugs
Just got up for lunch and a quick walk. Will get to it once Iโm back to my desk
AFAIK dictionary keys are not guaranteed to be in any particular order in either CPython or CircuitPython. In CPython I think there is a seperate OrderedDict class which can be used if you need the keeps to keep a specific order, unsure if we have something similar in CircuitPython.
As of CPython something, it became official that insertion order was preserved: https://gandenberger.org/2018/03/10/ordered-dicts-vs-ordereddict/
that is NOT true in MicroPython/CircuitPython. There was some angst about this in MicroPython when the decree came down'
Oooo neat, for a few years now even. I am behind the times.
Thanks!
@slender iron i will start working on release notes
thank you!
Just a quick check generally shared-bindings will do the argument checks and anything else? and then pass it to a common-hal function (even if it is shared in shared-module). Am I missing anything?
argument checking and conversion
Thanks, looking at the uzlib stuff and just want to make sure I separate it correctly
With both performance knobs turned to "go fast", a little loop on rp2040 became nearly 20% faster:
import adafruit_ticks
class K:
def __init__(self, v):
self.v = v
def main():
k = K(7)
t0 = adafruit_ticks.ticks_ms()
for i in range(1000*100):
k.v
t1 = adafruit_ticks.ticks_ms()
dt = adafruit_ticks.ticks_diff(t1, t0)
us_per_loop = dt / 100
print(f"{dt} ms for 100,000 loop = {us_per_loop} us/loop")
main()
...
https://circuitpython.readthedocs.io/projects/adafruit-circuitpython-minimqtt/en/latest/api.html#adafruit_minimqtt.adafruit_minimqtt.MQTT.loop. loop() is documented as non-blocking, but execution is blocked for the timeout period. When there is a message in the queue, loop() returns in less than the timeout period. Is this expected behavior?
Yes. You can set the timeout to 0 so it's non-blocking.
I thought about that, but timeout=0 throws an Exception: ```
6912.975: DEBUG - Sending CONNECT to broker...
6912.976: DEBUG - Fixed Header: bytearray(b'\x10.\x00')
Variable Header: bytearray(b'\x04MQTT\x04\xc2\x00<')
6912.984: DEBUG - Receiving CONNACK packet from broker
6913.006: DEBUG - SUBSCRIBING to topic office/rgb_lighting with QoS 0
Traceback (most recent call last):
File "code.py", line 161, in <module>
File "adafruit_minimqtt/adafruit_minimqtt.py", line 805, in loop
File "adafruit_minimqtt/adafruit_minimqtt.py", line 823, in _wait_for_msg
MMQTTException:
Code done running.```
I'm so sorry, I thought I'd tried that. The implementation of loop defaults to a timeout of 0.1, so that should be a safe minimum. The issue seems to be that it takes more than 0 time (by the nanoseconds clock) to check if anything's in the buffer.
Note that 7.2.0-rc.0 is on the 7.2.x branch, so PR fixes for the 7.2.0 release should be against that branch.
Release announcement and circuitpython.org push will be later tonight, after several hours of builds finish.
Documentation says int, it supports float. 0.2 seems to work well with adafruit_led_animation from a visual perspective.
Automated website update for release 7.2.0-rc.0 by Blinka.
New boards:
- hiibot_iots2
- ai_thinker_esp32-c3s-2m
Looking for suggestions on this. Modified from extmod/moduzlib.c. I am getting a "error: cast increases required alignment of target type [-Werror=cast-align]" error. The original MP code is using the pointer math to find the MP object. The compiler is (rightfully) worried that this may then miss the alignment.
mp_obj_base_t base;
mp_obj_t src_stream;
TINF_DATA decomp;
bool eof;
} mp_obj_decompio_t;
STATIC int read_src_stream(TINF_DATA *data) {
byte *p = (void *)data;
p -= offsetof(mp_obj_decompio_t, decomp);
mp_obj_decompio_t *self = (mp_obj_decompio_t *)p;```
Outside of changing the uzlib library to include a reference to the MP object not sure how else to handle this.
The TINF_DATA object passed to read_src_stream is the same one that is stored in the mp_obj_decompio_t. Hence the sorta hacky way to find the original MP object
I just realized this breaks update_sdkconfig.py
Are the builds OK? I've put this in 7.2.0-rc.0.
[adafruit/circuitpython] New tag created: 7\.3\.0\-alpha\.0
The fix in #6033 to use git describe --first-parent ... does not quite work when there is a tag.
https://github.com/adafruit/circuitpython/runs/5254687864?check_suite_focus=true#step:7:151
tools/describe does
~/repos/adafruit/circuitpython$ git describe --first-parent --dirty --tags --always --match "[1-9].*"
7.2.0-rc.0
The default describe used by setup() is
https://github.com/pypa/setuptools_scm/blob/bdcbe2ee9da8f422c80b0090bfd95162401a7c5d/src/setuptools_scm/git.p...
The builds are ok, it's just a utility script for editing sdkconfigs
- Fixes #6063.
This should use --long so setup() in setup.py will be happy when running on a tag.
Thank you! Sorry I left this time-bomb for when you made a release, but I'm not sure how it could have been made visible sooner.
@jepler Don't worry! It's very hard to test this stuff.
[adafruit/circuitpython] Pull request opened: #6065 ai\_thinker\_esp32\-c3s: Pull LEDs down on reset
Use the new espressif_board_reset_pin_number hook to pull all 5 LED pins down instead of up on reset. Also disable the pullup on IO19, which is a JTAG USB pin with an LED connected to it.
Tested on 2M board, not tested on the 4M.
these ai thinker boards aren't so good
missing transistors so i cant use the usb port on board
weird LEDs
your mean they left them out of the design? Or just unpopulated?
the LEDs are all populated, but the white one is connected to a pin used by the USB JTAG
so its usually dimly on, my commit fixes it
I meant to reply to the "missing transistors"
the missing transistors are for the DTR and RTS stuff, whenever i try to connect to it using any serial program, the board is forced into reset
i dont know why they are unpopulated
eck
red boxes are not populated
not sure why they couldnt just use the jtab/serial usb and leave out the usb to serial chip
compare to espressif dev board:
i am not sure they know what they are doing, or they recycled a previous design, or something
speaking of workflow, anyone know how mpremote works ? does it require support in the core ? and if yes did we pick it up from the upstream merges (even if disabled) ?
@viscid pine ive noticed the esp32 c3 is still 'wobbly' when it comes to hardware design
like i did my design and didnt realize a resistor was required, and cuased flakey behavior - but the resistor wasn't documented where i thought. its just a new 'exciting' chip. will take a bit to get a good boilerplate
maybe the c4 will be better :)
I went ahead and implemented this, but contrary to my above calculations it ended up bigger. You can check out the code: https://github.com/adafruit/circuitpython/compare/main...jepler:compress-errors-zlib?expand=1
adafruit_rotary_trinkey_m0 (english translation) had 5388 bytes free in flash before the change, but only 4918 bytes free after.
I didn't test on HW but I did make sure that messages seemed to be printed properly from within the unix port.
I'm also concerned about the amo...
I will try to give it a go.
When I use the latest build for the feather_m0_rfm9x it fails when importing the bus_ddevce module
Adafruit CircuitPython 7.3.0-alpha.0 on 2022-02-19; Adafruit Feather M0 RFM9x with samd21g18
>>> import adafruit_rfm9x
Traceback (most recent call last):
File "", line 1, in
File "adafruit_rfm9x.py", line 17, in
ImportError: no module named 'adafruit_bus_device.spi_device'
>>>
If I upload the python version of the library from the 7.x bundle, it works .
je...
This very strange:
I can import adafruit_bme680 (an I2c device, but not adafruit_rfm9x (an spi device)
but both use adafruit_bus_device....
I am confused
Do you see this problem with 7.2.0-rc.0?
7.3.0-alpha.0 merged in some new code from MicroPython for freezing modules as part of the merge of MicroPython 1.18. The merged code may be broken in some way.
Try building off the 7.2.x branch for a bit if you want to experiment with freezing things to avoid the merge.
I'll try that -- but do you have any idea why I can import bme680 but not rfm9x?
Also it the core bus device module supposed to be useable any more?
@tulip sleet should I create a separate issue for the freezing problem -- from the core bus-device problem?
They might be related. There may be something wrong with the dictionaries, or subclassing. No idea, the MPy freezing code is kind of different. We'll figure it out. You've given enough test cases for now, if you want to make progress on the RFM stuff, stay off of main and see whether the issues are still true on 7.2.x.
If the SPI CLK polarity is set to 1, then a pull up resistor is required to keep the CLK signal high when the CLK goes to tri-state during idle periods. The pull up resistor could be external, but if your board is hard to modify, then setting the internal pull up resistor on the SPI CLK pin is useful. As the SPI CLK pin gets set up as a busio it becomes marked as "in use" and you can't manually set it to a pull up/down using digitalio, so the pull up/down should be set on spi configure.
I'll try that -- but do you have any idea why I can import bme680 but not rfm9x?
bme680 does from adafruit_bus_device import spi_device conditionally, in the constructor. rfm9x does import adafruit_bus_device.spi_device as spidev at the top level, and it does the rename as well. I have no idea why this would make a difference, but it is a difference to be investigated.
Also is the core bus device module supposed to be useable any more?
Sure, it's supposed to be.
Thanks -- it is building OK on 7.2.x
we'll figure it out - this is an example of why I wanted to leave the 1.18 merge out of 7.2.0 ๐
No doubt, I was just very confused this morning....
we appreciate your early testing very much!
This was just bad timing ๐
it may or may not have to do with frozen modules; I was mistakenly thinking the native module was frozen, of course it isn't
At this point, I can't import both gps and bme680 on the rfm9x so sdcard is not the main problem -- I'll try cutting out some code from the libs.
right -- the initial problem was with a "stock" build so something is broken in the core module but then the freezing issue may well be unrelated.
there is some new optimization having to do with name lookups, and that may be broken
life on the cutting edge is always eventful!
@tulip sleet @solar whale I recall that there was a micropython vs circuitpython difference for importing submodules of built-in modules. we changed the behavior for ulab and also took advantage of it for the built-in adafruit_bus_device. I must not have preserved that behavior, and we didn't add a test for it. I assigned myself that issue.
scott (rightly) wanted import ulab.numpy as np to work but it doesn't in micropython because they (rightly) simplified import of built-in modules as much as possible
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> import ulab
>>> import ulab.numpy as np
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: no module named 'ulab.numpy'
>>> from ulab import numpy as np
>>>
Yeah we're back to micropython behavior on this detail
micropython shouldn't fail silently on this, it should at least complain, or maybe the point is that in MicroPython native modules shouldn't have submodules
i guess the latter
Good morning! I realized last night that I thought I merged upstream in my fork of a repo, embarrassingly I actually did it on the Adafruit version that had an upstream. I went to revert the commit and roll back the changes but it looks like no files were actually changed. Could someone double check? I am infinitely sorry for the hassle in advance, just wanna do due diligence. ๐
Blue: Chip select
Yellow: SCK
Before change, you can see SCK is not driven until after chip select is driven active low, and then SCK is set back to tri-state before chip select is driven high again:

After change, SCK is idle high before chip select is driven active low and remains idle high after the transaction too:

well I didn't plan to work on CP today but there ya go ๐
these things happen ๐
I tested this on the feather_m0_rfm9x -- the core adafruit_bus_device does work now.
I also verified that I can build the "frozen" version of adafruit_bus_device and turn off CIRCUITPY_BUSDEVICE
this does appear to fix #6066
thanks for the quick fix -- CI is not happy, but "it works for me"
@solar whale I'll see to the CI's emotional needs later
as always I appreciate the bug reports & the testing
Happy to help. I appreciate your leaving little tests for me to find ๐
Moving the MicroPython extmod/uzlib to the CircuitPython shared-bindings/module pattern.
Provides zlib decompression functionality.
Thanks for doing this! I have not looked at the rest of it yet, but we want to call this zlib, not uzlib. If there are incompatible differences with the CPython API (that is, if it's not just a subset), then we would want to change them to match the CPython API.
So call everything zlib instead of uzlib. An example of this renaming without the shared-bindings/shared-module changes is re, which is ure in MicroPython.
At ~day 6 unit 1 didn't show the problem, but unit 2 did
monotonic_ns JUMPED MORE THAN A DAY! 524287999023437 786431999877941 : 14147094 loop_count: 4617955 state_clock: 4617954
monotonic_ns MOVED BACKWARD! 786431999877941 524288015747072 : 14147095 loop_count: 4617956 state_clock: 4617955
During the day unit 1 doesn't call monotonic_ns a often, so it might just be that it didn't call monotonic_ns during the window (but not sure where the period is v. ET day/night....)
Thanks for the continued testing. I had hoped I found the non-atomic reading of the register and incrementing the overflow count, but there must be something further to do atomically.
Thanks for working on this @gamblor21!
I tested the functionality of this successfully with this:
import uzlib
data = b'\x1f\x8b\x08\x00\x00\x00\x00\x00\x00\x03EPAn\xc2@\x0c\xbc\xe7\x15\xd6\x9e\tJ\x02\xa2Jn\xfd\x00\x87\xaa\\ZU\xc8\r.\xac\xbaI\xc0\xeb\xd0\xa2(\x7f\xafw\x13\xca\x9e<c\xcf\xd8\xb3C\x02`Zl\xc8T`\x98\xd0\x89\xd5z\x11X\x8f\xcd\xd9\xd9\xf6\xa8\x9da\x8c\xcc\xa5\'\xbe\x05\xa8@aC\xc2\xb6\xf6J\xbcGB)\x96\nk\xb1W\xdaybo"\xfd\xb1\x98\xc7\xf17e\xf2\xbd\x93 \xc93}\xda\x98\x9c\xd5\n...
Ensuring consistency with the main rp2040 page, moving the Arduino support link into the main sentence of
"There is great C/C++ support, unofficial (but really good) Arduino support, an official MicroPython port, and a CircuitPython port."
Including a link to the unofficial Arduino core.
@tulip sleet I was able to get sdcardio into an rfm9x build and then get the rfm9x, bme680 and SDCard to play together. I did have to use the del() function in places. That seems to help a lot although not always.
I saw! Impressive.
I'll try it again on the 7.3 branch now that the merge is done.
It's OK with 7.3.0 as well
I will be very interested to see I I can get an OLED (ssd1306) display to actually function with the m0_rfm9x using the del() tricks. That has always be a big problem.
what are the del() tricks?
see the code example here <#help-with-circuitpython message>
import adafruit_rfm9x
#with digitalio.DigitalInOut(board.RFM9X_CS) as cs:
rfm9x = adafruit_rfm9x.RFM9x(spi, radio_cs, radio_reset, 433.0)
# putem ajusta putere de transmisie (in dB). standard e de 13 dB
# RFM95 poate ajunge la o putere de peste 23 dB:
rfm9x.tx_power = 20
rfm9x.send(packet_date)
del(adafruit_rfm9x)
del(sys.modules["adafruit_rfm9x"])```
this can be called repeately
Doing the same for another large module -- like gps -- allowed them to co-exist without running out of memory.
It did not always work. I could not add in the SDCard module as well, but it clearly seemed to help.
I had never seen this until the user asked for some help with it.
And I won't claim to fully understand it. I'll still trying to understand more about waht is really happening. Any insights would be welcome!
i'm also curious about the mentioned del tricks
The idea seems to be that doing the del(module) and del(sys.modules["module"]) frees up much of RAM used when the module was imported. At least it seems to...sometimes....
fyi @leaden wadi (me) = sctv on github
have you tried unmounting the sdcard first ?
Ah -- no I did not. Good suggestion. With sdcardio it is not a problem but I'll try going back to SDCard and unmounting/mounting it each time. That will have to wait until tomorrow...
FYI -- I was experimenting with what happens if you remove an SDCard when it is being written to and the resits were very strange. The system did not seem to know for a long time - It still seemed to write and read to "something" for "awhile". Eventually it crashed, but there is some significant buffering going on....
you know that del is a statement, not a function, you don't need the parens
I did not -- thank you... there is much I don't know
nobody knows everything
but this is why I didn't understand what you mean, the parens confused me
it's like that with sizeof in C as well
i can't bring myself to use sizeof without parens
ah -- sorry about that -- I was just blindly following an example.
There is something comforting about the parens
it's an operator, like not
That makes sense -- thanks
Does the general scheme I described make sense to you - to free RAM?
the trouble with the oled display on the m0 is that i can't even import the module
It may still be too much to even get started.
deleting the sys.modules is pointless, because the class will keep a reference to the module anyways
unless you del everything that came from that module too
OK good to know --I'll try removing that.
yeah I would think you need to del every variable using the module
I think that was the hope
but I don't know, I gave up trying to fit things on the M0 a while ago
I would rather try to trim down the libraries, and remove anything you don't use from them
I have good luck with m0 by using my own code to access peripherals
instead of libraries
but that's a life choice
True, but using del did seem to help -- I was able to get some modules to play together that run out of RAM if you try to import them all before hand.
This was really meant see if there was a way to get more use out of the m0_rfm9x board with the existing libraries. I was encouraged by some limited success. Now I need to better understand what I did and why it worked...
I am pretty exited to see it working with a gps,sdcard and temp/humidity sensor. I did not think it was possible.
I doubt sdcardio will fit in all the translations though... EN_US only has about 700 bytes to spare.
I kind of want a minimal translation where every message is a number, displayed as a URL to a page in cp.org describing the error when you click, doubling as a reference to usual solutions (or auto loaded from an internal database in Mu)
just tried with the release candidate and it depends on the order that i import stuff! some of the behavior when running out of memory seems very random
Yes -- that has been my experience as well --try standing on your left foot ๐
one easy trick to get more ram on those boards is to disable usb midi and usb hid
they statically allocate some memory up front
there is nothing left in the feather_m0_rfm9x to remove....
i mean build wihtout support not disable
maybe "math" or analogio but they are often used.
math by the sensor libraries and analogio for the battery monitor.
almost everything else is gone
>>> help('modules')
__main__ board microcontroller sdcardio
adafruit_bus_device builtins micropython storage
adafruit_bus_device.i2c_device busio neopixel_write struct
adafruit_bus_device.spi_device collections os supervisor
adafruit_rfm9x digitalio pwmio sys
analogio gc rainbowio time
array math random usb_cdc
Plus any modules on the filesystem
CircuitPython version
7.1.1
Code/REPL
# SPDX-FileCopyrightText: Copyright (c) 2020 ladyada for Adafruit Industries
#
# SPDX-License-Identifier: MIT
import time
import board
import adafruit_sht4x
print("test")
i2c = board.I2C() # uses board.SCL and board.SDA
sht = adafruit_sht4x.SHT4x(i2c)
print("Found SHT4x with serial number", hex(sht.serial_number))
sht.mode = adafruit_sht4x.Mode.NOHEAT_HIGHPRECISION
# Can also set the mode to enable hea...
Hi,
The Stemma QT port on that QT PY is not on board.I2C, which uses the SDA and SCL pins marked on the side of the board.
It is on board.SDA1 and board.SCL1.
import busio
i2c = busio.I2C(scl=board.SCL1, sda=board.SDA1)
With Circuitpython 7.2.0 (currently in realease candidate) you can use:
i2c = board.STEMMA_QT()
Guides will surely be updated when the release is stable.
yep please check
https://learn.adafruit.com/adafruit-qt-py-esp32-s2/i2c
which has some example code/warnings!
Similar problems with similar code. Tried on two RP2040 boards - Ardino Nana RP2040 Connect and QT Py RP2040 with same problematic results. Tried code on a CPB and it worked without these probs.
Have been using RP2040s in lots of situations but this is the first Iโve had these consistent problems. Also the first time Iโve used audiocore and audiomixer. Earlier work with PWMAudioOut didnโt seem to run into these problems (about 50 students, two semesters, but didnโt hear regular complaints)
...
You were correct -- unmounting the SDCard allows frees along with del(adafruit_sdcard) frees enough memory for the code to run....thank you!
FYI- I found that I could remove the del(module_name) as long as I did the del(sys.modules["module_name"]).... If i removed the del(sys.modules["module_name"]) and only did the del(module_name) I still ran out of memory. I also found that without the parentheses, it failed with memory allocation errors but with the parentheses it works. I won't claim to understand, just reporting what I find...
that is super-weird
agreed
CircuitPython version
Adafruit CircuitPython 7.2.0-rc.0 on 2022-02-19; Adafruit FunHouse with ESP32S2
Code/REPL
# trigger a syntax error
import None
Behavior
After code.py exits the FunHouse display is empty except the Blinka image in the top left corner. After a soft restart (Ctrl-D) the only text on the display is:
Press any key to enter the REPL. Use CTRL-D to reload.
Description
Expected: The text after running should appear...
Maybe we should fix this for 7.2.0, since it's a recent regression.
The del(module_name), and the import of that module, happens inside a function scope, so the binding of the name to the module, and hence the reference, disappears when the function exits. But sys.modules is global -- it's basically used to share the same module if it's imported more than once.
In this case, al l the imports that are later removed with del are done within functions. I'm still pretty fuzzy on all of this, but it does open up some significant opportunities to free RAM and allow for these boards to function better with CircuitPython.
Do you have any idea why del(sys.modules["module_name]) behaves differently that del sys.modules["module_name"] in terms of the amount of RAM freed?
'fraid not; that's a puzzle
Good -- not only to me ๐
I looked in the builtins module to see it's defined as a function as well as a statement, but no dice
Do you have any idea why del(sys.modules["module_name]) behaves differently that del sys.modules["module_name"] in terms of the amount of RAM freed?
Do you mean del module_name vs del sys.modules["module_name"] , or do you just mean the lack of parentheses?
No, using the parentheses makes a diffence.
hmm, it shouldn't, because del is an operator, not a function call
like return (3) vs return 3
I found tat if I use del(sys.modules["module_name]) I don't need del(module_name) but without parentheses, I run out of memory.
agreed -- but it does....
I'll do some more experimentation and monitor the impact with gc later today.
I looked for MP_QSTR_del to make sure, but it does not exist.
I would really like to be able to come up with some guidelines for using del.
If I revert #5954, the screen is not cleared. @kmatch98, I don't immediately see why the terminal gets cleared on restart, but you probably know. Do you see a way to fix this? I thought it might be due an VM object going away, but I don't see that is the problem.
So call everything
zlibinstead ofuzlib. An example of this renaming without the shared-bindings/shared-module changes isre, which isurein MicroPython.
Will do. Just a FYI for you (and others) the underlying library itself is called uzlib (it is separate from MP) so I won't change the naming within that but the CP visible calls I'll rename.
Someone have a quick explanation or link on * and / in python type hinting function definitions? Trying to google * and / are rather difficult
in function definitions ?
Yeah like : function:: decompress(data, wbits=0, bufsize=0, /)
in the documentation sorry
"Parameters after * or *identifier are keyword-only parameters and may only be passed by keyword arguments. Parameters before โ/โ are positional-only parameters and may only be passed by positional arguments."
Thank you so much! Google-fu was failing me this morning
yeah that, it's not about type hints
I think creating the correct documentation gives me more pain then actually making all the C code ๐
Documentation is hard but vital
@dhalbert can we close this up?
Correction.
- Now I'm experiencing the same problem with CircuitPlayground Bluefruit. I can enter Safe Mode, but can't re-enter standard mode & run my code on the CPB, just like the RP2040 models.
- I had been using audiocore previously on both boards without any problems (just importing WaveFile. The only thing that's new is audiomixer, so perhaps that's the problem.
@dhalbert Is there something special with the funhouse display where the upper left corner is not (0,0)? Whenever display.show(None) is executed the terminal is moved back to (0,0). If for some reason the display setting donโt match that, then it could pace the REPL terminal out of view.
I think the best way to debug is to test on the hardware and boot straight to REPL and check the root_group display element (x,y) locations on the screen and then trigger the bug and see the difference...
@kmatch98 I tested this on a PyPortal, and though the screen does not blank completely on restart, it does erase the error message. Do you have this or a similar board to test?
E.g.:
print("Hello World!")
3/0 # raises ZeroDivisionError
7.1.1:
7.2.0-rc.0:
 -- he was using a PyPortal.
I also see it on a featherS2+FeatherWing TFT 3.5" combo. After the script sets up the display, any error messages are lost.
import board
import displayio
from adafruit_featherwing.tft_featherwing_35 import TFTFeatherWing35
if "feathers2" in board.board_id:
featherwing = TFTFeatherWing35(
cs=board.D5, dc=board.D6,
ts_cs=board.D21,
sd_cs=bo...
The amount of runtime memory is even bigger than that, about 2.5kB. the uzlib structure is 1.5kB and the "dict" is 1kB.
I threw a few more tricks at it, and even then ja was bigger in total flash size. (tricks that mean the auxiliary idea that maybe the translation can just be appended to the bin wouldn't work, either)
before - 3776 (ru) 5388 (en) 4072 (ja)
after - 4229 (ru) 5429 (en) 3970 (ja)
before = 918145f76
after = c6b68a93a
I think this isn't going to end up wor...
I think maybe the terminal is in the right position but gets the text from it cleared out. If you start using the REPL you do see it begin to show things on the display.
Do the start/stop terminal here result in clearing the text that was previously in the terminal away? https://github.com/adafruit/circuitpython/pull/5954/files#diff-edac12d728f2a3db7c325f4b3d9865f5fe9feb69e34302d626dc2cd11b2bd695R172-R173
@kmatch98 I did a brief test with split screen REPL / displayio on a build that removes those supervisor_stop_terminal() and supervisor_start_terminal() statements. I was still able to reset_terminal to half the display size, add a Label to the displayio group and move it around on it's half of the display. Everything seemed to behave normally, but I was not super thorough.
Do you think there is potential harm in removing these?
@onyx hinge too bad about the zlib. You made some comments a long time ago about SCSU: <#circuitpython-dev message>
Is it supervisor_stop_terminal() or supervisor_start_terminal() that does the clearing? Can you leave one out? I wonder if you need the supervisor_start_terminal() in case the dimensions change. Maybe it can check if the dimensions are actually changing and only do it if necessary.
Having only one or the other doesn't lead to a better outcome in either case than removing both of them.
With only supervisor_start_terminal() the error message is still not shown. But I don't see other adverse effects at first glance.
With only supervisor_stop_terminal() the error message is also not shown, but the REPL is no longer shown on the display either only the blinka icon and no other text..
Asterisks in Sphinx Python type signatures are not showing up in the generated doc, but only sometimes:
usb_cdc.c:
//| def enable(*, console: bool = True, data: bool = False) -> None:
//| """Enable or disable each CDC device. Can be called in ``boot.py``, before USB is connected.

But sometimes it shows up:
SPI.c:
//| def configure(self, *, baudra...
As for including supervisor_start_terminal() and supervisor_stop_terminal(), I think I just blindly copied what was already in there.
If we want to keep the old error message around: One thing I noted in the PR was whether we wanted to keep the text data in the terminal when we resized it. The challenge with that is that if the terminal is resized, first you have to allocate a new Terminal, then copy the...
Having only one or the other doesn't lead to a better outcome in either case than removing both of them.
With only
supervisor_start_terminal()the error message is still not shown. But I don't see other adverse effects at first glance.With only
supervisor_stop_terminal()the error message is also not shown, but the REPL is no longer shown on the display either only the blinka icon and no other text..
Now Iโm remembering stop_terminal deallocates the memory for the t...
I thinks okay not to retain the data in the terminal when it gets resized. The user presumably would have intentional resized it so they would understand why it's gone I think.
In the case originally reported here though there terminal isn't getting resized, at least not intentionally I don't think. The user has a code.py happens to raise an exception which stops it executing and breaks out to "press any key to enter REPL". So have not done anything with resizing the terminal.
I do th...
Ok Iโll take a crack at avoiding the start/stop of the size is not changing.
msgpack.unpack should require read, not write.
This has the potential to crash circuitpy if a write-only stream is passed to unpack:
import msgpack
import usb_midi
# get a write only stream
_, port_out = usb_midi.ports
# before fix: faults
# after fix: OSError: stream operation not supported
msgpack.unpack(port_out)```
@kmatch98 If you make a PR, could you make it against 7.1.x? Thanks.
From a learner's perspective, there are two points missing from the documentation:
- pull is set automatically
- direction is set automatically
I was unsure until I found this issue, so you might want to include 2. as well.
In looking deeper, if we just run supervisor_start_terminal, if the terminal is the same size, it should reuse the tile grid allocation. However, in testing it I see that the tiles get cleared. I've got to dig deeper to see where the tiles get cleared.
Other objects which work for buffer are of type busio.UART and usb_cdc.Serial. (So the msgpack format would a good basis for a binary serial protocol.)
I don't know of any type annotation in standard Python or CircuitPython that encompasses all these types. Perhaps the best approach would be to annotate with a pseudo-type like "bytestream" and explain what that means in the class or method documentation (in shared-bindings/msgpack/__init__.c) I'm willing to wordsmith a PR if this seems ...
We have circuitpython_typing.ReadableBuffer and .WriteableBuffer in circuitpython_typing (https://github.com/adafruit/Adafruit_CircuitPython_Typing), which are inspired by https://github.com/python/typing/issues/593.
When adding a library using cookiecutter, in this case to CircuitPython Org, should I use my username or "circuitpython" for the user? I figured I would make the library and then if it was any good it might be forked, but I don't know how it works on that front for that bundle.
I assume mine?
ReadableBuffer and WritableBuffer are objects that allow accessing bytes by index and a length, these types do not work with msgpack. Msgpack requires something more like a WritableStream and ReadableStream. You can search for STATIC const mp_stream_p_t to find the types that implement stream.
Sorry, I did not read carefully enough. Something like https://stackoverflow.com/questions/41748896/the-correct-way-to-annotate-a-file-type-in-python. If you would like to add such a type to circuitpython_typing, that would be fine.
https://news.ycombinator.com/item?id=30402407 some interesting ideas about compression here, I wonder if any apply to the circuitpython message catalog .. not that I want to continue thinking about it right now.
cubefox
@proven garnet I think it's the github user name but I'm not 100% sure
Awesome, thank you!
@kmatch98 If you make a PR, could you make it against
7.2.x? Thanks.
I said by mistake. Corrected.7.1.x
This is some kind of problem with autoapi dropping * in signatures; I can see it in the autoapi output. But I don't know why it's doing that, and I don't see any filed issues complaining about this yet. I have a simple test case.
I'm trying to push a commit to my CircuitPython fork, but I'm all the sudden getting an error:
! [remote rejected] repl_fixes -> repl_fixes (refusing to allow a Personal Access Token to create or update workflow `.github/workflows/build.yml` without `workflow` scope)
error: failed to push some refs to 'https://github.com/kmatch98/circuitpython.git'
Not sure what changed since a few days ago, but I did merge in all the recent CircuitPython updates. Any suggestions on how to clear this git hurdle?
I was just seeing something like that, but with my new repo I created. I'm not the greatest at this stuff, but it looks like that perhaps whatever token you're using to push changes doesn't have the permissions needed to alter workflows
@mental nexus do you have this checked off for the Personal Access Token you're using?
Hmm. I had to add a token last week when I got back to building CP, maybe I missed this checkbox. Will check and report back.
The flash is optional on this board (its basically a haxpress) and the pins are meant to be usable when the flash is not populated (the non-"with_flash" board). I still think that having board pins defined which probably don't work would cause more support issues than people wondering why they're not there if they're removed. The board does have multiple additional SPI ports available in any case.
I think I've set everything up okay, but let me know if there's any issues. It's been a while since I've added a new board def
For those interested, a brief update on the use of del -- after more testing, I have found that the difference between using it with or without parentheses is minimal. The test case I was using was so tight on memory, that almost any change broke it. It does appear that the best results of freed memory are obtained with del sys.modules["module_name"] followed by del module them doing a gc.collect(). executing gc.collect() at the start of each function that is going to import a module also seems to help. I am working on some examples, but this is encouraging so far. What I am doing in each function is ```gc.collect()
import module
use the module (create spi if needed)
spi.deinit() (if spi used)
del sys.modules["module"]
del module
gc.collect()
CircuitPython version
Adafruit CircuitPython 7.1.1 on 2022-01-14; Adafruit ItsyBitsy nRF52840 Express with nRF52840
and
Adafruit CircuitPython 7.2.0-alpha.2 on 2022-02-11; Adafruit ItsyBitsy nRF52840 Express with nRF52840
Code/REPL
def connectionid(self, c):
try:
if DeviceInfoService in c:
try:
dis = c[DeviceInfoService]
s = ""
try:
...
Build failures are GitHub Actions problems only (network failures).
Thank you @wtuemura and @bergdahl!
I'm trying to make a PR vs 7.2.x, but in my local branch I just merged the latest version with my changes. When I committed, I thought I only added the files that I changed, but the PR template says there are 118 changed files. How can I make a PR only on the files that I changed?
did you merge ? did you rebase ?
I merged the latest upstream, then made my changes.
Here's my git reflog:
220564f08 (HEAD -> repl_fixes, origin/repl_fixes) HEAD@{0}: commit: retains REPL terminal data after display.show(None) when terminal size is not changed
8a5123827 (repl_wrangler) HEAD@{1}: checkout: moving from repl_wrangler to repl_fixes
8a5123827 (repl_wrangler) HEAD@{2}: commit: updated code so the REPL will retain its text if not resized when code stops
b5b04fb9d HEAD@{3}: pull git@github.com:adafruit/circuitpython.git main: Fast-forward
I merged from the latest adafruit/circuitpython, then made my changes. Now I want to make a PR of just my changes against version 7.2.x
not sure, can you git rebase 7.2.x ?
Ok, let me try
I tried rebase and there's a bunch of merge conflicts. I wonder if cherry-picking may be easier. I'll try that and see what happens.
@lone axle I don't know if you managed to checkout my PR for the Dial widget in CirPy Org yet, but I mocked up and tested the repository I mentioned there: https://github.com/tekktrik/CircuitPython_Org_DisplayIO_Effects
For libraries going into CircuitPython Org you can leave the default username circuitpython. You can put your own name for author though, that is what will end up in the copyright comments.
Ahhh got it, thanks!
I guess at this point, should I just fork my repo into CircuitPython Org or just create a new one from scratch and copy/paste?
@proven garnet (am catching up on chat now) I have not checkout the dial PR yet, but it's on my list for today.
No worries! Just wanted to give the link for the PR
either one is fine I think, fork or create new an copy paste. Personally I'd prolly lean toward creating new and copy pasting. But it's mostly just out of familiarity with having my repo be a fork of the "real" one rather than the other way around.
Interesting If I understand you're new library correctly it reminds me of a concept from Android: https://developer.android.com/reference/android/animation/ObjectAnimator They have "ValueAnimators" that can change the value of a property on some object based on a set of rules. A basic use-case being linear interpolation for moving the location of a view element, but can do much more complex things as well.
Oh that's neat I'll have to check that out! But sounds about right
It could have other effects as well
But I guess let me know if you think effects should be a new library or each widget should have it individually
An example of another one would be the widgets "indicator" doing a color wheel effect
<@&356864093652516868> Just a reminder that there is no meeting today, as it's a US holiday. We'll meet 24 hours later than usual, 11am Pacific / 2pm Eastern Tuesday.
replied over on the dial PR. Gist is I think seperate library is better than including them in with each widget, added a bit more info in the PR.
did anyone try adding a touchscreen onscreen keyboard to the circuitpython wordle? it would be great in portrait mode on a pyportal, i'm tempted to think..
I feel like someone who showed one on Show & Tell within the past few weeks did have an onscren keyboard
Maybe I am mis-remembering though. There was one that used the BBQ10 keyboard, and another that hosted JS to play the game in the browser. I thought one more, but not certain.
That was maybe the guy with a Blackberry keyboard attached to screen? I think it was also Wordle realated.
yeah I recall a version for keyboard featherwing(maybe it's called?) and one with clue using the two buttons to select letters
Yep, I had a look back through a few shows and tried some keyword searches in that channel and came up empty. I think I must've had wires crossed from the BB keyboard one.
When your editor is being "helpful" removing extra spaces at the end of lines that cause tests to fail because the text compare is looking for those spaces...
I have set up mine to merely highlight those spaces as spellchecking errors, I have to remove them manually
This PR improves upon a previous PR to make the behavior of the REPL more predictable in 99.9% of uses, yet still provide user access to the REPL group.
This resolves issue: https://github.com/adafruit/circuitpython/issues/6071
Alright, in the correct channel this time: Okay @lone axle, I forked my repo into CircuitPython Org, I did want to keep the git history. Happy to change it to a standalone repo if that ends up making more sense.
I reproduced this problem with a simple example and opened an an autoapi issue about this: https://github.com/readthedocs/sphinx-autoapi/issues/328
Starting fresh with a branch copied from 7.2.x and then cherry-picking did the trick.
sometimes things doable 'in theory' with rebase are much easier with cherry-pick. It's good to have both in your arsenal. For moving just one or two commits to a different base branch I'd cherry-pick every time.
Would you still use the storage for anything? It's possible to disable the USB storage from appearing at all, maybe that would fit your use-case?
I'm gonna use the usb-storage lots, and it will be used by other ppl too, and I would like to prevent accidental deletions of the project files
the final product is gonna be fully opensource, but in order to keep it clean I would like to embed as much as possible onto the uf2, and only keep user-changable stuff on usb
I see. I would guess that it is possible, but I'm not really sure how to do it. This is probably the best place to ask though someone here may be able to point you in the right direction.
Hello everyone, I hope you all had a good day. I would like to ask about the ST25DV16K. I am working with it in circuitpython and with the QTPYRP2040. Do you know how many Bytes can be transferred via NFC to the mobile. I only manage to send 230 Bytes. Is it possible to send more bytes and how?
that would require some changes to main.c: code.py and boot.py are not "imported" and looked up in sys.path, they are just files. You could have the code in a frozen module and import it from code.py, with recovery instructions... You can change the default files created in supervisor/shared/filesystem.c. It's not really Circuitpython anymore though.
eh, I will give it a try
It's not really Circuitpython anymore though.
I suppose, but for simplicity I'll take it.
I don't know if pyexec_file can run a frozen module or if there's an alternative function that could
Thank you for the quick fix! Tested on FunHouse and PyPortal, with a code.py that throws an exception.
I am testing this out on a PyPortal and I think I'm seeing some odd behavior
My code.py contains this:
for i in range(3):
print("Hello World!")
code.py Runs automatically first time upon power up but all of the "Hello World!"s get scrolled off the top of the display leaving none of them showing:

They were visible briefly but scrolled off the top edge.
Fro...
@tulip sleet I think there may still be some issues around https://github.com/adafruit/circuitpython/pull/6076 I am trying it out right now and getting some weird results with extra things being printed on the display. But I was a tad too slow in leaving my comment on the PR.
I could open a new issue to document what I am seeing? perhaps it's a different root cause or not related specifically to the changes from that PR, but it does seem to be different behavior from 7.1.1.
I see that too. I agree, there is something odd going on about which parts of the screen are cleared or where new output goes.
yes, I see something of the same. I did not try it as thoroughly as you. I will wait a bit and see if kmatch has time to look, or I will revert the PR and then revert the original PR, for 7.2.0 only.
I tried removing this line: https://github.com/adafruit/circuitpython/pull/6076/files#diff-edac12d728f2a3db7c325f4b3d9865f5fe9feb69e34302d626dc2cd11b2bd695R173 and it seems to behave normally after that to my eye.
I'm going to try the split screen REPL to ensure that still works but if so I could submit a new PR with that change as long as both "normal" and split screen mode still behave well.
which line? sounds good, thank you. Yes, a new PR would be great
supervisor_start_terminal(self->width, self->height);
in the display_core show function.
I'll make one shortly.
Weird, sorry I missed that. Let me take another look.
@mental nexus see ^^
This will fix the current issue, but then it will revert so that if the REPL is resized, then it won't get reset to the original size when the code.py finishes.
@mental nexus Ah Yeah, in the process of testing that I noticed the adverse effects when code.py finishes or when I am trying to reset back to full size.
As a short term fix (and in the interest of getting 7.2.x stable and ready for mass usage ASAP) I think it's worthwhile though. In 99% of use cases the user isn't using the split screen, and most likely has a code.py with a while loop that makes it not end.
For almost everyone the behavior will return to normal, only folks playing with the new feature will have any weirdness if I am understanding.
It looks to me like way scrolling is performed gets messed up when supervisor_start_terminal gets run. I'm still hunting to understand what is causing the insertion pointer to go weird and for the data not to get cleared on a newline.
If there's a rush to a stable revision, I'd just revert for now and we can revisit for the next round.
I'll leave the call to Dan, I was going to PR removing the start_terminal but then keep digging on trying to get the scrolling to behave normally in the post split screen use-case afterward.
I've got a little time now, I'll look for a bit to see if it's obvious...
Ok, I think I've got it. Let me clean up a few things and push a PR for review.
I tried out this branch again after newest commits on Feather TFT ESP32-S2. Confirmed that the name is now zlib and functionality still working as normal for unzipping data from the US Govt. analytics site.
Yes, when autoreload stops working autoreload_delay_ms is always stuck at 500. So, it's not running autoreload_tick(); which means supervisor_tick() isn't getting called from evsyshandler_common(). I am not sure how the interaction between tinyusb and the event subsystem is supposed to work, however.
This PR is to resolve the garbled characters observed in:
https://github.com/adafruit/circuitpython/pull/6076#issuecomment-1047174101
Test code for standard use of the REPL:
for i in range(3):
print("hello world!")
Test code for resizing the REPL. I just see one minor weirdness when using the resized REPL and then code.py finishes running. If there is no serial connection, whenever the code is done running and it resets back to the REPL, the "Code is done...
Thanks @tulip sleet and @lone axle. I hope this revision resolves the issues that were observed. If this needs to wait for another version, no problem with me.
There's just one minor weirdness with the "resize-REPL" usage. The "Code done running." is printed before display.show(None) is called. So if your REPL-resizing code finishes the code.py, and without a serial terminal connected, you just get a Blinka and a black screen. I'll add an issue.
Thanks! @lone axle I think you are in the best position to test, if you could. I will do a smoke test but you have a clearer idea of the best behavior.
Yep will try it out in just a moment.
Looks good to me. Tested successfully on PyPortal. The following scenarios all appear to be working as intended:
code.py without while True and doesn't raise an exception
code.py that does raise an exception (it remains visible)
code.py that contains screen splitting and doesn't have a loop. (screen split works normally and terminal returns to normal full size after code.py completes)
REPL executing code that raises an error. (error is visible but scrolls off the top as expected i...
Finally used the little tft on my clock
Whoops that's not for this channel, it's an Arduino project๐ฉ
CircuitPython version
Adafruit CircuitPython 7.2.0-rc.0-3-g6b2266b24-dirty on 2022-02-21; Adafruit PyPortal with samd51j20
Code/REPL
import board
import displayio
import supervisor
import time
display=board.DISPLAY
# Create a Group
mygroup = displayio.Group()
print()
print()
print()
print("REPL control test: Taking control of REPL group")
time.sleep(3)
# clear the display to the REPL
display.show(None)
splash = board.DISPLAY.roo...
Support for the LILYGO TTGO T8 ESP32-S2.
It's heavily based on the already available LILYGO TTGO T8 ESP32-S2 V1.1 ST77789. The main difference seems that this unit doesn't have a display, more GPIOs to use and a third button button (KEY, not implemented at the moment).
[adafruit/circuitpython] New comment on pull request #6079: Add support for LILYGO TTGO T8 ESP32\-S2
Duplicate VID/PID usage found!
- VID/PID: 0x303a:0x8007
Boards: lilygo_ttgo_t8_s2, lilygo_ttgo_t8_s2_st7789
$ lsusb
[...]
Bus 003 Device 002: ID 06cb:00f9 Synaptics, Inc.
Bus 003 Device 046: ID 303a:8007 LILYGO TTGO T8 ESP32-S2
Ignore it?
[adafruit/circuitpython] New comment on pull request #6079: Add support for LILYGO TTGO T8 ESP32\-S2
hi, no they need unique PIDs please!
@kmatch98 sorry, I thought this was pre-PR, and closed it by mistake.
I'm working on a modification to Adafruit_CircuitPython_Typing (to add a ByteStream protocol), and running pre-commit locally is happy with everything except this:
pylint (examples code)...................................................Failed
- hook id: pylint_examples
- exit code: 127
with no other diagnostic output. I haven't touched examples. What should I do?
it may be mad that there is no code in the example. I'm not certain though.
maybe try running pylint on the example script directly to see if it outputs any more than pre-commit.
Hi folks - after @slender iron's stream Friday and my discussion w/@tulip sleet, I thought I'd go live with some thoughts about USB Host. I'll try to keep them short https://www.youtube.com/watch?v=TwxYrRGAOko
Quick stream discussing Scott Shawcroft's live stream from Friday as well as some thoughts about USB devices in general. Perhaps a conversation about distributing/selling devices.
Thanks. I tried running pylint and found out I didn't have it installed. So I'm not sure what pre-commit was running... Anyway, I pip'd it in, reran pre-commit, and everything passes. Thanks!
we have some Reasons that we don't install pylint via pre-commit, even though letting pre-commit do it in a virtual environment is the "right" way... glad you figured it out
No worries. Just wanted to leave a few bread crumbs for when someone sees it again.
The __await__ method is added to Task class, which is just a wrapper of getiter. The name of the module is not modified for now, because the renaming should be in sync with adafruit/asyncio. With this PR, Task object becomes awaitable, and the following code works.
import asyncio
async def coro(s) :
print("coro start", s)
await asyncio.sleep(s)
print("coro done", s)
return f"coro result({s})"
async def main() :
print("main start")
res = await asyn...
I have reopened https://github.com/adafruit/circuitpython/pull/6041, where __await__ method is supplemented to Task class.
Thank you for doing this, and testing it! I have a few changes, but I'm glad you were able to figure out an easy way to do this.
Can you move these routines back down to their previous position, and then move task_await() below them, so that it won't need forward references? That will make it easier to do a merge from upstream later.
Instead of defining it here, use MICROPY_PORT_BUILTIN_MODULES (as mentioned below for other modules), which is in py/circuitpy_mpconfig.h.
Go ahead and rename it to _asyncio instead of _uasyncio. I'll change the library now to reflect that, since a change in the library now makes no difference. That will also ensure that it will only work with the fixed version . Don't rename MICROPY_PY_UASYNCIO; we'll leave that name alone.
@tulip sleet I'm happy to release that library for asyncio, but I assume it's probably a major rev change?
@tulip sleet what's the quick summary of the advantage of enabling _asyncio? Is it faster / less memory / ???
I'm trying to submit a PR, and getting this error from Build docs:
Warning, treated as error:
29
/home/runner/work/Adafruit_CircuitPython_Typing/Adafruit_CircuitPython_Typing/circuitpython_typing/__init__.py:docstring of circuitpython_typing.ByteStream.read:1:'any' reference target not found: count
30
Error: Process completed with exit code 2.
I imagine it's complaining about the lack of a :param statement, but the message is kinda cryptic. Where would I find documentation of the expected comment format?
@winter mortar can you link to the PR directly? I'll take a look.
"""Read `count` bytes from the stream. If `count` bytes are not immediately available,
Try using double backticks, ``count`` instead of `count`. The markup for docs uses single backticks for cross references and double backticks to set something in typewriter font. A bit different than markdown.
It also looks like you'll run into the same problem for buf in the docstring of write below
This is the the error I hit most ๐ญ
It is faster, and i think there is additional functionality
We can wait on the circuitpython PR I referenced, that is not done yet, and then I may do some testing. Also I need to finish reviewing your PR; they could be released together.
Sounds good!
Actually, on that note, I ended up merging it, did you want to wait on that too?
it doesn't really matter one way or the other, since _uasyncio is not turned on in builds anyway
and the release is separate from the merge
Awesome, thanks for explaining!
<@&356864093652516868> CP Weekly meeting is in ~50 minutes. Please add your hug reports and status updates to the notes doc if you're planning to participate or want them read off during the meeting. See you all soon! https://docs.google.com/document/d/18qlzNr5o2KUEwxZWGmxTlj0CBFyns3sBlGcCfc1j1D0/edit?usp=sharing
Google Docs
CircuitPython Weekly for February 22nd, 2022 (TUESDAY!) 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...
This usually happens when we don't fully reset the PWM peripheral or how it's tracked as in use between runs. I think this is usually done from reset_port().
@lone axle ports/espressif/certificates/nina-fw I think
re: "Try to figure out where / how to update the certficate(s) that circuitpython uses for making HTTPS requests."
Thank you! I guess there is a separate place for the AirLift ones that use co-processor? maybe inside of the nina firmware?
@lone axle yes the idea was to share between them
Adafruit Industries - Makers, hackers, artists, designers and engineers!
We just released Adafruit.io WipperSnapper support for theย Adafruit Feather Huzzah ESP8266! Over the past few weeks, Melissa worked on a web-based installation tool to upload firmware to an ESP8266โฆ
1๏ธโฃ 0๏ธโฃ 0๏ธโฃ 0๏ธโฃ 0๏ธโฃ 1๏ธโฃ 0๏ธโฃ 1๏ธโฃ 1๏ธโฃ
โค๏ธ
@onyx hinge is it 8-bit or 8-inch Atari floppies? (maybe both ๐ )
oh 8 bit. they're 5.25s.
did I say 8 inch? my mistake. I've dodged having to get an 8 inch floppy drive thus far
no, you said 8-bit. I was not familiar with the Atari nomenclature
I don't know much about Atari either, from that era
you can do so much with a 160K 8 inch floppy
You are not live-streaming the birth? ๐
We'll wait for a deep-dive on diaper changing...
๐
๐
or print-debugging trying to calm a crying baby
Neopixels turn red when needs change
TFW your audio was sending to the wrong output so for a hot minute there you thought there was no audio at all on the recording. ๐
CircuitPython version
If I understand the pinout of the `ESP32-S2 TFT` correctly I should be able to access to `boot` button through the `board`'s `BUTTON` attribute, but this throws an exception.
Link to pinout PDF: https://github.com/adafruit/Adafruit-ESP32-S2-TFT-Feather-PCB/blob/main/Adafruit%20ESP32-S2%20TFT%20Feather%20Pinout.pdf
I can't find another way to access GPIO0.
Code/REPL
# Adafruit CircuitPython 7.1.1 on 2022-01-14; Adafruit Feather ES...
ok, host calendar is updated
Keen, thanks!
I think the BUTTON attribute may have been added after the release of version 7.1.1 I would recomend trying with version 7.2.0-rc.0 and see if board.BUTTON exists on that one.
Will check later today and report back. Thanks for the amazingly quick response !
Note that we already have a "stream" protocol internally and it'd be good to have a corresponding Python type for it.
@t-ikegami Are you ready for another review? Let me know when you are.
Want to init the eink here? See the magtag for an example that does.
Thanks for the PR @gamblor21!
It looks like the uzlib API isn't grounded in the real zlib API. The CPython API doesn't have an IO wrapper class at all. The decompress object doesn't really have the stream API.
However, gzip has a GzipFile class and a gzip.decompress() function. I think that's the best approach for making this CPython compatible. Rename to gzip and rework the API to match. https://docs.python.org/3/library/gzip.html
There's a pull request (https://github.com/adafruit/Adafruit_CircuitPython_Typing/pull/2) to add a ByteStream protocol.
I think tinyusb should just start the tick using supervisor_enable_tick via autoreload_start(). It is interesting that there is a check that autoreload_delay_ms == 0 to start the tick. Here it is 500, so it must have tried and failed to start the tick. Or ticks were disabled separately while autoreload_delay_ms was non-zero.
[adafruit/circuitpython] New comment on pull request #6079: Add support for LILYGO TTGO T8 ESP32\-S2
Looks like the first version is from Espressif so you can request a second one here: https://github.com/espressif/usb-pids You may want to update the description of the original ones as well to make it clear that they have screens and a different pinout.
I'll take a look a bit more in depth at the gzip API but I did not see anything that allows a stream just the file functionality. I think the stream functionality was required in the example @FoamyGuy had decompressing the web service request. Or can the file functionality be used for a data stream from HTTP?
zlib does have a decompressobj(...) function that states it is used to decompress streams of data (and returns a zlib.Decompress object). But may also take some work to change...
Thanks. I'll check with Gadgetoid, as he's been writing our support for this board, so will have a better idea of how feasible that is.
My current code is access response.content which I originally did think was a stream. But the docs list bytes, so perhaps I misunderstood what it was.
I've only taken a quick look, but I didn't see anything in gzip that seems to have the stream functionality.
I do think being able to decompress a stream would be good functionality to have. I can see CPython not benefiting from it a...
Just as FYI did this as a quick change to hope the extmod could work so depending on the extent of rework this may take a while as it is low on my priority list at the moment.
Ya, totally get that. We do have a third option of picking a non-CPython name for the existing API. I'd avoid uzlib because it's not like zlib.
Can't the file API be used for streams? I wonder how the real requests library handles gzip.
I'm trying to set up a CircPy build environment, following the instructions at https://learn.adafruit.com/building-circuitpython/macos. I downloaded gcc-arm-none-eabi-10-2020-q4-major-mac.pkg from the Arm developer site, installed it apparently successfully, but can't find any of the content. (In particular, gcc-arm-none-eabi isn't in my path.) What am I missing?
did you restart your shell? I feel like I just used the installer when I was on mac
I might have used brew instead though
I'm in a different shell, and looked in yet different shells. (The build is actually complaining about arm-none-eabi-gcc). Yeah, I just used the installer on the .pkg.
There's a way to install the compiler with brew?
What does which arm-none-eabi-gcc show you?
Well that looks easier! I'm trying the brew-install now.
That's how I did it.
Woo hoo!
~ % which arm-none-eabi-gcc
/usr/local/bin/arm-none-eabi-gcc
Thanks!
๐
@onyx hinge Does grep ignore .files by default or something?
ummm "sort of"?
Or wait, it's not checking for file names... I want it to check for files with a word in the name
But include .files.
It's in a git repo folder
What magic am I looking for?
you want to find files that match a grep-style pattern?
I think?
in the current directory, or in all subdirectories too?
All subdirectories
"find -print" will print one filename per line. You can 'pipe' it to grep, which will print matching lines: "find . -print | grep example"
Looking for filenames that include the word skip in them. But they're likely dotfiles.
ok
you'll find sites that offer you more complicated ways to do it if you're dealing with insane filenames (like, say, someone names a file to contain a \n newline character) but I assume you're dealing with something sane for the sake of simplicity
I think so yes
That found nothing. Hmm.
wait
I didn't need the wildcards.
That worked
I believe find always prints line by line when piping, I use find . | grep something
if you're also looking just for files 'known to git', you can git ls-files "**/*.skip". The pattern "**/*.skip" is an "extended glob" which is different than a "grep". ๐คฏ why can't computer science people keep it simple
ugh, guys, find . -name '*skip*', no grep please
or you can use -name with a full name or wildcards find . -name '*.py'
@jaunty juniper I think you're right! but I have memories of some obsolete version of find that chided me for not saying "-print" so I usually include it. go figure
Oof.
Didn't find what I was hoping to find anyway. ๐ฆ
or -iname if case insensitive
I usually prefer using grep, more options for the name pattern
find | cat | grep | cat
also, I'm so annoyed by people piping the output of find into xargs and then rm, when there is -delete...
not enough cats
Anyone see a way in this file to force the CI to skip testing a file? https://github.com/adafruit/ci-arduino/blob/master/build_platform.py
It's designed for a .boardname.test.only file to be included with all .ino files, and it only builds for that board.
I want it to not build for anything.
@idle owl you can also use github to find files .. click the "go to file" button near the top of the files list and then type the substring you're looking for
It's a weird use case.
Oh good to know.
I don't know the answer about arduino though ...
looks like if you create a file named the same, but with '.skip' at the end, it will skip the original file
So I still need to include a .boardname.test.skip file if I'm reading that correctly...
or press "t"
Wait... is that right? It still needs a platform in the .test.skip file for it to work, right?
it has to be a full file name
Right.
Oh hmm. Now I'm wondering if it skips only that platform, or all platforms....
it skips just that platform, I think
Bugger. There are groupings, I think I can use, to cover a lot of them. Hmm.
But I don't think they cover all.
I think you just get to create each one separately
So I'd end up with an endless set of .skip files that will have to be updated every time we add a new board.
you're thinking "wow I need to skip all the boards with 'y' in the name" and noticing you can't do that?
I think you're right to have a sinking feeling about that.
would specifying the files not to be skipped be easier?
It won't build for anything. It's template starter-code, so there's random things in it that need to be replaced with actual values before the code will compile for anything.
Normally, yes.
But this is a weird use case.
do you have to put it in a folder called "examples"? or can you put it in a folder called something else?
or maybe that's not how it works
It's going in Arduino_Templates/example_name
can you call it .ino.txt instead of .ino?
But that can be anything, I guess.
Oh hmm.
Yeah, I could do that, I think
It has to get copied into Arduino, updated, tested, and submitted to Learn separately anyway.
on windows it can be tough to revise the file extension within the Windows Explorer but from commandline it's all fine
If a new name were selected would it be for the stream API only and decompress() would stay under zlib since zlib.decompress() does seem to match the CPython API as-is. Or would decompress() move as well?
I tried poking around in https://github.com/psf/requests to figure out how it's handled in there, but I'm coming up empty. I tried some git greps for terms like gzip, zlib, and zip and the majority of the results I found seem to be in the documentation or the test files. T...
And GitHub renders .txt files... I have no idea if it would manage to render a .ino.txt file, but viewing "raw" would probably show the code.
MacOS is easy with that. It verifies you mean to change it, but it updates it pretty simply.
Also I don't want to hardcode the Arduino_Templates directory to be skipped, because some of the template code will probably compile properly as-is, so I'd want CI to run on it. Though, I'd only be testing it against one board in Learn CI, because I'm not including a .test.only file for every board guide the template goes into. So maybe that's not out of the question. Or maybe it's worth adding an actual .all.skip type functionality. That's outside my wheelhouse though, I think.
@lone axle did you notice https://docs.python.org/3/library/gzip.html#gzip.open can take an open()'d file?
"The filename argument can be an actual filename (a str or bytes object), or an existing file object to read from or write to."
I don't understand what that means practically speaking.
@lone axle requests uses urllib3 internally, and urllib3 uses zlib:
https://github.com/urllib3/urllib3/blob/f0dffb4e2437cb2da2ba0a6bbea6211f6fd0fa4b/src/urllib3/response.py#L4
https://github.com/urllib3/urllib3/blob/f0dffb4e2437cb2da2ba0a6bbea6211f6fd0fa4b/src/urllib3/response.py#L303-L313
@jaunty juniper thanks, I was just finding that as well!
Oooh, no I didn't catch that. I wonder if "existing file object" means anything with the expected read() function would work. In our case there is no local file that contains the data it would all be coming from the response to the HTTP request. If it were a stream though it would behave similar enough to an opened file maybe?
Yeah, I don't understand how the skipping vs platform-specific bits even work in here. Much less how to add something that skips all.
@lone axle pretty much I think? ```py
import gzip, io
zipped = gzip.compress(b"I'm a little teapot")
with io.BytesIO(zipped) as open_gzip_file:
with gzip.open(open_gzip_file) as unzipped:
print(unzipped.read()) # Prints b"I'm a little teapot"
... afk!
And thank you @jaunty juniper! looks like they are using zlib.decompressobj() which appears to be one of the differences between CPython zlib and micropythons uzlib (now called zlib in that PR). The micropython module doesn't have the decompressobj() functions.
I guess the .txt option is the best way to go.
Is there an example anywhere of our requests library reading the data as a stream? I had originally though that is what response.content was but now thinking I was mistaken in that.
Ah it appears that requests has an iter_content function for streaming a smaller chunk at a time. When the content property is accessed it uses that internally: https://github.com/adafruit/Adafruit_CircuitPython_Requests/blob/270565665ada26fe8d7a99a3cb5941b452444471/adafruit_requests.py#L426
Oof, looped Carter into the conversation in the #help-with-arduino channel....... .none.test.only skips CI entirely for .ino files. ๐ Good thing I mentioned it to him... I would have done a bunch of nonsense to get around it otherwise.
@slender iron @onyx hinge I'm doing 7.2.0-rc.1 unless you know of some reason not to.
all good to me
@onyx hinge @stuck elbow Carter knew the answer. ^^
Automated website update for release 7.2.0-rc.1 by Blinka.
New boards:
- espressif_esp32s3_devkitm_1_n8
It's a sneaky little if platformname != "none" that I think does it.
groan, I tagged 7.2.0-rc.1 against main, not 7.2.x
Oof.
in process ๐
๐
Nice ๐
Automated website update for release 7.2.0-rc.2 by Blinka.
Closed, mistakenly released against main instead of 7.2.x
Thanks @tulip sleet !
Confirmed working as expected on 7.2.0-rc.0
For those who are waiting for 7.2.0 to land in stable I worked around this with:
import microcontroller
import digitalio
b = digitalio.DigitalInOut(microcontroller.pin.GPIO0)
Pin PC13 on my STM32F412CG has the alternate function of an anti-tamper pin, but I planned on using for a SPI chip select. When I go to assign it as a digitalio it says that the pin is already in use with no other code running. I'm guessing it has to do with
never_reset_pin_number(2,13); // PC13 anti tamp```
in my `peripherals/stm32f4/stm32f412cx/gpio.c` file. Is that `never_reset_pin_number` necessary? I put it there because I saw other microcontrollers in there had it.
the f401 doesn't seem to have it, maybe it's not needed
you shouldn't need that; the never-reset is for a pin that has some dedicated use, like always connected to a display, etc.
are you making up your own board definition?
or is this an existing board?
then you don't need it
That did it
Has anyone setup circuitpython on the Digispark Attiny85? If so could you link a project? Thanks. Searching and I haven't found anything yet. Maybe there is a physical limitation I'm not aware of.
@old marsh not enough flash
The ATtiny is, well, much too tiny. It has 8K flash memory and 512 bytes of RAM. The smallest MCU on an Adafruit board has 256K flash, 32K RAM, and those numbers are probably close to the low end of what you need in order to do anything useful with a Python.
Understood. Figured there was a reason why I didn't find anything. Just didn't want to do ducky scripts in C++.
I found a project where someone used a Pi Pico with circuitpython. Changed a few pins in the code and have it working on my feather 2040 I already had circuitpython installed on.
@t-ikegami Are you ready for another review? Let me know when you are.
Please go ahead.
The module is renamed from _uasyncio to _asyncio. I couldn't figure out MICROPY_PORT_BUILTIN_MODULES stuff well, but the module is now registered not in objmodule.c but by MP_REGISTER_MODULE. (I referred modure.c and modujson.c.)
If you want a really tiny interpreter, check out https://sneklang.org/ . There are also versions of FORTH that run on very minimal microprocessors.
https://xkcd.com/1987/
Today I'm learning about environments so I can get my CircPy build building (https://towardsdatascience.com/what-is-a-python-environment-for-beginners-7f06911cf01a)
I'm a bit late to the SI1145 party but was also very disappointed Adafruit did not have a circuitpython driver for a sensor they are currently selling. I have created my first Raspberry Pi Pico project with an attempt at the circuitpython driver for the SI1145. Just opened my github account , here's the link: https://github.com/socraticmethod00/pico
@tulip sleet do you have time to chat usb host API?
sure, one minute
๐
CircuitPython version
Adafruit CircuitPython 7.1.1 on 2022-01-14; Adafruit Feather STM32F405 Express with STM32F405RG
Board ID:feather_stm32f405_express
Code/REPL
# can't so the entire program... the code in the traceback is here, line 223 is the last line
if SDWRITE:
# save the data to the data_log.txt file
with open(DFN, "a") as dl:
dl.write(ds)
dl.write('\n')
...
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/1CtfTbhzjGUZczy9LULKjNmz8eXSboHFM93cvudDZc0g/edit?usp=sharing
Google Docs
CircuitPython Weekly for 28 February 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 participate,...
anyone want to try and replicate this? https://forums.adafruit.com/viewtopic.php?f=60&t=188728
@tidal kiln FYI, the CircuitPython TFT pages are live now. So you can point folks to those when needed. Working on the Arduino template for basic TFT stuff.
https://learn.adafruit.com/adafruit-esp32-s2-tft-feather/tft-basics
https://learn.adafruit.com/adafruit-esp32-s2-tft-feather/tft-github-stars-wifi-demo
Checked with him and he agrees its a good idea to do, and in theory shouldn't be too much work. However, we have a hard deadline for launch and looking at our outstanding task list, I don't know if it is feasible for us to get it implemented in time.
Would it be problematic to launch with these current definitions and add the board_init stuff at a later date?
Hi. A while ago i was here seeing if circuitpy supported MAC address changing in the nrf52840 ble libraries. The answer was it didnโt. Does anyone know if itโs now possible?! Or i just stick with our c code.. ( https://github.com/AceCentre/morAce/blob/572e972336961dcf111b94a6fbabcda6ba3ca1be/morAce/morAce.ino#L852 if anyones interested..!)
Since examples for picoplanet use pulseio, it's good to enable them.
Instead I'm disabling rotaryio and keypad, since the picoplanet doesn't
really have any pins you could use those with.
@analog valve why do you need to change it?
@tulip sleet so bill's main feedback was to move away from press/release events to passing the current pressed state
if you do events and overflow your buffer then you risk missing a release
which is something I heard from obra as well
do you think this applies to keypad too?
ya, that's what I'm thinking
HID library as well potentially
bill doesn't know that its how usb works too
it's also not obvious to me what the descriptor for the intellikeys actually is
and whether tinyusb would recognize it as HID
bill could send it; I don't seem to have it in email
it's not obvious from the arduino code
si
so I guess I'm walking back my idea a bit. I still think we could do the class level stuff but also make the generic API available
let's find out about the intellikeys, i'd say don't change yet
@tough flax we'd love to know more about intellikeys when you are around
Not at all. Later is fine with me. Just wanted to make sure it was on your radar.
Please provide a full test program that shows the issue. It's much easier to fix a full example.
Support for the LILYGO TTGO ESP32-S2-WROOM.
This board is similar to the NanoESP32 S2 w/WROOM.
If a new name were selected would it be for the stream API only and
decompress()would stay underzlibsincezlib.decompress()does seem to match the CPython API as-is. Or woulddecompress()move as well?
I'd be ok if they were split into two modules.
@slender iron lotsa intellikeys on eBay, not expensive
ok, ordered
@slender iron @tulip sleet I assume you found https://github.com/gdsports/IntelliKeys_uhls ?
// From OpenIKeys on github
const INTEL_HEX_RECORD loader[] = {
16,
0x146c,
0,
{0xc2,0x00,0x90,0x7f,0xa5,0xe0,0x54,0x18,0xff,0x13,0x13,0x13,0x54,0x1f,0x44,0x50},``` ๐ฑ first upload the firmware to the embedded 8051..
I forgot about that repo
@onyx hinge ya, I saw that but couldn't tell what the device actually does
Where (or how) are MP_QSTR_* symbols defined? I want to change the name of a parameter in a shared-bindings file.
they are not, they are found in the code by a script prior to compiling
(There's a MP_QSTR_stream used in another .c file, so maybe I don't have to do anything except use it?)
you can just make them up and they will be added to the strings automagically
thanks!
there are very occasional problems with adding QSTRs in this way, due to a source file not being listed in a place it needs to be. If you run into one (where, say, you add QSTR_abcdefg and then get an error about it not being defined) filing a github issue about it may lead to it being resolved. But as a workaround, you can make BOARD=whatever clean and then make again and that'll almost always fix it.
Becauseโฆ. If you use switch access on iOS. - if you want a device to change from a system switch interface to say a switch interface for a app then changing the MAC address is the only way to do it. If you donโt (& just change name, manufacturer name etc) iOS just refuses to see it as a different device. Another use case. We have some code that interprets morse code to hid. But then we want a user to use the same interface to use switch scanning. Doing it this way allows this.
The IO parameters in msgpack.pack and msgpack.unpack are now named stream and annotated as circuitpython_typing.ByteStream. Fixes issue #6050.
build-doc is failing for msgpack/__init__.pyi, apparently because shared-bindings/circuitpython_typing/__init__.pyi does not have the new ByteStream definition in it. How do I correct this?
To address a slight elephant in the room: SONY Spresense, the CircuitPython board with the headphone jack does not currently have audioio or audiomixer.
Currently working on Spresense with the initial aim of porting Mozilla WebAudio Biquad Filter (Equaliser) to CircuitPython audiomixer
(which is half and half completely unrealistic due to the way it's been architected with NuttX)
This Arduino Sketch sums up what I found and plays a TV Beep through the headphone jack,
with hope that it could be used to trace doing the same thing in CircuitPython with some of its extra DSP features for accelerating audio on other boards.
Tested while wearing SONY's old but pristine headphones of course. The same beep example can be done on a Raspberry Pi (with GPIO 14/15 muxed I think it was?) without any OS
list of dead links:
- https://github.com/adafruit/awesome-circuitpython/blob/076bfa61813df46026f3eac97f351edcaa392842/README.md?plain=1#L98
https://electroniccats.com/producto/meowmeow/ and https://electroniccats.com/producto/catwan_usb-stick/ and https://electroniccats.com/store/bast-wifi/ - https://github.com/adafruit/awesome-circuitpython/blob/076bfa61813df46026f3eac97f351edcaa392842/README.md?plain=1#L103
- https://github.com/adafruit/awesome-circuitpython/blob/076bfa61813df46026f3...
hi,
in this list there is a lot of redirected links
and lot of http://.
i fixed those up like i did in https://github.com/sindresorhus/awesome/pull/2180 , https://github.com/troxler/awesome-css-frameworks/pull/66 , https://github.com/44bits/awesome-opensource-documents/pull/28 , https://github.com/academic/awesome-datascience/pull/320 , https://github.com/AchoArnold/discount-for-student-dev/pull/137 and https://github.com/adafruit/awesome-adafruitio/pull/5.
and i created a https:...
๐ please file an issue so we can track it: https://github.com/adafruit/circuitpython/issues/new/choose
@warm stump sony actually added support for that. I'm sure they'd be happy to see you add more to it
will do once I get an authentic analog recording straight from the board, surely I can't be alone in wanting this to be a thing supported on most CP boards
we do have an issue for analog recording in cp
the one about mp3 playback? yeah maybe it could be a comment on that one, but it is quite specific to Spresense
We would love to be able to change MAC address of a ble device in circuitpy. Right now itโs the last thing holding us back to rewriting alll our code in py
use case. You can see some code here of how we are doing it in c https://github.com/AceCentre/morAce/blob/572e972336961dcf111b94a6fbabcda6ba3ca1be/morAce/morAce.ino#L852
imagine you use switch access on iOS. - if you want a device to change from a system switch interface to say a switch interface for a app then changing the MAC addr...
thanks @analog valve
I'm around
Just got home from the Lightning game (we won)
Good lord I hope you bought one on ebay
I have lots and would be happy to send you one
Sometimes they are like $300!
Well, that's a question and a half
It's requires custom drivers
But I believe it uses an HID model
do you have a copy of the descriptor?
@scanlime did a teardown and we have the actual source of the drivers here:
Let me see if I can find it
๐
I'm just thinking about whether we'll do low level endpoint access in addition to higher level HID access
the lower level will work for more devices
This is the USB Host library the "gdsports" wrote that interfaces with the IKeys
It's what we use today
GDSports (no idea their pronouns - and I asked and got no response)
ya, I was looking at it but couldn't tell what the usb interface actually was
But they reverse engineered that host from the source code we had released
k, let me look at that
It is based on an EZUSB which you are probably too young to remember
Basically, every time the device is connected, the full firmware is downloaded
It's a bizarre thing they did when non-volatile memory was rare
This is probably where to look https://github.com/ATMakersOrg/OpenIKeys/tree/master/original/IntelliKeys/WindowsOld/common/firmware
Here at line 71 you'll see HID report descriptors https://github.com/ATMakersOrg/OpenIKeys/blob/master/original/IntelliKeys/WindowsOld/common/firmware/Ik.h
But you'll also see an original comment saying "these structs are wrong/not used"
So... you know
good stuff
ya, it does seem like it is custom hid
This might be helpful https://github.com/ATMakersOrg/OpenIKeys/blob/629f88a35322245c623f59f387cc39a2444f02c4/original/IntelliKeys/MacOSX/common/firmware/dscr.a51
yup, looks like vendor HID
It's vendor HID... BUT, because it needs to load the firmware, it also needs to send the firmware. So it's not "driverless vendor HID"
right, and the firmware is sent over hid too?
I saw the arduino driver does check pid to know the device state
I'm not sure how GDSports was loading the firmware... I was delighted that it just worked ๐
๐
When Ablenet open sourced the drivers, they literally shipped me the hard drives from their servers
no docs, no help
"Here, it's all yours"
having source is nice though
ok, I'm off but I found the teardown video and will watch it
Great - thanks for looking at this stuff... did my thoughts about how we buffer make sense to you?
Firmware loading happens here around line 100 https://github.com/gdsports/IntelliKeys_uhls/blob/master/IntelliKeys.cpp
Mozilla WebAudio API covers a large portion of what you would like to see working in CircuitPython audioio, audiomixer and synthio: https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API
It is currently in Working-Draft for Javascript in Modern Web Browsers such as Firefox and Chrome and is very well documented, so much so that I have written several demo apps: https://github.com/adafruit/circuitpython/issues/5944
A CircuitPython port of this API would be able to bridge...
Aside from the one change request the other changes look solid. I spot tested several, but not all.
The original link is preferred by the owner's.
ok i will change that back soon
I receive error when building STM32 ports,
./st_driver/stm32f4xx_hal_driver/Inc/stm32f4xx_hal_def.h:30:10: fatal error: stm32f4xx.h: No such file or directory
30 | #include "stm32f4xx.h"
Where "stm32f4xx.h"?
The library repos currently link to https://adafru.it/discord. I'm not familiar enough with discord to know if there are differences between the different links though. It may have gone through a few different phases of link shortening type over the years.
@jwcooper This looks like a typo in wherever the redirects are?
make sure the submodules in git are up to date. Do make fetch-submodules from the top-level repo directory
@tough flax I also ordered an eBay intellikeys (same vendor as Scott, I think)
https://blog.rust-lang.org/inside-rust/2022/02/22/compiler-team-ambitions-2022.html it's worth seeing how other communities talk about year-scale goals
Let me know if there's any problems. We'll be launching this imminently.
Automated website update for release 7.2.0 by Blinka.
The feature list is now a bit shorter. The details were a bit extensive from my point of view and mostly covering the ESP32-S2FN4R2 and not so much the S2 Pico itself.
Also, add a small intro.
Yup, I've heard a similar suggestion from others too
@tannewt noticed that in I2C-bus specification version 7.0 (October 2021), official new names were given: Target and Controller replace the older deprecated terms.

This would potentially include renaming (again) the I2CPeripheral class, as well as other code and documentation changes. Since renaming a class is an incompatibili...
@TheMindVirus I'd recommend adding an issue for supporting the existing audio apis on spresense too.
Merge changes to branch 7.2.x made for 7.2.0-rc.2 / 7.2.0. This is in preparation for 7.3.0-alpha.1.
Looking more closely at our implementation, I believe this is already supported. Adapter.address is both readable and writable. So, I think you can do something like:
import _bleio
new_address = _bleio.Address(b"\x00\x00\x00\x00\x00\x00", _bleio.Address.RANDOM_STATIC)
_bleio.adapter.address = new_address
Please give it a try and let me know if it works for you.
I think it's worth making the peripheral and target naming available in 8.x and then only target in 9.x.
@solar whale Greetings. Are you around? I have an Adafruit IO question you might be able to answer.
Further to some investigation into audioio and audiomixer being missing from the Spresense build of CircuitPython
and providing some basic support for setBeep() coming from Arduino, there are a whole lot more Audio DSP features
of the Spresense SDK and Carrier Board with built-in Headphone Jack that both this board and other boards could find
useful: https://github.com/adafruit/circuitpython/issues/2676#issuecomment-1050119528
The Spresense has its own abstraction layer that may req...
@kamtom480 Do you have any suggestions on how this would be implemented? Have you looked into it?
OK, figured out step 1. But now I think I'm running into a bug unless I'm missing something obvious.
build-doc is failing for
msgpack/__init__.pyi, apparently becauseshared-bindings/circuitpython_typing/__init__.pyidoes not have the new ByteStream definition in it. How do I correct this?
I thought i had released circuitpython_typing 1.1.0, but apparently not. I just released it, confirmed it's in pypi.org, and am rerunning the PR jobs.
