here is a my version of the pin diagram.
Open for any suggestion.
1 messages · Page 46 of 1
here is a my version of the pin diagram.
Open for any suggestion.
@HelenFoster People shouldn't be using drive strength to limit LED current. It doesn't work that way, e.g. setting 4mA drive strength doesn't actually limit the current to 4mA, you just get a voltage drop which may or may not limit current by much, depending what you're driving.
Yes, that's exactly right. I ran a small experiment on an RP2 where I tied 6 GPIO pins to ground each through its own 220R. At 3.3V this should draw 15mA each. Varying the drive strength, I saw the following mea...
I don't know if this would end up working with an I2C multiplexer, if you mean something like the chip in this product: https://www.adafruit.com/product/5626 -- is that important for your design? The PCA9554 for example has 8 selectable addresses giving up to 64 I/Os on expanders, without needing an I2C mux.
What I'm envisioning is that the IO expander could work with
This is not likely to be in any release before 9.0, which is still a ways away from seeing any alpha releases, let alone general releases.
I loaded this up on an ESP32-S3-devkit-n8r8 and it worked great. It seemed like the WiFi connection was faster and more reliable than I normally see. I'm not sure it that's a possible benefit of this PR or if I just had a really good session for some reason.
Hiya - I'm trying to commit my FeatherS3 Stemma I2C changes into the 8.2.x branch in github, and I'm having some pre-commit issues... everything has been installed correctly as per the learn guide for building CP. All requirements (dev + doc) have been installed. Everything looks fine... but I keep getting a fail with translations because of /bin/sh: xgettext: command not found
Full commit output is here...
https://gist.github.com/UnexpectedMaker/ce7d79bc0a2193d2f12bbeb850943ac3
This on an M2 Mac running 13.5.1, python version is in the gist
Any thoughts?
On linux I needed to run "sudo apt install gettext" at one point
I have the xcode command line tools installed - which should apparantly provide xgettext
Ok, I just brew installed gettext and got past that error, but now it's failing to translate a bunch of stuff I've not even touched 😦
Ok, I got it - wow, was a submodule conflict nightmare after checking out the 8.2.x branch
👍
Same changes as I added to main, but wanted them I the 8.2.x branch as that's still being worked on.
Well, that was fun! hahaha... dislike_git++ 😉
I keep two different clones, one set to 8.2.x and one to main, so I don't need to switch a single clone back and forth.
That's a very clever idea ! The switching of branches with so many (and such large) submodules is a killer.
Sometimes even more than that, if I have multiple PR's going 🙂
I have added this board to main branch
I'm confused: is this related to #8188, which is for the main branch? That has a different author.
For the matrix panel height being implied might not work in all situations. a panel that is 64x32 rotated 90 degrees would have a height of 64 and width of 32. if it's implied prior to the rotation that would work but then there's also the 64x64 panels out there too. while height might be optional i still think it's best practice to specify all dimensions, just like you would do with a TFT.
I have added this board to main branch
I'm confused: is this related to #8188, which is for the
mainbranch? That has a different author.
let me clear things up for you.
pull request #8188 has not been merged.
but pull request for same board #8352 has been merged.
I don't know if this would end up working with an I2C multiplexer, if you mean something like the chip in this product: https://www.adafruit.com/product/5626 -- is that important for your design? The PCA9554 for example has 8 selectable addresses giving up to 64 I/Os on expanders, without needing an I2C mux.
Ah sorry. When I mentioned multiplexer, I meant an analog multiplexer. On Yukon we have their address controlled by the IO Expander, and thus it's beneficial to set all the relevant ...
Closing, as this was superseded by #8352, which is merged.
Thanks - somehow I did not find #8352. Approving and merging into 8.2.x.
@PaintYourDragon Do you think Protomatter 1.6.1 will address this, or is it still to be debugged?
@phantomsixthplayer #8376 may help this.
I'm not sure where to put this. An issue, a feature request, etc..? The Metro M7 iMX 1011 does not include the RGBMatrix library. Apparently that library only exists in shared-bindings and common hal etc.. within circuit python.
Attempted to use the iMX with the Uno/Metro form factor RGB Matrix shield. Would likely work in Arduino but doesn't seem to be support in Circuit Python.
was just an experiment anyway. ```py
Traceback (most recent call last):
File "code.py", line 10, in <module>
ImportError: no module named 'rgbmatrix'
I know that kind of combination is likely out of leftfield. Was too tempting to try the iMX's speed with the panels.
@midnight ember yeah it's not supported at the moment on that chip. first move would be to file a feature request on the protomatter github repo, but I don't know if adafruit is inclined to devote developer time to it.
As to your other question/remark, unless I'm mistaken rgbmatrix doesn't support rotation. rotation comes into play when you add the displayio layer with a FramebufferDisplay. So rgbmatrix "height" and "width" are always about rows and columns in the panel addressing scheme. when you create a FramebufferDisplay you can get/set its rotation property and you can get its width and height properties which for 90 and 270 rotations are swapped compared to the rgbmatrix.
though .. there is a "teensy4" "core" for rgbmatrix, so maybe it's not as much work as you'd think (i.e.,does "teensy4" support all mimx10xx or just mimx106x or what..)
the code does imply it's 1062 only, unfortunately.
Could I use the matrixportal library? I was trying to use rgbmatrix itself as that's what I'm doing on the matrixportal s3. I'm not using the matrixportal library with the matrixportal s3... only rgb matrix.
It will do rotation np.
here's the current code i'm experimenting with 6 panels. https://github.com/DJDevon3/My_Circuit_Python_Projects/blob/main/Boards/espressif/Adafruit MatrixPortal S3/128x96 RGB Matrix/code.py
seems the matrixportal s3 has the rgbmatrix lib frozen in.
RGBMatrix is native C; it is not frozen
ah
this section tries to explain how rotation works. You use the RGBMatrix constructor the same (so rows and columns are "un rotated" numbers), and then set the rotation on the FramebufferDisplay.
The MatrixPortal library is a wrapper and convenience library around RGBMatrix, see, e.g. https://github.com/adafruit/Adafruit_CircuitPython_MatrixPortal/blob/main/adafruit_matrixportal/matrix.py
guess i should say i was using rotation with the framebuffer yes
was being lazy and didn't want to rewrite the whole thing around the matrixportal library. thank you for the directions, will do.
Verified this is a fast-forward update of the submodule. Didn't test.
Motivation is clear, execution seems fine but didn't test.
It seemed like the WiFi connection was faster and more reliable than I normally see. I'm not sure if that's a possible benefit of this PR or if I just had a really good session for some reason.
It's just cert updates, and there are no previous PR's that should improve things. But glad it worked -- thanks for testing!
A pin on an I2C expander has a characteristic we never imagined before: maybe it can't be read or written RIGHT NOW because it's on the other side of a locked bus. 😕
I’m about 90% confident this should fix it, yes.
I’m about 90% confident this should fix it, yes.
Hello
Any news about BLE software support on Raspberry Pico W?
👀
Any updates or commits or pull requests?
There aren't any updates - you can follow progress on this issue: https://github.com/adafruit/circuitpython/issues/7693
Ah ;((
Alright
Thanks
I've been doing some reading on the fascinating (and as it turns out related) topics of drive strength and slew rate. Full disclosure: I am not an EE but do have enough experience with digital electronics to be dangerous, so take my analysis with a grain of salt.
Have a look at this https://electronics.stackexchange.com/questions/360750/how-the-slew-rate-and-drive-strength-affect-the-output-signal-of-the-fpga/360752#360752. It shows graphically how drive strength and slew rate affect a sig...
I imagine there will also be all sorts of race conditions with setting its value
Picow will probably not work very well with ble too..
It already is crippled by ram..
Reserving more for the ble stack isn't gonna be fun.
not yet, because it would require changing SPIRAM_USE_CAPS_MALLOC in every sdkconfig with psram; hoping this is better after your idf5 changes!
@tulip sleet can you do final (hopefully) review on the dot clock display PR? Since scott's last review I fixed the typo and the copyright notice; and added the hack tablet board def. It'd be nice to merge it today since I'm out tomorrow; asking you because scott's out today.
sure, I'll take a look
Automated website update for release 8.2.5 by Blinka.
New boards:
thank you
you usually only use ble or wifi, though, so you could hopefully only reserve the ram for one or the other?
This looks OK to me, though of course I don't know some details. But it's consistent and I understand the related changes. Thanks!
I mean won’t cp reserve some just for the ble workflow?
I do not use picow, I don’t like it.
(Yes I bother making fixes and PR’s for a platform I don’t like)
But still I target ljinux to run on it.
And it’s seriously becoming hard.
It should be only using 70k but big allocations (10k+) fail a lot more often, rendering it pretty useless.
That’s fragmentation, even though I spam gc.collect every free slice of time
Until I learn how to execute code from storage in segments this is really hindering what picow can do
Cause currently to exec() something I need to load the whole thing.
And some .py’s are already 15k
Using the picow with Pimoroni's DVI base (or I imagine the PiCowbell) might demonstrate the case, it's possible to build the firmware with both WiFi and PicoDVI active but you're limited by RAM with what you do with it.
@onyx hinge I approved the PR, but I think Scott would still like you to update the copyright notices in shared-bindings/dotclockframebuffer to be you. There was a spelling fix that it looks like you already resolved. I can re-approve after a push.
rp4080 Ti with psram eta wen
Both Adafruit TFT Experiment board and for an unreleased pimoroni board use on-board I2C bus expanders.
Besides this, the Pico W has a special I/O pin that is on the CYW wifi coprocessor.
It is desirable for these "pins" to be able to be treated consistently by anything that doesn't require fast or accurate timing. This could include:
there was a some way to get the build artifacts for a particular pull request, anybody remembers how?
do you mean after it's merged?
no, after the tests pass?
Checks --> Build CI for open PRs
in any case, if you click on one of the builds, you can then click "Summary" at the top of the left sidebar. Then scroll down to show the artifact .zip files
or click on the apppropriate build here: https://github.com/adafruit/circuitpython/actions
note that pre-merge PR builds don't build all the languages
I will be continuing and probably finishing the ftp implementation today.
Can I stream it in one of the channels if anyone wants to see me working?
I have my v4l2loopback in obs setup so I can stream from wayland!
No objections!
but you might need privs you don't have to do video
It works.
Just curious how the streaming worked 😁 You're upside down though....
The video screen is upside down
?!
that's better, fixed 😄
So discord's preview is just wrong.. K, good to know, thanks!
Thanks for getting the CI green. Just a couple other minor things.
My WIP code (it's only compile-tested and only on rp2040) is here: https://github.com/jepler/circuitpython/pull/new/ioexpander
it includes the refactoring to create the "abstract pin protocol" and converts the microcontroller pin to implement it, but doesn't implement any other pin types yet.
@jepler I did not consider the locked I2C problem. I was testing with the ST7789 library, I found that having auto_refresh=True was a bad idea, and it was better to explicitly call display.refresh() when a refresh was wanted. As such I never thought about any async or other way of handling the display that may cause the lockup you describe.
One thing I did have to do in my build was release the displays on reset_board() to avoid the REPL rendering to the screen and thus tanking perfo...
I think this is mostly a DigitalInOut abstraction rather than a Pin one. The Pin would only be needed if you wanted to have references to them in board. If that's the case, then they could be attributes on a long living object for the expander that is also available like board.SPI(). This is a similar model to the existing PCF8574 driver.
I don't think a protocol is necessarily the right approac...
I think this is mostly a DigitalInOut abstraction rather than a Pin one. The Pin would only be needed if you wanted to have references to them in
board.
I just want to throw in that in my case I do have the pins referenced in board: https://github.com/ZodiusInfuser/circuitpython/blob/yukon/ports/raspberrypi/boards/pimoroni_yukon/pins.c
My rational there is that the IO Expanders are an implementation limitation of the board, due to the RP2040 not having enough native IO pins to perfo...
If we had the space, I'd suggest also including
DigitalInOut.drive_strengths, which would return a tuple of port-specific available drive strengths, in mA. Then the code can choose. SettingDigitalInOut.drive_strengthwould then have to either set a valid drive strength exactly, or (alternatively, a more forgiving API) would set the nearest one (or floor or ceil).So you could get the max by
.drive_strengths[-1]and the min by.drive_strengths[0]. This is portable.I d...
@tulip sleet I wonder if we need to make the Pin object smarter and encompass drive strength. maybe rename it Pad
also pulls are usually independent of usage
Done in #8372. Thanks @tirtharajsinha. Feel free to keep dropping info on this issue even once it is closed.
the only artifact is mpy-cross?
This must be a bug in the build matrix script.
@tannewt This PR exists to just make
raspberrypiact the same way asespressif.
I understand that. My intention was to ask how that behavior was implemented on ESP. My goal is to remove the special case from the supervisor code. ESP doesn't need it and therefore RP2 shouldn't either. The wifi reset must happen in some other call on ESP and RP2 should copy that.
Everything working well for me, you know, very easy to check on Linux that the USB Serial Port is working as also the USB Mass Storage device:
Two more minor things. Thanks for the updates!
There should be helpers to verify this already. At minimum let's use the same error string. %q can be used in place of "start" in MP printf and passed the qstr.
Another make translate should remove this.
ya, most micros do have a Pad concept that impacts how it behaves based on the incoming gpio or peripheral signal
Is there a way to make sure a socket.send() has been ack'ed?
If I spam file parts at max speed, they arrive with missing parts, with no errors on the board side..
I had to add some nominal time.sleep()'s to make em arrive well.
time.sleep() however isn't the right way to ensure that.
Something like .send_with_ack() that checks the ack was good, like on the rfm stuff, doesn't exist for the socket stuff?
When sending small stuff it's all good, but as I begin sending files >20k, packets are lost..
512 byte chunks with sleep(0.02) is the best I could do reliable and with margin for hops
tcp or udp?
what does socket.send() return?
self._socket = pool.socket(pool.AF_INET, pool.SOCK_STREAM)
self._socket.setblocking(False)
idk, isn't it tcp?
the no. of bytes sent
and are you checking that the number of bytes sent, is the number you requested?
it always returns the intended number, even if it fails?
lemme recheck to make sure
if the buffer only has room for 500 bytes, and you try to send 1000 bytes
it will send the first 500 bytes, and then return 500
Oh it does indeed report lower numbers on failures..
so you need to retry the send, with the tail end of the buffer
It is always the last bytes?
Well, I guess it's easy enough to just retry and check if the sums match
when it returns 832, that means it sent the first 832 bytes of the buffer you gave it
so you need to cut the first 832 bytes off, and send the remainder
lemme try that
you likely also dont need to stick to 1024 byte blocks
just try to send your entire jpeg in one shot
and then discard however many bytes send sent
and keep trying with whatever is left
it did around 2 pages of retries, all of which are 832 for some weird reason.
there are ~3 layers of buffering that are going on
first, there is however big the buffer is on the sending device, it usually has a max size, to prevent using all ram
dat = f.read(self.tx_size)
if not dat:
break
res = 0
while res != len(dat):
try:
if res:
print("Retry:", res)
res += self._data_socket.send(dat[res:])
except OSError:
pass
then there is the packets that are in-flight on the network
but an in-flight packet may be dropped, so it has to keep a copy in the tx buffer, until it gets an ACK
the more data in-flight, the higher the latency when you drop a packet and have to re-send all of the in-flight data
a normal TCP stack will adjust the "tcp window" to minimize the packet loss
and then there is the rx buffer on the receiving side
I have never made it that deep into the esp source.
Tysm for sharing all of this info with me!
don't read the whole file into memory at once
only as much as you want to send
the size I read is 1kb?
ah ok
but you can further improve it by using a memoryview for that slice
If modern linux has issue with 1mb.. I am fine with that..
memoryview is too complex for my poo poo brain
the linux end is likely reading fast enough that the buffer never fills
precisely so
it basically makes that slices without copying the data
isn't python already passing it by reference to the funcs?
slicing makes a copy
unless it's on a memoryview
ah k
I will eventually try to learn memoryview
maybe once I finish the module and try converting it to C to add it to the core
write() on linux behaves the identical way when in C
and most MCU stuff like circuitpython tends to try to copy that behavior
Does anyone know if USB Host support is included in CircuitPython?
depends on the board i think?
You’re probably really used to microcontroller boards with USB, but what about a dev board with two? Two is more than one, so that makes it twice as good! And the Adafruit Feather RP2040 with USB Host is definitely double-the-fun of our other Feather RP2040 boards, with a USB Type A port on the e...
I don't see it in the list
maybe it's frozen, maybe it's not
usb_host it is iirc
so if it's not in here, it prolly isn't on any other
"Currently, support for the USB Host peripheral is only in Arduino. So check out the TinyUSB ‘dual role’ examples for some things you can do"
(from that link)
Eh that's out of date..
yea, lemme check the source
thx
answer: it does
I can see it init the usb port from boot
so it certainly does have it
It could be though, that 8.2 doesn't have it but the current main does
No problemo, Idk much on the topic, but glad I could help!
CircuitPython 8.2.5 Latest was just released 3 hours ago, so it's probably in there
i recently build circuitpython from source, for the regular rp2040 pico, and wired a usb cable to the right gpio pins, and was able to do usb host, i think i just had to run 2 lines of python
Certainly worth checking, but CP is currently developing both the 8.x line and the 9.x line so if it doesn't seem to be in 8.2.5 grab the firmware from the "Absolute Latest" link
the boot stuff that is in 9.x isn't in there
they prolly weren't backported
This?
that's the board I am looking at
Well, it could be that just the boot stuff wasn't backported idk
I was busy studying for exams while the usb stuff was going on
so missed all the commits
heh -- ok
well, just go ahead and try it, if you want to try the 9.x pre-pre-alpha builds, that are 101% up to date, you can grab them from aws s3:
https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/
Excellent!!!
Do you know when 9.x is "likely to be released"?
It is a few days or a few months-ish?
months-ish more like
I have only been here since 7.0 so I have only witnessed the 8.x development cycle
9.0 will be a little bit messier, and we are right at the start
Ok, good to know
so, yeaaaa
hah... ok, cool
Holy smokes the github diff between 8.2.5 and the main branch is massive
Ya, it's like using debian vs arch in terms of updates.
I track main for that reason. (I use arch too btw)
Adafruit CircuitPython 8.2.4 on 2023-08-22; S2Mini with ESP32S2-S2FN4R2
(also on an S3Mini with 8.2.4, too)
import board
import pulseio
from time import sleep
pulse_in = pulseio.PulseIn(board.IO9, maxlen=120, idle_state=True)
pulse_in.pause()
pulse_in.clear()
pulse_in.resume(1000)
sleep(0.25)
pulse_in.pause()
while pulse_in:
print(pulse_in.popleft())
pulse_in.deinit()
Running the abov...
There's not a helper for unsigned int types that I could find. I'd added one in an earlier commit as mp_obj_get_uint, but that involves a change to py which is undesirable. So, I've moved its code inside memorymap_addressrange_make_new. If you've got second thoughts about this approach, it's no trouble to move it back out to py/obj.c.
It turns out that the "start must be an int" message can be done away with entirely by attempting object conversion to an int by means of `mp_unary_o...
https://blog.adafruit.com/2023/09/07/circuitpython-8-2-5-released/
Updated TLS certificates; RGBMatrix tuning; new boards
Tested and confirmed fixed with 8.2.5 released today on the following boards
Thank you @dhalbert, issue closed.
I made a new clone of circuitpython, and I'm trying to run fetch-all-submodules, and both in main and in 8.2.x it errors with missing commits in a number of submodules. What am I doing wrong?
@dhalbert @PaintYourDragon
With adafruit-circuitpython-grandcentral_m4_express-en_GB-8.2.5.uf2 there is somewhat an image now, however still an issue. The adafruit-circuitpython-grandcentral_m4_express-en_GB-8.2.2.uf2 is still the working release.
https://github.com/adafruit/circuitpython/assets/22541984/7c8b24eb-db47-421a-b248-2efa69533ba0
Honestly no idea. I last fetched main 2 days ago just fine. I only fetch esp and rp2 modules though.
May I suggest remove-all-submodules?
Then start over.
I could have just been gith being weird
I've hit this problem a few times over the last couple of days too. It seems to be related to when I resynch the branches in my fork on github and receive a bogus "0 commits" message on the first synch attempt. Once that happens, the next clone to my local machine suffers the missing commits in submodules, but is OK on a subsequent attempt. Weird.
did that several times already, and tried with differtent branches
Just cloned and setup successfully on main. My exact steps were:
Rebasng on latest main seems to fix the uart problem.
btw, do you know how to type a non-breaking return into discord?
shift+enter
thanks
very much!
By the way, that board comes with a b2b connector with some extra pins on it, do we want to include that in pins.c, or do we want a separate board definition for xiao esp32-s3 sense?
The pins are described in https://files.seeedstudio.com/wiki/SeeedStudio-XIAO-ESP32S3/res/XIAO_ESP32S3_Sense_Pinout.xlsx
@tyeth Could you open a new issue about the bundle loading? Also try it on regular CPython, and try just one cert and more than one.
I has assumed a separate board def for the Sense version.
I was thinking that the separate board definition would need a separate pid, which might be a problem, but it looks like it's a problem anyways...
I think the new boards are missing from this. I don't see arduino_nano_esp32s3, but it is found in #1247.
Hmm, I redid this by hand specifically to include them.
8.2.4 + 9.0.0-dirty from end of august (before final certs submodule change as part of resolving #8299 )
import ssl
context = ssl.create_default_context()
data = MY_CA_DATA # some pem string or bytes from a file of single cert or bundle (was testing bundle)
context.load_verify_locations(data)
Reports extra arguments given: 1
No response
Supplying the ar...
It is currently required to be a keyword. But that is not true in CPython. Easy to fix.
https://github.com/adafruit/circuitpython/blob/0928a95bb203a4b879fc4b48fc2946a34a2a0458/shared-bindings/ssl/SSLContext.c#L103
All
import ssl
context = ssl.create_default_context()
data = MY_CA_DATA # some pem string or bytes from a file of single cert or bundle (was testing bundle)
context.load_verify_locations(data)
If a path is passed, via ca_path named argument, or a certificate (or bundle of certificates) is passed in PEM format using the named argument cadata/ca_data then it should be accepted, and the bundle should be us...
I can replicate on test hardware here: Matrix Portal M4. Don’t even need to run code…issue is visible in the REPL display.
This is a photo of 8.2.5 but it’s basically the same as what’s seen w/8.2.2:
Meanwhile, an Arduino example w/current Protomatter lib (1.6.1), rock steady:
) at some point. i think it was like ~73 on first pass, and then 512 after that. chuck_size is 512.
@crimson ferry re the seeed esp32s3 board definition for Circuit Python, Matthew from Seeed is the person in charge of that wiki program I mentioned in the thread on their discord to potentially reach out re: as a contact for the vid and pid you need there. He is very responsive via email and includes his email in his github portfolio. He may be a good person to reach out to for the remaining board aspects.
I was hesitant to say more on their discord, as silly as it sounds, as I had seen an earlier ask they had from that program to implement CircuitPython for this board and it was marked as done / someone did it in a generic way vs the board definition and I didn't want to call out the deficiency in a public way shaming the dev (weird anxiety thing of mine) https://github.com/Seeed-Studio/wiki-documents/issues/327 given their callout specifically to support this board on this platform I think he'd be happy to have you reach out to discuss it further though to get the last bits in place.
so does it only crash if it's writing to an SD card of any kind, or also crash if writing to a CIRCUITPY file or even sys.stdout?
Do all boards which have a drive strength option specify it in mA? What should drive_strengths be for boards which don't have the option? And where should it go (like I was saying, DigitalInOut seems a little odd).
only test with one sd card. same one that worked fine with 6.3.0 CP. did not test writing to CIRCUITPY, but poster did.
Do all boards which have a drive strength option specify it in mA?
I think in some way they do, though it's tricky, since the total current that's sinkable could be less than the sum of the pins due to power bus issues.
What should
drive_strengthsbe for boards which don't have the option?
It would be a 1-tuple that is the rating for the pin.
It would be great to try to get a simpler example, but people write to SD cards all the time, so I'm wondering what the issue is. You could instrument a sequence of writes and data lengths that causes the problem and then try to reproduce that in a simpler example.
disable_concurrent_write_protection sounds dangerous. was that being used? if you pull the power during a file write yes it will absolutely corrupt files on the sdcard. it should not corrupt circuit python.
i haven't been able to recreate with simple example yet. it's something about that context. it also crashes writing some static bytes, i.e. replace file.write(i) with file.write(bytes([23]*512))
And where should it go (like I was saying,
DigitalInOutseems a little odd).
Drive strength, pull settings, etc. are not just GPIO, but right now a Pin is just an immutable identifying object. @tannewt had an idea of refactoring this somehow so that a, sya, Pad object would carry the current settings. But that is a big change to the current API.
part of the problem might be related to running 8.2.4? try with 8.2.5?
there aren't any changes from 8.2.4 to 8.2.5 that should affect SD writing
since it's an online script if it failed halfway and didn't complete the chunks, it might be possible to corrupt an unfinished file?
does it reset with an open file?
seems as if it's pulling from an api url though APIURL = "https://openaccess-api.clevelandart.org/api/artworks?cc0=1&has_image=1&indent=2&limit=1&skip="
with 8.2.4 the adafruitio part of the script would likely work but the clevelandart.org url might decide not to.
I just got the ftp STOR command working (put)..
But writing is so slow!
---> STOR IMG_2023-03-29-14-56-39-732.jpg
150 Opening data connection for IMG_2023-03-29-14-56-39-732.jpg
226 Transfer complete
1067934 bytes sent in 60 seconds (17.4 kbytes/s)
ftp>
---> QUIT
That is on a dio flash board, and I cached the writes.
I made 2 bytearrays, one for rx and one for storing chunks of the file as to not write too often.
I think I will remove all the caching code, since the gain is pretty minimal from gathering many writes.
But I at least got to learn memoryview
Suppose you disable the actual network fetch and just write fixed data?
do that in portal_base/network.py?
or something like that
i'm trying to reduce the amount of code that leads up to that... Since you said a simpler example is not failing.
is the network code somehow interfering with the SD writes (which use SPI)
looking...can comment the fetch...but then it needs something to iter on in the write loop....
not sure. don't think so? at this point it's done the fetch, and now it's just writing to sd.
so you tried extracting the SD mounting, and the write loop, and it didn't fail?
yah. a very simple sd card write example. that mounts, opens file, loops and writes bytes.
worked
are the chunks determined by the fetch? Is the data coming back in chunks from the website, or is it all concatenated?
if the latter, you could replace the request.get() with a string assignment
lots of layers. and a mix of frozen modules, etc.
i'm overriding the frozen portalbase for testing
by placing lib in root folder
(wasn't frozen in 6.3.0)
is it using sdcardio or adafruit_sdcard?
sdcardio
could try substituting adafruit_sdcard and see if it's the same. Are you using one of the 512MB cards or some random 2GB,etc. card?
using 16G card formatted FAT32
CP 6.3.0 had no issues writing to this SD card
could even remove and view BMP on PC
is it writing to the display? Could disable the display
maybe some interaction between SD card SPI and display SPI
just comment out anything that is writing to the display?
not simple, since that's happening in side pyportal/portalbase libs
how about no background image, don't add "circle" to splash; comment out the circle update code
response = pyportal.fetch(APIURL + str(itemid)) replace that with something static that's not a fetch
there was an issue in 7.1 with display shapes on the pyportal, think it turned out to have something to do with pinalarm. https://github.com/adafruit/circuitpython/issues/5705 old issue but somehow might be related if pinalarm has been revamped since then?
not sure what you mean by static
response = "some long bytestring the same length as what was sent"
simulate the fetch
replicate what the response should be so you can feed it data locally
could just be [1] * reponse_length, kind of like what you did before
that'll just not call the offending code?
not call pyportal.fetch(). I want to see if the network fetch is causing a problem.
And if it still fails, that helps reduce the example.
and also take away messing with the display (the cicle thing). But try one thing at a time.
just divide and conquer
been doing that since yesterday 🙂
i think i'm just going to label that guide as works with 6.3.0 only
fer sure for now!
there's tons of intermingled automagic happening in the pyportal/portalbase libs. it's a convoluted divide/conquer
can open an issue with a summary of all this, just point to the forum thread, say the code in use, and the versions that work/don't work. It would be a circuitpython issue, should raise an error there
what error does it actually raise?
it doesn't sound like a hard crash
oserror 5?
sure include that
here's an example response url as far as i can tell https://openaccess-cdn.clevelandart.org/1962.154/1962.154_web.jpg
it parses the json for the path https://openaccess-api.clevelandart.org/api/artworks?cc0=1&has_image=1&indent=2&limit=1&skip=69
Minor updatelet: looks like Arduino and CircuitPython are both compiling with -Os, but with Arduino using GCC 9.2.1 and CircuitPython using 10.2.1…so there might be differences in the generated code.
As a quick last-ditch thing, I’ve declared certain vars as volatile in the innermost loop. This should prevent the optimizer from removing those lines. Confirmed on scope that Arduino timing is unchanged. As an alternative, in CircuitPython, exposing the duty cycle setter (_PM_setDuty()) mig...
Works with 6.3.0.
Tested the following versions and they show the issue:
* 7.3.3
* 8.2.4
* 8.2.5
Example banner from 8.2.5:
Adafruit CircuitPython 8.2.5 on 2023-09-07; Adafruit PyPortal with samd51j20
### Code/REPL
```python
Code is from Learn guide here:
https://learn.adafruit.com/cleveland-museum-of-art-pyportal-frame/code
There is other output, including URLs that include API keys, so not adding that here. ...
seems like it's first checking the width of the image so it doesn't grab one that's 5101 px wide for example
i don't have a pyportal. this one seems right up my alley though. :/
foamyguy would be a good one for this
@tidal kiln ok, thanks for the issue!
It's ok to have them in board but we need to decide if they should work with native classes like digitalio. On the Pico W, the LED is off micro so we probably do want digitalio to work so blink examples "just work".
@tulip sleet thanks for taking a look and suggestions!
The FTP server is almost done. Should I open an issue for us to discuss if and how it's getting in the core?
We could very well decide to just freeze it due to how big it turned out. But that would mean no ftp-web-workflow.
Why not just have it as a library people can install?
That's a valid option alright. I was just asking, cause it would be interesting if we could get it to be a web-workflow alternative mode.
for web workflow, I think it would be easier and much smaller to expand the current implementation with a few commands to make it webdav compatible
I mean, is there a reason other than lack of time that this hasn't been done?
My vote is yes, given Yukon also has two LEDs off micro (and two buttons).
(modern UI FTP clients generally support webdav too)
(I mean webdav is poor man's ftp)
and specifically my lack of time 😅
@slender iron @onyx hinge just fyi - cool photo of someone using the swirly grid
https://forums.adafruit.com/viewtopic.php?t=204291
neat to see it in the wild 🙂
Well I guess, it sounds pretty counterproductive, shoving 20k of code into core if webdav is a few command implementations away..
the brass standoffs worry me a little
I can take a look at webdav after this.
And perhaps fix the remote shell which never worked and made me implement telnet
Jokes aside, soon enough I will have almost all the common coreutils and programs a old linux distro would have running in circuitpython..
Here’s a CircuitPython build (thanks @dhalbert!) with the 'volatile' change — and the timing is looking correct now both on matrix and on scope. Let me know if this clears things up. If so, it’ll go in the next release, alongside other fixes.
firmware.uf2.zip
Do you have the FTP client side built yet, with the direction boards are going to support local displays and keyboard input I'd actually be more interested in reaching out from the microcontroller for files rather than the other way around
If I get the server side going, it should be fairly easy to do the client too.
It's just that even having read RFC959 (twice), I still haven't understood all the commands.
The client is basically the same code in reverse.
Since the data sockets and stuff also need to made, all the same code would be there.
The messages would just be different
tbh, I made the ftp server just to be able to have "usb" on non-native usb boards.
I love my M5Stack timer camera.
But developing code without native usb is such a pain.
with filezilla I can just have a local copy and sync
Bruh.. bytes(memoryview(self._rx_buf)[:size]).decode(_enc).split(" ")[0].replace("\r\n", "").lower()
anyone disagree with setting the default RTD version to 8.2.x for now?
Tysm! it's so fast now!
FYI if that does become necessary, a named argument in the constructor is sufficient; does not require willy-nilly set/get. _PM_setDuty() accepts an integer from 0 to _PM_maxDuty (check is probably unnecessary, the C setter clips values).
Do all boards which have a drive strength option specify it in mA?
No, not necessarily. Some parts give you the option of "normal" and "strong" or similar language. As @HelenFoster pointed out, drive strength is not a limit on the amount of current the pin will drive. From my research, I've determined that it is the current limit at which VOH is guaranteed to be met. My experiment on the RP2040 that I detailed above shows that for at least that part the drive strengths are very conservat...
I asked for VID/PID on their support forums
The Seeed GitHub wiki was the other place suggested, if this doesn't pan out.
@PaintYourDragon when I tried to install the firmware, the circuitpython board is borked.
(hope you don't mind, I syntax-highlighted the example code)
OOF, quite right. I apologize, had my wires (figuratively) crossed.
Writing the Grand Central CircuitPython 8.2.2 or 8.2.5 firmware should revive it, it’ll just still have the wonky matrix timing until we have an updated version for that board.
(hope you don't mind, I syntax-highlighted the example code)
I'm truly outraged! Mainly that I didn't do it 😭
Sounds like a good idea!
I use latest version (8.2)
# microcontroller - sender
import sys
import time
from ulab import numpy as np
import board
import busio
uart = busio.UART(board.GP4, board.GP5, baudrate=2000, timeout=0)
def sending(data):
uart.reset_input_buffer()
time.sleep(0.001)
uart.write(data)
time.sleep(0.001)
return print(data)
k = 1
while k < 50:
data = np.zeros((3, 3), dtype=np.ui...
@phantomsixthplayer
Here is a similar build with the fix for Grand Central M4:
gc4-rgbmatrix-fix.uf2.zip
Thanks @dhalbert and @PaintYourDragon please see the video for the results.
https://github.com/adafruit/circuitpython/assets/22541984/ffc484ce-1712-4e45-8c07-64e28fb9ab01
@phantomsixthplayer Well, that is weird. Are you able to easily try various versions of the Protomatter Arduino library? There are examples: https://github.com/adafruit/Adafruit_Protomatter/tree/master/examples. Try 1.6.0, 1.5.10, 1.5.9.
At this point I think it’s gonna require exposing the duty cycle setting. 8.2.2 and this test version have an identical clock period, only the duty is different (~50% in new code, ~75% in 8.2.2). Newer matrices really prefer the 50% duty.
The baud rate is very low and is also non-standard. Did you try, say 1200, and 9600?
If you set the timeout to 0, then .readinto() will only read as many characters as are available. It will not wait for the whole array to fill. It returns how many bytes it actually read. Add print statemtns to see what .in_waiting and .writeinto() return.
Are the two boards connected to have a common ground?
@dhalbert @PaintYourDragon tested arduino simple.ino, seems to work properly.
#if defined(ADAFRUIT_GRAND_CENTRAL_M4)
uint8_t rgbPins[] = {8, 9, 10, 11, 12, 13};
uint8_t addrPins[] = {4, 6, 3, 5};
uint8_t clockPin = 1;
uint8_t latchPin = 2;
uint8_t oePin = 0;

I receive messages in the correct order and without distortion:
array([[1, 0, 0],
[0, 0, 0],
[0, 0, 0]], dtype=uint8)
array([[2, 0, 0],
[0, 0, 0],
[0, 0, 0]], dtype=uint8)
Glad you got it working!
I am not associated with M5Stack.
AtomS3U is very similar to already supported board AtomS3 Lite, so large portion of this PR is taken from https://github.com/adafruit/circuitpython/commit/89bd5fae616ec6d403d820bb470a5375789ccf5d
Datasheet https://docs.m5stack.com/en/core/AtomS3U
USB IDs taken from https://github.com/espressif/usb-pids/blob/60f612f5e2e177104382a009e7b787fc463c18d1/allocated-pids.txt#L399
I used AtomS3 Lite bootloader (as LED and button pins match and controller is t...
Scope trace, special CircuitPython build:
Same, Arduino lib 1.6.2:
The timing is identical, down to the clock cycle, even the every-8th-bit delay. I cannot explain why this would work with the Arduino library and not with CircuitPython _built against the same code and g...
Does CircuitPython do anything with the pin drive strength? Arduino on SAMD always sets PORT_PINCFG_DRVSTR (stronger drive strength) on all GPIO. If this is not the default behavior of CircuitPython, perhaps it could be added to the _PM_pinOutput macro so it’s applied to all Protomatter pins.
Drive strength theory might also explain why either works on Matrix Portal; that board has level-shifted outputs.
If the Grand Central circuit lacks level shifting…drive strength might work just well enough to get it working in this situation, but we really really highly extremely discourage controlling these matrices from 3.3V logic.
Does CircuitPython do anything with the pin drive strength? Arduino on SAMD always sets PORT_PINCFG_DRVSTR (stronger drive strength) on all GPIO. If this is not the default behavior of CircuitPython, perhaps it could be added to the _PM_pinOutput macro so it’s applied to all Protomatter pins.
CircuitPython does not do anything with the pins except pass them on to _PM_init(). It does use high drive strength for DigitalInOut, but not for RGBMatrix.
MicroPython's machine.Pin object is more like a Pad, though it has some other things that are closer to the hardware than we might want to expose.
I want to emphasize that this would be a really big potentially incompatible change. It should still be really easy to use pins, and some backward compatibility would be needed. Also any complication of how pins/pads are treated would still need to fit in the smallest ports like SAMD21. This is not something to do lightly just to handle a sm...
I would suggest we open a new issue for broader considerations. The current issue is really about nRF drive strength.
OK @phantomsixthplayer, here’s a quick-n-dirty thing to try. Add this before declaring the matrix:
for pin in [ board.D8, board.D9, board.D10, board.D11, board.D12, board.D13, board.D4, board.D6, board.D3, board.D5, board.D1, board.D2, board.D0 ]:
foo = digitalio.DigitalInOut(pin)
foo.direction = digitalio.Direction.OUTPUT
foo.deinit()
From what I can tell, looks like deinit() doesn’t reset a pin’s drive strength. So in theory this will set each pin to high streng...
@PaintYourDragon
adafruit-circuitpython-grandcentral_m4_express-en_GB-8.2.5.uf2
displayio.release_displays()
for pin in [ board.D8, board.D9, board.D10, board.D11, board.D12, board.D13, board.D4, board.D6, board.D3, board.D5, board.D1, board.D2, board.D0 ]:
foo = digitalio.DigitalInOut(pin)
foo.direction = digitalio.Direction.OUTPUT
foo.deinit()
matrix = rgbmatrix.RGBMatrix(
width=64,
height=32,
bit_depth=4,
rgb_pins=[board.D8, board.D9...
This is the order I uploaded the firmware:
adafruit-circuitpython-grandcentral_m4_express-en_GB-8.2.2.uf2
adafruit-circuitpython-grandcentral_m4_express-en_GB-8.2.3.uf2
adafruit-circuitpython-grandcentral_m4_express-en_GB-8.2.4.uf2
adafruit-circuitpython-grandcentral_m4_express-en_GB-8.2.5.uf2
gc4-rgbmatrix-fix.uf2
import displayio
import rgbmatrix
import board
import framebufferio
from adafruit_bitmap_font import bitmap_font
from adafruit_display_text.label import Label
im...
OK. I can’t be certain whether CircuitPython is fully resetting the pin on deinit(), it was just a quick hack to try in that it might have left high-drive enabled. CircuitPython is big and I’m not deeply involved in it.
Regardless…without level shifting in the circuit, this is a design problem, not a software bug. That it showed some success in a prior release is “stars aligning” and not an engineered solution. I’ll spend a little more time and see if I can work drive strength into the l...
@blissful dragon what board?
Pico W?
what's the content of the boot_out.txt file on CIRCUITPY?
you need the Pico W UF2, that's the regular Pico... no wifi
If I was to buy another matrix from digikey how can I be sure I won't get the 'old' revision matrix that doesn't support the ~50% in duty cycle update. I got unlucky and got three of them lol. I guess another solution is to rewrite the entire CirciutPython application in Arduino which would solve it as well.
I think the new/old matrix thing is a red herring. We can try to make the duty cycle configurable. We can try to boost the drive strength. But without level shifting, all that might seem like it’s fixed, but the temperature swings 20 degrees and things inexplicably go haywire because it was all a lucky edge case.
I don't know that stuff very well... but it works on the regular Pico UF2? that would be strange
the only differences are the wifi module, and a couple of subtle pin differences
2.1.0?
not too many people around right now, I'd suggest post the question in #help-with-circuitpython now or in the (U.S.) morning, and see if someone can help
it is, timing varies depending on the change and how extensive, who has expertise to review etc
yes, definitely odd... it's never a guarantee that a close firmware will work on a board with more features, but usually it's OK (some things might not be accessible or have the right names)
CP is in an awkward interval right now... working on 9.0.x (main), and having to backport critical changes to 8.2.x
you can always grab latest from the downloads page
Right, maybe this is too big and too deep for a proper fix. For ports with memorymap support, it's possible to manipulate pad settings without the need for any additional changes. In the documentation embedded in the RP2 memorymap support, there is example Python code for reading and setting pad drive strength that can be easily adapted for nRF. Ditto for other pad attributes. Maybe just call that the answer and close this issue?
Anecdata, it's 2am so not tagging. How did you get the markdown to do a collapsible arrow? That's a really nice feature I think should be added to the default issue report template. That helps make an issue report filled with code examples much easier to digest. https://github.com/adafruit/circuitpython/issues/8381
I will be doing this from now on. Would like to see it added to the base issue reporting template.
The same behavior for ESP32-S3 controllers, for example, M5 AtomS 3 Lite.
Here is a simplified version of the Cleveland Museum code that can be used to demonstrate the issue:
import board
from adafruit_pyportal import PyPortal
WIDTH = board.DISPLAY.width
HEIGHT = board.DISPLAY.height
APIURL = "https://openaccess-api.clevelandart.org/api/artworks?cc0=1&has_image=1&indent=2&limit=1&skip=1234"
pyportal = PyPortal(
image_json_path=["data", 0, "images", "web", "url"],
image_dim_json_path=(["data", 0, "imag...
SD CARD INFO - forgot to mention that a 16GB SD Card formatted FAT32 was placed in the PyPortal for all of the above testing.
Note that this same SD card worked fine when reverting to 6.3.0 for testing. So it does not appear to be an SD card size/speed/format issue. Unless older CP firmware was somehow more forgiving in this regard.
You are aware of the flash access time limits? You are aware of the RAM arbitration limits?
There is no real way to count cycles in cooperative 32-bit processor beyond 25-50MHz in most that I have seen. Closest you can do is with RAM function using bus arbitration promoting CPU. (Variable CPI, like Von Neumann and like Harvard.)
Protomatter belongs on dedicated processor. I would presume CircuitPython will ditch Protomatter eventually or recommend against it. This would allow better ce...
You are aware of the flash access time limits? You are aware of the RAM arbitration limits?
There is no real way to count cycles in cooperative 32-bit processor beyond 25-50MHz in most that I have seen. Closest you can do is with RAM function using bus arbitration promoting CPU. (Variable CPI, like Von Neumann and like Harvard.)
Protomatter belongs on dedicated processor. I would presume CircuitPython will ditch Protomatter eventually or recommend against it. This would allow better cen...
How stable is the power rail? How stable is the cable signals? (Ringing, load capacitance, etc.) Temperature and power can mess with it. (Look at the end of the chain to see the truth. This is what the drivers saw.)
i think that commit is about bcm2711 pulls, which differ
but the zero-w, is using the vc4 pull style, which is write-only
I went and put micropython 1.20 on one of my s2 boards, and this is not reproducible.
I opened 4 sockets and connected to them successfully.
@dhalbert I’ve added some code in arch/samd51.h that in theory enables high drive mode on all Protomatter pins (static function _hi_drive()).
HOWEVER…it makes an assumption about pin numbers that might not be correct. I’ve dug a few layers down into CircuitPython source but you could probably answer this in like 12 seconds…
I don’t know how pin indices (as stored in the core structure) map to hardware in CircuitPython…whether it’s fairly direct or if these go through a table (as in Ar...
@PaintYourDragon The pin numbers are the actual numbers. The remapping is at the pin name level. So this should work. I will try to do some testing.
IEEE Spectrum ranks Python the number 1 programming language for 2023. A quote from the article for the hard working CircuitPython develpers to savor, "And although Moore’s Law is winding down for high-end computing, low-end microcontrollers are still benefiting from performance gains, which means there’s now enough computing power available on a US $0.70 CPU to make Python a contender in embedded development, despite the overhead of an interpreter. Python also looks to be solidifying its position for the long term: Many children and teens now program their first game or blink their first LED using Python. They can then move seamlessly into more advanced domains, and even get a job, with the same language."
can someone double check me? This is not correct usage, right? you might write Union[A, B] or A | B but writing Union[A | B] is .. redundant?
in this docstring in the core: //| hostname: Union[str | ReadableBuffer]
Union[A, B] is the syntax I am most familiar with. I do believe comma's inside the sqaure brackets is correct, not pipes for seperation.
I think both are correct, just mean different things
technically correct, anyways
Union[A | B] would be equivalent to Union[Union[A, B]] which basically means the same thing as A | B
Yes, that is my understanding as well, and much better put/explained
Add an (expired) root cert, DST Root CA X3, to the roots cert list to handle the special way Let's Encrypt does its root cert. See details here: https://github.com/adafruit/certificates/pull/1.
This cert was present in the older NINA-FW list. It was removed when the roots cert bundle was completely reworked in #8374. But mbedTLS does not seem to work properly with the Let's Encrypt scheme without this cert.
Discovered by @BlitzCityDIY while using site.api.espn.com.
Done!
Initially posted on the live channel by mistake:
Sorry, skipping the meeting without notes... my poor non CP excuses:
Wondering if there are any outstanding CP issues that I could lend a hand with? I'm well tooled up for RP2040 and enjoy low-level detail oriented issues. Would really love to help.
https://github.com/adafruit/circuitpython/issues/7990 is 8.2.x and rp2 but not super clear what the issue is
thanks @dhalbert ! tested the generated UF2 from here on the matrixportal s3 and it is working with the API
this should be easy https://github.com/adafruit/circuitpython/issues/7608
multicore, run C blob on second core could be interesting
bigger and less clear
Thanks! I'll take a closer look at 4106 and 7990. 4106 looks especially interesting.
<@&356864093652516868> We have around 15 minutes until the community meeting in https://discord.com/channels/327254708534116352/359422932545568799
@slender iron Turns out the issue started on GitHub, and they suggested contacting them through their support page (https://readthedocs.org/support/). I ended up talking to Eric, and then another person took care of the needed changes. I would suggest using the support page as it definitely got me to the right folks.
👍🏻
Link to meeting notes, please?
If you have news, projects, updates, & more - please send them to cpnews@adafruit.com for the next newsletter
Congratulations Kattni! We will miss you but it's exciting to see your next steps!
🎉 Congrats, and the absolute best of luck in everything that comes next!
Congratulations Kattni!! Best wishes! Thank you!
Congratulations @idle owl
Thank you so much, everyone! 😊
Congratulations, and thank you for having been such a pillar in this community! A lot of how welcoming this community is is thanks to the effort you've put into it!
Your guides have been an amazing welcome to so many newcomers to CircuitPython.
And helping run the newsletter, and the meetings, and all the other product guides, and building this Discord, and bringing in so many absolutely wonderful people to this community....you're an awesome community architect 💜
Whoa, that is breaking news...
I have so much to say.
I guess most of us have seen you create and improve this community... but we have also seen you make your first board, your first contribution to the core and so many other steps where you improved the range of your skills.
This place would not be what it is now without everything you did.
Good continuation @idle owl
@thorny jay Thank you. I really appreciate your words. ❤️
ooh gamma correction.
About @devout jolt in the weed... Is that for flashing from a computer or flashing from a smaller board like LadyAda testing board? Having a Feather RP2040 USB Host do that job would be great!
computer I assume
Educators may also be interested to setup a classroom "en mass".
also yay it's important we have someone who has run an adabot patch actively involved
thanks for hosting @slender iron
Thanks for another excellent meeting!
Thanks everyone
Thanks for hosting Scott, have a great week everyone.
Thanks all, have a great week!
you all are welcome! thanks for meeting up!
for some reason a very old pi -- is it a pi 1? -- has surfaced on my desk. (c) 2011.12
It belongs in a museum.
I think it might be my computers in this space. Not super sunny but still went from 78 to 82 during the meeting.
@slender iron do I repeat the "Adafruit" name in both the USB manufacturer & product? ```USB_PRODUCT = "Adafruit-Qualia-S3-RGB666"
USB_MANUFACTURER = "Adafruit"
A Pi 1 is running my heating system automation... talking EnOcean to give the target temperature value to the valve that lets the hot water flow in the radiator.
Still working fine, obviously not developed by me. 😉
I don't usually
@slender iron is there any big problem changing the USB_PRODUCT string after the fact? There are apparently a handful of Adafruit boards that do this.
espressif/boards/adafruit_feather_esp32s3_4mbflash_2mbpsram/mpconfigboard.mk
espressif/boards/adafruit_feather_esp32s3_nopsram/mpconfigboard.mk
espressif/boards/adafruit_qtpy_esp32s2/mpconfigboard.mk
```plus the one I'm alreayd renaming
I wonder if the first 3 were specifically due to there also being the Unknown Maker Feather S2/S3
yep, full CircuitPython app restore via computer, preferably via UF2 (thanks @slender iron for clarifying for me, sorry I couldn't make the meeting)
I don't think I'll change the others right now
This board got a KICKIN marketing name!
I'm seeing something weird when cloning the CP repo. Lots of "multiple configuration" messages like this:
warning: 01cabb0324186808c14ec1b02fb8a3be28837160:.gitmodules, multiple configurations found for 'submodule.lib/axtls.path'. Skipping second one!
warning: 01cabb0324186808c14ec1b02fb8a3be28837160:.gitmodules, multiple configurations found for 'submodule.lib/axtls.url'. Skipping second one!
gh repo clone eightycc/circuitpython circuitpython-82x
I haven't seen that before
It's just happening when I clone my fork. Think I'll try to delete it and fork again.
I usually use raw git
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/1J0mv2qVnfBwjg4DZj47JYn-WPQI68thUqp8ZYfr14fs/edit?usp=sharing
Deleting my fork and re-forking fixed the problem.
What the title says.
Without this, if you deinit your camera object, you have to reload to be able to use the pins.
Thank you @wtuemura @bergdahl @andibing and @gfghjjk
@phantomsixthplayer I duplicated your setup, more or less:
@dhalbert thanks for testing. I still get an issue. I'll stay on adafruit-circuitpython-grandcentral_m4_express-en_GB-8.2.2.uf2 until I learn arduino and port it over
I've set up a small test jig that can reproduce the problem. I borrowed a simple keyboard HID emulator from here https://learn.adafruit.com/circuitpython-essentials/circuitpython-hid-keyboard-and-mouse and modified it slightly to work with a Pico W. I put these lines from @dhalbert into boot.py:
import usb_cdc
import storage
storage.disable_usb_drive()
usb_cdc.enable(console=False)
Plugging this into a cold RP 4 fails, but plugging it in when the RP 4 is booted works. I...
Plugging this into a cold RP 4 fails, but plugging it in when the RP 4 is booted works
This is exactly the behaviour I experienced when starting this issue. Lets see where your testing goes
You all confirmed what we also have.
If it is already connected at boot time it works as expected.
But looks like only in boot mode.
Is there a way to detect hid mode at runtime?
Also used now tonny editor instead of bloated Mu-editor. Give it a try.
I'm using the latest version 8.2.4 on both Pi Pico
# same code into both microcontrollers
import busio
import board
from adafruit_bus_device.i2c_device import I2CDevice
i2c = busio.I2C(board.GP3, board.GP2)
while not i2c.try_lock():
pass
ad = i2c.scan()
print(ad)
Hello. I'm trying to connect two Raspberry Pi Pico microcontrollers using i2c.
I'm scanning the i2c bus using scan(). I loaded t...
one device needs to act as an i2c controller, the other needs to act as an i2c device
having 2 controllers wont work
Thank you
Please tell me - how to make one of the controllers a slave?
One board needs to run a board that uses the "i2ctarget" module. there is a simple example shown in the documentation. https://docs.circuitpython.org/en/8.2.x/shared-bindings/i2ctarget/index.html
import board
from i2ctarget import I2CTarget
regs = [0] * 16
index = 0
with I2CTarget(board.SCL, board.SDA, (0x40, 0x41)) as device:
while True:
r = device.request()
if not r:
# Maybe do some housekeeping
continue
with r:...
I didn't see an I2CTarget guide on Learn...
Adafruit CircuitPython 8.2.4 on 2023-08-22; TinyS3 with ESP32S3
import time
import board
from adafruit_bus_device.i2c_device import I2CDevice
def read_i2c(send="123"):
ret = "nothing"
try:
with board.I2C() as i2c:
device = I2CDevice(i2c, 0x08)
br = bytearray('yyyyyy', 'ascii')
with device:
print(f"sending {send}")
device.write_t...
This started being an issue between 8.2.0-beta.1 and 8.2.0-rc.0. Investigating futher.
@tulip sleet I notice this in the git history: ec1e7a03b38c625664a4615e60d26956205d7a67 Reset UART on deinit, reduces power consumption
ok, you saved me doing a bisect 🙂
seems a likely candidate to introduce a subtle problem
@furbrain Sorry to report that this issue is being caused by #8089, your UART power-saving PR. If I revert that the problem goes away. It appears that power-cycling the UART peripheral leaves something in a bad state.
For the next 8.2.x release, I am going to just revert #8089 for now, even though that will cause increased sleep current. It would be great to figure out the best way to do this.
Thanks for the report.
I looked over your example programs for any problems and I did notice some things that are strange but I don't think they are probably the cause of the behavior you're seeing.
The first thing I noticed is apparent incorrect buffer use in your attiny firmware:
char buf[6] = "xxxxxx";
sprintf(buf, "%c ", rcvd);
Handling strings & buffers in C is .. hard. I think code is incorrect, because C strings always include a trailing "NUL" byte. This me...
I saw the note about this work in the circuitpython newsletter. Just wanted to offer any help on performance of this, we've spent a LOT of time / code getting the same thing going in Micropython for TulipCC.
We're using ESP5.1-rc2 and running the SPIRAM at 120MHz. We're getting pretty stable 30FPS on full screen refreshes on a 1024x600 RGB dot clock display. We use the bounce buffers reading from a SPIRAM framebuffer that's bigger than the screen siz...
It's quite some years since I really coded in C, so yes I've been lazy.
The first buffer size mismatch is a fair cop - 7 bytes (rcvd, 5 * space, null terminator). But that said, it's sending 6 bytes over the wire, so whether there's a seventh \0 byte or not isn't the issue.
The second double assignment of the send buffer was down to me simplifying things to try and narrow the problem down and not bothering to remove the previous line.
'yyyyyy' in the buffer was putting somethi...
I need REPL redirect to a UART. I've found mention of DEBUG_UART in 4761, but other than a mention in ports/stm/supervisor/serial.c there's nothing else in CP. Before I hack up my own, wondering if anyone has redirect code gathering dust somewhere?
It would be nice to rework #8089 in the long run, since it does address a sleep power problem.
I had to manually revert the commits to do this on the 8.2.x branch. Pressing the "revert" button and changing the base did not work out.
Tagging @furbrain for interest.
There is CIRCUITPY_CONSOLE_UART; I think that might do what you want. See supervisor/shared/serial.c.
Thanks, looks like exactly what I need.
makes sense. thanks. I don't know why I didn't also encounter this.
Is this worth rebasing to be on 8.2.x before you merge?
@bwhitman hihi thanks - we've got the proof-of-concept going, and will probably focus more on automation over the next bit. the text/sprites stuff is already managed by 'displayio' and the REPL-on-display is built in as well as the mass storage filesystem. it may be a fairly easy 'port' if you want to try adapting it to circuitpy
@tulip sleet just curious - any idea why the singleton uart worked? (for that nrf issue)
i think it doesn't get deinit-ed on soft-restart
so the new code in the PR never gets run
makes sense. thanks. I don't know why I didn't also encounter this.
I tried rebasing to 8.2.x but I got a zillion commit changes. So it will need manual backporting if it's worth doing that.
@dearmash is this stalled?
Shall I create a minimal "backport" just doing the fix?
@bill88t do you mean this is fixed in main?
@tannewt did you want this fixed in 8.2.x?
I will manually cherrypick it in a new pr in a bit.
Here is a simplified version of the Cleveland Museum code that can be used to demonstrate the issue:
I tried this code on a PyPortal with 8.2.5, and it's working for mepc . SD card is a SanDisk 4GB.
Adafruit CircuitPython 8.2.5 on 2023-09-07; Adafruit PyPortal with samd51j20
>>>
>>> import test
Connecting to AP PBE2
Retrieving data...Reply is OK!
image dim: 969 893
original URL: https://openaccess-cdn.clevelandart.org/1973.160/1973.160_web.jpg
convert URL: https://io.adafru...
Activated UART REPL by adding these lines to ports/raspberrypi/boards/raspberry_pi_pico_w/mpconfigboard.h:
#define CIRCUITPY_CONSOLE_UART_TX (&pin_GPIO0)
#define CIRCUITPY_CONSOLE_UART_RX (&pin_GPIO1)
and then connected the UART through picoprobe. Here's what I get on a cold RP 4:
Serial console setup
Adafruit CircuitPython 8.2.5-1-g707120244c-dirty on 2023-09-12; Raspberry Pi Pico ...
Looks like the PyPortal I was using for testing has 1.6.1:
>>> esp.firmware_version
bytearray(b'1.6.1\x00')
>>>
Let me try upgrading...
@cater the forum post user says they were using 1.7.5 ... hmm. I did circup update all my libraries too
i had old fw. trying update now.
the user said they had 1.7.5 but if they don't really that would cause the issue
we certainly should change the library code to prevent the red herring SD card message, which wasted a lot of time
As it stands, this does technically work.
Things that still need to be done:
led blinked two shorts and a long pause repeatedly.
This is an exception. REPL is usually solid white when entered.
OSError: USB busy
This can be trying to send over USB before it is fully connected.
If I plug the Pico into a simple power adapter, I get the same OSError as for a cold RP 4. That leads me to think that something in the USB stack doesn't like getting invoked by keyboard.py before the host USB is initialized.
@tulip sleet what if you use libs taken from bundle zip? still work?
circup update uses the libs from the latest bundle
so that is what I updated to, without having to do it by hand
right. but wondering if it could be a lib issue. and we aren't sync'd on that? someone following guide would just use bundle zip.
i thought the program bundle downloads the latest libraries
I did not test the Learn example, just your simplified example
I don't really care. I think I put it in 8.2.x because it is a crash. I don't want to fix it myself atm though.
Nina FW updated:
Adafruit CircuitPython 8.2.5 on 2023-09-07; Adafruit PyPortal with samd51j20
>>> import board
>>> from digitalio import DigitalInOut
>>> from adafruit_esp32spi import adafruit_esp32spi
>>> esp32_cs = DigitalInOut(board.ESP_CS)
>>> esp32_ready = DigitalInOut(board.ESP_BUSY)
>>> esp32_reset = DigitalInOut(board.ESP_RESET)
>>> spi = board.SPI()
>>> esp = adafruit_esp32spi.ESP_SPIcontrol(spi, esp32_cs, esp32_ready, esp32_reset)
>>> esp.firmware_version
bytea...
@bwhitman Thanks! Do you have any mapping between espressif modules and flash and ram settings? We haven't optimized it in CP and (I suspect) have a lot to gain from it. We have 131 boards so it's tricky to know the best settings for each.
This is so weird. I will re-update my PyPortal to 1.7.5 again, in case my 1.7.5 is not the same. I think I was testing when NINA-FW was being updated.
Automated website update for release 8.2.6 by Blinka.
You can use supervisor.runtime.usb_connected to detect whether USB enumeration has completed. If you busy-wait on that in the code.py, does it help?
During HID initialization, adafruit_hid/keyboard.py tries to release all keys by means of self.release_all() and then tries once more if after 1 second. So, this clearly isn't going to cut it if there's a long delay between power-on and host enumeration. Thanks @dhalbert I was just going to search for such an animal as supervisor.runtime.usb_connected. Giving it a try now.
The library code like keyboard.py and mouse.py don't wait indefinitely for things to come up. They try once, and then sleep and try once again. That was based on empirical testing a long time years ago on SAMD21 on host computers. If they should busy-wait for longer, that would be a fine improvement to the HID library.
@tulip sleet one thing to keep in mind is that the portalbase lib is frozen in. so it isn't latest. and isn't using what is in /lib.
On the RP 4 the delay is several seconds (seems like at least 10 without measuring it), while your typical desktop PC the BIOS enumerates PDQ after power on to find HID devices.
oooh, hmm, I wonder if I have a non-lib/ version
@tidal kiln well, I only have .mpy libraries, and only in .lib
i just re-updated NINA-FW, and it's still working
testing 8.2.5 with your test program
does it work without an aio key?
i'd think it'd fail trying to access it?
yeah
but on that point - my setup still has secrets.py instead of toml
is there any possibility we are using different AIO servers which are set up differently
I have both secrets.py and settings.toml, updated with a new key. updating settings.toml did not help; I needed secrets.py
io.adafruit.com for me is 52.54.163.195
64.190.63.111 for me
hmm, hmm
could copy the library into the top level of CIRCUITPY and change io.adafruit.com to a numeric IP
i just did ping io.adafruit.com from the command line
it pulls OK just copying URL into browser
do you have a paid IO subscription? I don't
no. just free one.
@tidal kiln so nslookup io.adafruit.com returns 64.190.63.111 for you?
The original delay was done here: https://github.com/adafruit/Adafruit_CircuitPython_HID/pull/15, clearly not enough now sometimes.
@tulip sleet hmmm...not anymore. now i'm getting 52.54.163.195
I have no idea how they manage servers; maybe it is dynamic
I tried using curl and it's working fine with the given URL.
You can get the time from Adafruit IO without any credentials, but it should go through the same TLS stuff: https://io.adafruit.com/api/v2/time/ISO-8601
here is a simple test program for ESP32SPI; could modify it to test the time URL I just gave
tried numeric ip. looks like maybe nina fw doesn't support that? dumps with an esp32 not responding on the fetch.
the numeric IP doesn't match the cert, so it complains (I saw that when I tried the numeric IP in curl). So that won't work 😦
Fetching text from https://io.adafruit.com/api/v2/time/ISO-8601
----------------------------------------
2023-09-12T15:22:51-04:00
----------------------------------------
worked
had to comment out the wifi scan
but otherwise, just change TEXT_URL to the aio time URL
the wifi scan works for me
nothing but hidden here. so got a nonetype on return. and didn't like it.
I erased CIRCUITPY completely, added back your test program, and the needed libraries. Still works.
how fast is your internet? Mine is 300Mb up/down. It's slower through the wifi, but I have good wifi access points
i'm grasping at straws a bit
could you maybe try your phone as a hotspot?
oh...i'm sad slow...like 5mbps down/0.5mbps up. best option i have out here.
I'm doing some empirical testing here to find an appropriate delay, then I'll submit a PR.
I'm doing some empirical testing here to find an appropriate delay, then I'll submit a PR.
Will this be a library PR? We can transfer this issue to the HID library.
@tulip sleet if you're suspecting something network, wouldn't it hit it also replacing the file write with a print?
Yes, please transfer to the HID library and I'll pick it up from there.
I'd think so, but it doesn't hunh? I was wondering if there were long delays on the retrieval
lemme try it again. pretty sure i did that days? ago. whenever i was originally troubleshooting.
only portalbase is frozen in. pyportal is coming from /lib.
we should be using the same libs now
you're using ones from bundle zip?
ohh....sry....that's what i meant by bundle
the bundleflyblob thing
from learn
and i'm not actually sure what i have loaded right now, since have tried many things. i'm going to storage.erase and start over.
try what I am using: your short test program, and circup-installed libs. I'll compare the libs
(i'll need to install circup)
the libraries differ only in adafruit_esp32spi/PWMOut.mpy (!)
ERROR: Failed building wheel for circup
worth chasing this down? or can just use bundle zip?
use Learn bundle and if that fails, try library files from latest library bundle: https://github.com/adafruit/Adafruit_CircuitPython_Bundle/releases/download/20230912/adafruit-circuitpython-bundle-8.x-mpy-20230912.zip https://circuitpython.org/libraries
circup is really a time-saver; worth tracking down the issue at some point
maybe your desktop python is old
it was something about setuptools versions. probably easy fix. but not now.
all of those taken from adafruit-circuitpython-bundle-8.x-mpy-20230912.zip
and then running simple test from GH issue thread
exact same issue
it consistently fails on the second pass through the iterator. note the single . that gets printed on first pass
going to try print instead of file write now
where is the iterator? I will instrument it the same way
are you using your short test program or the original program?
Never mind. I misunderstood. It's:
aving data to /sd/cache.bmp
.............................................................................................................................................................................................................................................................................................Created file of 144138 bytes in 9.0 seconds
using short test program from GH issue
@tulip sleet do you have both secrets.py and settings.toml on the PP?
try removing toml
ok. try running again.
still works
@dhalbert This was a crash I found as I was seperating wifi-autoconnect from web-workflow. In the rush of things, as I was testing edge cases, I assumed it's a side effect of my changes and fixed it. It went in main with that pr.
After seeing this issue however, I realized it was broken all along.
I offered to backport just the fix, but since it was deemed unimportant, I took no further action.
That's fine; we can just leave it for now.
Your ~pizza~ backport is here!
git cherry-pick'ing is faster than any rebase / merge.
https://blog.adafruit.com/2023/09/12/circuitpython-8-2-6-released/
@tulip sleet do you have an ssl test script?
to run on CircuitPython?
it'd be handy for idf 5 testing. yup
You may need to comment out some of the fetches. I get memory errors sometimes if they are all executing. This is the usual test script, + adafruitIO + a Let's Encrypt site
@tannewt Two places to look: (1) for DDR 120MHz PSRAM you need "octal flash", which are the modules that say OT in this chart
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/hw-reference/esp32s3/user-guide-devkitc-1.html#ordering-information
(2) You want to see this list of "groups" of settings: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-guides/flash_psram_config.html#f8r8-hardware
Note that the N8R8 in (1) is OT PSRAM but "only" quad flash -- wh...
@slender iron I started to do that 8.2.x PR too, but it has merge conflicts
want me to fix them or do you?
I want to rebase my idf5 changes on it since it has the pin in use fix
i was going to do a local PR from my fork, yeah, I can do it if you just want to close it
Something to consider about module _thread in CPython and MicroPython is that they do not offer concurrent execution of Python code on multiple cores. The interpreter implementation is such that it can run only on one thread at time under the control of the GIL (Global Interpreter Lock). Quote from the CPython documentation:
CPython implementation detail: In CPython, due to the Global Interpreter Lock, only one th...
@tirtharajsinha I was merging 8.2.x into main. One thing I saw is that this backport has differences from the one you did for main. Most of the changes are clear, but you made the default RX and TX pins here be GPIO44 and GPIO43. I think you meant GPIO12 and GPIO11, because that's what's in pins.c. So in the merge, I changed it.
Thanks! I read through the changes other than in ports/espressif/boards and did not spot anything funky.
thanks @dhalbert , may be I had missed that part. Thanks for noticing.
Verified that pulsein works as expected on a Raspberry Pi Pico board, even across script restarts. For the ESP32-S2 I tested on, it seems like everything is fine on 8.0.5 but broken in same way described above starting in 8.1.0.
One more thing, as you updated the files in main it's still unchanged in branch 8.2.x. Should I cherry-pick from main to 8.2.x?
Good idea -- I forgot that the 8.2.x UART pins were wrong in 8.2.x.
Updating the rx tx gpio numbers suggested by @dhalbert in #8372 .
Thanks! Will be in next 8.2.x release (no immediate plans for that).
This is possibly SD card related. :(
Since the one used above worked when reverting to an older version of CP, it was considered OK. However, just did the simple check of swapping to another SD card - and it now works! Running simple test from above:
Reply is OK!
Saving data to /sd/cache.bmp
.........................................................................................................................................................................................
where do the CIRCUITPY_CREATION_ID come from for non-USB boards?
Adafruit CircuitPython 9.0.0-alpha.1-39-g3032d4e7d5 on 2023-09-13; M5Stack Timer Camera X with ESP32
import espcamera, board
a = espcamera.Camera(data_pins=board.D, pixel_clock_pin=board.PCLK, vsync_pin=board.VSYNC, href_pin=board.HREF, i2c=board.SSCB_I2C(), external_clock_pin=board.XCLK, external_clock_frequency=20_000_000, powerdown_pin=None, reset_pin=board.RESET, pixel_format=espcamera.PixelFormat.JPEG, frame_size=espc...
here is a my version of the pin diagram.
Open for any suggestion.
Hi @tirtharajsinha, I noticed the drawing you published today. I have been working with the Waveshare ESP32-S3 Pico for over a week now (with great pain I might add)... I was not able to get the SPI interface to operate on the pins you indicated :
...
Tested with:
a = espcamera.Camera(data_pins=board.D, pixel_clock_pin=board.PCLK, vsync_pin=board.VSYNC, href_pin=board.HREF, i2c=board.SSCB_I2C(), external_clock_pin=board.XCLK, external_clock_frequency=20_000_000, powerdown_pin=None, reset_pin=board.RESET, pixel_format=espcamera.PixelFormat.JPEG, frame_size=espcamera.FrameSize.QXGA, jpeg_quality=55, framebuffer_count=2, grab_mode=espcamera.GrabMode.LATEST)
Which is the absolute maximum and the wifi connected.
nevermind, my 2 braincells went full circle
first thing first there is a wrong color for UART and TOUCH pins in legend, thanks for pointing out.
Second, ESP32 chips allow for 'multiplexing' of almost all signals so it isn't like some pins can do SPI and others can't. You can connect any of the available PWM channels, I2S channels, UART, I2C or SPI ports to any pin. I have added the pins as default. you can Ignore the pins that are in diagram.
As you said you could not able to use the rgb led, the rgb led is connected to GPIO 21...
Could you also describe the ordering of rgb_pins and addr_pins? I didn't see this written down anywhere when I recently needed to jumper to a panel. I asked @PaintYourDragon and he told me it was (R1, G1, B1, R2, G2, B2), or the equivalent, and the address pins are (A, B, C, D). I am going by the pin labeling here: , which is either x1 and x2 or x0 and x1.
@tulip sleet like so? ```//| :param Sequence[digitalio.DigitalInOut] rgb_pins: The matrix's RGB pins in the order (R1,G1,B1,R2,G2,B2...)
//| :param Sequence[digitalio.DigitalInOut] addr_pins: The matrix's address pins in the order (A,B,C,D...)
yes, that would be great -- thanks. There's not complete standardization on the nomenclature, but that is a big hint
Also, did you want to add pin list defs for MatrixPortal S3?
This MTX_COMMON dictionary seems redundant, since the pins are already named as board.SOMETHING., and the clock, latch, and OE pins need to referenced separately anyway when passing them to the RGBMatrix constructor.
How about making rgb_pins be MTX_RGB_PINS at the top level of board instead, and removing MTX_COMMON?
Or is there some use for this dict I am not seeing?
addr is used in the arg list, so we can use the abbreviation to be consistent.
{ MP_OBJ_NEW_QSTR(MP_QSTR_MTX_ADDR_PINS),MP_ROM_PTR(&matrix_addr_tuple) },
//| :param Sequence[digitalio.DigitalInOut] rgb_pins: The matrix's RGB pins in the order ``(R1, G1, B1, R2, G2, B2, ...)``
//| :param Sequence[digitalio.DigitalInOut] addr_pins: The matrix's address pins in the order ``(A, B, C, D, ...)``
is it ok if five pins are given but only four are needed? Does Protomatter ignore the fifth pin?
Sorry, could you elaborate on this one? The line in question that uses this string is
if (state < 0 || state > UINT16_MAX) {
mp_raise_TypeError(translate("state only supports 16 bits"));
}
I also do other checks such as
if (chip < 0 || chip >= TCA9555R_CHIP_COUNT) {
mp_raise_TypeError_varg(translate("chip can only be 0 to %q"), TCA9555R_CHIP_COUNT - 1);
}
and
if (!mp_obj_is_type(pin_obj, &tca_pin_type)) {
m...
Ah thanks. I admit it's inclusion here was purely because the SRC_CYW43 was included there, without really understanding what the line was doing. I will remove.
no, that's why you have to "slice" the address pin list if you actually use fewer address pins.
Also, did you want to add pin list defs for MatrixPortal S3?
These [should] match what was already defined for MatrixPortal S3; it's about bringing the M4 up to the standard I created with S3. If the "standard" I dreamed up in that PR is not good, then I can just drop/revert this part of the change for now.
The reason there's a dict and a tuple that is not in the dict:
Where possible, you should use the routines defined in py/argcheck.c. (declaration in py/runtime.h) This helps reduce code size and makes error messages more consistent.
For instance, here's the implementation of one of them:
mp_int_t mp_arg_validate_int_range(mp_int_t i, mp_int_t min, mp_int_t max, qstr arg_name) {
if (i < min || i > max) {
mp_raise_ValueError_varg(translate("%q must be %d-%d"), arg_name, min, max);
}
return i;
}
you'd call `mp...
I never saw the S3 new "standard" way, so if you are duplicating that, that's fine. :)
I also encountered this issue while working on POC of adafruit_template_engine.
While this is not fixed, one way of making it work is using encode("utf-8") and then decode("utf-8").
text.encode("utf-8")[match.start():match.end()].decode("utf-8")
This is not an elegant solution, but might be the only way of doing it right now.
@analog bridge are you ok with me trying to force push to your update-idf branch? I'm just about ready to PR it. (I think) Pushing to your branch will update the existing PR.
with the i2c bus operating at 400kHz this achieves a 4.8kHz SPI clock rate which could be worse.
It accepts the same style of init sequence as displayio.
tested by scoping the pins on the espressif lcd dev kit with a dummy init sequence:
Initialization exercise code
import busio, microcontroller, dotclockframebuffer
expander_addr = 32
init_sequence=b"\x55\3\xaa\xff\x00" * 100
bus = busio.I2C(microcontroller.pin.GPIO18, microcontroller.pin.GPIO8, frequency=400_000)
...
@brazen hatch your web workflow change also changed when we construct mdns
were you seeing issues with mdns as your ip changed? the mdns server should stay up
hardfaults
at least if memory serves well
my brain is kinda cooked rn
Yea, if the network changed, it was producing a hardfault for some reason.
Not quite sure why, but I did decode the backtrace and it was mdns
So I kinda went, "sure, have a || reload".
Is this causing an issue?
I kinda assumed it's harmless and spared no more of my time on it.
ya, its a bit weird because a second construct call will mark the object as deinit
so the web workflow then sees its deinit and doesn't think that mdns is active
How do I check that?
I have very little experience with actually using it.
I saw the issue on esp32
when I loaded the webpage, board name (really instance name) and hostname were empty
walk time. back in a bit
I need time anyways to test some stuff, I have an idea on how to alleviate the issue.
But it could take many tries.
Enjoy your walk!
removing the reload fixes the immediate issue
But booting without web workflow, enabling and reloading will prolly be a hardfault
Hey @jepler. Could you clarify the difference between shared-bindings and shared-module. I've checked both folders, and I see each has folders such as digitalio. It looks to me like shared-bindings is for the micropython binding part of a module (i.e. anything dealing with mp_obj)? Then shared-module is for common_hal functions, which I don't explicitly have.
It could just be i'm not thinking clearly as it's late evening over here 😅
enabling from user code?
I'll give it a shot as I test C3
writing a settings.toml and reloading yea
My condolences.
enabling web workflow via settings.toml. correct?
after adding the web workflow password, it doesn't start up
doesn't crash though either
Could you clarify the difference between
shared-bindingsandshared-module.
shared-bindings is the layer that defines the Python API, checks any port-apnostic preconditions and converts to the common_hal_ internal C API. shared-modules is for port-agnostic implementation of common_hal_ functions.
Okay. In that case I'm not sure how you're wanting me to move my TCA driver over to these folders then, given theirs no comman_hal style functions. Is there an example you can point me to? I based my implementation on how the CYW driver for Pico W was written.
You are doing the separation some. You just aren't designating it common-hal. For example, tca_port_read_polarity_state is used to parse and validate params and then call tca_get_polarity_port. The latter would be common_hal_ and moved into shared-modules. tca_port_read_polarity_state would be in shared-bindings and documented with a Python stub comment.
cyw43 is a bad example because it doesn't split out the limited implementation. Both rp2pio and picodvi are split along...
Okay, i'll have a look at rp2pio and picodvi tomorrow.
Adafruit CircuitPython 8.2.6 on 2023-09-12; ST STM32F746G Discovery with STM32F746
Board ID:stm32f746g_discovery
print("Hello World")
I programmed the "adafruit-circuitpython-stm32f746g_discovery-en_US-8.2.6.bin" file from the official repository and tried to connect to the REPL. I tried just to see what was available but running "import board" printed a few extra new lines and then hung.
Either press...
It's worth noting that we should get micropython's bug fix for this when we merge mp version 1.20, which is planned for circuitpython version 9.
Adafruit CircuitPython 8.2.5 on 2023-09-07; VCC-GND Studio YD RP2040 with rp2040
Board ID:vcc_gnd_yd_rp2040
>>> import microcontroller
microcontroller.cpu.temperature
-1479.79
>>> board.board_id
'vcc_gnd_yd_rp2040'
got negative reading -1479.79
No response
No response
New BPI-Leaf-S3 v1.1 version support double-clicking the reset button to enter the UF2 bootloader.
Update the pics and bpi_leaf_s3.md.
New BPI-Leaf-S3 v1.1 version support double-clicking the reset button to enter the UF2 bootloader.
I've changed this over to an argcheck now. I hadn't realised the exact function that was referring to when you posted.
Switched over to argchecks, and even added a new one for the dual pin type checking both tca and cyw do.
Still figuring this out. Splitting out the python binding stuff is obvious so I will try that first. In the meantime I've added the python stub comments you mentioned.
@jepler Is there a process for sorting out the makefiles for having your code in shared-bindings and shared-module? I'm getting so many linker errors 😭
- Verbosity options: any combination of "steps commands rules", as `make V=...` or env var BUILD_VERBOSE
QSTR not updated
Module registrations not updated
/usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/bin/ld: build-pimoroni_yukon/py/objmodule.o:(.rodata.mp_builtin_module_table+0x214): undefined reference to `tca_module...
not exactly but looking at a commit which adds a new module that is split across shared-modules and shared-bindings may be instructive: f5c637dc10e2374ca1282cbc430c94fc0973b2f6 (there's this guide but it's well out of date: https://learn.adafruit.com/extending-circuitpython/inside-the-virtual-machine)
This is less of a feature request and more of a request to get down to decide an api for it.
I would like to try implementing it, but I want your input on how it will work.
I was thinking of making a fallback of sorts.
If the STA network /settings.toml specifies is not found, or could not be connected, check if AP credentials exist and make an AP.
CIRCUITPY_AP_SSID
CIRCUITPY_AP_PASSWORD
Also it would perhaps be worth considering installing some random defaults onto the files...
not exactly but looking at a commit which adds a new module that is split across shared-modules and shared-bindings may be instructive: f5c637d (there's this guide but it's well out of date: https://learn.adafruit.com/extending-circuitpython/inside-the-virtual-machine)
- Add a SRC_PATTERNS stanza and some SRC_SHARED_MODULE_ALL lines to py/circpy_defns.mk
- Add a default enable/disable Make...
I agree with this. Having a user create a secrets.py or settings.toml instead of providing one in the file system isn't intuitive especially for a first timer. For those of us who constantly play with new boards, having to create the file, and fill it with relevant credentials with copy/paste gets tedious. Even if the settings are blank it would be nice to have a default settings.toml included with all possible fields that can be used in a settings.toml file.
huh, weird/cool. I noticed today that this error isn't caught in circuitpython, but it is in micropython 1.20. Turns out it's newly detected by micropython, and misbehaved before: ```py
def f(**kw): return kw
...
f(x=1, **{'x':2})
{'x': 2}
i.e., micropython fixed the bug in 1.20
it'll raise an exception now?
More commentary at this older issue:
https://github.com/adafruit/circuitpython/issues/6795
let me double check but yeah
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> def f(**kw): return kw
...
>>> f(x=1, **{'x': 2})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: function got multiple values for argument 'x'
>>>
check if AP credentials exist and make an AP.
What do you gain by making an AP? I don't think web workflow works on one yet.
Even if the settings are blank it would be nice to have a default settings.toml included with all possible fields that can be used in a settings.toml file.
This will take up more flash space because we'd need to store a copy of the default file in the image. I think it'd make it harder to write to since you'd need to edit a line instead of appending.
T...
nice! better errors are better 🙂
I don't think we have may folks using CircuitPython on the F7 and this is likely a bug. (Us Adafruit-funded folks haven't spent time on it since we don't have any F7 boards of our own.)
We'd appreciate the help debugging it if you are interested. We can answer dev questions on Discord in the #circuitpython-dev channel. Thanks!
I don't think we automatically want an AP started by default on every CircuitPython install (or storage.erase_filesystem()) with no user intervention. An AP uses board resources and creates security and privacy vulnerabilities that don't require physical access to the device.
But an easy way to optionally enable web workflow via AP would be very welcome.
Isn't the main reason to have this natively is for boards with native displays? It's a bit weird that there isn't one using it. I wonder if it should only be made available internally.
From Python can't we do IOExpander DigitalInOuts + bitbangio?
@jepler An attempt was made at restructuring the code. Builds locally and passes the test here, but please let me know if there are structural things I should improve. There's probably some imports I can remove.
Hello, sorry to bother, but I'm new looking to help debug issue i posted for supporting the STM32F7 disco board. Is there any documentation on how to setup to debug the core? I have experience with embedded firmware, so I don't need hand holding, but any standard practices would be helpful. I have also built circuit python for another project to add a custom board for a client using the RP2040, so vaguely familar with basic getting of code and building, but looking for any direction on how to build for debug. TIA
This will take up more flash space because we'd need to store a copy of the default file in the image. I think it'd make it harder to write to since you'd need to edit a line instead of appending.
It could just be generated at fs creation time.
There is no reason not to just touch and append to it whatever we generate.
This way, we could use the #if's to very quickly append placeholders for whatever the board has.
What do you gain by making an AP? I don't think web workflow work...
@tulip sleet We did not fix the issue. https://adafruit-circuit-python.s3.amazonaws.com/adabot/bin/reports/circuitpython_library_report_20230915.txt
Out shopping. I can make a new token and we’ll try that
Sounds good. Thank you.
Hi! The make command can take a DEBUG=1 parameter to include symbols in the build
and then a debugger should be able to know what is happening
for debugging safe mode, you can break on reset_into_safe_mode
@onyx hinge do you have a repo with test code for these dot clock displays?
@slender iron no, just some gists e.g., https://gist.github.com/jepler/56758bd4bc0d9f9ff5548f52c5801cba
oh the lcd driver?
DotClockFramebuffer
does it look like a tough change? I'll test of course.
that's good for us! we can lose the hack to retrieve it
I think I also saw double/triple buffering
yup, just deleted it
there is also this guide: https://learn.adafruit.com/circuitpython-samd-debugging-w-atmel-studio-7/overview
@slender iron by the way, would it be possible to add the same tags to your article as are on that atmel studio one? it's much harder to find
\o/
🙂
Unsure if I should raise an issue for this, but if anyone recalls there was an issue with the FunHouse having a display glitch (https://github.com/adafruit/circuitpython/issues/4775) that was fixed by lowering the display rate but it only occurred in CP an not in Arduino so there was more too it.
I am now seeing similar behavior on the ESP32-S2 TFT after I hooked my lightning detector board to it.
I know how to lower the display frequency/build a custom build to fix my porblem, and so far it has only occurred for me with a second SPI device hooked up. But this is showing that the underlying, unknown issue still seems to exist.
humm is there a reason that these are not static const arrays as a rule? uint8_t display_init_sequence[] = {
seems like not making them const means they use up RAM in addition to flash
sometimes they get patched but I think that's usually from python drivers
Did a bit more tidy up. I think it's ready for me to convert from a draft, but I'll leave it over the weekend in case I think of any last changes to make.
I wonder why uncrustify INSISTS on the extra indentation here. ```c
.bus = i2c,
.i2c_device_address = i2c_device_address,
.i2c_write_size = 2,
.addr_reg_shadow = { .u32 = 1 }, // GPIO data at register 1
.cs_mask = 0x100 << 1, // data payload is at byte 2
.mosi_mask = 0x100 << 3,
.clk_mask = 0x100 << 2,
.bus = bus_obj,
.i2c_device_address = i2c_address,
.i2c_write_size = 1 + gpio_data_len,
// ASSERT(LITTLE_ENDIAN, "don't have to differentiate 8- vs 16-bits here")
.addr_reg_shadow = { .u32 = gpio_address | (gpio_data << 8) },
.cs_mask = 0x100 << cs_bit,
.mosi_mask = 0x100 << mosi_bit,
.clk_mask = 0x100 << clk_bit,
};
```it did here too
@onyx hinge do you know what clock source it should be set to?
Is that using our post-processing?
that's how pre-commit changes it
that's uncrustify + python post-processing iirc
so it might be the post stuff going awry
I don't know about the clocking. I guess I am relying on a default
you mean the function lcd_rgb_panel_select_clock_src?
examples/86box_smart_panel/main/bsp_board.c: .clk_src = RMT_CLK_SRC_DEFAULT, // different clock source can lead to different power consumption
examples/smart_panel/components/esp32_s3_lcd_ev_board/sub_board/sub_board_480x480.c: .clk_src = LCD_CLK_SRC_PLL160M,
examples/smart_panel/components/esp32_s3_lcd_ev_board/sub_board/sub_board_800x480.c: .clk_src = LCD_CLK_SRC_PLL160M,
examples/smart_panel/main/bsp_board.c: .clk_src = RMT_CLK_SRC_DEFAULT, // different clock source can lead to different power consumption
```some different demos in esp-dev-kits make different choices and I don't konw why.
yeah the RMT_CLK_SRC must be for something else. Use PLL160M or LCD_CLK_SRC_DEFAULT then?
components/esp_lcd/test_apps/rgb_lcd/main/test_rgb_panel.c: .clk_src = LCD_CLK_SRC_DEFAULT,
welp, it compiles but doesn't work or error
Yes, this is needed to support boards with built-in displays like the esp32s3 lcd dev kit. but if you like I can gather numbers showing it's also a good deal faster than a pure Python bitbang spi-over-i2c. (even so, it's not fast; each SPI bit is 2 I2C transactions with 24 bits each, so the absolute maximum with a 100kHz I2C bus is about 2kHz and in practice it's slower; the 400kHz I2C bus only got to 4.8kHz SPI bit rate)
@tulip sleet im going to call this sd issue and close unless you want to keep open?
https://github.com/adafruit/circuitpython/issues/8382
I agree!
I'm going to consider this to be an SD card issue and close.
Asked the original poster to try this as well, but as yet have not heard back:
https://forums.adafruit.com/viewtopic.php?p=985638#p985638
thanks for all the cycles spent looking into that
np!
Looks like I managed to purchase a few of these boards and since I'm unable to get a refund from the seller, what would be the process to build the firmware for these boards that would allow them to work?
The espressif_esp32s2_devkitc_1_n4 is an example of a board with 4MB and no PSRAM. It's pretty generic, since it's an official dev board, so you might just try loading that .bin or .uf2 and see what happens.
Thanks @dhalbert I'll give that a try. Thanks for the quick response!
@shmick You can also just add a CONFIG_SPIRAM_IGNORE_NOTFOUND=y in sdkconfig of the regular board if you want to.
In addition to the MIDI note value to frequency converter helper already in synthio, it would be very handy to include a converter for a note's Scientific Pitch Notation (SPN) string to a frequency.
Here's an example of a helper in CedarGroveStudios/CircuitPython_MIDI_Tools (also in the community bundle) that converts SPN to a MIDI note value.
def name_to_note(name):
"""Translates a note name to a MIDI sequential note value. Note names are
character strings expresse...
From the OP, this is the key:
check if AP credentials exist and make an AP
An auto-generated random password doesn't solve the problem of not having serial access to the device. And if you do have serial access, AP might be a convenience, but you could do anything over serial without needing an AP.
I would not want every new device to start an AP by default, increasing complexity, using resources, broadcasting an SSID, and revealing its permanent hardware MAC address (and by infer...
I am currently working on the templating engine for CP, a common feature that they offer are functions for escaping unsafe characters like < to < or " to " in HTML.
Although I can think of multiple formats that might benefit from this feature, only HTML seems to be useful in context of CP.
Markdown, SQL or XML cannot be used directly in CP, so implementing functions for them seems pointless as it increases lib size.
Can anyone think of any other format that would require this functionality while also making sense in CP?
I am trying to build a macro pad thing with the follow set up, is it possible to read the (big)switch if I wire it to the stemma port at the end of this chain? I currently have everything up to the big switch working as expected.
no, the big switch needs I2C connectivity, and it doesn't have it. Out of the box, it's just like any other pushbutton. The Trinkey RP2040 does not have any exposed pins you can use for that; it only has I2C, through the STEMMA port.
Consider using something like a QT Py RP2040 instead, which will let you connect the switch to one of its pins.
You could repurpose the rotary switch push button, if your not using it and bound to that hardware
I uploaded the last uf2 file to my PicoW and the previous error related to the pio machines seems to be solved by using the GP26 and GP27.
My code is:
import microcontroller
microcontroller.cpu.frequency = 120000000
print(microcontroller.cpu.frequency)
import board
import usb_host
import usb
import sys
import supervisor
import time
usb_host.Port(board.GP26, board.GP27)
if supervisor.runtime.usb_connected:
print("USB<host>!")
else:
print("!USB<host>")
w...
But it seems that it is not able to read and print any press of buttons on the keyboard. I am new to circuitpython and maybe there is a different way of reading the usb.
I would suspect that the USB keyboard isn't assigned/added to the stdin-"channel" automatically - all search results I got refer to the board emulating a USB keyboard (and not using a keyboard for stdin as a USB host). But some code parts in supervisor/shared/usb/host_keyboard.c seem to implement just that....maybe I fin...
I create a single like this:
class SingletonClass(object):
def new(cls):
if not hasattr(cls, 'instance'):
cls.instance = super(SingletonClass, cls).new(cls)
return cls.instance
This is declared in fileA, and fileA is imported by many other files. It seems to initialize for each import!
WHy?
Its like i have multiple instances of my singleton...!
I believe you want __new__
__new__ is not supported in MicroPython or CircuitPython, iirc
Ahh, there I go using my normal Python knowledge... this has bitten me too many times.
just make a factory function
Wasn't aware of the limitation. Can you point to a CPy factory function example that serves a simlar purpose?
singleton_class_instance = None
def make_singleton_class():
global singleton_class_instance
if singleton_class_instance is None:
singleton_class_instance = SingletonClass()
return singleton_class_instance
Ah! global variables 101. Got it! Thanks man!
a class variable is a hidden global
Yes of course. Just never thought of it that way. OK.. I'm off to re-factor some code.
@dhalbert I loaded the bin for ESP32-S2-DevKitC-1-N4 onto the boards and it looks to be working. Thanks for the suggestion!
https://github.com/izuchukwu/USBBridge#what states
A lot of Android devices support USB OTG, which lets you read USB drives. But most, like Google's Pixel and Nexus devices, don't support FAT12 and FAT16
so are you certain that this would provide compatibility with Android?
I haven't looked at this in detail for several years, but my impression was that FAT16 would work. I have some very small SD cards and could try this with an Android tablet. But there is no work being done on this at the moment.
I'm seeing the same issue but only after connecting the 5v lead from the Pico to the Adafruit 16x2 RGB Char LCD Shield (Adafruit Part#714).
If the Shield is not powered on then microcontroller.cpu.temperature returns a correct cpu temp around 34° Celsius. As soon as I boot the Pico with the Shield attached via i2c and powered from the Pico's 5v vbus the cpu temp is reported as a negative number usually around the -70° Celsius range.
Pico W
Cir...
On the transmitter microcontroller I use version 8.2.4. On the receiver microcontroller I use version 8.2.6.
################# transmitter microcontroller #################
import sys
import time
from ulab import numpy as np
import board
import busio
uart = busio.UART(board.GP4, board.GP5, baudrate=9600, timeout=5)
def sending(data):
uart.reset_input_buffer()
time.sleep(0.01)
uart.write(data)
...
An actual 8mb sdcard, that has 6.8mb usable is reported to have fat12 content on a fat16 partition type.
My big boi n16r8 borb, reported to have fat16 on a fat12 partition type:
:
for i in range(len(buf)):
self.data[block_num * self.block_size + i] = buf[i]
Like 10 times slower than:
def writeblocks(self, block_num, buf):
area = block_num*self.block_size
self.data[area:area+self.block_size] = buf
it makes no sense..
because the first one gets executed in python, while the second one is executed in C
yea but the 2nd one is the slower one..
that's the issue
I tried to do it the smort way
you mean the slice is slower?
what is self.data and buf exactly?
just plain bytearrays
there is something weird going on there, the slicing should be much faster
Here is the whole code:
from storage import VfsFat
class RAMBlockDev:
def __init__(self, blocks: int, block_size: int = 2048) -> None:
if block_size < 512:
raise ValueError(
"Block size must be at least 512."
)
if blocks < 64:
raise ValueError(
"Cannot be less than 64 blocks."
)
self.block_size = block_size
self.data = bytearray(block_size * blocks)
VfsFat.mkfs(self)
def readblocks(self, block_num, buf):
mvd = memoryview(self.data)
for i in range(len(buf)):
buf[i] = mvd[block_num * self.block_size + i]
def writeblocks(self, block_num, buf):
#for i in range(len(buf)):
# self.data[block_num * self.block_size + i] = buf[i]
area = block_num*self.block_size
self.data[area:area+self.block_size] = buf
def ioctl(self, op, arg):
if op == 4: # get block num
return len(self.data) // self.block_size
if op == 5: # get block size
return self.block_size
The code.py is:
import os
import storage
from ramdisk import RAMBlockDev
import time
a = time.monotonic()
print(time.monotonic()-a)
vfs = storage.VfsFat(RAMBlockDev(512))
storage.mount(vfs, "/ram")
storage.umount("/ram")
print(time.monotonic()-a)
btw, to make that code equivalent, it should be self.data[area:area+len(buf)] = buf
the writes will always be of block size so its faster to use the stored val
if buf is different size than self.block_size, your coode would make a copy of the whole self.data
using a memoryview might help
2k blocks.. I was on 512 and confused it.
so it's copying indeed
so wait
it's not writing blocks of the correct size???
it will replace the self.block_size bytes with the whole buf
for that it will need to reallocate and copy the whole self.data
k I fixed it, but it's still slow..
self.data[area:area+len(buf)] = buf
Now it should never copy??
I am actually gonna speedrun filesystem corruption
try wrapping self.data in memoryview
wait aren't mv's readonly?
bb
apparently not.. you can write just fine..
still no speed improvement.. very weird
@onyx hinge For the V1.20.0 merge, I am down to about eight files with remaining merge conflicts. Some of these are just tedious, but some I could use your expertise on (generators, type stuff). I think I would like to do some "pair merging" if you're up to it.
btw I like your new avatar on Discord. It's very crisp even tiny. Have you considered it for GitHub? The tiny pictures in Blame listings are hard to see.
@tulip sleet good morning. I'd like to do that!
I'm out at 4PM ET to get my COVID vaccination, so we could do it before meetings today OR we could do it tomorrow OR we could do it for a short time after meetings.
I am also trying to get vaccines around that time, though the store said the COVID one is not in stock. That's another story. in about 30-45 minutes would be good for me. I am running the meetings today so I'm pretty occupied 12pm ET on.
OK, let me eat breakfast and then I'll ping you.
@tulip sleet I'm available now.
be right there - 1 min
OK, take your time
Adafruit CircuitPython 8.2.6 on 2023-09-12; TinyS3 with ESP32S3
import board
import time
import sys
from adafruit_bus_device.i2c_device import I2CDevice
delay = 0.1
bytes_to_read = 12
print("")
print(f"Reading {bytes_to_read} bytes from I2C every {delay} seconds")
reads = 0
errors = 0
while True:
try:
with board.I2C() as i2c:
device = I2CDevice(i2c, 0x08)
data = bytearra...
Turns out that FAT16 does indeed work on my Fairphone 4. I just took a MicroSD card from my Nintendo DSi XL (used in that with a MicroSD to SD convertor, in case you're confused) and it worked without needing to be formatted.
@tulip sleet was that 2 files we got through? makes me appreciate your work all the more to do some of it with you.
thanks! it was three files, five to go. After we do those I can finally commit everything as a WIP commit, and then maybe go back and review the diffs (and I might ask you more). I am more confident now about changing all the _type defs in shared-bindings etc. now too.
@danh Big shout out of thanks for keeping the core of CP in synch with MP. Bravo!
I never saw the S3 new "standard" way, so if you are duplicating that, that's fine. :)
I'm trying to understand why an I2C bus needs a lock.
In the days of using "continued start", I can see why -- other interspersed activity on the bus would have been trouble. but now everything is writeto_then_readfrom.
Unlike SPI there's no settable frequency and no cs pin to manipulate.
Could the lock be dispensed with?
(broadcom and stm call RUN_BACKGROUND_TASKS during i2c transactions so that would have to change: that WOULD allow an i2c function to be re-entered recursively from background context and right now the locks prevent that. but most ports don't seem to)
There are a couple chips I've used where I could not use writeto_then_readfrom as you had to pause a small amount of time before the result was ready.
That aside, with CP controlling the i2c device though I'm trying to think of any case where a lock would be needed. Maybe something with DMA?
@blissful pollen does access to a different device in between the operations have to be prevented?
or can you write(slow); write(fast); read(slow)
threads may have also been an initial consideration; I think @slender iron will have the historical background on the locks
we can discuss in In the Weeds
I don't think reading/writing to a different device would matter while you are waiting for the result. But haven't tested it.
I ask because the I2C lock is the main thing that made me decide to put aside the core I/O expander support work.
i also found it intrusive in the past. I wonder the same about SPI
I can only think maybe for large writes (displays?) if it is broken up for any reason and something else in background tasks jumps on the i2c bus and somehow that causes an issue. Maybe more for SPI. I'll keep mulling it over and let you know if I think of any cases.