#circuitpython-dev
1 messages Β· Page 71 of 1
I think I considered --user but it wasn't going to work? I could try a test run of that.
this is the pep
This applies both to system-wide installs (sudo pip install) as well as user home directory installs (pip install --user), since packages in either location show up on the sys.path of /usr/bin/python3.
you are right about --user
ok, now I re-remember, thanks!
I hate it when project politics take precedence over user needs
There are many different versions of mpy-cross binaries listed here: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/mpy-cross/linux-amd64/ are there definite differences between all of these or are some of them the same as previous versions but are just increased to match the cpy core release cadence?
The 8.x and 9.x mpy-cross should all produce the same output. e.g. don't worry about 9.0.x vs 9.1, for instance
I clean that up from time to time
Okay thank you. Do you know how circuitpython-build-tools chooses which version to use when it runs in actions? Is there a specific point at which that will switch to using 9.x?
I thought it was using 9.0.0-alpha.something?
it's in a .github file somewhere, I think
I would do a repo or org search for mpy-cross in Github
This action task downloaded the 8.2.0 one it appears: https://github.com/adafruit/Adafruit_CircuitPython_ImageLoad/actions/runs/10229379612/job/28302965678#step:2:908
maybe because it builds both 8.x and 9.x right now. However I don't see any other s3 links with a 9.x version in the URL in that actiosn log.
the failure is actually bad python?
Traceback (most recent call last):
File "/tmp/tmpv_f3cj59", line 127
SyntaxError: invalid syntax
I traced it back to this: https://github.com/adafruit/Adafruit_CircuitPython_ImageLoad/pull/85#issuecomment-2269194399
the mpy-cross used doesn't support f-string with repr format f"Unsupported image format {magic_number!r}" seemingly
https://github.com/adafruit/circuitpython-build-tools/blob/1f3c5bd0a250dc162306a522c3ee5cd2c117716b/circuitpython_build_tools/target_versions.py#L25 is where the mpy-cross version is set
(I have not tried a 9.x mpy-cross yet but I am about to)
Ahh, I see. Yeah it appears the 9.x mpy-cross does compile it successfully with the f-string and !r. I have not tested it specifically on hardware, but was just thinking maybe that it's not so much that mpy-cross doesn't / didn't support it, but rather micropython itself.
you can use repr(...) instead, it's just an alternate syntax. Since we want the library to still work with 8.x, I think that's the right thing to do
So we definitely will want to keep the 8.x compatibile version until whenever we make the final bundle build for 8.x
yes, exactly
<@&356864093652516868> weekly meeting will be in less than 2 hours, at 2pm US ET / 11am US PT. Add your notes: https://docs.google.com/document/d/1vwgVemFzcQIq3IEBjD66LEsObJawdNTniufYQoimPdc/edit?usp=sharing
I think it's simplest to say you fully light sleep only if you've never received a character from the usb to serial chip
we have a notion of pretend deep sleep for a similar purpose
It's possible to make a UF2 file based on your current setup so that it can be flashed on other board with everything included, correct? (e.g. code, libraries, additional files)?
Yes, on RP2040, at least. Use picotool. Boot board into UF2 mode, then do picotool save -a myproject.uf2 https://github.com/raspberrypi/picotool This is how I make a UF2 to flash all the boards I send out
Thanks - is is possible on other devices as well (in theory at least)? Trying to verify for an article I'm working on.
Is what I have
@devout jolt fancy giving this vgm class a go for me?
On SAMD21, yes. If you boot into UF2 mode, then the "CURRENT.UF2" file will contain the entire flash contents.
All other architectures, no. I believe you only get the internal flash of the chip and not the SPI flash. So on an ESP32-S2 board, CURRENT.UF2 only contains the 128kB internal flash and not the 8MB (or whatever) SPI flash. The TinyUF2 bootloader could be written to read out the external flash (and I wish it would!), but that would make it more complex
Ok, thank you!
Just spent a few minutes extricating the bits and pieces that make it depend on my wider code
Seems reasonable and easy to implement. I'll add this next time I have some time to work on it
Thanks!
@devout jolt foamyguy is working on wwshell. It's been mentioned in discord
oh! great! I will edit my weeds
test
hello devs
Cool, pinged you a message
need help wiht 2 missing drivers for cirpy
We're starting the circuit python meeting now. All text visible in this channel will be on youtube.
it's being recorded and will be posted to Adafruit's youtube channel after the meeting is over. https://www.youtube.com/c/adafruit
you can listen in by joining the CircuitPython audio channel or wait until the video is released later.
#CircuitPythonDay2024 (just to put it out there)
appreciate all the effort you put in every week @turbid radish always cool stuff to read in the newsletter.
text only please
@gilded cradle mute please
very very very low paul, look into your mic settings.
Thanks @slender iron
oh it's Monday and a new bootloader episode. will go watch that after the meeting. π https://www.youtube.com/watch?v=Y_IhpN_pbSY
bill88t or a different bill?
phil, pt
oh phil my bad
Congratulations!
π±
asyncio with RFM? awesome!
i have a few rfm projects i can test with sure.
I have a tab open for the changes
recommended boards to use with it, any boards you'd like tested in particular? or doesn't matter?
Any boards
Anything other than M0 based boards -- It requires asyncio which they don't have.
OOps -- taht was not meant for me.... sorry
well it was a good question for you too since i only have rfm featherwings i think.
I have RFM9x M0 which is too small unfortunately. Cannot even fit 9.1 plus RFM9x library
An rfm feather wing on anything except a feather M0 should be fine.
didn't know m0 can't do asyncio so that's good info.
just not enough room in the firmware
Demo page for cookiecutter on the web: https://cookiecutter.foamyguy.com/cookie/?template=gh:adafruit/cookiecutter-adafruit-circuitpython
I definitely intend on using your cookie cutter web form. Just a lot of projects ahead of it to be done with imageload.
It seems like a much more friendly way to get a cookie cutter thing going. The current cookie process is absolutely daunting. The web form looks sooo much easier to use.
Could something like it be hosted at circuitpython.org?
Sorry -- it just won't fit anymore...
The way some of the issue forms are formatted is very easy to use too. I'm ok with that too.
You can use JSZip
I wonder if cookiecutter could work in pyscript
I've held back on contributing libraries to cookie cutter because it's so daunting and i just don't want to deal with it. The complexity and inconvenience is a barrier.
I have seen some repos run pre-commit as a github task and then committing the changes
I can do pre-commit, pylint, black, or ruff. Those are a bit easier to figure out than cookie cutter as it is now.
only if we did port it over to something in Javascript or something that can be done staticly. AFAIK circuitpython.org is hosted statically in github pages.
oh so would be looking at an action eventually anyway.
The advantage to using Jinja would be that we could keep all of the same source files.
As long as a repo is formatted to a normal standard that most other libraries use, I'd love to just point adabot or something at my library repo and it does it all for you.
Just in general need something easier to use.
Great meeting everyone. Thank you for hosting @tulip sleet 
Thanks all.
π
thanks everybody!
Thanks for hosting Dan, Have a great week everyone.
I'm not familiar with the si570 but do you mean xpt2046 touch driver? I think I have one of those.
If it's not the exact touch driver you need just based on the model # it's probably close enough to work with. https://github.com/DJDevon3/CircuitPython_XPT2046
oddly enough this is actually one of the libraries that i'll probably test out foamyguy's cookie cutter web form with.
yes
the si570 is a single clock chip like the si5351
ok I will test this out as we are working on developing a vfo interface for a 2meter ssb radio and it will have a touch enu
when done
enu/menu
i have the base of a py driver I will find it and post fer further help
but I have to say learning circuitpython in 1 week has been fun .
CircuitPython version
Adafruit CircuitPython 9.0.5 on 2024-05-22; Adafruit-Qualia-S3-RGB666 with ESP32S3
Β«Using 9.0.5 instead of 9.1.1 due to display issues (jitter) on the newer version for that boardΒ»
Code/REPL
import os
import time
import socketpool
import wifi
print(f'{wifi.radio.connected =}')
pool1 = socketpool.SocketPool(wifi.radio)
addr_info = pool1.getaddrinfo('0.adafruit.pool.ntp.org', 123)
print(f'pool1 {addr_info =}')
pool2 = socketpool...
this is the page I have been learning from but think its outdated https://helloraspberrypi.blogspot.com/2021/04/raspberry-pi-picocircuitpython-ili9341.html
I found several Arduino and Python libraries that support Si570, so I think it will be a simple task to port the functionality of those to CircuitPython. I don't know the details of the differences between Si570 and Si5351 but you could probably use the SI5351 CircuitPython library as a base.
Yes the XPT2046 driver I wrote was in part based on that specific driver and article plus the Adafruit library that uses an identical but differently named chip from Texas Instruments called the TSC2046. Those libraries are from Circuit Python 6, 7, or 8. My library is the most up to date for Circuit Python 9 which has changes in the way the display interacts with the SPI bus.
specifically the change to FourWire
ok
my driver also allows for display rotation independent or aligned with the rotation of the touch x/y 0,0 point.
some minor updates that make it a little easier to use in landscape or portrait mode.
I coded it to use the ST7796S display. I've not used it with any other display so any feedback is appreciated.
similiar enough should be pretty easy to drop in the ili driver and just go... hopefully. π¬
awesomeeee
lol didnt know this existed i mainly use it for programming my picos and rp2040 stuff
@random junco just listened to the bootloader. My hope is that circuitmatter will run on all wifi boards that support ipv6. You don't need BLE for it (it is only used if the device isn't on the wifi already.)
@Here is the notes document for next Mondayβs CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and weβll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1izl2ShgUGlfcqk4x2GsMl09FlTILnFV6XS57sEJ-mH8/edit?usp=sharing
Oh, thank you for letting me know! That's very cool, I'll add an update in our newsletter. And thank you for listening. π
No problem! Thanks for covering it. Always happy to hear folks' take on things
These are good questions! We should figure it out for CP 10 because we may choose to break things.
Thanks! Just ordered one for myself.
It would be helpful to be able to specify a sample rate by reference to another peripheral, i.e. "use whatever sample rate the ADC pacer is set to." One way this could be done is to define some high sample rates as special-purpose codes, e.g. a sample rate of 0xFFFFFF00 would be interpreted as "use the ADC DREQ", etc. Thoughts?
Would it be enough for us to coordinate internally so that the ADC and PWM output dma's use the same pacing timer when set to the same rate? I don't really like t...
What about waiting a few minutes after boot for a serial connection before enabling sleep, and just accepting any new connections after that will lose the first char and give some kind of error, unless you have native USB?
You don't need to wait too long I think. I think the first character is known to be unreliable. I think it is common to do multiple ctrl-c.
I'm not sure how to handle the supervisor serial console through, and other similar background tasks.
Can you run CP back...
Thanks for the revisions. I think some of my old comments haven't been addressed either.
mp_raise_NotImplementedError(NULL);
Does uncrustify still change all of this?
One header thing. I think this is ok to consider a fix. The memory layout is an implementation detail of bitmap rather than an API.
I wasn't paying attention to this, I wonder where it came from.
Correct USB connector information. Correct spelling for microSD
That would be better, it's just more code.
Re: the TAC5212, these things are great, up to 768 kHz sampling at up to 32 bits, and you can daisy-chain the devices to get up to 8 channels over one pin. To do them justice, planning to use rp2pio with whatever modifications are needed to support continuous streaming from input to output. That module is kind of the ultimate as far as commanding low-level hardware performance with high-level CP functions. There is a lot of variety in how codecs like to be spoken to, and it will be nice ...
Still working on this. The micropython-uncrustify package from requirements_dev changes it, and so does manually calling uncrustify -c tools/uncrustify.cfg --replace shared-bindings/wifi/Radio.c with the old archived Ubuntu 22.04 binary(Which is 0.72). Modern versions just give a ton of warnings about the deprecated options and do the same thing.
I used Meld to pick the changes one by one and clean up the stuff the bad IDE settings messed up, micropython-uncrustify seems to be working now
I haven't seen a lot of unreliability with the first char myself but it does seem like the sort of thing applications and users should be able to handle.
We could just limit the sleep time to 1s or 100ms at a time(I think usual WiFi sleep is 100ms but will be longer when target wake time is common), regardless of what WiFi is up to, and run a CP/supervisor tick in between each sleep?
foamyguy, tannewt, and danh: reviewing the recording of today's meeting, I heard your In The Weeds discussion on improving the cookiecutter-for-libraries situation.
I don't know if you're looking for additional help with developing proof of concept alternatives. But, if you are, I might have some ideas.
In particular, if you wanted to make an easily deployable local http-server based web-GUI configuration form thing with the capability to generate zip files, Go might be a good fit. Its standard library has great support for templating, working with zip files, and implementing http servers. Also, the go compiler can build static binaries that are easy to distribute without dependency installation hassles.
Doing the same local-http-server to web-GUI to zip-archive workflow in Python should work fine too. The one mild advantage of Go would be that, in theory (haven't tested this), it ought to be pretty easy to use a GitHub Action workflow to have the Go compiler build static binaries for macOS and Linux (perhaps also Windows?) as part of releases to the library-generator tool. Again, in theory, I think those static binaries should be able to include all the necessary string templates for files to start a new library.
Were you to try that approach, you could potentially have a cross-platform "make me the start of a new library" CLI binary tool that could be distributed as a single static binary file for each supported platform.
So, you could have a learn guide with "Download Library-Maker Tool" buttons that work kinda like project bundle downloads. People would still need to run the thing in a shell, then open the web-GUI link in their browser. But, the procedure could potentially be much simpler than the steps involved in setting up a Python environment.
If a go-based tool sounds like a thing you'd like to have, I could potentially help get a proof of concept going.
If I am trying to make a build on the raspberrypi port but getting a lot of errors like this:
./mpconfigport.h:9:10: fatal error: src/rp2040/hardware_regs/include/hardware/platform_defs.h: No such file or directory
9 | #include "src/rp2040/hardware_regs/include/hardware/platform_defs.h"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
What is the the likely cause? It feels to me like it's missing some required library like the rp2040 SDK or something? I ran make fetch-port-submodules already and it seems to complete successfully. I'm not sure if I missed some other step somewhere. I tried running make fetch-all-submodules to see if it would pick up some thing I might be missing, but it does not complete successfully for me, I think it's problem is unrelated but am unsure.
can you find that file? It should be in ports/raspberrypi/sdk/src/rp2040/hardware_regs/include/hardware/platform_defs.h. Is there anything in sdk/? Does git status say that anything is changed in the submodule?
You could try make-remove-all-submodules and the fetch them agian
the contents of the submodule might have been removed by accident, but the submodule is still there
also try a clean build
Ports/raspberrypi/sdk/ is empty except for a .git file I think
Heading to bed soon and already shut down will follow up tomorrow
that's wrong. go to sdk and do a git restore .
or git submodule update --init sdk maybe in the directory above
but there may be other missing things too
CircuitPython version
CircuitPython 9.1.1
Code/REPL
we don't get to run the code
Behavior
nothing
Description
in this board page https://circuitpython.org/board/lolin_s3_mini/
the link for the tinyuf2 is this:
https://github.com/adafruit/tinyuf2/releases/download/0.18.2/tinyuf2-lolin_s3_mini-0.18.2.zip
the file does not exist and the web installer locks
Additional information
No response
Thank you! After remove-all-submodules and then fetch-port-submodules again it appears to be working correctly. I got a successful build. For some reason my original submodule fetch got messed up but remove / re-fetch fixed.
I haven't got any experience with Go so I can't make much in the way of informed comment on that possibility. Off the top of my head I think I'd find an end solution that doesn't need to be compiled to be ideal. But I could perhaps be persuaded otherwise if the compilation is taken completely out of the end users hands.
The idea of using JSZip and some JS templating library together to try to re-implement the core concept of cookiecutter question results getting "inflated" into a template folder (or zip) as a front end static HTML/JS page does seem like a promising route to me because the resulting tool could be used locally, or hosted on the internet and won't require any compile step or even "installing" any libraries since JS can just load modules with script tags or other ES6 methods.
All of that being said, I wouldn't say that I'm opposed to any options at this point. I'm not positive if I fully understand the mechanism you propose and a PoC that to look at would help ensure I'm understanding the idea you've got. Realistically I am pretty much in favor of any solution that 1) simplifies the process for people who haven't done it before, or don't do it often, and 2) makes the process less tedious which I find it to be even though I'm not unfamiliar with it. Personally I can say that I'd be interested in at least checking out any attempt that anyone wants to make at achieving those goals. So if you've got some ideas and are interested / willing to try to build out a small PoC to demo I'd say go for it. If you do, feel free to ping me when you're ready to share I'd be happy to take a look and try it out.
There seem to be a number of "cookie cutter gui" projects (which I found just with a websearch on that term).
https://github.com/cookiecutter/cookiecutter/issues?q=is%3Aissue+gui
A lot of them seem to have died on the vine, but there's recent new activity, and a pretty complete summary here:
https://github.com/plone/cookieplone/issues/17
It looks like other people are already inventing this wheel.
Nice!, thank you I'll take a look through some of the existing efforts
I'd rather not have a go tool to maintain. Python is something we already need so we should keep using it.
Any LWN subscribers? Pay-walled article about CircuitPython: https://lwn.net/Articles/983870/
I noticed in the core some functions accept a typed self argument like this one: https://github.com/adafruit/circuitpython/blob/main/shared-bindings/vectorio/Rectangle.h#L15 vectorio_rectangle_t *self
But others take a void *obj such as: https://github.com/adafruit/circuitpython/blob/main/shared-bindings/vectorio/Rectangle.h#L24 and then inside of shared-module the first thing they do is "convert" that obj into the self instance like this: https://github.com/adafruit/circuitpython/blob/main/shared-module/vectorio/Rectangle.c#L52 vectorio_rectangle_t *self = obj;
Is there different behavior between these two ways of declaring and using that first argument? Or are both equivalent?
To do them justice, planning to use
rp2piowith whatever modifications are needed to support continuous streaming from input to output.
Note that this isn't portable. An I2SIn would be better because it could be implemented on other platforms. RP2 can use PIO internally.
That would be better, it's just more code. Using a magic number is a ~two-line change.
More code is fine. Magic numbers are too much magic imo.
We could just limit the sleep time to 1s or 100ms at a time(I think usual WiFi sleep is 100ms but will be longer when target wake time is common), regardless of what WiFi is up to, and run a CP/supervisor tick in between each sleep?
I'd only do it if the tick timer is enabled. Will light sleep be woken by interrupts? Much of what background tasks are used for is queued by an interrupt.
Note that this isn't portable. An I2SIn would be better because it could be implemented on other platforms. RP2 can use PIO internally.
Yeah, I was thinking to do both, like right now there's both https://github.com/adafruit/Adafruit_CircuitPython_PIOASM/blob/main/examples/pioasm_i2sout.py and the same pio code in https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/common-hal/audiobusio/I2SOut.c.
vectorio_rectangle_t *self = obj;
that code doesnt really do any anything (at runtime) it just tells the compiler that we have a variableself(points to the same memory address asobj) of typevectorio_rectangle_tinstead ofvoid, so that compiler can do stuff likeself->some_field
at the end of the day, the pointer is just the memory address where the object is stored, lets say 0x1234
the difference here is that one function is taking that as "there's a vectorio item at 0x1234" while the other is taking it as "there's something(void) on 0x1234" + then you add the type information with the extra type *new_var = var; + operate on new_var
Wonderful! Thanks!
Jeremy Littler
LEAD Emerging Technologies
The Creative School
Toronto Metropolitan University
416-979-5000 ext. 552222
RCC 353
On Tue, Aug 6, 2024 at 1:17β―PM Melissa LeBlanc-Williams <
@.***> wrote:
Merged #1444 https://github.com/adafruit/circuitpython-org/pull/1444
into main.β
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython-org/pull/1444#event-13781791231,
...
that said, i dont know why one would have the argument as void and the other have it as a concrete type (not that i've even clicked the links, though π )
my guess would be that the one with void has to adhere to some typing rules, as in...```c
typedef void (generic_one_arg_func)(void);
void some_func(void *self) {
a_concrete_t *obj = self;
}
// then you have something like
typedef struct {
generic_one_arg_func func;
} foo_t;
// if function was defined as void some_func(a_concrete_t *self) you wouldnt be able to use it here
foo_t bar = {.generic_one_arg_func = some_func};
Okay, thank you for the explanation. So if I understand correctly the one that takes void *obj is more generic in nature. Theoretically it could have pointers to different types of objects passed for it.
But in it's usage within vectorio in the linked functions as far as I can tell there is no situation where anything would be passing a pointer to anything except a vectorio_rectangle_t. So if I understand the function is able to be used more generally but in practice within this code at least it's not using any of that more general functionality. And theoretically those void *obj could be changed to vectorio_rectangle_t *self. I may give that a try locally to test whether I've actually got my head wrapped around it correctly.
I do not necessarily follow the code example all the way, but that is mostly on me only sort-of knowing C.
Although I think what we're really going to want is an I2SInOut that does both directions with the same clocks.
is more generic
yeah, you could pass the address of anything into it, but if you wanted to operate on the contents of it, it would have to be casted into some type, otherwise you just have a memory location but no idea what it has inside
however, you would need some context to know what to cast into (eg you wouldnt want to operate the contents of a struct as if it was a boolean)
pointers to different objects passed
yeah, when you callfunction(&something)it is equivalent tofunction((void *)&something)-- aka: type information is removed, as expected becausefunctionis not type-aware
would be passing a pointer to anything except a vectorio_rectangle_t
as i said before, there might be other factors in play so that you must define the function asvoid *, and there is no harm on having it asvoid *(other than slight readability)... i would bother rewriting
I don't intend to rewrite it permaently, just try it the other way to validate my understanding.
writing a basic foo.c is a better way to mess some code up and learn from it, in my experience
rather than battling a huge existing codebase
for example, i would start with something like this and do some fiddling from it ```c
void func_void(void *ptr) {}
void func_type(int *ptr) {}
int main(int argc, char **argv) {
bool foo = true;
func_void(&foo);
func_type(&foo);
}
mostly, reading what the compiler yells me about
I would agree and I'd probably be able to learn C more easily by working on something smaller. But in this case my goal really is to (attempt to) implement a specific new feature within vectorio objects more than to learn the language more broadly (though I do grant if I hunkered down and went through the process to learn the basics better it'd make it easier to make these sorts of changes). If I can get the feature I'm attempting to work even without a full understanding it'll be a win in my book.
The void * might be related to the draw protocol support I added (foggy memory). I remember wanting to make vectorio able to draw from arbitrary python objects that implement draw protocol. I haven't had another project to pull me back and add it yet though :-).
Ahh, I wondered if maybe the VectorShape / draw_protocol thingy had something to do with it. Quick question while you're here... Do you happen to know if using common_hal_vectorio_vector_shape_get_x(self->draw_protocol_instance); is the correct or only way to access the x val inside of a function in Rectangle.c in shared-module where self is the Rectangle object.
I also wanted to add native floating point rotations and scales π . Lots of possibilities.
I was initially trying thigs like self->x or self->draw_protocol_instance->x but those were not working (also probably showing my lack of actual knowledge of the basics.)
also I know it's likely not something you've looked at lately, totally understand if you are unsure, please don't go digging into it on my behalf!
Yeah, if you're in the abstract, in vectorshape / draw protocol or layer territory, you have to ask through the adapter. Do you know what a vtable is? If so, this is basically the guts of that.
Rectangle doesn't have an x though - that's a common property of all shapes
rectangle gets its common shape properties and implementations from vectorshape, along with circle and polygon
Okay cool, thank you! I don't know what vtable is (by name atleast) I'll read up. I did eventually realize the rect didn't have the x property directly and figured out how to get it from that common_hal call using the draw_protocol but wanted to make sure I wasn't way over-complicating it somehow if there was an easier way to grab those values that come from the VectorShape rather than the subclasses.
I think of them as related by composition rather than inheritance π but yeah
I recall the protocol stuff being fairly interesting to wire
I am trying to make some basic collision detection support for Circle and Rectangle, maybe eventually Polygon, but I'll need to find some geometry resources for that one, rectangle and circle I've got an idea of how to do already.
It's funny, I wanted to do that too. You can kind of cheat by asking the shape to draw an x/y and inspecting the pixel π
I implemented it in python first, but I'm curious to see if / how much faster it is if it's in the core API for them. I'm working on a breakout clone that is using vectorio shapes.
It's really cool to see people using it. I had a lot of fun with it. Anyway, best of luck! And if you change behaviors remember to test a lot haha
Thanks again for the insight!
The tick timer doesn't seem to be compatible with sleep at all, since the IDF automatic light sleep doesn't trigger when there's stuff scheduled every millisecond, right now I'm just disabling it when entering sleep and re-enabling it on exit.
Interrupts work in light sleep unless the peripheral is just disabled entirely like most of them are, but I'm not sure if/how you can detect the automatic background wakeups in general, so the main thread is only going to get notified by stuff that sp...
fair enough. hope you folks find something that works well to fill the need.
This change is an initial working implementation of collision detection for vectorio. Specifically it supports Circle and Rectangle only right now, and currently the is_colliding() function has been added to Rectangle only but it accepts either another Rectangle or a Circle to test against. But my intention would be to also this function to the Circle as well so that the test can be done either way.
I wanted to open this up to get feedback before I went further adding it to Circle though...
I do prefer overlaps, and maybe intersects is even more common. is_colliding implies motion, and that's not necessarily true.
the latest commits have renamed the function to intersects() and disabled the vectorio module on the mini_sam_m4 which overflowed it's size with these changes.
Changed intersecting to intersects: I think that's what you wanted?
{ MP_ROM_QSTR(MP_QSTR_intersects), MP_ROM_PTR(&vectorio_rectangle_intersects_obj) },
bool common_hal_vectorio_rectangle_intersects(vectorio_rectangle_t *self, mp_obj_t other_shape) {
bool common_hal_vectorio_rectangle_intersects(vectorio_rectangle_t *self, mp_obj_t other_shape);
Change doc
//| """Return true if this shape intersects (overlaps with) another shape."""
Yes, thank you! The recent commits have changed everything over to intersects.
I've also added the function implementation on the Circle class now. I performed minimal testing only so far, with an updated version of the script above to switch around which shapes are tested, and tested against.
Submitting to include the Waveshare board RP2040 One with Circuit Python. It's essentially an RP2040 Zero clone from the same company, except for the larger flash and the Trinkey-like form factor.
In fact, it's so much of an RP2040 Zero clone that Waveshare doesn't offer a separate bootloader for it, which makes the Product ID something of an issue. When I compiled a .u2if for it, I had temporarily assigned 0x111F for the One , agains...
Thank you! I've been struggling with a lot of code I wish was just python
In fact, it's so much of an RP2040 Zero clone that Waveshare doesn't offer a separate bootloader for it,
The RP2040 bootloader is in ROM, and identifies the same for every RP2040 on any board. So you can't distinguish based on that. To get an official PID for this board, see https://github.com/raspberrypi/usb-pid (explained in https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython/frequently-asked-questions#faq-3130481)
The addition of intersects() function on Circle class pushed a few other devices over the storage limit. The latest commit disables vectorio on all of the ones that failed during the last action run.
It appears the docs build failed too, but it may have been an intermittent issue with the network in the container, or the server that hosts the svg file that dogs build attempts to fetch. I found these warnings in the action log:
WARNING: Could not fetch remote image: https://github....
The addition of
intersects()function on Circle class pushed a few other devices over the storage limit. The latest commit disables vectorio on all of the ones that failed during the last action run.
These failures are not due to overflow, I believe, but instead are multiple GitHub actions network issues. See https://github.com/adafruit/circuitpython/actions/runs/10277146885. I think you should revert https://github.com/adafruit/circuitpython/pull/9483/commits/f11cd0c40507c986838743a6e...
I'm curious about how to tell the difference between those types of actions failures? I noticed this time it seems to have skipped building the ports so it didn't re-attempt any of the builds from last time that didn't succeed.
In the actions log I found a few of them with errors like this: https://github.com/adafruit/circuitpython/actions/runs/10277146885/job/28438883955#step:10:1361 and 20 lines down from here at line 1381 it shows the negative space readout:
1441808 bytes used, ...
It is a mix of actual storage overflows and transient CI failures. The C3 failures look like actual overflow. The nordic failures are not. I was able to see the transient failures easily in the list at the link I gave above: https://github.com/adafruit/circuitpython/actions/runs/10277146885. Some of these even succeeded after retries, but the transient errors still show up in that log.
It's worth considering whether to turn something else off to make things fit on the C3 builds, especial...
I misspoke; I meant to say that Waveshare doesn't offer a separate .uf2 for the One and instead links the file for the Zero.
Being unfamiliar with the process, are there potential issues applying for a product id as someone unaffiliated with Waveshare?
Thanks for the clarification. The README in https://github.com/raspberrypi/usb-pid links to a Google Form. I think you should get Waveshare to ask for a new PID via that form. This issue, https://github.com/raspberrypi/usb-pid/pull/14, was submitted by @EngineerWill, who appears to work for Waveshare, based on their profile. You could contact them and ask them to request a new PID. Maybe the ping of them here will also be helpful.
Your prompting has led me to discover that Waveshare has registered 0x103A as the product id for the One. I will update the files accordingly. Many thanks, Dan!
Ahhh I see the logs for the transient ones now. Thank you. I was confused and only seeing a few of them before.
And that does make sense to me as well to leave vectorio enabled for devices that have a built-in display.
The Build CI / ports (raspberrypi) / board [...] test seems to be tripping over the entry for the flash chip. The product spec on the website lists it as "W25Q32JVSSIQ - 4MB NOR-Flash," which is twice the size of the Zero and it is by that number I refer to it in the .mk file. Again my inexperience is showing, but I knew I wished to avoid the controller being able to 'see' only 2MB.
Use this name for the flash chip. See https://github.com/adafruit/nvm.toml/blob/main/flash/winbond/W25Q32JVxQ.toml
EXTERNAL_FLASH_DEVICES = "W25Q32JVxQ"
CircuitPython version
Adafruit CircuitPython 9.1.0-beta.2 on 2024-05-15; Waveshare RP2040-Zero with rp2040
Code/REPL
import usb_hid
import keypad
import storage
import board
import supervisor
import analogio
from time import sleep
def range_map(x, in_min, in_max, out_min, out_max):
return (x - in_min) * (out_max - out_min) // (in_max - in_min) + out_min
# This is only one example of a gamepad descriptor, and may not suit your needs.
...
Great! Could you now also submit a PR to https://github.com/adafruit/circuitpython-org to add a listing for the board? What to do is described here: https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website
Could you please re-verify with 9.1.1? I don't know if there's anything that would change this, but that helps us to make sure it hasn't already been fixed.
Does that conflict with some other process that might be enabling or disabling ticks?
Do you know what is enabling ticks? In theory it should only be on if used.
so the main thread is only going to get notified by stuff that specifically calls the port wake main thread function.
I think its safe to assume we should wake the main thread when needed. Doing so is required.
What about the keypad and the other activities that happen in the polled supervisor tick? Could we make it...
CircuitPython version
circuitpython v9.1.1 (en_GB UF2) and adafruit-circuitpython-adafruit_funhouse-en_GB-20240806-main-PR9479-7f92099.uf2
Code/REPL
none
Behavior
it gives me Yellow flashing dotstars at circuitpython boot then nothing.
No circuitpython drive shows up and nothing on display.
Description
No response
Additional information
I've tried two funhouses, both erased first then bootloader 0.18.2 then UF2 of 9.1.1 en_GB
...
From marching through the UF2s on S3,
- v9.1.0-beta0 works
- v9.1.0-beta1 does not work
And by "not work" I mean the board doesn't even come up: doesn't show up as a USB device. So probably not just the display change from 2ddae3d. I'm looking now through the changes between 9.1.0-beta0 and 9.1.0-beta1 but wooo that's a lot of files
I'd start by seeing if there are any board-specific changes.
There did not appear to be any board-specific changes between 9.1.0-beta0 & beta1
Please don't change template.md to add search filters that are specific to your board. Instead add your features under the description area.
Following up from Pull Request #1446 to echo support for including "Castellated Pads" and to propose including "Trinkey Form Factor" or similar to denote a board's capacity for direct-to-host machine connection via integrated PCB USB-A plug.
Looks like the ticks getting enabled was probably just some other unrelated code that I didn't notice because I thought they were supposed to be always-on.
I think this might be closer to being ready than I thought!
It seems like a lot of ESP32 boards don't have the alarm module at all though, I wonder how many actually have space for it?
Thank you. I had forgotten about the issue to add castellated pads, but also would like to mark all boards at the same time when adding.
Absolutely makes sense - I'd like to help if that issue has stalled. Thank you for your review!
Add a link to jepler's PyCon 2024 talk, todbot's synthio tricks, and add The Bootloader podcast.
CircuitPython version
Adafruit CircuitPython 9.0.5 on 2024-05-22; Adafruit-Qualia-S3-RGB666 with ESP32S3
Code/REPL
v = 1
for _n in range(30):
l = f'{v:,}'[0:1]
if l == ',':
print(f'{v:,}')
v *= 10
Behavior
,100,000,000,000
,100,000,000,000,000
,100,000,000,000,000,000
,100,000,000,000,000,000,000
,100,000,000,000,000,000,000,000
,100,000,000,000,000,000,000,000,000
,100,000,000,000,000,000,000,000,000,000
Descr...
A driver for Pervasive Displays Aurora CoG chipsets:
https://www.mouser.com/new/pervasive-displays/pervasive-displays-aurora-mb-displays/
My group used these displays for a Circuitpython badge we created, and this driver came from that effort.
The driver uses framebufferio.FramebufferDisplay (very similar to the sharpdisplay module) to interact with displayio. I has support for the 1.44", 2", 2.7", 1.9", and 2.6" sized Aurora EPD products, however I only have the 2" sized EPD so...
Board Waveshare RP2040-Zero was deleted by:
Where file _board/waveshare_rp2040_zero.md was moved to _board/waveshare_rp2040_one.md.
Also, the board Waveshare RP2040-PiZero is not to be confused with Waveshare RP2040-Zero.
This commit gets that fixed by:
- Fixing Waveshare RP2040-PiZero title and name.
- Restoring ...
Thank you for spotting this and correcting the oversight; it's a valuable lesson you've helped me learn here so I can be more careful in future contributions.
@gilded cradle https://circuitpython.org/blinka/waveshare_rp2040_one/ it looks like maybe a circuitpython board was accidentally added as a blinka board?
just ducking in for a moment, forgive me for not looking into it in detail.
I looked for this yesterday and of course it came out after my last PR. :)
That was my PR; I followed the documentation for the Trinkey QT2040 (also a Blinka board). Please see open PRs documented here
Ok, I'm happy to find out I'm mistaken (rp2040 boards usually use circuitpthon) but wanted to mention my impression
Like the Trinkey, it's listed both places, which I understood to be proper; forgive me if mistaken. As someone new to the contribution space, I appreciate that folks are thorough! It helps me learn and improve.
Since we're both unsure I hope someone authoritative can settle it.
This already supports Micropython and shouldn't require massive effort to port. I can help test if anyone's interested in building this.
https://www.seeedstudio.com/Seeed-XIAO-RP2350-p-5944.html
This adds support for the next RP2 microcontroller, the RP2350.
Thanks to Raspberry Pi folks for early access and to @arturo182,
@oberchoo and @SalamCytron for helping with CircuitPython.
It looks like there is a PR for adding it to Blinka, but it's also listed under CircuitPython boards.
Forgot this existed, tested on samd51. Now I have tested every port I have.
There is nothing else to be done from my side.
The SDK doesn't have an official API for it yet. So, we can wait or DIY it.
Disabled it and haven't tried re-enabling it yet.
It compiles but crashes.
Macro argument name should be pio_index not pio_isntance. It ends up not breaking anything because the literal pio_index happens to be what is needed.
It seems like a lot of ESP32 boards don't have the alarm module at all though, I wonder how many actually have space for it?
Is that due to the 4MB flash limit? I think we plan on changing the partition layout with CP 10 so that those boards can have more features like BLE.
I do remember seeing some scattered discussion somewhere about getting rid
of the OTA partition
On Thu, Aug 8, 2024, 3:04β―PM Scott Shawcroft @.***>
wrote:
It seems like a lot of ESP32 boards don't have the alarm module at all
though, I wonder how many actually have space for it?Is that due to the 4MB flash limit? I think we plan on changing the
partition layout with CP 10 so that those boards can have more features
like BLE.β
Reply to this email direc...
Do you know what USB PID they use? Do you have one already?
Thanks! Looks like you'll need to format via pre-commit and then it'll be good to go. https://learn.adafruit.com/improve-your-code-with-pylint/check-your-code-with-pre-commit
@ladyada Want to review since others are out? We can always follow up with more changes too.
did basic feather rp2350 testing
What an exciting release too! Does most of the 2040 code work on the 2350?
Ya, most of it just worked
once the build system could handle a different chip
There are definitely bugs. I just realized there was an additional UART pinout
and the USB host code is crashing
That's a bonus most of it works. Minus the host. Just scanning the PR and was wondering how much would just work while at work today.
No better way to find bugs than to release an alpha π
As soon as people can get a hold of the boards I do not think you will lack testers!
Automated website update for release 9.2.0-alpha.2350 by Blinka.
New boards:
- adafruit_feather_rp2350
- adafruit_metro_rp2350
- cytron_motion_2350_pro
- raspberry_pi_pico2
- solderparty_rp2350_stamp
- solderparty_rp2350_stamp_xl
- vidi_x
- waveshare_rp2040_one
I was just about to add my Stamps, thank you!
Glad I checked first :)
I was just about to add my Stamps, thank you!
Glad I checked first :)
No problem! Please make a PR to pid.codes for the USB PIDs you added.
Yes, I am planning to do that but need to wait for the Stamps to go on sale, that's when I publish the HW designs and can qualify for a PID :)
CircuitPython version
9.1.1
Code/REPL
Adafruit CircuitPython 9.1.1 on 2024-07-22; Adafruit-Qualia-S3-RGB666 with ESP32S3
>>>
>>> import microcontroller
>>> microcontroller.reset()
Behavior
TFTS3BOOT drive appears instead of CIRCUITPY
Description
No response
Additional information
No response
Thanks for adding this Scott.
IMPORTANT!
This board does some pretty weird AXP2101 with the RTC, and claims differently in the docs.
To get all the hw to work, following configuration commands are run after the pmic is loaded:
pmic._aldo1_voltage_setpoint = 3300
pmic._bldo1_voltage_setpoint = 0
pmic._bldo2_voltage_setpoint = 3300
pmic._aldo1_voltage_setpoint = 3300
if pmic._read_register8(24) != 13:
pmic._write_register8(24, 13) # Charge VBackup at 3v3
If the coin cell battery is not cha...
I'm sorry but I can't seem to wrangle sphinx to do what I need. For some reason the second line of the docs comment is being included in the title of the page.
//| class AuroraMemoryFramebuffer:
//| """A framebuffer for Pervasive Displays Aurora E-paper displays.
//|
//| These displays are 2 color only.
Do I need another line break or special character to stop it from doing this?
Hi, can you please help to add CircuitPython support for this board?
https://www.cytron.io/p-iriv-io-controller
Thanks.
CircuitPython version
9.1.1
Code/REPL
Adapted version of Liz's countdown clock for CircuitPython Day 2024, bitmap background + bitmap label that scrolls
Behavior
Image renders about 5 lines at a time, but seemingly randomly out of order and not the whole line at once.
Probably made worse by my use of display.rotation=90
Description
No response
Additional information
No response
It's also incredibly slow once the bitmap label starts being scrolled (but I'd possibly expect/accept that)
Code:
G.zip
Video:
https://photos.app.goo.gl/DLvyEcP4XDUtz9xN8
Still image part way through initial render:
Just realised I'm not using the color converter for the main tilegrid that the default example uses, like this:
tile_grid = displayio.TileGrid(bitmap, pixel_shader=displayio.ColorConverter(input_colorspace=displayio.Colorspace.RGB565))
That looks right to me. Can you share a screenshot of what it is doing? There should be a matching .pyi file somewhere with the Python stub version. That may make it clearer.
This can put TX and RX on additional pins!
Fixed merge conflicts, please validate against RP2350 too.
Maybe it would make sense to move this out of vectorio, or at least out of the Rectangle and Circle classes. If they were separated from those it would mean we could have a single something.cirlce_rectangle_intersects(rect_x, rect_y, rect_w, rect_h, circle_x, circle_y, circle_r) or similar. It wouldn't accept vectorio.Rectangle or Circle directly, but instead just the relevant coordinates and sizes. That way user code can use it with a variety of different objects rather than just Rectangl...
The RP2350 has a new peripheral for a true random generator, it could be nice to make use of it.
I was looking at the latest github build actions version here: https://circuitpython--9488.org.readthedocs.build/en/9488/shared-bindings/aurora_epaper/index.html
However, it seems like its working the way I expect now. I must have been seeing an old cached page on my browser.
@slender iron - WOOHOO!!
Do you have time to test? I just guessed the display settings
found the schematic for the pinout
@slender iron - I may have time tomorrow. Today was teaching DCNextGen Python and CircuitPython π€πΌ
Not yet but I may order a few...
Based on a quick perusal of the 2350 datasheet the 2040 compatible "rosc randombit" generator should work with the new chip but using the new hw module mother be faster or something.
Better yet switch to pico rand from the sdk and delete my "crypto" code from circuitpthon. It will select the right hw mode for generating random bytes
#help-with-git message after stumping into this a few hours ago, i've done a very minimal research and it seems like mypy already has a tool called stubtest that compares hints in .pyi(aka, circuitpython-stubs) with actual code in .py (aka, blinka)
i was thinking of doing a similar thing myself from scratch if it didnt exist yet
think it is worth investigating and perhaps add some testing with it, or at least a "we know these dont match" list
didnt feel like opening an issue or anything, as i dont use either project and dont want to (potentially) get a lot of notifications about the topic π
Update on progress: the system locks up at mp_call_function_0(module_fun); in do_execute_raw_code - looking at the address of the function:
function at: 3f8077f0
and the memory map from the ESP32 technical reference manual:
I suspect that the issue is that the module is loaded into data memory not instruction => system throws exception when hits the f...
there's an inconsistency in the "Get Setup to Add Your Board" page at https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython/get-setup-to-add-your-board in the tutorial for adding a new board -
The following files must be updated. The board_name folder will be your board. The first three must be customized for your board and your board must added to the last:
there are 3 files listed, but not a fourth, as the text implies.
yea, board.c is missing from the list
but it's probably better to submit this to the Feedback? Corrections? link on the left side of the guide page
you don't normally need to edit board.c, unless your board has a display that needs to be initialized or some other special hardware
I think the language is unclear there, since it's talking about setting up a new port, with the port folder and the 4 initial files
ya, I was more looking for guidance than the correction. i'll post something to the feedback link.
i'll probably need to edit board.c, as this board (sparkfun thing plus esp32s3) has an SD slot on the bottom
Ah, I see, my bad
Look on the next page of the guide https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython/initial-configuration
it lists all the files needed
seems like a case of either too much info for the 'getting started' page, or not enough
π
also having trouble with the initial setup - doing the 'make fetch-all-submodules' thing, and got this at the end:
Cloning into '/home/brian42/repos/circuitpython/tools/python-semver'... Cloning into '/home/brian42/repos/circuitpython/tools/uf2'... Submodule path 'data/nvm.toml': checked out '6b678f15e378edce820f2ffdef3286b3e55449e7' remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 fatal: transport 'file' not allowed fatal: Fetched in submodule path 'extmod/ulab', but it did not contain eacb0c9af47f85f5d4864b721c3b28661364e8e3. Direct fetching of that commit failed. fatal: ::endgroup:: Duration: 168.70768673699786 Traceback (most recent call last): File "/home/brian42/repos/circuitpython/tools/ci_fetch_deps.py", line 238, in <module> main(target) File "/home/brian42/repos/circuitpython/tools/ci_fetch_deps.py", line 220, in main fetch(submodules) File "/home/brian42/repos/circuitpython/tools/ci_fetch_deps.py", line 134, in fetch run( File "/home/brian42/repos/circuitpython/tools/ci_fetch_deps.py", line 110, in run subprocess.run(shlex.split(command), stderr=subprocess.STDOUT, check=True, cwd=cwd) File "/usr/lib/python3.10/subprocess.py", line 526, in run raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command '['git', 'submodule', 'update', '--init', '--depth', '1', '.', 'frozen']' returned non-zero exit status 128. make: *** [Makefile:343: fetch-all-submodules] Error 1
I think it's just make fetch-submodules
no all in there
this is a fresh clone of my fork from adafruit/circuitpython:main, FWIW
yes, it has the 'all'
definitely something git doesn't like... running that commandline separately gives the same failure
Similar issue here.
Description:
When attempting to copy the files multisparkline.py, polygon.py, rect.py, roundrect.py, sparkline.py, triangle.py into my CircuitPython device (drive E: named CIRCUITPY), the file becomes corrupted with strange characters, and the following error message appears:
No puede copiar el archivo debido a un error inesperado. Si sigue recibiendo este error,...
Transferred issue to https://github.com/adafruit/circuitpython, because this issue is not related to the particular files.
There are various reasons the copies might be corrupted.
- How are you copying the files? Drag and drop?
- The CIRCUITPY drive may be corrupted due to previously unplugging or resetting the device before a write was complete. Try this in the REPL serial connection. It will erase and reformat CIRCUITPY. Then copy the files agan.
import storage
storage.erase...
CircuitPython version
Adafruit CircuitPython 9.1.1 on 2024-07-22; Adafruit ItsyBitsy ESP32 with ESP32
Code/REPL
import board
import analogbufio
import array
N = 1000
rate = 1000
buffer = array.array("H", [0x0000] * N)
adc = analogbufio.BufferedIn(board.A3, sample_rate=rate)
adc.readinto(buffer)
adc.deinit()
for i in range(N):
print(i, buffer[i])
Behavior
>>> %Run -c $EDITOR_CONTENT
Traceback (most recent call last):
Fil...
got past the above. now, during build:
`brian42@CarasGaladhon:~/repos/circuitpython/ports/espressif$ make BOARD=adafruit_feather_esp32s3_4mbflash_2mbpsram
- Verbosity options: any combination of "steps commands rules", as
make V=...or env var BUILD_VERBOSE
Traceback (most recent call last):
File "/home/brian42/repos/circuitpython/ports/espressif/../../tools/gen_web_workflow_static.py", line 7, in <module>
import minify_html
ModuleNotFoundError: No module named 'minify_html'
make: *** [../../supervisor/supervisor.mk:210: build-adafruit_feather_esp32s3_4mbflash_2mbpsram/autogen_web_workflow_static.c] Error 1`
where is minifiy_html supposed to be? there isn't a file by that name anywhere in the circuitpython tree
Pages
https://docs.circuitpython.org/en/9.1.x/shared-bindings/usb_cdc/index.html
https://docs.circuitpython.org/en/8.2.x/shared-bindings/usb_cdc/index.html
https://docs.circuitpython.org/en/latest/shared-bindings/usb_cdc/index.html
under class usb_cdc.Serial Include
You cannot create an instance of usb_cdc.Serial. The available instances are in the usb_cdc.serials tuple.
However, with
Adafruit CircuitPython 9.0.5 on 2024-05-22; Adafruit-Qualia-S3-RGB666 with ESP32S3
usb_cdc.serialsdoes not exist:
>>> import usb_cdc
>>> dir(usb_cdc)
['__class__', '__name__', 'Serial', '__dict__', 'console', 'data', 'disable', 'enable']
>>> usb_cdc.serials
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'serials'
Is that specific to the build for the qualia board?
I think they are usb_cdc.console and usb_cdc.data
looks like some leftover from an earlier version
Hello and so many thanks for the quick response.
1. How are you copying the files? Drag and drop?
Yes, I download manually the source code and copy/paste to the board's folder, I went file by file because I noticed when copying the whole folder the behavior happens too.
2. The CIRCUITPY drive may be corrupted due to previously unplugging or resetting the device before a write was complete. Try this in the REPL serial connection. It will erase and reformat CIRCUITPY. Then ...
This is how the unit looks when I try to copy the files:
After a short time (or pressing Enter in the Cardputer) it mounts.
Are you using a hub or a direct connection?
Please try a different cable as well.
Could you try CircuitPython 9.0.5 and see if it makes any difference?
Are you using a hub or a direct connection?
Direct connection to the pc.
Please try a different cable as well.
I have another cable and it still happening...
Could you try CircuitPython 9.0.5 and see if it makes any difference?
Sure I will try again, I'm resetting using the command you gave me earlier and try the whole process again and write it here in few minutes.
import storage
storage.erase_filesystem()
Using CircuitPython 9.0.5:
This files are copied without problems.
Now I try to copy the mentioned files.
This has given no errors so far, now I go with the folder on my next step:
ALL FILES COPIED SUCCE...
I also have been messing putting a git repository in this folder... That may have affected this in some way... after i copied a .git folder into the file system the error appeared again...
So 9.0.5 is not better when the .git tree is added?
If you have another computer to try that's rather different (e.g. Mac, RPi, etc.) that would be a useful experiment.
Sorry I do not have a Mac nor RapsberryPi, but I can try tomorrow to replicate whole file copying and file editing process in my dual boot ubuntu GNU/Linux (it's the same pc I run Windows 10) and see what happens.
It blocked again like this
trying to edit the code.py file...
π°
It's only happening randomly at some times... But fortunately the last changes I made it worked.
But for ...
It's a python module. It's listed as a requirement inside of the requirements-dev.txt file https://github.com/adafruit/circuitpython/blob/5f7c42e277a20aef1863aaeadd5464a3e3c2ef67/requirements-dev.txt#L33 It's mentioned, albeit only briefly in this section of the building circuitpytyhon guide: https://learn.adafruit.com/building-circuitpython/build-circuitpython#install-required-python-packages-3086211
apparently i'd missed one of the pip3 installs. now, esp-idf doesn't like what it just installed for itself:
`brian42@CarasGaladhon:~/repos/circuitpython/ports/espressif$ source esp-idf/export.sh
Detecting the Python interpreter
Checking "python3" ...
Python 3.10.12
"python3" has been detected
Checking Python compatibility
Checking other ESP-IDF version.
Adding ESP-IDF tools to PATH...
Checking if Python packages are up to date...
Constraint file: /home/brian42/.espressif/espidf.constraints.v5.2.txt
Requirement files:
- /home/brian42/repos/circuitpython/ports/espressif/esp-idf/tools/requirements/requirements.core.txt
Python being checked: /home/brian42/.espressif/python_env/idf5.2_py3.10_env/bin/python
The following Python requirements are not satisfied:
Requirement 'setuptools<71.0.1,>=21' was not met. Installed version: 72.1.0
To install the missing packages, please run "install.sh"
Diagnostic information:
IDF_PYTHON_ENV_PATH: /home/brian42/.espressif/python_env/idf5.2_py3.10_env
Python interpreter used: /home/brian42/.espressif/python_env/idf5.2_py3.10_env/bin/python`
hrm. something in the pip3 installs tools 72.1... install.sh removes it an puts 71 back on. go figure.
yay... finally... a build. π
I have not been actively writing CP since 6+(?) months, but I still listen to the weekly meeting (not LIVE).
I figured that I could restart working on a library (IS31FL3730) and maybe finish for CP Day (15 August is a day off).
So I try cookiecutter again to have fresh start... this is where I start to understand the last "in the weed" discussion.
So I have to answer 14 questions right, the first time, and if ever I make a mistake I have to start all over again???
I never succeed first time (typo, question I don't know the answer and need to search, ...).
I don't remember the value I used the last time I used cookiecutter for that project (because I did not save the answer).
Apparently the last time I worked on https://github.com/dglaude/CircuitPython_IS31FL3730 is a year before 2024 CP Day. !!!
UPDATE: I found .cookiecutter_replay/cookiecutter-adafruit-circuitpython.json and that seems to contain my answer from previous run (and luckily I only worked on one library on that Pi400 where I started the development).
There is also this that could be of interest: https://stackoverflow.com/questions/60458434/cookie-cutter-whats-the-easiest-way-to-specify-variables-for-the-prompts with ~/.cookiecutterrc file where you can put your frequent answer.
Having a way to save a "per library" file, in the repo of that library, so that re-running cookiecutter 6-12 months later become painless... would be great.
(ping @lone axle)
I wondering if there is interest in having an math.dist() (CPython ref: https://docs.python.org/3/library/math.html#math.dist) in the core?
I had a try at implementing it in this branch: https://github.com/FoamyGuy/circuitpython/tree/math_dist. It only supports 2D, whereas the CPython one seems to allow higher dimensions, and I have done only some minimal "happy path" testing, but it does seem to work correctly and mostly match CPython results with the points I've tested.
I started w...
I have learned about an alternative way to calculate euclidean distance from here: https://stackoverflow.com/a/1401828/507810 This one uses numpy.linalg.norm which it turns out that we already have access to by way of ulab
The syntax to use it is a bit different, needing you to create two numpy arrays, so maybe the math.dist() version could be slightly more convenient to use. But I'm not sure if "slightly more convenient" really makes it worth using up the extra space.
The `nump...
I copied stuff I found in .cookiecutter_replay/cookiecutter-adafruit-circuitpython.json and edited to be in the right format for ~/.cookiecutterrc... nothing automated, but I could keep one such file per library.
Here is how it look and I just have to press Enter to approuve the new default value:
default_context:
target_bundle: Community
github_user: dglaude
author_name: David Glaude
(env) dglaude@pi400-64:~/CC $ cookiecutter gh:adafruit/cookiecutter-adafruit-circuitpython
You've downloaded /home/dglaude/.cookiecutters/cookiecutter-adafruit-circuitpython before. Is it
okay to delete and re-download it? [y/n] (y): y
[1/14] Select target_bundle
1 - Community
2 - Adafruit
3 - CircuitPython Org
4 - test
Choose from [1/2/3/4] (1):
[2/14] github_user (dglaude):
[3/14] author_name (David Glaude):
CircuitPython version
CircuitPython 9.1.1
Code/REPL
not related to code
Behavior
web installer does not work
Description
web installer does not complete since it tries to download a file that does not exist. the correct .uf2 now exists since 2 days but the web install script should be updated accordingly.
Additional information
No response
I see that most XIAO are already supported by circuitpython but XIAO ESP32S3 is missing. in there a reason for this?
The pull request is here. It's waiting for a USB VID/PID from Seeed.
If I understand correctly the board identifies itself with standard USB VID/PID instead of specific ones
I think that lolin boards do the same but are suported.
What is the blocking issue in having a shared VID/PID?
Anyone know if it's possible to get the USB VID/PID from a board somehow? Or do I need to ask Sparkfun for their IDs? (working on board definition for the Thing Plus ESP32S3).
edit: i see the IDs for the jtag device that shows up in Windows for it. i did read that UF2 and CP should have their own PIDs. Should I just put the jtag ones in mpconfigboard.mk?
This is in process after https://github.com/adafruit/tinyuf2/issues/401. There are some files to test in https://github.com/adafruit/tinyuf2/releases/tag/0.19.0. @marcobrianza Could you test those and see if they work for you.
What is the blocking issue in having a shared VID/PID?
The reasons for having unique VID/PIDS are discussed here: https://learn.adafruit.com/how-to-add-a-new-board-to-circuitpython/frequently-asked-questions#faq-3130480
Uhh, I just tried building current master with the t-watch PR.. It doesn't even boot now.. Did I miss a big PR?
All I am getting on a debug build is:
[20:40:55.972] Connected to /dev/ttyACM0
I (624) esp_image: segment 0: paddr=00010020 vaddr=3c1500atency : 0x02 (10 cycles@Fixed)
I (1004) octal_psram: DriveStrength: 0x00 (1/1)
I (1010) MSPI Timing: PSRAM timing tuning index: 5
I (1015) esp_psram: Found 8MB PSRAM device
I (1019) esp_psram: Speed: 80MHz
I (1446) esp_psram: SPI SRAM memory test OK
I (1455) cpu_start: Pro cpu start user code
I (1455) cpu_start: cpu freq: 240000000 Hz
I (1456) cpu_start: Application information:
I (1458) cpu_start: Project name: circuitpython
I (1464) cpu_start: App version: 9.2.0-alpha.2350-19-ge0d326edfc
I (1471) cpu_start: Compile time: Aug 11 2024 20:36:16
I (1477) cpu_start: ELF file SHA256: 8f06be8f5...
I (1483) cpu_start: ESP-IDF: v5.2.1-548-gd58f9ce0b4
I (1489) cpu_start: Min chip rev: v0.0
I (1494) cpu_start: Max chip rev: v0.99
I (1499) cpu_start: Chip rev: v0.2
I (1504) heap_init: Initializing. RAM available for dynamic allocation:
I (1511) heap_init: At 3FCB6B10 len 00032C00 (203 KiB): RAM
I (1517) heap_init: At 3FCE9710 len 00005724 (21 KiB): RAM
I (1523) heap_init: At 3FCF0000 len 00008000 (32 KiB): DRAM
I (1529) heap_init: At 600FF064 len 00000F84 (3 KiB): RTCRAM
[20:41:05.334] Disconnected
Hey, diffs between merge commits can get quite complex and the current implementation doesn't handle them very well. Here, the runs should have been scheduled according to the changes introduced in the 9.1.x branch since it diverged. Hopefully, the following sheds some light on this:
| env_var | commit | ref |
|---|---|---|
BASE_SHA |
https://github.com/adafruit/circuitpython/commit/901dd228cbdb2069e66fae8c2108d44466ab1e7f | 9.1.x |
GITHUB_SHA~ |
https://github.com/adafruit/circuitpython/com... |
In a typical pull request scenario, intersection_update gives intersection of changed files between the following two sets:
- The changes between the current PR commit
headand the last commit that had CI runsbase. - The changes being introduced in the PR.
In this instance, the second part worked as expected, but the first part failed.
Uh, it's the RP2350 PR..
https://github.com/adafruit/circuitpython/pull/9490
So yea, TinyUSB is broken.
Artifacts main-PR9479-7f92099 or earlier work fine.
The alpha release is of course broken too.
Oops
Hi, consider I'm just starting to use circuitpython that is why I was counting very much on the web installer.
anyway I flashed the combined.bin using https://adafruit.github.io/Adafruit_WebSerial_ESPTool/
then I copied to the pseudo-usb-drive adafruit-circuitpython-lolin_s3_mini-en_GB-9.1.1.uf2
circuitpython runs and I just made the onboard neopixel blink.
board.out is the follwing:
Adafruit CircuitPython 9.1.1 on 2024-07-23; LOLIN S3 MINI 4MB Flash 2MB PSRAM with ESP32S3
Board I...
I can also test "lolin s3 PRO" but there is no new release for it
Oh wow, that did get merged quick didn't it
You do need specific ones for UF2/CP and cannot just share the jtag ones. For your own testing you can re-use one, but not for release. I'd ask Sparkfun
Please file an issue. I can look tomorrow
CircuitPython version
As stated, PR #9490 and later, including release alpha.2350, tested on two ESP32-S3 boards.
Unknown as to if it affects S2 or other platforms, I don't have time to test.
Code/REPL
N/A
Behavior
Bootloops, not blinking the led.
Description
Most certainly TinyUF2 related.
Additional information
No response
Thanks!
Np, I was kinda confused, I should have done it alr.
that's why it is alpha
I was confused how nobody caught it before me.
i'm glad it was you and not me. i started thinking i was going crazy, then noticed your post matched what mine is doing. π
Oh I know this. It's the double reset setting in tinyuf2.
// GPIO that implement 1-bit memory with RC components which hold the
// pin value long enough for double reset detection.
#define PIN_DOUBLE_RESET_RC 4
Furthermore, it seems the latest commit there changed that from IO5 to IO4.
https://github.com/adafruit/tinyuf2/commit/da3eaf9949ef33e484106115b16b849034559664
Defining this without the proper circuit leads to this exact behavior.
Suggestion: Transfer this issu...
@brazen hatch ya, that was it for me too. checked out 9.1.1, and my new board def built & is running AFAICT. At least I get the right name in the REPL, so that's a good sign. Now to figure out how to get the UF2 bootloader going... but that's something for another day.
Looks good! Thank you!
Thanks.
Please help to add the new product to the CircuitPython list.
Thanks in advance.
Added dependencies for Cytron IRIV IO Controller frozen library.
Sorry for not adding them during last PR.
Curiously I'm pretty sure I've been running firmware since that change, but to be fair I've no idea the actual last version I ran before 9.x
Curiously I'm pretty sure I've been running firmware since that change, but to be fair I've no idea the actual last version I ran before 9.x
@tyeth The CircuitPython version has nothing to do with this. It's just the bug doesn't happen every time (it's a 80% from what I can tell).
CircuitPython resets correctly, but then the TinyUF2 bootloader performs the double reset check and (in most cases) succeeds, sending you to TinyUF2 instead of CircuitPython.
The TinyUF2 bootloader is als...
The PR is kinda ready, I'll update the branch and fix the merge conflicts in a moment.
Hardware init guide:
<details><summary>PMIC (AXP2101)</summary>
import board
from axp2101 import AXP2101
pmic = AXP2101(board.I2C())
pmic._aldo1_voltage_setpoint = 3300
pmic._bldo1_voltage_setpoint = 0
pmic._bldo2_voltage_setpoint = 3300
pmic._aldo1_voltage_setpoint = 3300
if pmic._read_register8(24) != 15:
pmic._write_register8(24, 15) # Charge VBackup at 3v3
if pmic._read_regist...
I cannot get that one samd board to fit. I don't know what to do from here.
adding Adafruit Vindie S2 board
Ahhh yeah good points, morning brain wasn't thinking bootloaders.
Not sure which versions I'm running on each, but probably 0.18.2 (definitely on this problematic one), and half aware that the bootloaders on circuitpython.org/downloads are often older than latest tinyuf2 releases (most are on 0.18.2).
My INFO_UF2.txt:
TinyUF2 Bootloader 0.18.2 - tinyusb (0.15.0-566-gf1e006d09)
Model: Adafruit Qualia ESP32-S3 RGB666
Board-ID: ESP32S3-Qualia-revC
Date: Mar 22 2024
Flash Size: 0x00...
The TinyUF2 version is recent and correct from the looks of it, so there isn't anything I can do to help you on from here.
I do not have the board to physically test and evaluate against the schematic.
What is the background for this? Is it helping you do something faster?
If a manufacture won't grant a USB PID, you can also request a PID from pid.codes as a third-party adding open source software on a closed source board.
No problem! Thanks for the follow up PR.
<@&356864093652516868> The weekly meeting will occur here on discord in about 1 hour, at the normally scheduled time of 2pm Eastern / 11am Pacific. We look forward to hearing from everyone!
This is reverting a bunch of changes back. You'll want to limit the changed files to the board directory likely.
Undo this change. It fixes the windows build.
I am trying to make intersection detection functionality for arcade / physics style games. (https://github.com/adafruit/circuitpython/pull/9483 is the beginning of this effort).
Some of the intersection functions rely on euclidean distance calculations so I looked into refactoring it into it's own function but went looking and found that CPython already has it.
I do intend for for these intersection detection functions to help me do something faster, specifically being able to check fo...
@FoamyGuy for collision detection you really don't want to use the euclidean distance directly, you want to use the square of the euclidean distance (and also square the number you are comparing it with), this way you don't have to calculate the costly square root.
adding Vindie S2 board - i had done a reversion in my branch on the last PR to get around the espressif boot issue in the newest alpha to test the artifacts and then couldn't quite figure out how to get back π
Cat safely ejected πΌ
the report is from 8/7
I must need to poke it
no newer ones
we hit the 60 day limit
Breakout on the T-Watch-S3 would be lots of fun, looking forward to it!
Thanks @lone axle
thanks for hosting!
Thanks foir hosting @lone axle
Thanks for hosting!
Thanks you, hope everyone has a great week see on on Friday for CircuitPython day!
@lone axle I didn't want to put you on the spot during the meeting, but was wondering if you could do some testing on code-beta.circuitpython.org focusing mostly on USB workflow?
@lone axle It looks like the release of the RFM library worked OK
@brazen hatch what board were you testing with?
Firebeetle 2 ESP32-S3 and the T-Watch-S3
Yes, I'd be happy to. I've got a few things lined up to do after finishing the meeting tasks but will add this to them.
Thank you
Awesome, Thank you.
for the s3 crash, right?
I can test on a s3 tft feather too if you want me to
yup. I tried a debug build on an esp devkit with 16mb flash and no external ram and it worked
trying an S2 now
did you get a crash backtrace?
do you have the idf logging output from it?
normal terminal logs, I sent them a bit before those msgs, one moment
.
S2 w/psram broken too
without a backtrace things are very rough
curiously, this S2 board blinks the led once
it could be resetting via reset_into_safe_mode() repeatedly
the idf logging will tell you why it reset
true, but i'm not getting a usb connection at all
Wait if it's this, regular ESP32 could excibit it too..
I'll go load my m5x
idf logging is over uart so you use a serial to usb converter
the esp devkits have this built in
that's why they have two usb ports
Oh I have one of those boards, lemme load it, it is n16r8
Here is the notes document for next Mondayβs CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and weβll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/13Q0vqnzMAVGwjdVG3-lXMxt62ouymSQ134-o-ROgXBM/edit?usp=sharing
CircuitPython Weekly Meeting for August 19, 2024 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you canβt make the meeting and woul...
SBC compiling go brrrr
ok, I think n32r8 shows the issue
ok, my tlsf change is the issue
not sure why it causes the hang
Yea watchdog timeout reset...
rst:0x10 (RTCWDT_RTC_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
I'm going to get lunch. will push a fix later. I suspect it is writing off the end of psram
Enjoy your break, i'll go back to watch app making, if you need me to test anything else later, ping.
thanks!
this is what my watch is running: https://gist.github.com/tannewt/6240315a92746796f663d80289c4f4c9
I have a full touch tui app alr with reusable elements. You might wanna try it when yours arrives.
Though, I do not have notifications yet..
I also have implemented power states.
It clocks down to 40mhz while disconnected from wifi, 80mhz if connected.
Dimming based on accelerometer and touch.
It gets about 10 hours only though, so I still have more work to do.
I might need to actually consider deep sleep since we have interrupt pins.
The WIP package is here, pushing code constantly.
https://github.com/beryllium-org/twm
I'd advise to at least steal code.
nice! I'll keep an eye on it
The RP2350 branch brought in a bug via TLSF.
Adds an N16 variant of the espressif devkit that was used in testing.
Fixes #9508
It just worked after adding a macro check alongside RP2040 check.
Also, update TinyUSB.
Fixes #9492
It looks like there is an old leftover README.txt file in the Adafruit Bundle repo: https://github.com/adafruit/Adafruit_CircuitPython_Bundle/blob/main/README.txt which references a VERSIONS.txt file that doesn't currently exist.
Is there any reason to keep this file? The "real" content of the readme is inside of README.rst
@lone axle I think that may end up in the zip files
I think that VERSIONS.txt is autogenerated
Ahhhhh, thank you. I do see it in the zipped bundle. Circup has spoiled me, I haven't actually downloaded and unzipped a bundle manually in a while π
Where is the best place for feedback on the new beta editor?
I seem to be having an issue where saving a change to code.py from the editor is causing it to get broken somehow and always report OSError: [Errno 5] Input/output error
probably an issue here: https://github.com/circuitpython/web-editor
If I then go into pycharm and make a "nothing" change like add then remove a space and then save the file it will run successfully, but modifying in the web editor and then saving is always leading to that error. I'll try a different device as well.
@lone axle you can add to https://github.com/circuitpython/web-editor/issues/229. I wasn't able to reporduce the exact issue, so maybe you can add to it. I just reopened it.
It was crashing due to memcpy being left on the flash. Core 1 can't use code from flash because it may run during a flash operation that core 0 is doing.
Fixes #9493
Tested here too.
CI is stuck on one board. The runner seems to have hang.
I think it would make sense to add for completeness. Useful small addition to Math rather than using NumPy
Curious what the difference in performance comparing squares **2 vs squareroot **0.5?
Enjoying the progress @FoamyGuy
@devout jolt want me to make a board def for the sparkfun board and then you can test it?
hey guys who can i talk to about the si5351 lib
Sure! I did some prelim testing of it with the Pico 2 image. AFAICT synthio crashes π (was going to characterize it a bit better and submit an issue)
uh oh! does it have swd pads?
it does not appear to
k, file an issue and I can debug with my feather
no wait, I lied. found them
the psram may not be configured correctly
Go ahead and ask about it. A specific question will be easier to answer
what information are you looking for. PSRAM chip is APS6404L-3SQR-ZR. QSPI with all four data-lines ran
(oh oops, not to me)
@devout jolt
changes are here: https://github.com/tannewt/circuitpython/tree/sparkfun_pro_micro_2350
Looks good at first glance
bryan from SF got right back to me with a PID too!
try doing b = bytearray(1000000) and see if it crashes
where would I send a conversion of the si5351 setup that works for circuitpython vs a c ino ?
does not crash
nice!
that's speedy! so glad we can support this before CirPyDay
I fully expect crashes when we try to DMA from psram
perhaps that's why audio/synthio is crashing
Β―_(γ)_/Β―
I've also been getting a few crashes like this (both with this firmware and the Pico2 firmware):
You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Hard fault: memory access or instruction error.
Please file an issue with your program at github.com/adafruit/circuitpython/issues.
Press reset to exit safe mode.
Is this known behavior?
yep
These are extra and shouldn't be translated. I'll remove them in another PR that will be merged into this one by weblate.
The two checks on self->type should be impossible to hit so they are removed. Switch to Invalid ... for two others.
CircuitPython version
Adafruit CircuitPython 9.2.0-alpha.2350-6-gf064354648-dirty on 2024-08-13; SparkFun Pro Micro RP2350 with rp2350a
Code/REPL
import board, audiocore, audiopwmio
audio = audiopwmio.PWMAudioOut(board.D0) # or any GPIO
wave = audiocore.WaveFile("laser2.wav")
audio.play(wave)
while True:
pass
Behavior
As soon as audio.play() is run, board resets.
Description
Playing a RawSample from RAM works, e.g. this does not...
thanks! I totally expect bugs like this as folks get hardware and start using it
board.STEMMA_I2C pins are swapped. Should be:
#define DEFAULT_I2C_BUS_SCL (&pin_GPIO17)
#define DEFAULT_I2C_BUS_SDA (&pin_GPIO16)
Files look good! Please squash the commits together so that it is less than 21. Thanks!
I think this would be fine to add under MICROPY_PY_MATH_SPECIAL_FUNCTIONS.
@devout jolt you are saying what it was already set to
No, I don't think so. i2c = board.I2C() does not work. https://github.com/adafruit/circuitpython/blob/5dc5129ef77761b3104836da5fd10017dba6216e/ports/raspberrypi/boards/sparkfun_pro_micro_rp2350/mpconfigboard.h but SCL is pin 17, SDA is pin 16
ah! I think I was looking at the 2040 file
@devout jolt are you debugging the audio crash?
No I have other commitments today starting at 11a. Just enough time to try out some stuff
I'll take a peek now before lunch with a friend
The only thing I see that could possibly be disabled is CIRCUITPY_PS2IO..
Honestly, I'm not sure I want to add sample number configuration as an API. I'd be ok if the ESP did multiple samples internally but adding an API impacts all ports (as you see) and all ADC drivers. It is backwards compatible but any code that starts using it won't work elsewhere that hasn't added it.
Multiple samples can be taken from Python too if you really want to too.
Sure, it's new api, but something that arguably should have been there from the start.
If you need precision you kinda have to take multiple samples.
Taking them from python is fine, but python is notoriously slow on for loops.
This is something not so complicated, that passes on the burden to the underlying core.
but any code that starts using it won't work elsewhere that hasn't added it.
Yea, but how often is an application developed and it's expected for it to work on earlier ...
Sure, it's new api, but something that arguably should have been there from the start.
If you need precision you kinda have to take multiple samples.
analogbufio can be used to take multiple samples at once.
Taking them from python is fine, but python is notoriously slow on
forloops.
This is something not so complicated, that passes on the burden to the underlying core.
It is simple but likely to not be used. (We've gone 7 years without it.) Furthermore, it has the cod...
@devout jolt looks like the DMA interrupt isn't working correctly. I'm still debugging why
adding Vindie S2 board def
hasattr can't check for a kwarg.
It's an arg and an attribute, it can be set during creation or after.
adc.sample_size = 65535
So the check would be: hasattr(adc, "sample_size").
In either case, i'll close the PR. It could probably be optimized to fit, but if analogbufio can do it then it's redundant.
CircuitPython version
n/a, don't have the board yet
Code/REPL
import board; i2c = board.I2C()
Behavior
What I expect one would see:
>>> import board; i2c = board.I2C()
Traceback (most recent call last):
File "", line 1, in
ValueError: Invalid pins
Description
#define DEFAULT_I2C_BUS_SCL (&pi...
@devout jolt got time to test?
Yep in about 40 minutes
π
CMSIS-style is broken in pico-sdk 2.0.0.
config_autogen is less used in SDK 2.0.0 so remove everything but the rename_exceptions header. It is guarded internally by LIB_CMSIS_CORE so we can leave it.
Fixes #9517
pro micro 2350 build with fix
Yep audio (WAV and synthio) seem to work great on RP2350 now. Thanks!
Confirmed that #9520 fixes this issue.
lotsa failures due to #if !PICO_NO_HARDWARE, with PICO_NO_HARDWARE not defined.
Sorry - I don't understand what you mean by "conversion".
CircuitPython currently supports two sleep modes: Light sleep and deep sleep. Given the specification of the two existing sleep modes, and the capabilities of many microcontrollers supported by CP, I think there is room for one more sleep mode, which would have a clear benefit. Here is my rationale:
- Light sleep promises to keep background tasks such as WIFI, BLE, audio playback, etc alive. These promises make it hard to actually save any power with light sleep. This is even stated in the...
Have you tested anything of this? For a POC, this could be tested without an API change just to see if it is worth it. If you have any code to test, I would be happy to give it a try.
As a side note: there are currently a few issues open regarding sleep-modes (e.g. #9464 or #8977) so IMHO it would make more sense to fix the existing issues first with the existing sleep-modes before comparing results with a new third one.
I have no idea what's going on in my thing I did not approve of this I don't know what is this Or who I'm at work @GitHub
- [ ] I[u see eyes**```
- [ ] ```**]()π«₯π«₯π«₯
The circuitpython-stubs are based on doc comments (//| ... ) and dont get checked in any way against the actual logic exposed to the VM, right?
Mostly, im "worried" about using them to check whether blinka adheres to the APIs naming/typing
For example, i currently dont know if the readonly properties in here are blinka protecting them "for no reason" or the stubs not marking them as such π
The original light-sleep/deep-sleep distinction was based on a misinterpretation of what was preserved in Espressif light sleep. In retrospect, we might have just dropped light sleep. As you mentioned, "Light sleep promises to keep background tasks such as WIFI, BLE, audio playback, etc alive.", which is not necessarily all that useful. So redefining light sleep as RAM-preserving, but not activity-preserving, might be worthwhile. I am not sure that many people even use light sleep now, as...
I also agree with this proposal.
A simple blocking statement that does whatever it can in each port to lower the power usage and only monitoring an interrupt pin or alarm.
In many applications, you may end up waiting for hours, but then have to respond immediately.
Yay! Glad that was the only issue
gonna try and update to idf 5.3 today
Ok @dhalbert. Now it builds
We're revising the metro anyway for the 80-pin chip so we'll fix this then.
Has merge conflicts now.
@ladyada just checking on your testing on this.
My concern with making a light sleep that doesn't preserve activity is that some object state won't be preserved across the light sleep. This will be confusing and it won't be clear what is impacted.
If light sleep was smarter, then user code could shut down wifi and audio itself before sleeping and then restart it afterwards. That'd be clearer and fit in the existing API.
ugh i dont like Dx names that dont match IOx names, because arduino doesnt do remapping, it will confuse people. just stick to IOx when the 'D' name is not the same please
ditto for D13, D12, D11, D10
D names are there so code is portable. When printing out the pin object, the top name will be used. Only dir(board) will show the D names too.
oki thats fine then
On Wed, Aug 14, 2024 at 1:50β―PM Scott Shawcroft @.***>
wrote:
@.**** commented on this pull request.
In ports/espressif/boards/adafruit_feather_esp32c6_4mbflash_nopsram/pins.c
https://github.com/adafruit/circuitpython/pull/9475#discussion_r1717341366
:@@ -66,18 +68,15 @@ static const mp_rom_map_elem_t board_module_globals_table[] = {
{ MP_ROM_QSTR(MP_QSTR_IO7), MP_ROM_PTR(&pin_GPIO7) },
...
which code are we trying to make portable? Is it Feather code that assumes the SAMD/etc numbering?
Yes, any code that assumes the standard feather pinout. https://learn.adafruit.com/adafruit-feather/feather-specification#pin-naming-3096825
Little bump π
I recently discovered that I can't communicate with the ESP32-C3 based controller via serial port bypassing REPL. It's not the most convenient thing in the world! I think I'll have to swap out the ESP32-C3 for another board.
Did you both load CircuitPython via esptool? Or the uf2s from circuitpython.org/downloads?
I independently came up with something very similar to https://github.com/adafruit/circuitpython/issues/673#issuecomment-616831705 from @Tasm-Devil switching the transmit pin between digital out (for Break + Mark-after-Break) and uart (for start condition + data)
That works on the ESP32s3 I use.
Notable difference is that time.sleep has a minimum increment of 1ms. to asking it to sleep 8uS for the Mark-after-break ends up being really 1ms. But initializing the uart takes more than the...
Did you both load CircuitPython via esptool? Or the uf2s from circuitpython.org/downloads?
I was using the UF2s, after I upgraded the TinyUF2 bootloader to latest (18.2 at the time)
How can one use the keyboard from the CircuitPython program? E.g. if I just try to manually create a DemuxKeyMatrix object, CircuitPython justifiably complains that "KB_A_0 is in use". Indeed, the keyboard has been configured for scanning at board initialization time in this commit.
Is there a way to get a hold of the event queue the keyboard events are being pushed by the pre-initialized object? Alternatively, is there a way to deinitialize the keyboard scanner (and free the pins) so that...
How can one use the keyboard from the CircuitPython program? E.g. if I just try to manually create a DemuxKeyMatrix object, CircuitPython justifiably complains that "KB_A_0 is in use". Indeed, the keyboard has been configured for scanning at board initialization time in this commit.
Is there a way to get a hold of the event queue the keyboard events are being pushed by the pre-initialized object? Alternatively, is there a way to deinitialize the keyboard scanner (and free the pins) s...
Hi, do we have any option to access translations that CircuitPython uses inside .py files?
I am 95% sure the answer is no. The translated language is compiled in at build time. There is not enough room to store all the translations in the build.
Makes sense, so if a translation is used for a const in core module, then is should be accessible for the given language, am I right?
I want to add strftime to adafruit_datetime and I am looking for a way to get translated months and days names. Getting them from CircuitPython installed on the board seems logical, as the uf2 files are already localized.
Hmm that I'm not sure on but may be possible. I don't see the months or days in the translation file in a quick check.
Added support for 2 of my new boards:
OMGS3
https://unexpectedmaker.com/omgs3
RGB Touch Mini
https://unexpectedmaker.com/rgbtouch
I am not sure that many people even use light sleep now, as it's not that useful.
@dhalbert : I am using it in all my battery-based projects, at least for RP2040-based boards replacing time.sleep() with light-sleep. It saves about 30%.
Light-sleep is currently not fully activity preserving. One thing I noticed is that driving a ST7789 with backlight set to 0.7 fails during light-sleep, presumably because of the PWM not working as expected.
I didn't realize the keys are accessible via stdin (just curious, where in this commit is this functionality hidden?)
I do not think this would be enough, though. I'm trying to use the keyboard as a sound controller of sorts and would like to get access to individual key up / key down events. Would that be possible?
If not now, could the board_keyboard object be somehow exposed as board.KEYBOARD to the Python code here?
I didn't realize the keys are accessible via stdin (didn't guess by just looking at the code that
board_serial_xxxdoes that).I do not think this would be enough, though. I'm trying to use the keyboard as a sound controller of sorts and would like to get access to individual key up / key down events. Would that be possible? If not now, could the
board_keyboardobject be somehow exposed asboard.KEYBOARDto the Python code here?
How is it set up
The keyboard is set up l...
This might be completely unrelated, but I was also debugging why my nrf draws around 0.5-2 mA in deep sleep. I had detachted the USB data connection, so I was measuring true deep sleep and not fake deep sleep. My mistake was that while I had disconnected USB data, USB power was still connected. The mcu appears to draw ~1mA from VDD in sleep mode if VBUS is at 5V.
If I detach VBUS, I get ~ 2Β΅A deep sleep with only time alarms and around 20 Β΅A with a pin alarm active.
I see, thanks for the detailed write-up.
Having access to individual key-up/key-down events is pretty important to be able to implement any sort of game-like interaction, however (which, for my personal purposes, is way more important than the built-in terminal. Neither do I want to be able to ctrl+C out of the uploaded program).
It would be nice then, if we could come up with a slighly looser integration here. Either of the following would work:
- Ability to disable the built-in key...
CircuitPython version
-
Code/REPL
-
Behavior
Description
No response
Additional information
No response
There's a pin named IO14 for the Feather ESP32-C6, but it's marked 12 on the silkscreen so was sticking in a PR to rename IO12 matching the other silkscreen pin naming (IO pin names), but not quite sure how I verify the GPIO name is correct as there is no PCB repo / guide yet. It's set as GPIO14 currently:
https://github.com/adafruit/circuitpython/blob/main/ports/espressif/boards/adafruit_feather_esp32c6_4mbflash_nopsram/pins.c#L57-L58
This closes #9523
Hey CircuitPython Networking folks: We've created a new guide to help people with networking in CircuitPython: https://learn.adafruit.com/networking-in-circuitpython - We know that it isn't a baby steps guide or that it completely lets one know the differences between when you need to use requests vs connection_manager vs both but it's a start.
I'd like your help. While the guide is 13 pages, it likely needs to contain more. It needs to be unambiguous and be sure it explains things and not just show examples.
If you'd like to help, please email me anneb(at)adafruit . com with your constructive suggestions. If you're busy, it can wait a few days, as long as the community works to get this right. I know we can get to a guide that addresses the needs of beginners and seasoned folks. Thanks!
@tyeth Did you see #9475? This was merged into 9.1.x, but is not yet in main.
Closing this, I didn't check the reverse of the board which clearly labels the pin IO14, the top side just says 12 and is next to many pins with more space for silkscreen and include the IO prefix in label
Closing this, I didn't check the reverse of the board which clearly labels the pin IO14, the top side just says 12 and is next to many pins with more space for silkscreen and include the IO prefix in label
I'd love to figure out how we can do translations for library code!
I gotta get back to merging translations first
The bundle action was suspended too. We should move the daily reports and bundle updates to the circuitpython repo
@willow totem @devout jolt Does this work on funhouse for you?
1sec
nah same flashing yellows. Oooh wait, reset and got same, and now it's self reset and cleaned up filesystem and seems to have booted. Success!
Yes. With that firmware, my FunHouse properly negotiates as a USB device and CIRCUITPY drive is present. Even the code that was on it was still there.
nice one Scott, what was it that bit us?
oh classic
and the deinit would hang because we lock them but don't release
aha, thanks for the details!
oh but hmmm.... no ulab?
maybe a debug build. gotta drop so much
gotcha
gotta make space for logging
The Funhouse problem was due to a locking change for SPI. The Funhouse is one of a few boards with DotStar status LEDs that use SPI and have this bug.
I thought it might be IDF related so I updated it first. :-)
Fixes #9486
@tulip sleet just pushed the IDF update PR. It'll likely overfill some boards but I did build one of each chip locally first
π should i do some smoke testing or have you done that already? After this, maybe make alpha.2351?
maybe i'll test a tft feather
gonna eat while the CI churns
CircuitPython version
adafruit-circuitpython-bundle-9.x-mpy-20240730
adafruit-circuitpython-seeed_xiao_esp32c6-en_US-9.1.1.bin
seeed xiao ble
Code/REPL
from adafruit_ble import BLERadio
radio = BLERadio()
print("scanning")
found = set()
for entry in radio.start_scan(timeout=60, minimum_rssi=-80):
addr = entry.address
if addr not in found:
print(entry)
found.add(addr)
print("scan done")
Behavior
Auto-reload ...
got some help in discord, tried this sample code
https://github.com/adafruit/Adafruit_CircuitPython_BLE/blob/main/examples/ble_simpletest.py
got this output
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
scanning
ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0xc (SW_CPU),boot:0x1f (SPI_FAST_FLASH_BOOT)
Saved PC:0x4001975a
SPIWP:0xee
mode:DIO, clock div:2
load:0x40875720,len:0x124
load:0x4086c410,len:0xbe0
load:0x4086e610...
after hitting reset and reconnecting serial, running the same sample code,
i saw meaningful output:
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
scanning
<Address 66:df:81:01:b7:62> <Advertisement flags=<AdvertisingFlags > >
Advertisement(data=b"\x0e\xff\x03\x37\x51\x10\x7a\x87\xdb\x36\xcd\xbc\x36\x54\x56\x02\x01\x18\x03\x0...
I think #9526 also fixes this. It may be an IDF bug.
I'm working on a version of Circuitpython for the Xiao ESP32S3 Sense and I had the same problem. In my case, I have a machine with Dual Boot (Ubuntu 22.03 and Windows 11). I carried out all the customization of the source files in my fork on Github and cloned the Adafruit repository. Then, on Linux, I moved the custom files and compiled the firmware.
When I start the machine in Linux, I have the CIRCUITPY drive mounted and read and write access. But when I boot into Windows, I don't have acc...
CircuitPython version
Adafruit CircuitPython 9.1.1 on 2024-08-16; Seeed Xiao ESP32-S3 Sense with ESP32S3
Code/REPL
>>> f = open('settings.toml', 'w')
f.write('CIRCUITPY_WIFI_SSID = "wifissid"\n')
f.write('CIRCUITPY_WIFI_PASSWORD = "wifipassword"\n')
f.write('CIRCUITPY_WEB_API_PASSWORD = "webpassword"\n')
f.close()
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 30] Read-only filesystem
>>>
Behavior
Can't save any...
- Exposed the DemuxKeyMatrix object as board.KEYBOARD.
- Implemented the ability to not have the keyboard assigned as serial input (sys.stdin) by specifying M5STACK_CARDPUTER_KEYBOARD_SERIAL=0 in settings.toml. This enables custom handling of individual key up/key down events.
For context, see discussion in https://github.com/adafruit/circuitpython/commit/090f330ad5e30acf2030900b45386d784cbcc1da
Ok guys, there is some issue with the firmware generation process. Both firmwares generate a read-only CIRCUITPY. But REPL works, and the pinout are correct. There is something wrong with TinyUSB? Tested on my local machine with dual boot (Ubuntu/Windows) and a Amazon virtual machine (also Ubuntu).
See if this firmwares works for you, ok?
https://github.com/djairjr/Seeed_Xiao_ESPS3_Sense_Circuitpython
Tested workaround: manually install tinyuf2 bootloader at https://github.com/adafruit/tinyuf2/releases and copy .uf2 files also generates a unusable readonly CIRCUITPY (not show on windows system).
The read-only is by design. CIRCUITPY is read-only from your code unless you remount it as read/write in boot.py. It is read/write from the host computer that has it mounted as a drive. This is to prevent corruption of CIRCUITPY if both the host computer your code try to write to it at the same time.
This is not true for boards like C3, C6, and plain ESP32, which do not present a CIRCUITPY USB drive.
The problem you describe with CIRCUITPY not appearing on your Windows machine is often due to third-party software that is interfering with the mounting of CIRCUITPY. See https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting#circuitpy-drive-does-not-appear-or-disappears-quickly-3004181
@djairjr Let's discuss in #9528.
It's great that you've already written some code to flesh out how this will work.
I do like the idea of controlling the keyboard mode with a config variable. Have you tested this code?
However, I wonder if there's a method to toggle whether the serial driver takes events from the queue.
One that can be controlled by the program.
I'll look over this tomorrow when I have some time.
Are you on the Adafruit Discord?
You'd be able to get support there, and you'd be able to send me a DM i...
No. It was not the problem.
I am using many other boards here. They all work.
When I am in linux, using fsck I got a message saying something about a dirty byte.
Again, in my Ubuntu boot, the CIRCUITPY is mounted as usual.
In Windows, only Serial port appears, but no Disk at all.
Thonny was able to access files in Circuitpython File system. But the Windows Explorer no. This happens only in windows.
If you reformat the filesystem in the REPL, does it fix the problem?
import storage
storage.erase_filesystem()
You can join us in discord https://adafru.it/discord, #help-with-circuitpython, if you would like some real-time help.
It's been a long time since I compiled Circuitpython directly from source. The last time was with Seeed's other card, the RP2040.
I have several boards here, including some ESP32C3, which are working perfectly using WebESPTool and the firmware available on your website.
I'm trying to make the Seeed Xiao ESP32 S3 Sense board compatible with Circuitpython, a project I had already started some time ago.
My system compiles the firmware properly, without any errors. And I can save the .bin ...
[adafruit/circuitpython] Pull request op...
Sure. Joined the discord, pinged you there.
I did of course check that the thing I wrote behaves as intended.
@tannewt Just retested my qualia project on #9526
Still seeing the glitch described here, and the weird scanlines in #9498
This is fine. Would you prefer to do this dynamically instead? We may be able to add functions to board to do it.
@tulip sleet this is ready for a look: https://github.com/adafruit/circuitpython/pull/9526
Bundle failed with "Unsupported updates": https://github.com/adafruit/adabot/actions/runs/10414944996/job/28844693549#step:7:20
Testing:
Metro ESP32-S3: simple BLE and WiFi HTTPS requests worked fine.
FunHouse: originally I couldn't get it to come up with serial or CIRCUITPY. I erased the FunHouse and reloaded the UF2 bootloader, and at first it was fine. But then it failed again. To reproduce, erase and load .bin, or load TinyUF2 and the .uf2. It will come up, but if you do import wifi, it hangs or crashes, with no output. If a settings.toml is present, the status line will come up with No IP, and a...
More testing:
Metro ESP32-S2: this has the same ESP32-S2 WROVER module as the FunHouse. Erased completely, loaded .bin. import wifi does not crash. Copied over settings.toml with CIRCUITPY_WIFI_*, values, comes up, and reports an IP in the status line.
So again the problem seems to be FunHouse specific.
I could go ahead and merge this and you could keep working on FunHouse, if that makes sense.
@slender iron weird -- FunHouse is still failing when wifi is started. ESP-IDF 5.3 seems fine for other boards I tested.
Ok! I can look later or next week. I'm in bundle fixing land now
I can't get storage.disable_usb_drive() to work. I'm running CircuitPython 9.x on a Pi Pico and I've got a boot.py with the following code:
import board
import digitalio
import storage
button = digitalio.DigitalInOut(board.GP24)
button.direction = digitalio.Direction.INPUT
button.pull = digitalio.Pull.UP
if button.value:
storage.disable_usb_drive()
But regardless of what I try, the USB drive inevitably pops up. Any ideas what could be the problem?
I think I will go ahead and merge to get 5.3 in, since the other boards are still working, and further testing will happen on 5.3. Does that make sense?
Fine with me! It's an alpha
will do, and will leave the FUnHouse bug open
Merging to get the other changes in, and @tannewt will look at #9486 again.
@tulip sleet Can you review https://github.com/adafruit/Adafruit_CircuitPython_PyPortal/pull/136 ? It'll fix the bundle
(Though I'll have bundle script changes too)
@devout jolt which pimoroni 2350 boards do you have?
I think I'll do board defs during my deep dive
I have Tiny 2350 and Pico Plus 2
Would you prefer to do this dynamically instead?
This is a reasonable idea. I didn't go for it immediately as I was not sure what would be the best interface for it and simply tried the simplest thing that came to mind first.
Intuitively it currently seems to me that a reasonably clean solution would be to have an M5StackCardputerKeyboard class, exposed as board.KEYBOARD, which could a DemuxKeypad with the extra functions:
- attach_serial/detach_serial that would enable/dis...
@devout jolt plus2 with (hopefully) psram
Yep!
π
For some reason, my old USB_VID and USB_PID values does not compile a correct firmware. This one, make a USB drive available.
cc: @todbot @ZodiusInfuser @Gadgetoid
Draft PR for this is here: #9532
My impression is that you still need to ask Seeed for a PID, is that right? This one was just chosen by you.
We've changed the format of the headers of these files. Check a file for another board and copy that.
We've changed the format of the headers of these files. Check a file for another board and copy that.
I just emailed someone I know there about USB PIDs for their boards. Will keep this in mind too.
Hi - the files all need new-style headers.
Remove OTA partition from Espressif 4MB builds to make room for BLE, and then expand the firmware partition.
This requires new bootloaders, I assume. We need to come up with a transition plan.
Hey @slender iron , I was going to add the links to the modules lists on boards pages (after imaginging they existed earlier π ). I've got that sorted but the frozen modules are more tricky, mainly removing adafruit_ from the name and sticking after https://docs.circuitpython.org/projects/ works, e.g. https://docs.circuitpython.org/projects/display_text but not for connection_manager as it's page is without the underscore. Can RTD do aliases to fix that or do I need a more cunning plan?
This turns the library list on board pages into clickable docs links.
It supports having class links like busio.SPI and frozen modules.
There were a few modules that don't have docs (_asyncio for example), and one frozen module (adafruit_connection_manager) that doesn't follow the expected path, but ignoring that it's working well.
Tested on the pico page (for normal modules), and pyportal (for frozen modules)
My circuitpython day contribution π
I experienced really slow updates on Qualia w 2.1 round display when using any display rotation.
Even calling rotation=0 seemed to cause slow loading if I recall.
This PR decreases the power consumption of sleep modes with active pin interrupts by ~10x by using the SENSE feature, when possible.
"Normal" GPIOTE interrupts increase sleep current consumption by ~20Β΅A, but using SENSE (aka PORT events) instead can reduce this to ~2Β΅A.
This behaviour is documented as an Erratum here and discussed for Zephyr [here](https:/...
You're right @dhalbert. I took the data from that Espressif board and put it in the mpconfigboard.mk header. It's not the definitive solution, but it worked. I contacted the folks at Seeed again. They created a wiki with several tasks and I had taken over this a while ago.
I'm checking the pinouts for the camera and will make some changes to the naming. There were two pins missing to be addressed and I will use the CAM_ prefix before the pin number. I will try to make some equivalence between the nomenclature used in Arduino.
I think it would be best to make the pin names consistent with https://github.com/adafruit/circuitpython/blob/main/ports/espressif/boards/adafruit_esp32s3_camera/pins.c#L60-L73 (and maybe also include that data tuple in board)
Okay, guys. I have now got a working version for the board. I tested the camera with the Xiao Round Display and everything works great.
The problem with the USB_PID and USB_VID still needs to be addressed and this is preventing my changes from being included.
But I'll see about that with Seeed.
Running USB VID/PID and Creator/Creation ID Duplicate Checker...
Duplicate VID/PID usage found!
- VID/PID: 0x303A:0x80D1
Boards: seeed_xiao_esp32_s3_sense, unexpectedmaker_tinys3
If yo...
CircuitPython version
Adafruit CircuitPython 9.1.1 on 2024-07-22; Adafruit Feather ESP32S3 No PSRAM with ESP32S3
Code/REPL
import time
import busio
import board
from micropython import const
from adafruit_seesaw.seesaw import Seesaw
BUTTON_X = const(6)
BUTTON_Y = const(2)
BUTTON_A = const(5)
BUTTON_B = const(1)
BUTTON_SELECT = const(0)
BUTTON_START = const(16)
button_mask = const(
(1 << BUTTON_X)
| (1 << BUTTON_Y)
| (1 << BUTTON_...
If I run the I2C scan (https://learn.adafruit.com/scanning-i2c-addresses/circuitpython), it does see the device at 0x50, but can't "speak" to it
It's hard to be sure without looking at the signals on the bus, but it looks like the seesaw device is crashing leaving the SCL line pulled low, that's why you get a timeout when the CircuitPython side waits on clock stretching, and it fails the test for pull-up resistors (because the line is kept low by the other side). Might be some combination of a bug in the seesaw device code, and different timings on different ports?
Try setting the I2C busio frequency to 400000:
Replace:
i2c_bus = board.STEMMA_I2C()
with
import busio
# ...
i2c_bus = busio.I2C(board.SCL, board.SDA, frequency=400000)
There's a thread here: https://forums.adafruit.com/viewtopic.php?p=978381 that suggests that at least in some circumstances, that helps. That thread was about an RPi (not Pico).
As for the motor controller you mentioned in your forum thread...
@brazen hatch I'm not having any luck flashing the Lilygo T-Watch 2020 v3 from circuitpython.org. CP flash/bootloader organization seems like black magic to me so I'm probably doing something obviously wrong but the first thing I did was flash the combined.bin for the S3 chip but I realized there isn't a UF2 for the watch, so I then flashed the circuitpython.org BIN file to address 0x0000 but that leads to a boot loop "invalid header". I've tried erasing the flash before attempting the firmware and I can get the default flash back on the device, but no luck with CP. Any pointers π?
That board is ESP32, not ESP32-S3, so no tinyuf2.
You could try to set -fm qio and -ff 80m
but idk if the flash params are the same as in the S3 version
Oh, I didn't look close enough π, I thought the circuitpythong.org binary was from your recent PR. I just got the S3 version and was trying to flash that, I guess I need to go to the artifacts.... Thanks!!!!
oh lmao, no .org is not updated yet
wait one moment
here is the s3
The uf2 should also work, i'd give it another try with the boot button held down
if you have trouble, you could also try from CP with microcontroller.RunMode
it's a tricky board to reset
I have tried with your code, sadly shows exactly the same behavoir.
@deshipu but with arduino code it seems to work fine. This is why i thought, it would be more on the circuit python side, as the hardware is the same, just running a different code on. Sadly I don't have the equipment for testing the bus, I only own a multimeter.
UF2 loaded great, CP is up and on the display, time to start playing
glhf, just make sure to init pmic so the rtc isn't discharged, instructions in:
https://github.com/adafruit/circuitpython/pull/9480#issuecomment-2284086237
Thanks π
The pmic code segment sets _aldo1_voltage_setpoint twice, once before _bldo1/_bldo2 and once after, is that intentional?
nope, just a mistake, removing it
Fixed with #9526.
#9291 is still not fixed.
I tried a similar seesaw board, Adafruit ANO Rotary Navigation Encoder to I2C Stemma QT Adapter, and was able to reproduce the problem, with both frequency=100000 and frequency=400000. However, the program does not crash with:
i2c_bus = busio.I2C(board.SCL, board.SDA, frequency=50000)
Try that and see if it lets you proceed.
GPIO23 is not wired up on Pico Plus 2, so these two lines can be removed.
Thanks for setting these up @tannewt ! I take it you saw the USB PIDs appear in Pi's repo?
I've had a look over and they overall seem good. There are a few things that could be added, so I'll raise separate comments for those.
GPIO23 is not wired up on Pico Plus 2, so these two lines can be removed
GP26, GP27, GP28, do not offer Analog functionality on the B chip.
These should instead just be:
{ MP_ROM_QSTR(MP_QSTR_GP26), MP_ROM_PTR(&pin_GPIO26) },
{ MP_ROM_QSTR(MP_QSTR_GP27), MP_ROM_PTR(&pin_GPIO27) },
{ MP_ROM_QSTR(MP_QSTR_GP28), MP_ROM_PTR(&pin_GPIO28) },
For ADC access these additional lines are needed in relevant place:
{ MP_ROM_QSTR(MP_QSTR_GP40_A0), MP_ROM_PTR(&pin_GPIO40) },
{ MP_ROM_QSTR(MP_QSTR_GP40), MP_ROM_PTR(&pin_GP...
A3/VOLTAGE_MONITOR is now on GP43.
This board has our new SP/CE connector, so can have these pin definitions adding:
{ MP_ROM_QSTR(MP_QSTR_SPICE_CS), MP_ROM_PTR(&pin_GPIO33) },
{ MP_ROM_QSTR(MP_QSTR_SPICE_SCK), MP_ROM_PTR(&pin_GPIO34) },
{ MP_ROM_QSTR(MP_QSTR_SCK), MP_ROM_PTR(&pin_GPIO34) },
{ MP_ROM_QSTR(MP_QSTR_SPICE_TX), MP_ROM_PTR(&pin_GPIO35) },
{ MP_ROM_QSTR(MP_QSTR_MOSI), MP_ROM_PTR(&pin_GPIO35) },
{ MP_ROM_QSTR(MP_QSTR_SPICE_RX), MP_ROM_PTR(&pin_GPIO32) },
{ MP_ROM_QSTR(M...
GP0 and GP1 are user accessible for UART:
{ MP_ROM_QSTR(MP_QSTR_GP0), MP_ROM_PTR(&pin_GPIO0) },
{ MP_ROM_QSTR(MP_QSTR_TX), MP_ROM_PTR(&pin_GPIO0) },
{ MP_ROM_QSTR(MP_QSTR_GP1), MP_ROM_PTR(&pin_GPIO1) },
{ MP_ROM_QSTR(MP_QSTR_RX), MP_ROM_PTR(&pin_GPIO1) },
I suppose the UART object can be set up too:
{ MP_ROM_QSTR(MP_QSTR_UART), MP_ROM_PTR(&board_uart_obj) },
In our schematic we call GPIO22 USER_SW. I also see in the other board defs that you add a BUTTON def, though those other boards only have the one button.
{ MP_ROM_QSTR(MP_QSTR_USER_SW), MP_ROM_PTR(&pin_GPIO22) },
{ MP_ROM_QSTR(MP_QSTR_BUTTON), MP_ROM_PTR(&pin_GPIO22) },
These can have their GP pins defined too:
{ MP_ROM_QSTR(MP_QSTR_SDA), MP_ROM_PTR(&pin_GPIO12) },
{ MP_ROM_QSTR(MP_QSTR_GP12), MP_ROM_PTR(&pin_GPIO12) },
{ MP_ROM_QSTR(MP_QSTR_SCL), MP_ROM_PTR(&pin_GPIO13) },
{ MP_ROM_QSTR(MP_QSTR_GP13), MP_ROM_PTR(&pin_GPIO13) },
Oh btw, i've extensively tested idf5.3, no breakage.
It's on the watch now too, gotten about a day of uptime, jumping between mcu frequencies.
Right now, boards theoretically upgraded from before the dualbank storage expansion (#7000) could still have been upgraded to CP9.x without losing fs contents, and have working installations on ota1.
I think the ideal api would be booting with it as stdin, then whenever the user calls board.KEYBOARD() the keyboard is detached from stdin.
Then when that object is deinitialized (or expires from scope, finalizers?), it's attached back to stdin.
I don't think it's wise to try to get it under shared-bindings since every keyboard board will need different hacks.
It'd be more function arguments than actual code. (Just look at a cardputer, the t-deck and your keyboard, you'll get what I ...
This happens to me on the lilygo_twatch_s3 when files are being written with usb and the board is in it's low power state @ 40Mhz.
It's not related to a specific i2c library.
CircuitPython version
Any > #9342, discovered on S3
Code/REPL
import microcontroller
microcontroller.cpu.frequency = 20_000_000 # 20MHz
Behavior
Usb goes away. This is fine as by itself, as usb cannot operate with the board being at 20MHz.
However when switched back to a higher clock, usb does not start back up, even if the board is unplugged and plugged back in (assuming it's battery powered).
Description
No response
Additional in...
it looks like there was some exception raised during the generation of the 'state of circuitpython' report. I'm trying to run it locally with some additonal print statements to try to get a better idea about what the specific issue is.
It traces to here: https://github.com/adafruit/adabot/blob/main/adabot/lib/bundle_announcer.py#L70 basically comps is None. It's not clear at all to me why though. I added some print statements wrapping the line that creates comps
print(f"lib: {lib}")
comps = parse.parse("[{name:S}]({link_comp:S})", lib)
print(f"comps: {comps}")
They show the value of lib and that indeed comps is None:
lib: [rfm](https://github.com/adafruit/Adafruit_CircuitPython_RFM/releases/1.0.0)
comps: None
Exception Occurred! ...
But it doesn't really make sense to me why comps ends up None In a REPL when I run the essence of this parse operation it seems to succeed and get a legimate value that isn't None
>>> import parse
>>> lib = "[rfm](https://github.com/adafruit/Adafruit_CircuitPython_RFM/releases/1.0.0)"
>>> comps = parse.parse("[{name:S}]({link_comp:S})", lib)
>>> print(comps)
>>> <Result () {'name': 'rfm', 'link_comp': 'https://github.com/adafruit/Adafruit_CircuitPython_RFM/releases/1.0.0'}>
what if you print like {lib!r} (or {repr(lib)}, which is the same thing)?
perhaps whitespace (or some other invisible char) messing tthings up
FYI, using {lib =} would print both variable name and value, and you wouldn't need to write "lib: " on the string π
Thanks, I've never seen that syntax.
π€ ```py
lib = "hello"
f"{lib = !r}"
"lib = 'hello'"
f"{lib=!r}"
"lib='hello'"
I also started wondering about whitespace causing trouble. I'm running it again now with some additional printing. I did confirm in a REPL that if there were mis-matched whitespace that parse.parse() does return None so it does seem like a plausible theory.
Does circuitpython support that syntax too?
idk
it's quick to check, though :p
(if you have a device handy, unlike me, that is)
Do you know if there is a name for this syntax? Or where to find reference to it in the docs. I'm curious now if there are other helpers that I don't know about.
if you look for something like "f-strings cheatsheet" there should be nice images around
i have no idea how the !r or var = constructs are named (if they have a name to begin with)
if i were to give them a name, i would call most of the things you can do in f-strings as "format specifier" but that's a very vague and generic name
it does appear that whitespace, specifically a \r might be the issue.
lib_components: ['[rfm](https://github.com/adafruit/Adafruit_CircuitPython_RFM/releases/1.0.0)\r']
perhaps safer to .strip() the value before using parse on it
Anyone know what changed in memory management between CircuitPython 8.2.9 and 9.1.1, and the respective versions of adafruit_display_shapes lib, that would make code fail on CP 9.1.1 with
File "code.py", line 103, in <module> File "adafruit_display_shapes/roundrect.py", line 64, in __init__ MemoryError: memory allocation failed, allocating 26624 bytes
Code is here: https://gist.github.com/snkYmkrct/a4cb0d6d44bf6e2350225036db4f2197
something something https://github.com/adafruit/circuitpython/pull/8553
I honestly don't understand the new model fully (just when I'd gotten my arms around the old one), maybe someone with knowledge can help
maybe time for Scott to do an updated Deep Dive on memory, with fancy graphics https://youtu.be/baa5ILZTRkQ?si=InNPKBiNEL5RDxSY&t=977 π
yas! π€©
I pasted in the report info for today and added the parts that got cutoff of the automated one by the exception. It did run successfully locally with after stripping the whitespace. There were 2 of the strings that contained \r and the rest didn't. Not sure about why the difference, but this does resolve it.
I don't know any more about the memory inner-workings. but it might be worth a try to replace adafruit_display_shapes usage here:
game_board_frame = RoundRect(INGROUPXOFFSET-8, INGROUPYOFFSET-8,
HTILES*TILESIZE+16, VTILES*TILESIZE+16, 8, fill=BLACK, outline=PINK, stroke=3)
with an inflated tilegrid (https://github.com/adafruit/Adafruit_CircuitPython_ImageLoad/blob/main/adafruit_imageload/tilegrid_inflator.py#L32).
I haven't done rigorous testing, but my understanding is that shapes will make a bitmap of the full size, while Tilegrid gets represented internally in a more compact way storing indexes for each tile rather than raw graphical data.
Thank you, I will try it!
Meanwhile, I moved the font loading after the RoundRect declaration, and now the code works ... so I'm guessing there was some memory fragmentation going on.
I vote for a memory management deep dive show! π
there's an optional arg to .load_font to load only the glyphs you use ...may trim things slightly
Yea, for sure, I will try some memory saving tips.
I was just curious what changed that made the code stop working between CP 8 and 9
@lone axle thanks for fixing the report!
I'll leave the observation here, in case anyone has the same type of problem. The folks at Seeed Studio still need to answer some questions regarding USB device registration. My Windows system was mounting the CIRCUITPY drive as read-only because it was not recognizing the drive as a drive. Probably due to a problem in the registry, which identified the USB device incorrectly.
I added values ββfrom other boards (from ESPRESSIF itself) and managed to perform a first compilation. With the he...
i2c_bus = busio.I2C(board.SCL, board.SDA, frequency=50000)
With this speed, it works perfect.
I'm tempted to try to figure out why some of the tests take an hour when they run in actions. I did see messages about API rate limit requests per hour in the adabot print outs though. I wonder if the tests and other actions add up to over the per hour limit so it waits for them to get replenished.
@bill88t if I run this code:
[code]
import microcontroller
microcontroller.cpu.frequency
[/code]
the output is:
[code]
240000000
[/code]
I assume this is fullspeed
@dhalbert If I test again with the motor driver, it's working now too. The only thing I have changed, is a bigger power supply (LiPo wit DC-DC Stepdown). Nothing changed in the code.
@icebreaker87 Glad to hear on both counts. I will check about the 50000 speed requirement internally. And it sounds like it was power sag on the motor driver.
<@&356864093652516868> We'll have our weekly meeting in about 50 minutes from now in this text channel and in the circuitpython voice channel. Please take the time to add your notes in advance to the document: https://docs.google.com/document/d/13Q0vqnzMAVGwjdVG3-lXMxt62ouymSQ134-o-ROgXBM/edit -- I look forward to everyone's updates!
CircuitPython Weekly Meeting for August 19, 2024 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you canβt make the meeting and woul...
Given that for a few of the other boards that I've seen board.XXXXXX seems to always be either a pin or a display object, making board.KEYBOARD a function would feel rather inconsistent. I'd also find the behavior of detaching from stdin on object access pretty unintuitive and even more intutiive if anything would happen to it automagically on scope expiration.
Something like an explicit attach_keyboard_serial / detach_keyboard_serial would be a way more straighforward interface for th...
According to plan I'll be back (but jet lagged) next week. Group hug. Photo: spice market in Mombasa Kenya
Nice! I can smell it! I have fond memories of several trips to Mombassa for work in 1976 and 1979.
@tulip sleet looks like our i2c code waits 100 ticks: https://github.com/adafruit/circuitpython/blob/main/ports/espressif/common-hal/busio/I2C.c#L176
I agree that putting this into shared-bindings feels unnecessary.
You can put it in ports/espressif/bindings, which is port-specific, and turn it on only for that board. There is already a mechanism for finding doc in ports/*/bindings.
Waiting on plumber who could show up anytime, so I'm text-only this week.
Fully-featured Doom port for the Raspberry Pi RP2040 microcontroller - kilograham/rp2040-doom
Please send in projects, news and more to me cpnews@adafruit.com
@spare jacinth want to talk on voice about your in the weeds or should I read it?
π
i dont mind either way
my english will be worse than yours, that's for sure π
yeah, i meant out-of-sync issues, will trust what the stubs say then
I gave you the circuitpythonista role, but if you don't want it, let me know, you'll get notifications on Monday about the meeting
it's fine, thanks!
Thanks for hosting Scott, have a great week everyone!
np. thanks for fixing the stats!
Here is the notes document for next Mondayβs CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and weβll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1AlQdjcpzMwWRF_2UsoXykCqwJVCPx5kSR14VG4ozEOo/edit?usp=sharing
CircuitPython Weekly Meeting for August 26, 2024 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you canβt make the meeting and would...
Is there a good place for documenting such a board-specific module / class / variable?
There isn't a great place. This is kinda the first board-specific functionality. I think bindings is fine. Other docs can live on Adafruit Playground: https://adafruit-playground.com/
This could be an artifact of our tick speed change from 100 to 1000. That shortens timeouts like:
https://github.com/adafruit/circuitpython/blob/830294ebb533af1691e6afe0d58f5d4733fa099d/ports/espressif/common-hal/busio/I2C.c#L176
We should change the timeouts to be tick speed agnostic.
was taking a look at the issues for "type annotations are missing", first one in the list is Adafruit_CircuitPython_BLE_Eddystone on which i dont get mypy to error on the lines specified on the issue because it bails out as soon as it sees the imports coming from adafruit_ble not being typed (stubs or py.typed)
so... is there a reason why such marker is not in there alredy? adding it on my machine's copy of the lib gets mypy to go further but it's a pretty ugly hack around
though, BLE's typing seems to be very broken, when running mypy . in the repo, it yells about a bunch of stuff
I experienced really slow updates on Qualia w 2.1 round display when using any display rotation. Even calling rotation=0 seemed to cause slow loading if I recall.
Is this new? Loading from flash into PSRAM is going to be limited by the speed of their shared memory bus.
Rotation can be bad for loading since it may cause skipping through the file system to go column by column instead of row by row which wouldn't. This isn't new and I'd suggest rotating the asset to align with the displa...
@Sola85
Have you done any tests on what the reduced accuracy of using SENSE instead of GPIOTE is? (or have you found any documentation that states it)
I'm using light sleep with pin alarms to detect events in the ~30ms range, so just wondering if I will have reduced accuracy with this change.
Otherwise awesome with more powersavings on an already very low power chip.
@tulip sleet do you have a script to update board file headers?
it's in a PR, hold on
π
see next-to-last bullet item in https://github.com/adafruit/circuitpython/pull/9257
thanks!
All RP2350 headers updated using the script as well as addressed @ZodiusInfuser's comments.
I take it you saw the USB PIDs appear in Pi's repo?
Yup! I used those.
wondering if anyone has ever run mypy on them, lol... the more i look into reading/fixing errors, the worse it gets π
should i add mypy to pre-commit? π€
output (only from source, not examples): https://gist.github.com/elpekenin/806fe8ae8b71c922840ee49fa86e0c42
... so I looked a bit into the directory structure and it feels to me that creating something like a espressif/bindings/m5stack_cardputer_keyboard, along with the need to introduce the pretty niche makefile variable and effectively require every build to indirectly be aware of this, is not nice at all. Things would then become especially ugly if the approach starts proliferating for any other boards that might want to implement a similar board-specific module.
I'm therefore pretty convinc...
100 * tick rate / 1000
Does not affect or fix #9535 unfortunately.
I'm having a very similar issue with I2C on QT-PY-ESP32-S2. I've come at it all kinds of ways, with one or multiple I2C devices and varying the I2C bus speed from 10_000 to 400_000.
With these i2c devices:
-
adafruit_ssd1306 -
adafruit_seesaw (rotaryio: product number 4991)
When I do a i2c.scan() it never shows any devices, but I can "speak" to the rotaryio. When I enable the ssd1306, I get:
main.py output:
sys.implementation=(name='circuitpython', version=(9, 1, 1), ...
In V5.3, i2c_master_write_to_device() is deprecated and replaced with i2c_master_transmit(), which takes the timout in ms. I think it would be good to upgrade to that.
We changed CONFIG_FREERTOS_HZ from 100 to 1000 for most boards in #9134. So the old timeout was 100 10ms ticks = 1 second, not 100ms, which is what it is with the new CONFIG_FREERTOS_HZ . That may be the problem in #9535. Your change in this PR keeps it at 100 ticks (100 ms).
Hello all, is there a way to more quickly create a circuitpy module out of an existing Arduino/C++ library (that hopefully avoids full reimplementation)?
does it have to be in C, or can you rewrite it in Python?
It's in C++. I'm hoping for something like just creating a similar circuitpy API, but executes the underlying compiled c++ code.
Desktop Python has something like this, but I'm not sure with circuitpy (or even micropython)
Basically creating a circuitpy shim over the C++ code.
MicroPython has a somewhat easier way of doing this, which we have not enabled. We have a guide on this but it's quite outdated: many details are different now: https://learn.adafruit.com/extending-circuitpython.
what is the C++ code doing?
It's going to be doing some power controls, so I think the main thing is that it does I2C transfers to the revelant IC's: https://docs.powerfeather.dev/sdk/api/mainboard
class Mainboard
MicroPython has a somewhat easier way of doing this
What is the feature called, if I may, so I can look more about it?
It would be far easier to rewrite the i2C code in CIrcuitPython. Our I2C API is fine.
Thank you! I'll look into these methods first, but if that becomes too cumbersome, I'm also not writing off rewriting in CircuitPy/MicroPy.
I2C transactions are straightforward. You might try using an AI engine to do the intial translation if it's coming from Arduino.
Rewriting it in CircuitPython will also make it easier to change later.
We have many libraries that have both CircuitPython and Arduino versions. You could compare the two and see how one relates to the other.
As an example I see you are using an LC709204F. Here is our LC709203 CircuitPython library: https://github.com/adafruit/Adafruit_CircuitPython_LC709203F
I tried in 9.1.x lengthening all the timeouts to 1000 ticks. This did not help #9535 either.
Ooh, thank you very much!
As a follow up... Is there a list of all adafruit's CircuitPy libraries? As in... Could i automate downloading all of them to run MyPy on their codebases? Or would i need to iterate all repositories from the profile using some github API?
Idea would be to add py.typed to the ones that pass MyPy checks, and fix the ones that dont (thats a heck ton of work, i may bail out at any point)
@mrdalgaard I currently don't have the ability to do any tests (apart from simple current consumption measurements) myself. Regarding documentation, I have only found Table 5.3.8.3 "Device startup times" in the datasheet. This does not differentiate between GPIOTE and PORT events and only mentions general HW events (which might mean that there is no difference?).
In fact, the datasheet does not mention the word "accuracy" when it comes to interrupts and wake events, this only seems to appe...
Hi I have written an email to techsupport@seeed.io asking for VID PID and below is the replay I got
I think this helps the official support ;-)
...
Hi Marco,
Thank you for reaching out. Here are the VID and PID for the XIAO ESP32-S3:
VID: 0x2886
PID: 0x8056
These details should assist with the process. If you have any more questions or need further assistance, feel free to ask.
Regards!
Frank
Seeed Technical Support Team
@tannewt Thanks for the additions. The above lines for GP40, GP41, GP42 should be included too.
Missing a regular I2C object: { MP_ROM_QSTR(MP_QSTR_I2C), MP_ROM_PTR(&board_i2c_obj) },
As already mentioned, missing the correct ADC pins:
{ MP_ROM_QSTR(MP_QSTR_GP40_A0), MP_ROM_PTR(&pin_GPIO40) },
{ MP_ROM_QSTR(MP_QSTR_GP40), MP_ROM_PTR(&pin_GPIO40) },
{ MP_ROM_QSTR(MP_QSTR_A0), MP_ROM_PTR(&pin_GPIO40) },
{ MP_ROM_QSTR(MP_QSTR_GP41_A1), MP_ROM_PTR(&pin_GPIO41) },
{ MP_ROM_QSTR(MP_QSTR_GP41), MP_ROM_PTR(&pin_GPIO41) },
{ MP_ROM_QSTR(MP_QSTR_A1), MP_ROM_PTR(&pin_GPIO41) },
{ MP_ROM_QSTR(MP_QSTR_GP42_A2), MP_ROM_PTR(&pin_GPIO42) }...
The new RP2350 chip has an HSTX peripheral that allows for high-speed data transfers independent from the system clock. It could potentially be used for the fourwire and paralleldisplaybus modules, allowing greater transmission speeds and possibly making the transfers asynchronous, allowing them to happen while the next portion of the data is being computed.
@tannewt If I understand correctly, your preferred solution would be such that light sleep automatically determines the most power conserving, ram retaining sleep mode that is possible, given the ongoing background tasks. E.g. on an esp32, if nothing is going on in the background, actual light sleep could be used and if WiFi is still active the current behaviour would be used. Is that correct?
As far as I can tell, this would be a valid solution of this issue.
However it does sound like ...
Any libraries that got a type annotation issue created did have mypy run once with a specific configuration to create the list that was posted in the original issue. That was a while ago and not live updating so the lists in the issue are likely to be incorrect in substance or line numbers if the libraries have changed in the interim.
I do not think we would want to add mypy into the pre-commit across all the libraries right away because I think it's likely there will still be many warnings and issues emitted by the mypy check. The original issues and first pass through the libraries was focused mostly on the "lowest hanging fruits" of adding annotations for function arguments and returns. The mypy checks can include many additional things beyond those depending on how it's configured and I think it's worth discussing in the weeds at some point what configuration we'd want to use on the libraries before we start adding it to pre-commit.
With regards to a list of libraries, the Bundle repo is the best way to get it IMO. You can use git submodule foreach for automation tasks, or if you want more fine grained control you could list out the directories or even parse the drivers.rst file in the bundle repo.
If you're interested, this repo: https://github.com/FoamyGuy/missing_type_issue_maker contains the scripts that were used to run that initial mypy check and create the issues. It utilizes the bundle for looping over the libraries with git submodule foreach.
and this one https://github.com/FoamyGuy/circuitpython_bundle_automation is a slightly more generalized version built upon the same ideas. I also left a bit more documentation in the readme of this one that explains how it was used, and how to use it on a subset of the bundle. It's not necessarily comprehensive docs, but it's better than the "basically nothing" in the type_issue_maker repo.
Wow, wokwi is actually amazing for testing idf api..
I'm now half way there on switching CircuitPython's i2c api to the new idf driver.
i have always used mypy without giving it any configuration, i guess you could opt-out some checks but i'd say falling through the default settings the best way to use it
and yeah, maybe things got worse over the years as the code was changed, but given how broken some typing is, my feeling is that it was never really checked for type correctness but only checked whether any hint (regardless of how correct/wrong it is) was added to each(or most) variable... you can see how bad the thing is on the gist π€£ π
Did you switch esp-camera to it? That blocked me last time I tried
im already working on fixing the BLE repo locally, i will open a PR when i get everything fixed (or # type: ignore[<something>] if proper typing is hard on some place)
Not made it there just yet, I am still writing I2C.c
You should double check you can switch it over. You can't have both in a binary
Oh, alright, i'll go check that first then, thanks!
Thanks for looking into it!