#circuitpython-dev
1 messages · Page 23 of 1
it could also handle "packaging" of the games and their libraries and assets
and a game selection menu
so you would just copy a directory like you do with /lib right now
but I really don't have the energy to work on something like this right now
Agree'd that would be awesome. I don't think I am capable of all the parts to it though. But I'm up for trying to tackle any parts that I can. Even a relatively easy to use solution for buttons would be a great start to get us back to similar capability that was possible before. I will do some experimenting and add thoughts to that issue post once I have some more concrete ideas tried.
<@&356864093652516868> the weekly meeting will occur here on the discord in a bit under 90 minutes from now at 2pm eastern time. The notes document is available here: https://docs.google.com/document/d/1yqZABCU8BjP_njl0_8fed1P2dkDmNqw5o42qjZzLxqc/edit?usp=sharing if you have the chance go ahead and add your hug reports and status updates to it. We look forward to talking with everyone then!
CircuitPython Weekly Meeting for January 23, 2023 Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be...
I'm leaning towards a class that on init inspects the board module and guesses the buttons, then gives you the api and the constants – because then you can do hacks like with the analog joystick or even accelerometer or touchscreen
pylint folks. does this error look familiar? https://github.com/adafruit/Adafruit_Blinka_bleio/actions/runs/3959041983/jobs/6781347211
formatargspec specifically does ring a bell for me. But I don't recall much about the fix beyond maybe having just upgraded to a newer pylint version. Maybe @proven garnet may remember anything more about it from this time #circuitpython-dev message
I wonder if we should do one more IDF bump before 8.0 RC. This fix is in the upstream 4.4 branch but ours is too old: https://github.com/adafruit/esp-idf/commits/release/v4.4-circuitpython
One stray comment. Looks good otherwise. Thanks!
I wonder if we should do one more IDF bump before 8.0 RC. This fix is in the upstream 4.4 branch but ours is too old: https://github.com/adafruit/esp-idf/commits/release/v4.4-circuitpython
I was just going to try merging v4.4 from upstream experimentally to see if it fixed any network or I2C problems. There are a number of interesting commits past where we last merged from.
Modified espnow to use existing ringbuf functions.
Modified espnow to use existing ringbuf functions.
Moved to py/objtuple.h.
Is the callback called asynchronously when a message is received, like a MicroPython soft interrupt?
Yes it is called asynchronously. on_recv is removed now.
...If there is anything I can do to help, let me know.
@glenn20 (and others) Sure, will let you know and thanks for all the work you have done already. 🙂
Targeting this for 9.0.0 might make sense...
I am hoping this can be in CP8. The ESP-NOW API doesn't seem to have changed in esp-idf@v5.0.
I am hoping this can be in
CP8. TheESP-NOWAPI doesn't seem to have changed inesp-idf@v5.0.
We could do for 8.x.x. We are trying to close out 8.0.0 really soon, but we have a bunch of things for 8.x.x.
Contains some bug fixes and improvements:
- Use Ubuntu
22.04for everything but thetestjob inBuild CIwhich is on20.04. - Use Windows
2022for thewindowsjob inports_windows.yml. - Fix a bug in
create_website_pr.ymlintroduced by recent changes totools/ci_fetch_deps.py. - Don't cache in
pre-commitaspre-commit/action@v3.0.0already maintains a cache.
I think you moused over the chatbox icon and that dropped you into the video tiled page
@tulip sleet Before you make a release, #7477 fixes a bug in create_website_pr.yml.
@idle owl I notice that for me the "turn on camera" button is available, but maybe that's only for 'high roles'...?
(specifically in the voice channel)
I'm thinking that too.
I think mods are exempt.
Thanks. We are still a few days away from an rc.0.
text-only
Actually after looking this over again I'm wondering if CIRCUITPY_RTC = 1 is necessary. I'll try a test build this afternoon and pull it out if it builds without the parameter being set there.
Congrats on 100 PR's to TCFranks! 🎉
Yes! Mismatch between pylint and Python version.
@still zephyr Are you text only for your status update as well?
No worries!
🙂
wonders how many PRs the @jepler github account has made over the years
well also times a large number of years helps 🙂
Sometimes we call the Ada Bot???
Not at the meeting today but congrats!
@lone axle made some awesome progress with porting Displayio features to Blinka, that was a really interesting stream.
Hope Tekktrik and Melissa and everyone else dealing with stuff gets well soon. ❤️
My GitHub activity, apparently:
9732 Commits
974 Pull requests reviewed
395 Pull requests opened
44 Issues opened
499 issue comments
44 seems low for issues, but who knows.
I think last week Dan said some feature was available in IDF 5.0 but if we're on 4.4 does that mean we can't get those updates until we can port to 5.0?
My C64 to USB experiment.
@tulip sleet give a shot to the IDF v5.0 PR on a non-psram board and see if that fixes stuff
My Argon Light 2.
This may be entirely inaccurate. I regenerated the same info, and it's entirely different. 🤷🏻♀️
I have only 3 issues opened 
where did you get that info? I was busy writing a custom script 
Hah! I went to a site I found when writing the GitHub profile guide, that has a web instance of their metrics stuff.
Is there are a way to spit out contributions per person like that? That would be cool to see. I think I'm at 2.
talandsia!
Just spritz them using a water bottle with a misting nozzle. In nature they pull mist from the air, it's what they're called air plants.
They grow naturally here in FL.
I found the soak method in multiple instructions.... Including from the place I bought them. I'll try to keep up with that.
Woo good luck with plants! They look lovely!
Beautiful plans!
I do have food for them in a spray bottle though!
Was supposed to do that after watering, oops. I'll do it when we're done here.
Air plants when they bloom look gorgeous, similar to bromeliads in structure.
I also read somewhere they only bloom once ever?
depends on species, some bloom annually, every couple years.
I grabbed the only two with the magenta bits on them, all of the others were green only, so I assume had not reached maturity and therefore blooming time yet.
Oh. Nice ok.
That's pretty neat they grow in FL.
YES< Please
Pro gif too 🙂
For me they don't have to be big, 128x128 for now
Yes.
@onyx hinge @midnight ember Their web instance is here. It's limited because it's a free web instance, which is to say some of their fancier plugins don't work. But it definitely gives you basics. I don't know why I'm getting different numbers though. https://metrics.lecoq.io/
I'll take a look at gifs then. Figuring out how to keep them changing (almost a gif.next_frame()) call may be needed.
Scott super hacking bangle over the air. Most impressive.
Also it's limited by requests per hour or whatever. So if others are also generating metrics, it might be a bit slow.
gifs could help to update graphical representation of sensors easily
Suddenly the price of bangle.js watch explode and no one knows why...
price from where? from them directly?
I think he's referring to your work making them suddenly expensive.
"Opened 1523 pull requests" according to that website
I was assuming some will have a suddent interest in the watch...
Way ahead of me, evidently.
Go CP9 
@idle owl my oldest activity is a decade before yours, so per year I think you're ahead
Hmm. Fair!
It would be nice if the 9 cycle was shorter than the 8 cycle has been.
I'm sure moving to MP 1.19 and IDF 5.0 will be super smooth 😬
(i'll add timestamps for in the weeds and the first topic after the fact. forgot it for those)
No worries! They get missed from time to time.
I was testing watchdog things and noticed that since the watchdog can't be disabled, it is very disruptive during development, even just autoreload
the forum discussion was barely about that, it's more things I noticed when writing test code to check the watchdog use
my internet keeps crashing 😦
Thanks everyone
Thanks!
Thanks! Have a good week
Thanks for hosting FoamyGuy. See everyone next week.
Thanks all!
@lone axle The final timestamp looks like your stamper reset.
thanks all! Have a good week!
Thanks!
@Neradoc noticed that it was easy to corrupt CIRCUITPY when the hardware watchdog is enabled. We would like to reduce the chance of a corrupt filesystem by regularly "feeding" the watchdog at short intervals during a flash write.
this doesn't fix all irritations about having watchdog enabled during development (e.g., maybe it bites during reload still even if it doesn't corrupt anything) but it would be a step in the right direction.
I wonder how hard it would be to make a two-level watchdog for the users. We would basically have a usb-friendly watchdog implemented in C that would be friendly to all the filesystem and other needs, and that would be what the users interact with. But in addition, to guard against hard crashes, that "software" watchdog would in turn feed the hardware one, so if it ever stopped running, the board would restart hard (if the crash happened in the middle of a filesystem operation, the filesystem...
Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1kv7EzMdwVLd8ODEcqrHhSPrz_MGrS5Q9qMI6CgXBbXg/edit?usp=sharing
CircuitPython Weekly Meeting for January 30, 2023 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to par...
I've hacked away at this on and off for a week or so without any breakthroughs. My current theory is that the CircuitPython variable structure (sorry, I know nothing about the internals) is somehow getting misplaced or corrupted (or perhaps a variable pointer) when the SPI RAM is used.
Everything on the board seems to work fine with the SPI RAM, but when larger python programs are run, sometime during their execution when CP accesses a variable it actually retrieves a different variable's...
CircuitPython version
Adafruit CircuitPython 7.3.3 on 2022-08-29; Adafruit CLUE nRF52840 Express with nRF52840
Code/REPL
import time
import alarm
from adafruit_clue import clue
sleep_time = 20 # seconds
clue_data = clue.simple_text_display(title=" DeepSleep Test", text_scale=2)
current_time = time.monotonic()
clue_data[2].text = f"MonoTime: {current_time:.3f}"
clue_data[4].text = f"SleepTime: {sleep_time:.1f}"
clue_data.show()
time.s...
@wraith crow does your do dynamic imports and such ? I am wondering is this is a long-lived memory issue, if that hypothesis has not been mentioned before ?
see https://github.com/adafruit/circuitpython/issues/2687
with the use of SPI RAM triggering an edge case or something
just an idea though, but when I saw variables being misplaced I thought of that
Thanks, I'll have to stare at that issue for a while but any leads at this point 🙂
I think I do indeed use similar imports. I'll have to check if there's any correlation with the corrupted variables and the imported ones. I've run this code on half a dozen ports and dozens of boards without running into this so there must be a strange edge case if this is related.
I've got to run for a bit but tonight I'll build the Tinypico bits with and without the SPI RAM and test out the example code from #2687.
I don't know if the "long lived" system can be disabled on compile, that could help establish whether there's a correlation ( @slender iron )
there isn't a compile time setting for it
Is there any way to contribute to a library/make a request/change some code? Cuz currently, for the circuitpython MCP2515 only 8 MHz and 16 MHz crystal options are available and I've seen some other things that could be improved in that library
Most prefferably I'd just write the code but I don't really know if that's possible
Hey, all the libraries accept pull requests with changes. They will be tested/reviewed by other community members and then merged in.
There is a guide about contributing to CircuitPython and more information here https://circuitpython.org/contributing
Also in this channel you will find tons of help on getting started and any issues you could come across.
K, thx, how do I make a pull request? I have used git quite a lot recently but I've never contributed to any repository of someone else
Clone the library you want. Set the clone's origin to the adafruit repo. Then you can create a new branch and do your changes. When you are done you can push back to the adafruit repo.
That guide has a lot better / detailed information on it
Oh, thx great
there's a lot of nomenclature involved. this might help to understand the overall flow of things.
ideally that would also show making a "branch" somewhere after step 2
the guides discuss branching
the key is to work on a branch or it might be painful later down the line
also - consider opening issue(s) in the library repo first
Yep, that I know already
that helps give the pull request context..."this fixes issue number x"
K, I'll look into that tomorrow
Well, It's not a bug I'm experiencing, it's more of a feature, that I'm missing
yep. github only has "issues". but its generally ok to open a new issue even it's essentially a feature request.
the terms close and resolve are also allowed to auto link an issue from a PR
Ye, I guessed that, just wanted to say...
and keep each pull request as simple as possible so the code review is easier
there's an enhancement tag for a reason 😉
The whole feature added will be a small change
yep - just for future ref. sometimes people make PR's that add like 5 new features, etc. in a single PR. and the code diff (what needs to be reviewed) ends up being large.
my position would be that if you have a PR for a new feature, there's no need to open an issue (whereas bugs might need more of a discussion thread for tests and research)
like the "some other things" you mention above - defer those to later PRs
(or a partial implementation of a larger idea, would need an issue too)
The "some other things" is just an if that checks if the crystal frequency entered is valid but it uses a separate array instead of the .keys func on the crystal dictionary of whatever the function is called to check if the crystal frequency is valid
Makes sense
Hi, the python.org docs for socket.socket describe the args as class socket.socket(family=AF_INET, type=SOCK_STREAM, proto=0, fileno=None) but type is a Python builtin, so how should the type arg be named in a pure python implementation of socket.socket? Thx!
It is named type in CPython too, so it's not really an issue: https://docs.python.org/3/library/socket.html?highlight=socket#module-socket. Source code here: https://github.com/python/cpython/blob/5964b1282919b4f82fbe7f4afd28624a4564dc04/Lib/socket.py#L220. As long as the routine doesn't need the builtin name, it just overrides it.
you could argue they (the CPython socket authors) should have named it something else, but they didn't, so we'll just go along with what they did
you can always use builtins.type() even if type has been eclipsed by the arg name
I landed here after having some freeze problems. Just keeping this here for future reference and in case somebody gets to the same point as myself.
When I tried the following modified code, the communication was lost and the editor (MU) and became unresponsive.
I did the same using TIO and Screen command in ubuntu causing disconnection problems. After a while the code will show the expected result, however the communication is lost with the board. This is a little problem, but if people i...
Thank you!
You may need to suppress the pylint warning where that happens then, just a heads up!
Would there be any violent opposition for me to add a conditional target in the espressif makefile to set some efuses?
(for EFUSE_VDD_SPI_AS_GPIO on C3)
Yes, any firmware loaded in the former dualbank partition will be over written when user_fs gets exhausted.
However, if the filesystem was extended but the extra space was never used then the dualbank partition is still preserved and can be used to boot from.
A new UF2 install always writes ota_0 which is fine if ota_0 is the boot partition but corrupts data if ota_1 is the boot partition and ota_0 is being used as extended storage. I did start work on making TinyUF2 dynamically select and load the current boot partition instead of defaulting to ota_0 but didn't quite complete it.
Is this a sdkconfig setting? If so it can go in the board specific sdkconfig file.
the scenario would then be someone using dualbank to update CP over the air, then format the drive into extended partition mode, and then update CP through tinyuf2
by the way I was trying to make a no_ota partition file for 4MB boards with a larger CP partition to fit debug builds but I can't figure out what exactly needs to be done to do that
Checkout PR #6927, it has changes to make a no_ota partition work when CIRCUITPY_DUALBANK=0.
ah ! thanks !
We can have a general implementation in the makefile which looks in the board specific config files for what EFUSE bits to set.
That's kind of what I was looking for, put what efuses need setting in mpconfigboard.mk, etc.
Though right now there's only the one board that needs that one efuse
what's the preffered way of using git add I allways just do git add . before my commit, is that ok?
I've only changed one file but I'm done now and want to commit it, push it to github and create a pull request
Hi
I am emberrassed to make this post but here it goes.
I have used RPis and python for a few years, but never really understood the difference between different python versions, the difference between pip and pip3 or most of the errors I get when I fail to install stuff.
I really want to get OpenCV installed, and I have tried a few times and read instructions on many forums. I have no doubt that OpenCV is great, as well as many of the instructions that I have read, and that the fault lies in me. It is so frustrating knowing that if a knowledgable person would sit at my computer for 2 minutes, everything would work!
So please help me to get OpenCV installed. I understand that to be able to help me, you need to know a few different things. Can we start out by someone telling me what you need to know and how I can get that info?
hi, you want to install OpenCV on a Raspberry Pi ? That would be better asked in #help-with-linux-sbcs, this here channel is for the core development of Circuitpython, so the right people won't be seeing your question here
thanks, I will try that
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.0 on 2022-08-18; PCA10059 nRF52840 Dongle with nRF52840
Code/REPL
>>> a = b'abc'
>>> bytes(a)
b'abc'
>>> bytes(a[1:])
b'bc'
>>> bytes(a[1])
b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\...
When bytes receives a number as argument, it will create an empty (all 0s) bytes object, with length equal to ve argument received.
Perhaps you wanted to print(bytes(a)[1]), ie:
- Convert the hole thing to a
bytesobject - Index the element
1
What is happening on your code is that a[1] is "b" which is encoded as 98 (you can check this by doing ord("b")) Thus, you are creating a bytes instance with that length
PS: Tested this on Windows' Python, but I don't think...
@elpekenin is correct, this is how Python works. The elements of a bytes objects are integers, as opposed to single-element bytes. This is different than how strings work.
>>> a = b'abc' # bytes
>>> a[1] # get a single element, which is an integer
98
>>> a[1:2] # get a sub-bytestring
b'b'
>>> s = 'abc' # string
>>> s[1] # get a single element, which is another string
'b'
this might sound like madness but I would like to port pydash to CP - the plan would be to get it all working and then split it up into a library of libraries than can be imported without all the rest of the library - thereby saving large amounts of memory.
however, this means I need to test some base python tools across
some have been no issue but I am having an issue with line 283 of functools.py
def __new__(cls, func, /, *args, **keywords):
which reports:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/lib/functools.py", line 283
SyntaxError: invalid syntax```
any ideas?
this is 7.3.3 on an S2 Mini
oh? if this isn't possible, I might fork pydash and un-modularise-ise (sic) into different importable helpers that can be adapted
ooh yeah - good plan
right - back to the drawing board. thanks anyway
@rugged spindle https://docs.micropython.org/en/latest/differences/python_38.html Python 3.8's PEP 570 Positional-only arguments is not supported in MP/CP. You could consider def __new__(cls, __func, *args, **keywords): as an alternative, using __ to prevent any "normal" keyword argument from being associated with the positional argument. (and of course changing the use sites within the function itself)
@onyx hinge I did start doing that but then it just started spiralling into so many that I am rethinking it (as well as my direction in life, etc) 😄
Replicating some hand picked functions will likely end up easier.
Yeah, there's a lot more complexity to the cpython definition of functools.partial compared to micropython-lib's!
note you can just ask chatgpt to rewrite any code you need to be "more enterprisey" if you need to complicate it later without human intervention
Hehe nice
I think the way you do it is fine. You can specify the exact file that you changed if you want but it's not necessary. The main "risk" with doing it your way is if you did change more than 1 thing all of your changes are going to end up getting committed. If that could be a problem for you then it's better to be more specific with your add. But if you are actually only changing 1 thing, then it'll find it and add for you. I do git add --all as well when I am first adding stuff to a repo. I don't know for certain if it's functionally different from your way or not but I think is similar if not the same.
you can also do git commit -a ..., though it does not add new files.
CircuitPython version
Adafruit CircuitPython 7.2.0 on 2022-02-24; Raspberry Pi Pico with rp2040
Board ID:raspberry_pi_pico
Code/REPL
import traceback
try:
raise RuntimeError("Hello")
except Exception as e:
print("Formatted was")
print(traceback.format_exception(e)
raise
Behavior
>>> %Run -c $EDITOR_CONTENT
Formatted was
Traceback (most recent call last):
File "", line 7, in
TypeError: 'value' argument re...
Hi, the syntax with a single argument (brrowed from Python 3.10) was added in Circuitpython 8.0.0.
There's a menu at the bottom left of the documentation where you can select the version or Circuitpython that you can the docs for:
https://docs.circuitpython.org/en/7.2.x/shared-bindings/traceback/index.html
ColorConverter already allow you to set the dither attribute to apply a dither over the colors from the source bitmap. I'm adding the ability to Palette as well.
@jepler I'm confused, now there is a dupe between:
adafruit_feather_esp32s2_reverse_tft
and
adafruit_feather_esp32s2_tftback_nopsram
OK, let's try this too. Thanks!
I ran the test code from #2687 with SPI RAM enable and disabled and got the same results as described in the issue. It's not entirely clear to me from the open issue if this is really an issue or not but it did highlight the id() function for me and since both the working and not working memory models on this board behave the same way I'm thinking #2687 probably isn't a factor here.
I did try using the id() function to get a better feel of what's going on. I ended up chopping my main appli...
adafruit_feather_esp32s2_tftback_nopsram was never/will never be made
I wanted to extract one character as bytes. Thank's
a = b'abc'
b = a[:1] # extract one character as bytes
c = a + b
c
b'abca'
b
b'a'
a
b'abc'
Minor changes to espressif partition table.
- Correct the
bootloaderpartition'soffsetandsizefields. - Prettify the partition tables. GitHub now renders them as searchable tables.
Thanks - this is a lot easier to read. I thought these were machine-generated sometimes and then they were just copied. I appreciate the app consistency instead of 0.
@dhalbert should we remove the other board definition (it's been there for quite awhile!) or permit the duplicate ID?
Greetings async fans! I have put together this brainstorm doc of what async APIs might look like. Please comment and discuss. (You can comment directly in the doc.) I'm looking forward to your feedback.
https://docs.google.com/document/d/1v-0MbuARpYzmBExOID4HpNxOTmXXtO4cOYtfreebcWc/edit?usp=sharing
What could async methods look like in core CircuitPython libraries? This document is a brainstorm on what a more async enabled core API of CircuitPython might look like. The examples were inspired by GitHub issue 6736. Your comments and suggests are extremely welcome PulseIn https://docs.circuit...
I'd definitely add new modules for the APIs instead of expanding the existing API
Yep, that's a valid point. Would you add new modules even if the API changes were non-breaking?
probably because small boards likely can't fit the extra code
and we like to keep them enabled/disabled unit at the module level
that way it errors on import
not on use
I see. So it is expected that asyncio is an optional module, and not supported on some boards?
@idle owl what's the best way to fix an issue with pylint/cpython incompatibility in the CI? https://github.com/adafruit/Adafruit_Blinka_bleio/actions/runs/3959041983/jobs/6781347211#step:12:95
Probably. The SAMD21s are basically full
very cool to see the async apis though
we may want to run them by the MP folks too. this may be a chance for us to move to a shared hardware api
I see. How would you structure the new modules. A separate aynsc module for each core module (e.g., digitalio_async, etc) or dump everything in asyncio module, or something else?
ya, probably an async version of each module
https://docs.circuitpython.org/en/latest/docs/design_guide.html may be interesting for you to read
python seems to use aio for async libraries sometimes ? or is it just aiohttp ?
mp has aioble too
asyncio is "just" a library. support for async/await is what is turned off on the smallest builds. There is also _asyncio, which is a C level support for some things in asyncio, but it's optional, and isn't required to use asyncio.
In practice though you need an event loop to do anything useful with async/await, so you end up importing asyncio anyway.
you can always make your own loop, I did before there was asyncio in cp
with blackjack
we have had simpler event-loop libraries:
https://github.com/deshipu/meanwhile
https://github.com/bboser/eventio
formerly tasko:
https://github.com/kvc0/CircuitPython_async/
Right. So then the trouble is that any async device lib has to late-bind to whatever event loop lib you're using. If you want to support "bring your own event loop" instead of relying on a core event loop impl.
what kind of binding do you mean? there are well-defined python-level magic functions for all of that
the only thing that needs the low-level code is the select-like call in your loop if you don't want to use polling
and even that could probably be done with events
If I'm implementing aiodigitialio (or should that be digitalaio) for a particular device. The code in this module needs to interact with the event loop, but the event loop impl is not statically know. Previous version of regular Python used to pass around the event loop object. But then they got rid of that, which on one hand makes things simpler.
Let's remove adafruit_feather_esp32s2_tftback_nopsram, and any sign of it on circuitpython.org.
Actually maybe they didn't get of the loop parameter. I was reading the documentation wrong.
I think your document is assuming we can do native (C)async routines. Again, it's not clear to me that's easy or even possible. We are going to talk to the MPy folks soon, we think, and will discuss that with them again.
Nope, there are no native async routines. Async methods are an illusion created at the Python level; they don't exist at the C level.
but i mean:
class DigitalInOut:
def __await__(self) -> Iterator[None]
async def wait_high(self) -> Awaitable[None]:
while not self.value:
await self
DigitalInOut is native, so how is wait_high() implemented?
My approach to this is to first work out what is the best user-facing API to present to users. Once we agree on that, we can then work out how to implement it. The implementation is the easy part. Understanding users' needs is the hard part. 😀
i agree, but it needs to be possible to implement.
that was what motivated my passing Events around or returning Events
we can implement some of these libraries in Python, and have a less convenient lower-level interface that is native (that uses Events, say)
wait_high is purely implement in Python. The __await___ method will call C code that will setup the interrupt, then when the interrupt fires there will be more C code that tells the event loop that interrupt happened.
To support the "bring your own event loop" model, __await__ would instead have to be wait(loop=None) method.
you can't have a method implemented in python on a native C class
The passing around some sort of context object is the right idea. It could work with the MP Event object, but I think the actual event loop would be more fundamental.
We don't have mixed C/Python native modules. ... ah, so you are not saying digitalio.DigitalInOut, you are talking about digital*a*io.DigitalinOut?
The event loop is invisible in most cases, and I think we can keep it that way. Making the event loop highly visible was a design mistake in old asyncio
and you can see how they have tried to get rid of that
crikeys. and i'm just sitting here trying to figure out how to convert rpi.GPIO code to circuitpython's digitalio part.
Oof. I'll look into it.
It's a hypothetical DigitalInOut class that supports async. Whether that is the existing class or an new async variant is an orthogonal design decision. You can always manually implement Python code for wait_high in C in a C module.
@timid bolt I apologize if I am sounding negative. That is not my intention. We are constrained by implementation issues.
The are kind of two aspects of async-ifying the native modules. For some classes, like digitalio.DigitalInOut and countio.Counter, the current routines to get state or do things are not blocking. So right now you can monitor a DIgitalInOut in an async task, and poll it on task switching. That's what's in the current async guide. Adding something like Event support would make that more efficient.
For other things, like socket operations or buisio.I2C.read/write, some audio playing, etc.there are operations that block for a significant length of time. There may be no polling support.
So we could write digitalaio.DigitalInOut right now , In Python, and implement an API that has async support. We cannot write busaio.I2C right now, because we have no non-blocking-with-polling support.
So it would be possible to prototype an API for a lot of this now, and then figure out how to make it more efficient later. We could also experimentally add native non-blocking-with-polling for, say busio.I2C now, either adding to the original module (but we don't have room), or adding a _busaio.I2C that is lower-level non-blocking but non-async, and then implement true async routines on top of that in python
I agree, the visible event loop is annoying. But I think it is necessary to support user supplied event loop implementations, unfortunately.
No not negative all. I really appreciate your feedback and arguments. I have to run some errands right now, but I will happily address your questions when I get back. Thanks.
thank you too for thinking about this and having a different perspective
Thank you!
Sounds like the boundary_fill loop needs a RUN_BACKGROUND_TASKS; to handle USB while it fills.
Curious if anyone has tried any profiling tools on the CP core? Looking at this mostly for my own learning and curiosity and just wondered if anyone else had looked at it.
I landed here after having some freeze problems. Just keeping this here for future reference and in case somebody gets to the same point as myself.
When I tried the following modified code, the communication was lost and the editor (MU) and became unresponsive.
I did the same using TIO and Screen command in ubuntu causing disconnection problems. After a while the code will show the expected result, however the communication is lost with the board. This is a little problem, b...
I haven't. It crossed my mind to run CP in an emulator and just see how many instructions it takes to complete a code.py execution
I still dream of using the wokwi pico emulator for profiling memory use and unit tests
and that too
from https://github.com/adafruit/circuitpython/pull/5145#issuecomment-1404123840 (@tannewt):
Sounds like the
boundary_fillloop needs aRUN_BACKGROUND_TASKS; to handle USB while it fills.
if we go the route of separate python module with async interfaces to the hardware, I would strongly prefer if there were no name conflicts with the non-async ones, like DigitalInOut. They wouldn't be drop-in replacements, so there is no value in naming them the same, but a huge threat of confusion.
I agree with this: AsyncDigitalInOut etc or whatever
I know what the problem is, and am sorting out the fix. I'll update you once it's sorted.
or even PinChange, since that's what it would effectively be for
I don't think we need async for output
well, not for individual pins, anyways
yup, good idea
@timid bolt I'd like to see busio in your async doc too. Maybe some discussion of the internal API too. I'd love to transmit SPI data to a display while computing the next set of pixels.
Thank you for porting this over!
Do you want to keep it MP compatible?
//| message: ReadableBuffer,
Want to switch this to deinit() instead and then allow the constructor to make another new object instead? That would match how mdns.MDNS now works. (Except the constructor will error on second create.)
Maybe fold this into the truthiness of the object itself via unary_op. Then you could do if enow:
It'd probably be better to have a simple class hold data about peers instead of a tuple. tuples aren't really self documenting. BLE scans and MDNS finds use similar classes.
Thank you! Just a couple of requests.
I'd write this out. The ULP prefix isn't really needed because it is in the module name. The alarm has it as an artifact of it originating in alarm and to match the other alarm names.
{ MP_ROM_QSTR(MP_QSTR_Architecture), MP_ROM_PTR(&espulp_architecture_type) },
Please don't set self properties besides type here. Calling common_hal construct separates concerns and ensures there's one place that modifies the self state.
I did some experimenting with that a while ago, and it didn't really speed things up much
the transmission speeds are pretty good compared to the time spent calculating the pixels
I would love to have displays with fewer but bigger pixels
Agreed, there are two cases for async-ification: digitialio vs busio. Some busio-like classes, e.g., UART, have an in_waiting method that you can poll before calling receive which then won't block. This effectively transforms the second case into the first. But I notice I2C and SPI classes don't have this in_waiting method.
Using an async task with Event (at least in it's current form) does not removing the polling, it just pushes it into the C implementation of the event loop. If we are cool with this polling, then I agree there is not much to do. If we could add the "in_waiting" type methods to I2C and SPI we'd be in a good position.
However, the more advanced goal is to use hardware interrupts instead of polling to wait for events. The benefits of this are:
- it enables an O(1) implementation of "select" , instead of O(n), where n is the number of waiting objects
- it enables the CPU to go into a low power state when the event loop runs out of ready tasks
Bring adafruit/esp-idf/release/v4.4-circuitpython up to date with latest fixes in espressif/esp-idf/release/v4.4.
I checked our changes to release/v4.4 against this. No conflicts. @tannewt's https://github.com/adafruit/esp-idf/pull/10 fix has already been incorporated upstream. There are some additional fixes in that file for other things.
requirements.txt pinning was done differently by upstream. Instead of pinning certain things only on Windows, they are pinned if the python version i...
@slender iron The fix is merged into the Blinka bleio library. I commented on the PR. If they need help with updating their branch from main, someone else will need to step in. That's a huge stretch for my Git fu.
See https://github.com/adafruit/circuitpython/pull/7478 -- should probably only be merged after that PR is merged.
My impression about Event is that the task awaiting the Event would not be scheduled until the event fired (however that happened, by interrupt, or polling). There is also ThreadSafeFlag (maybe it was ThreadSafeEvent earlier). The MicroPython discussion I linked to earlier discusses using ThreadSafeFlag in interrupt handlers, though I think they mean MicroPython handlers (both hard and soft interrrupts). But there could be a similar kind of thing implemented natively. That discussion describes waiting on Events or Flags as the paradigm. https://github.com/micropython/micropython/discussions/9131. MicroPython as a native select, (maybe as uselect) and I think it's even enabled for CircuitPy, but we don't use it that I know of.
@timid bolt we are planning to discuss native events and the like with the MPy folks, as I think I mentioned
Sounds good. Let me know when that discussion will take place.
it will be just us and them, but we can pass on questions
I've looked at the MP thread a few times, but I'm unsure what the takeaway is though. Ultimately there are many ways to do this and having a crisp definition of what the goals are would help guide decision. Whether it uses the Event class or not is not really the important part. The important part is how it will enable users to do more.
Looks good. If the board will never be released, is there a reason it needs to wait for the PR?
@tulip sleet No luck with the TMP117 removing the CV class, I could do some testing removing some functionality. OR split in basic and advanced 🙂 https://github.com/adafruit/Adafruit_CircuitPython_TMP117/pull/13. let me know thanks 🙂
Dan's out for a bit today, not sure if he'll be around later this evening, or tomorrow. Simply letting you know so you have the right expectations on when you will receive a response.
Thanks :). No worries
You're welcome!
@onyx hinge are you interested in the bangle.js 2 as well?
@slender iron I have one.. but I don't really wear watches
ah, ok. maybe you can help test then 🙂
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
GEN build-itsybitsy_m4_express/genhdr/moduledefs.h
QSTR updated
File "<fstring>", line 1
(offstart=)
^
SyntaxError: invalid syntax
make: *** [../../py/py.mk:274: build-itsybitsy_m4_express/genhdr/compression.generated.h] Error 1
make: *** Waiting for unfinished jobs....```
Someone know offhand what tool I need to update (guessing?) to fix this? updated to the latest code after a while and failing. ATMEL and RP2040 ports tried
In case anyone else ever sees this error in the future the problem was python 3.7 was too old. Oops
Three people have posted about the fstring build error in the last month or two. Can the print(f"a={a}) statment in fstring.py be wrapped in a try/except block? I'm assuming if the program doesn't crash and the a=1 print message doesn't show up a more appropriate error is displayed.
never mind, it's a syntax error, try/except won't catch it :/
This might need to pull in https://github.com/espressif/esp-idf/pull/7688 to our esp-idf fork.
We now have those commits. This needs a re-test.
Kids and their fstrings these days lol. Thanks for the tip 👍
I didn't get to post a #circuitpython2023 in time but thought I'd follow up with a quick item to share...
I recently tried to mash up the asyncio and simple web server libraries. Unsuccessfully.
I would love something similar to the Python Tornado library in CircuitPython. MicroTornado if you will.
https://www.tornadoweb.org/en/stable/
Not sure if that is even the right solution today but thought I'd share.
Thank you all for your work! Hugs
I started working on async requests (not a server) here: https://github.com/dhalbert/Adafruit_CircuitPython_Requests/tree/async. That branch is now out of date, but somebody got it working (maybe with some changes -- that code was not even tested).
There are a number of MicroPython examples: https://www.google.com/search?q=asyncio+http+server+micropython&oq=asyncio+http+server+micropython
We now have those commits. This needs a re-test.
I just ordered an ESP32-S3-DevKitC-1-N32R8 and should get it Friday or Saturday.
Erased flash and loaded the bin with esptool.py v4.4. No CIRCUITPY, no REPL. It's boot looping.
The USB connector shows up as USB JTAG/serial debug unit (not good) and repeatedly displays:
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x18 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4210b312
SPIWP:0xee
Octal Flash Mode Enabled
For OPI Flash, Use Default Flash Boot Mode
mode:SLOW_RD, clock div:2
load:0x3fce3808,len:0x68
load:0x403c9700,len:0x980
load:0x40...
how can i install circuit python on NXP imx8 based board? , i have not found in the port folder
it's possible it's not supported
imx8 are Cortex-A. We have not ported CircuitPython to these processors.
Hi There:
I've developed an ESP32-S3 board and have been compiling circuit python (7.3.3 etc.) for it as per the instructions. When I do a compile I get a firmware.bin, circuitpython-firmware.bin and firmware.uf2 files. I've used the ESP Web Serial tool to upload my firmware. For some reason firmware.bin works perfectly (in Mu CP code runs perfectly). However, if I use the same ESP Web Serial tool and upload circuitpython-firmware.bin to my board it doe not work and the board goes into a...
Use firmware.bin. circuitpython-firmware.bin is not combined with the proper second-stage bootloader.
To install the UF2 bootloader, you need a build of https://github.com/adafruit/tinyuf2 for your board. If your board is straightforward, you may just be able to use an existing build for, say, one of the Espressif ESP32-S3 dev boards. To install TinyUF2, follow this procedure, more or less, but substitute the TinyUF2 build you have: https://learn.adafruit.com/adafruit-metro-esp32-s2/in...
Thanks for the fast feedback. Good to know that firmware.bin is the correct one! I'll give the UF2 a go and I will post on discord or in the forums from here on.
CircuitPython version
7.3.3
Code/REPL
import board
import time
import terminalio
import displayio
import busio
from adafruit_display_text import label
from adafruit_st7789 import ST7789
from xpt2046 import Touch
from digitalio import DigitalInOut, Direction
# Release any resources currently in use for the displays
displayio.release_displays()
TFT_WIDTH = 320
TFT_HEIGHT = 240
tft_dc = board.GP8
tft_cs = board.GP9
spi_clk = board.GP10
sp...
You don't need to toggle the pins manually, the drivers do that on their own. What is that xpt2046 module your are importing ?
Note: This looks like a support issue, they are better handled on the forums or the Adafruit discord.
The drivers should handle the CS pins internally, you don't need to toggle them yourself. It should just work. The #1760 is really about sharing the D/C and reset pins between two or more displays.
The build-arm matrix job now builds 255 boards, GitHub imposes a limit of 256 matrix jobs.
A matrix will generate a maximum of 256 jobs per workflow run. This limit applies to both GitHub-hosted and self-hosted runners.
I think we can just make a second arm-centric job to have do some ports.
@tulip sleet and @onyx hinge want to talk about rc.0 today?
Sure - i am not making a lot of progress on the long-lived wifi bugs
i have a few things to check
Looks good! Thank you!
Hello is happening for me in my Adafruit CircuitPython 8.0.0-beta.6 on 2022-12-21; Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM with ESP32S3 I am trying to connect to my home assistant, as you can see in the following code, I try to restart the micro-controller, however it does not restart, and the if the USB is connected it will freeze my ubuntu machine. I get a
Error:
[Errno 128] ENOTCONN
try:
while True:
x, y, z = [
value / adafruit_...
@tulip sleet we can always fix in another rc too
i just meant I wanted to look at some stuff before the mtg, is all
don't have any known fixes right now
@slender iron I just sat down to lunch, but can talk anywhere from 15 minutes to 4 hours from now
15 min works for me
Though Espressif has fixed and closed a number of storage leak bugs related to repeated esp_wifi_init() and esp_wifi_deinit() calls, it appears there is at least one leak still present: see https://github.com/espressif/esp-idf/issues/8446, particularly https://github.com/espressif/esp-idf/issues/8446#issuecomment-1400780650, which describes a scenario similar to what we do.
@slender iron @tulip sleet I'll be ready to join a video call as soon as my cup of tea is ready
i'm ready too
I popped in to the "amelia" channel
@slender iron we are in amelia
This is indeed not a CircuitPython issue. Instead it's a Thonny issue. Seems like it is trying to access disconnected network mapped drives. Which is reasonable since CircuitPython also uses mass storage device for accessing codes.
We see hard faults after a while on ESP and they are difficult to debug. The IDF can produce core dumps. Perhaps we should set those up so we have more debug info after the fact.
It may require changing the partition table. We can do this along with IDF 5.0 because it may require partition changes too. We may be able to shrink the TinyUF2 partition too.
FFFFBD70 is -17040 is possibly a memory allocation failure but I'll be danged if I can actually figure out mbedtls error numbers. https://github.com/espressif/arduino-esp32/issues/2286
Wow, circuitpython is y2k38 ready..
As I was setting the rtc I was expecting it to hard crash, but it just worked..
Thanks for the quick reply!
I am using an adaptation of this MicroPython driver. Waveshare did not publish their own native driver.
Thank you for pointing me to Discord. I will also try asking this there.
Pertaining to hats that use a single SPI bus for both the display and other peripherals, is that actually supported by displayio?
Are there any additional resources I can read about this?
I'm a little confused.
The LED is on board.D1, is that right?
Does PulseIn work the first time, but after deinit()-ing the PulseOut, PulseIn no logner works? Is that what you are saying is not working?
I thought that adding this cert will not turn off others, but it did and with such settings, sites that were working like adafruit quotes, stopped.
Using load_verify_locations() replaces the default certificates with the one(s) you supplied. You could switch back to the default set by. set_default_verify_paths() switches back to the default certificates. I guess you could do that, but I think you could create two SSLContext objects, and load your certificate(s) into one. Use that...
@Neradoc very kindly helped me figure this out on Discord. Closing.
I will publish the combined driver when I get all the peripherals working perfectly.
General Question regarding CircuitPython community Libraries, releases to Pypi were done automatically, however It seems that I have not update correctly my under the hood library files, as libraries are not longer updating automatically :(. any guidance would be appreciate: ex: https://pypi.org/project/circuitpython-styles/ vs https://github.com/jposada202020/CircuitPython_styles. Thanks in advance 😊Found the answer. needed to update release_pypi.yml and release_gh_yml in github workflows. 😊
Just getting them up to date for 8.0.0-rc.0
@onyx hinge @slender iron I finished the draft release notes for rc.0. I added four PR's to the 8.0.0 milestone: https://github.com/adafruit/circuitpython/milestone/30
**update frozen libraries **
#7491 opened 31 minutes ago by dhalbert
**Add frequency setting for RP2040 boards. **
#7430 opened 3 weeks ago by Lanzaa
Espressif ESP32-S3 DevKitC-1-N32R8 board New board or update to a single board
#5999 opened on Feb 9, 2022 by anecdata
**Add function for drawing polygons to bitmaptools **
#7471 opened last week by matemaciek
Of these #7491 is required. is #7430 done? #5999 was not working but would be nice to have. #7471 I think may be close to done? We can move some of these off the milestone depending on what you think.
@tulip sleet hum about the frequency changing one .. if it breaks USB that's a pretty huge caveat! I hadn't thought about that, I just concentrated on the USB aspect of it.
I guess the CI on 7491 was relatively quick because the build knows which boards have the frozen modules? have to admit that's pretty cool!
I hadn't even considered the impact on USB. Does changing the frequency at all mean USB won't work any longer?
yeah, I agree -- I was surprised
[20:13:24] >>> microcontroller.cpu.frequency=125_000_000; t0 = time.monotonic_ns(); t0; sum(range(1_000_000)); t1 = time.monotonic_ns(); (t1-t0) / 1e9
[20:13:44] 207238281250
[20:13:54] 499999500000
[20:13:54] 10.6943
[20:13:54] >>> microcontroller.cpu.frequency=300_000_000; t0 = time.monotonic_ns(); t0; sum(range(1_000_000)); t1 = time.monotonic_ns(); (t1-t0) / 1e9
[20:14:03] 226430664062
[20:14:07] 499999500000
[20:14:07] 4.45605
[20:14:07] >>> microcontroller.cpu.frequen...
why were these lines removed? doesn't it stop the clock setting from becoming effective?
[20:21:51] >>> n[0] = 0
[20:21:55] >>> n[0] = 1 # correctly changes color
[20:21:57] >>> microcontroller.cpu.frequency
[20:22:03] 250000000
[20:22:03] >>> microcontroller.cpu.frequency = 125_000_000
[20:22:06] >>> n[0] = 0 # sets incorrect color because PIO operating at wrong frequency
[20:22:08] >>> n[0] = 1
Additionally, you can see the commandline that circuitpython thinks is right for flashing each file:
flashing firmware.bin at 0:
$ make BOARD=adafruit_feather_esp32s3_4mbflash_2mbpsram -n flash
esptool.py --chip esp32s3 -p /dev/serial/by-id/usb-Espressif_ESP32-S2_0-if00 --before=default_reset --after=no_reset --baud 921600 write_flash --flash_mode qio --flash_freq 40m --flash_size 4MB 0x0000 build-adafruit_feather_esp32s3_4mbflash_2mbpsram/firmware.bin
flashing circuitpython...
@onyx hinge I saw you submitted this issue for the CI deprecation: https://github.com/jenschelkopf/issue-label-notification-action/issues/29
JavaScript isn't my first (or any) language, but I did manage to put together what we essentially need as an action
It needs a token with the proper permissions to write comments on issues, but otherwise works.
Happy to transfer over to Adafruit - I only own it now because I can't generate repositories for the org. Or just happy to own it, whatever is better/easier.
Would it make sense to change the esp32_camera module to espcamera so its more uniform with other esp specific modules?
and rename the take method to be compatible with parallel capture
I think PulseIn may not works .
import alarm library
Out of curiosity: why is this disabled on ESP32?
It is not implemented on plain ESP32 due to hardware differences. The current implementation relies on features not available on ESP32. We have an issue for this: https://github.com/adafruit/Adafruit_Protomatter/issues/48.
I'd like to argue openocd & gdb with breakpoints & line by line execution cover most use cases of coredumps.
I don't have time to actively work on code, however I could stress test espnow
I have 4 esps
Is it ready for testing?
Yes, go ahead 
The example in espnow/__init__.c is wrong. Use the docs in espnow/ESPNow.c instead.
alright thanks!
I'd like to argue openocd & gdb with breakpoints & line by line execution cover most use cases of coredumps.
Our aim here is to allow any user to send us a core dump after a hard crash, without having to do any set up. For our own purposes, yes, interactive debugging is great.
Are there any ideas that can be gleaned from Memfault's collection and debug tools for core dumps?
This is a specific feature of ESP-IDF. The "core dump" is not a full RAM dump, but an assortment of stuff that includes stack backtraces, registers, task info, etc. It's really more of a "state" dump.
that makes sense, but it could be done as an alias now, and then in 9.0.0 we would drop the old name.
Is an alias necessary? esp32_camera is not in 7.x.x and is only in CP8 pre-releases.
hmm, I didn't know that. @onyx hinge, what do you think, should we just change the name?
I am fine changing the name if there is a more consistent choice. It does need to be espressif specific in some way though
@analog bridge go ahead with a PR if you have time. I can get it into rc.0
I chose the name because the underlying library is called https://github.com/espressif/esp32-camera but that doesn't have to match
how about the take() name?
I don't think we have to be consistent with the library, since we may substitute some other library at some point
I don't recall immediately why I chose that method name
(and I'm mobile right now so I can't investigate much)
This makes the module name more uniform with other espressif specific modules.
I got this branch and merged in the latest circuitpython main, which has the latest backports (as of late December) from release/v4.4 in upstream. I erased flash and loaded the .bin. I get:
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4210b566
SPIWP:0xee
Octal Flash Mode Enabled
For OPI Flash, Use Default Flash Boot Mode
mode:SLOW_RD, clock div:1
load:0x3fce3808,len:0x68
load:0x403c9700,len:0x980
load:0x403cc...
I'm going to push this to 8.x.x unless we figure something out. It is not urgent for 8.0.0.
Updates a part of the CI with deprecation warning by using a new, custom GitHub Action. I intend to transfer this over to Adafruit, but if it makes more sense to hold onto it I'm more than happy to do so. In that case, I'll update this CI step accordingly after transferring.
Configured so that it results in the existing message from the old action step.
has anyone used transparency with ondiskbitmap? mainly curious how the desired color's index was found in the colorconverter
I just use gimp, it lets you view the palette
hmm. need to do it on the fly though. images will be grabbed from internet and stored locally. then brought in with odb.
check what color the (0,0) pixel is?
or do a histogram and pick the color that has the most pixels
hmm, maybe only count the pixels on the edges?
there are many possible heuristics, but none is foolproof
yah. no guarantee it'll be at a given location or dominate 😦
but do know it's "white"
then just iterate over the palette and find the white
that's what i'm doing with image_load
but obd doesn't provide a palette, instead it's a colorcoveter
even for indexed images?
iirc colorconverter is used for 24 bit images
indexed images use palettes
so if you know it's white, just call make_transparent with 0xffffff?
it's palette index, not hex value
ah. ok. looks like obd adapts. was working yesterday with 24 bit images.
i've changed now to 8bit, since don't need that depth
>>> type(obd.pixel_shader)
<class 'Palette'>
>>>
with 8bit you will get a palette
and now it's a palette
yeah
I just got a couple of ESP32-S2 cards - Wemos Lolin S2 Mini.
My plan is to sample some pots using the builtin adcs and send the data over USB and conventioal MIDI as MSB/LSB pairs, 32 CC's apart.
But what to do ? - the board is not on the list of boards providing usb_midi.
The board looks to my untrained eye like it has the same kind of USB connection as some other ESP32-S2 boards.
Here's a [link](https...
CircuitPython version
W5500-EVB-Pico board
adafruit-circuitpython-wiznet_w5500_evb_pico-en_GB-8.0.0-beta.6.uf2
adafruit-circuitpython-bundle-8.x-mpy-20230126
Code/REPL
import board
import busio
from adafruit_wiznet5k.adafruit_wiznet5k import WIZNET5K
import adafruit_wiznet5k.adafruit_wiznet5k_socket as socket
import adafruit_minimqtt.adafruit_minimqtt as MQTT
import digitalio
import time
##SPI0
SPI0_SCK = board.GP18
SPI0_TX = board.GP19
SPI0_...
@tulip sleet I made two small changes to the release notes draft
np should I know?
nope, that's weird, but the URL changes every time you update the draft, so if you accidentally edited an old draft, it might get confused
looks like it saved ok
(moved the note about audio playback taking in filename and remove the RISC-V note on the ulp support)
good, thanks
i deferred some PR's; only one left is the espcamera one. @onyx hinge is #7492 OK by you/
I could publish rc.0 tonight or over the weekend. Like to do it in time for Anne to get it in to the newsletter.
boy that touched a lot of files
@onyx hinge I think sed -i might have gotten a workout
I've got a 3 for 1 PR that I think could be 8.1. https://github.com/adafruit/circuitpython/compare/main...tannewt:banglejs2?expand=1
its got bangles js 2 support, jdi color memory display support and acep eink support
i can branch 8.x.x after rc.0 and before we merge that
thanks for the reminder. as usual I may encounter circuitpython-org update issues (that seems to happen often, especially just before major release 🙂 )
np 🙂
This 2-in-1 PR started with the goal of support the Bangle.js 2 smartwatch with no USB.
- Adds "secure" DFU build support with a committed private key.
- Adds 3-bit color support with one dummy bit for the JDI memory display
- Allows nrf boards to have a board_background_task() run in RUN_BACKGROUND_TASK. This is needed because the Bangle.js 2 uses the watchdog to reset.
- Renamed port_background_task() to port_background_tick() to indicate it runs on tick, not RUN_BACKGROUND_TASK.
- M...
I have been using stackless for all this time, had nothing to report on rp2, s2. c3, nrf52
I suggest it get's included in 8.1 alpha 0 so it can be publically tested.
This needs exposure and time to be deemed stable.
Once these very stable platforms are good with it, we can begin enabling it on the rest of the platforms
@brazen hatch make a PR and I'll mark it for 8.1
already is
CircuitPython version
Adafruit CircuitPython 7.1.0-beta.0 on 2021-11-12; PewPew M4 with samd51g19
Board ID:pewpew_m4
Code/REPL
N/A. code.py doesn't seem to make any difference.
Behavior
When connected via USB there is no serial connection that becomes available. i.e. /dev/ttyACM0 never appears.
Description
No response
Additional information
On version 7.0.0 the serial connection is made and /dev/ttyACM0 does appear.
On ve...
I will switch it out of draft status
k, thanks. I switched the milestone to 8.1
I will also fix the one board that is failing tomorrow, it just had seperate settings and forgor to switch them
I've narrowed it further to between these two versions:
Up to this version the serial connection behaves normally:
Adafruit CircuitPython 7.1.0-beta.1 on 2021-11-30; PewPew M4 with samd51g19
Board ID:pewpew_m4
Starting with this version the serial connection no longer appears when the device turns on.
Adafruit CircuitPython 7.1.0-beta.2 on 2021-12-10; PewPew M4 with samd51g19
Board ID:pewpew_m4
@slender iron I am not going to branch until after I make the release and then do some smoke tests before publishing and publicizing the release.
The only SAMD board I have is the Sparkfun SAMD51 Thing Plus which boots 8.0.0 so I'm wondering if the issue is caused by one of the PewPewM4 changes. Have you tried backing out these two changes?

After looking at my post, the board_deinit was added to most if not all the SAMD boards and the second change only disables the ALARM so probably not related....
Ah, I think it would be the CIRCUITPY_USB_CDC = 0 that would do it.
I made a build with that line removed and I do have serial connection again using that build. Perhaps this was an intentional change.
If I am understanding the history correctly I think this commit is where it was first added: https://github.com/adafruit/circuitpython/commit/4cf6579e2201e62988fbb6cf204037ce0d80e3f1
That commit leads back to here I think: https://github.com/adafruit/circuitpython/pull/4333
Which does look like an intentional change to save space.
Thank you @RetiredWizard! the diffs you posted got me pointed in the right direction to understand this.
I can make my own build with serial enabled for my purposes.
@lone axle I'm glad it worked out for you but it really looks to me like the CIRCUIPTY_USB_CDC = 0 line wasn't added in the beta 2 build just moved up higher in the file....
Maybe there were additional changes to the USB_CDC logic on the board level
@deshipu Did you want to turn off CDC?
That is true, in that specific diff it's just being moved to a different section of the file (into alpha order). But that line definitely seems to be what causes the serial connection to be disabled. I'm not sure if it's possible or how to tell which release came most imediately after #4333. That PR seems to be the one where it was first set to 0.
I added console and data then??
Although, maybe the location within the file can have some effect on it? I didn't test moving it back to the top, just removing it entirely (I made the assumption that value 1 would be default and enabled)
The order makes no diff
phew, I am glad for that 😅
I think there was probably another change somewhere, we were just very lucky someone decided to move it so it showed up on that diff 😁
Switched the flash mode to dout:
# Note: we use esptool.py to flash bootloader in
# dio mode for QIO/QOUT, bootloader then upgrades
# itself to quad mode during initialisation
config ESPTOOLPY_FLASHMODE
string
default "dio" if ESPTOOLPY_FLASHMODE_QIO
default "dio" if ESPTOOLPY_FLASHMODE_QOUT
default "dio" if ESPTOOLPY_FLASHMODE_DIO
default "dout" if ESPTOOLPY_FLASHMODE_DOUT
# The 1st and 2nd bootloader doesn't support opi mode,
# using fastrd in...
@tulip sleet A suggestion for release notes:
- In-place firmware update (`dualbank`) capability may be disabled in favor of a larger CIRCUITPY drive.
+ In-place firmware update (`dualbank`) capability can now be disabled (default) at runtime in favor of a larger `CIRCUITPY` drive.
Do you want to keep it MP compatible?
While I'm not the port-er, I'd be interested in maintaining compatibility with the original module on MP. I'm happy to adopt agreed changes to the api into the MP module if required.
This reduces code duplication across CI jobs.
Board (Can detect Ir remote signal)
M5Atom lite,ESP32 s2 . pca10059 , raspberry pi pico , RP2040-Zero
Board(Can't detect ir remote signal)
ESP32 C3 ( Seeed Studio XIAO ESP32C3 , M5Stack Stamp C3)
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.6 on 2022-12-21; Raspberry Pi Pico with rp2040
Board ID:raspberry_pi_pico
Adafruit CircuitPython 7.3.3 on 2022-08-29; ESP32-S3-DevKitC-1-N8R2 with ESP32S3
Board ID:espressif_esp32s3_devkitc_1_n8r2
Code/REPL
while 1:
data=input()
print(data)
Behavior
I faced unstable USB_CDC console communication.
Then I performed simple loopback test triggered from raspberry pi 3b+ to both ES...
@dhalbert no, I don't think I did, we might be able to switch off something else if there is no room
CDC got disabled on this board by mistake
This should fix #7498 7498
@deshipu Now some languages don't quite fit. These are the included modules from the last RTD build:
_stage, analogio, array, audiocore, audioio, audiomixer, board, builtins, busio, collections, digitalio, displayio, fontio, keypad, math, microcontroller, nvm, os, random, storage, struct, supervisor, synthio, sys, terminalio, time, watchdog, zlib
Frozen Modules: pew, stage, ugame
There are some specialized disablers you could use:
CIRCUITPY_BUSIO_SPI = 0 no bus...
It looks like CIRCUITPY_DUALBANK is off only on the 2MB boards? ports/espressif/mpconfigport.mk
Can you elaborate on the "instability" you encountered in your real use case ?
Your test here has a problem, since input() is for interactive use it echoes the characters it receives, so the board sends the line twice. And your test code will be reading only one line before sending another. You can show it by sending i and seeing what you read as reply. You'll receive each line in double, with the number being half of the value of i.
data_out = b'LINE\r\n'
i = 0
while True:...
95 0;code.py | 8.0.0-beta.6
This extra stuff is from the status bar, which you can disable. Is that something that's interfering?
Ya, 2MB isn't enough to have two ota partitions.
We could try disabling zlib with CIRCUITPY_ZLIB = 0 instead of current 1.
I didn't check all the languages, but did try a few and got successful builds from this branch with the change to disable zlib.
As of right now, the following platforms work with stackless:
rp2esp32s2nrf52
The tested boards are the following:
raspberry_pi_pico_wwaveshare_esp32s2_picoSeeed_XIAO_nRF52840_Sense
Pending tests:
beetle-esp32-c3
Before stackless is ready for public use, a recursion limit has to be implemented, because as of now, you can hard-crash the board with millions of recursive calls.
This is not something I can implement. I have neither the tim...
I was wondering about the word “default” in your suggested, change in the release notes, since there is no universal default
I agree with the addition of the word “runtime “; that’s a good change
dualbank is disabled by default on new firmware load, in case of an existing filesystem, the filesystem's configuration is respected
I have also been running stackless on the same chips bill88t listed for more than a year. In addition, I've been using ESP32, ESP32-Pico, ESP32-C3, ESP32-S3, MIMXRT10XX, SAMD51, BROADCOM and STM32L4 boards without any issues, although I have not been running any tests designed to look for memory/stack type errors specifically. My use typically stresses RAM usage and FLASH I/O. The peripherals I tend to use are I2c, SPI, simple PWM GPIO, the RTC and WiFi if available.
@FoamyGuy I need zlib to decode png images.
@dhalbert I think we can disable analogio, I will update the PR.
I was looking at https://github.com/adafruit/circuitpython/blob/f907f20eb98facb4d18e7cd9d2be79f1014d11bd/ports/espressif/mpconfigport.mk#L26, so on a new load, it is enabled, except on small flash boards, is that correct?
2MB:
disabled all the time, import dualbank will give ModuleNotFoundError
>2MB:
a runtime setting, import dualbank will give RuntimeError: storage is extended when disabled
dualbank is disabled by default on completely new firmware load, in case of an existing filesystem (e.g. uf2 update), the filesystem's configuration is respected
I feel like this needs to be documented, likely on the dualbank page
I will look at your newwording, and maybe we need to update the doc too https://docs.circuitpython.org/en/latest/shared-bindings/dualbank/index.html because I think this is not really written down anywhere.
Also disabled watchdog
I'll do a PR, also need to add a good example for dualbank
Thank you!
to be clear, the module is available on all boards (except 2MB boards) but the drive is now formatted in extended mode by default (thus the module is disabled until reformatting in non-extended)
right ?
disabled/enabled vs available/builtin/compiled in/whatever ?
@tulip sleet I updated #5999, can you do a re-test.
thanks for working on that
do you have that board?
ya, that sums it up + any existing filesystem configuration will be respected, for e.g. on uf2 load, existing filesystem extension setting is kept
no, but it should work now, opi flash needs to be flashed in dout mode
so i need different args on the esptool.py command line
yes:
# Note: we use esptool.py to flash bootloader in
# dio mode for QIO/QOUT, bootloader then upgrades
# itself to quad mode during initialisation
config ESPTOOLPY_FLASHMODE
string
default "dio" if ESPTOOLPY_FLASHMODE_QIO
default "dio" if ESPTOOLPY_FLASHMODE_QOUT
default "dio" if ESPTOOLPY_FLASHMODE_DIO
default "dout" if ESPTOOLPY_FLASHMODE_DOUT
# The 1st and 2nd bootloader doesn't support opi mode,
# using fastrd instead. For now the ESPTOOL doesn't support
# fasted (see ESPTOOL-274), using dout instead. In ROM the flash mode
# information get from efuse, so don't care this dout choice.
default "dout" if ESPTOOLPY_FLASHMODE_OPI
so the web-based flasher may not work, I wonder?
I don't know about that but we should be defining these ESPTOOL settings in the sdkconfig as that is what multiple idf tools use
currently these settings are overridden by those defined in mpconfigboard.mk
are the settings embedded in the .bin?
i am getting Warning: Image file at 0x0 is protected with a hash checksum, so not changing the flash mode setting. Use the --flash_mode=keep option instead of --flash_mode=dout in order to remove this warning, or use the --dont-append-digest option for the elf2image command in order to generate an image file without a hash checksum when trying to specify on the cmd line
if i don't specify, it loads but then boot loops
is this with a new firmware built with dout?
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4210b566
SPIWP:0xee
Octal Flash Mode Enabled
For OPI Flash, Use Default Flash Boot Mode
mode:SLOW_RD, clock div:2
load:0x3fce3808,len:0x68
load:0x403c9700,len:0x980
load:0x403cc700,len:0x2574
entry 0x403c98a4
I took the artifact from #5999
@tulip sleet can you try dio flash mode
I think I will need to build it myself, since I can't override the flash mode to esptool.py
(as implied by the error msg above??)
changed to dio in mpconfigboard.mk, still bootlooping, v similar to above (Saved PC is diff)
Can someone help me with creating a VID/PID pair for the Flipper Zero WiFi Dev Board?
I've forked the repo, but I'm not sure what folder to make in the org folder.
@tulip sleet flash this using:
CIRCUITPY_ESP_FLASH_MODE=dio
CIRCUITPY_ESP_FLASH_FREQ=80m
CIRCUITPY_ESP_FLASH_SIZE=32MB
bootloop:
SP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4210a89e
SPIWP:0xee
Octal Flash Mode Enabled
For OPI Flash, Use Default Flash Boot Mode
mode:SLOW_RD, clock div:1
load:0x3fce3808,len:0x68
load:0x403c9700,len:0x980
load:0x403cc700,len:0x25a0
entry 0x403c98a4
I am also getting messages:
WARNING: Flasher stub doesn't fully support flash size larger than 16MB, in case of failure use --no-stub. for both esptool.py 3.3.2 and 4.4
I think this PR has not been merged from main recently. There are esp-idf changes which may help this which are in the recent PR I did to update the esp-idf
I updated the PR to get the recent v4.4 commits
I am doing another build with octal flash enabled in sdkconfig.
@tulip sleet flash this using:
CIRCUITPY_ESP_FLASH_MODE=dout
CIRCUITPY_ESP_FLASH_FREQ=80m
CIRCUITPY_ESP_FLASH_SIZE=32MB
is it possible to build like this with some syntax ? Setting a define on build
make BOARD=raspberry_pi_pico CFLAGS="-DCIRCUITPY_SKIP_SAFE_MODE_WAIT"
that is only setting it in cpp; try make ... CIRCUITPY_SKIP_SAFE_MODE_WAIT=1. That will set it in make, and then the .mk files will define the CFLAGS version (assuming they are set up that way)
ah thanks, I don't remember if I tried that !
and I assume it's not possible to overwrite boardconfig.mk (since the CIRCUITPY_* are not set conditionally there)
why doesn't OnDiskBitmap like this BMP? it works with adafruit_imageload, but ODB has a skipped columns appearance
Adafruit CircuitPython 7.3.3 on 2022-08-29; Adafruit Matrix Portal M4 with samd51j19
>>> from adafruit_matrixportal.matrixportal import MatrixPortal
>>> import displayio
>>> import adafruit_imageload
>>> mp = MatrixPortal()
>>> odb = displayio.OnDiskBitmap('image-formatter.bmp')
>>> tg1 = displayio.TileGrid(odb, pixel_shader=odb.pixel_shader)
>>> mp.splash.append(tg1)
>>> bmp, pal = adafruit_imageload.load('image-formatter.bmp')
>>> tg2 = displayio.TileGrid(bmp, pixel_shader=pal)
>>> mp.splash.append(tg2)
>>>
🎉
code.py output:
Hello World!
Code done running.
Adafruit CircuitPython 7.2.0-alpha.1-113-g401d160c5-dirty on 2023-01-28; ESP32-S3-DevKitC-1-N32R8 with ESP32S3
>>>
Finally... 🥳
still wondering if we'll need special args on esptool.py, I'll try a plain flash with no args after the artifact builds
I think that's right
I just always edit the board file
or maybe it does force override... you could try it
but i don't think so
I don't know which repo you mean
Basically, the esptool settings in mpconfigboard.mk have to be removed for all boards, it just creates two sources of information and messes things up
but we need them for the esptool.py flash etc. targets in Makefile??
the problem is not using cmake, maybe (??????)
i have to keep re-deriving how our build process works
i forget
https://github.com/pidcodes/pidcodes.github.com is the repo. I'm following the instructions from https://pid.codes/howto/ to make the pair.
what VID/PID is the Flipper using already?
They can be inferred from sdkconfig with some parser script or maybe idf has some way to do it, I just want to have one true source of information.
Why does it have to be sdkconfig? Because it is known to idf as the only source of config information.
As for espressif_esp32s3_devkitc_1_n32r8. For now setting CONFIG_ESPTOOLPY_OCT_FLASH=y in board's sdkconfig should work with dout mode.
And yes the bin does contain these flash config settings
This can be viewed by using esptool.py image_info --version 2 *.bin. (available in idf v5.0)
agree with that, we can work on that. I'll retest when the rebuild is done. will be afk for a while in a little while. If it works I'll merge for rc.0
wahoo excellent detective work you two
i am just the tester 🙂
i am just hacking things together 🙂
It's using the Saola 1 w/WROVER pair at the moment, since that's the board I used as a base.
@onyx hinge thank you in any case
That is weird. I don't know what is making it do that. I opened it in GIMP and re-exported without changing anything, the resulting bmp is a different size and when drawn by displayio doesn't have a different between odb and imageload
i mean if you plugged in the Flipper now, what VID/PID's does it use?
without circuitpython
for its custom firmware or whatever
The Dev Board? I'm not sure how to check it.
an actual Flipper, I eman
I have verified that the call to xRingbufferReceive() in update_internal_buffer() works on an ESP32S3, but always returns 0 on an ESP32C3. So, no pulses will ever show up. I'll continue to investigate.
same here. both saving / not saving colorspace work when exporting from GIMP. maybe some clues here?
$ file image-formatter.bmp
image-formatter.bmp: PC bitmap, Windows 98/2000 and newer format, 64 x 32 x 8
$ file image-formatter2.bmp
image-formatter2.bmp: PC bitmap, Windows 3.x format, 64 x 32 x 8, image size 2048, resolution 2835 x 2835 px/m, 256 important colors, cbSize 3126, bits offset 1078
$ file image-formatter3.bmp
image-formatter3.bmp: PC bitmap, Windows 95/NT4 and newer format, 64 x 32 x 24
first is original that does not work
2 is exported from GIMP with "do not write color space" selected
3 is same but with option selected
both GIMP exported ones work
lsusb
interesting. The raw data diff shows a difference in the first part and then same data after that. (albeit, not so happily about reading binary data as text)
There must be some additional configuration or something in the header causing a difference.
ah CIRCUITPY_SKIP_SAFE_MODE_WAIT is a bad example, it's not in the makefile (there's literally a single occurence of it, the ifdef)
also we try not to use ifdef, instead using if so we can catch typos
yep. most likely something being mishandled in header.
When I plug my flipper in, Windows displays VID_0483&PID_5740 I don't have the WiFi Dev board though, that has it's own ESP chip I believe.
and USB port....
How do I use lusb to see the Flipper's VID/PID pair? I'm porting CircuitPython to the WiFi Dev Board for, not the actual Flipper.
I can check the Dev Board since I have one.
Wikipedia has a decent looking listing of the header: https://en.wikipedia.org/wiki/BMP_file_format#Bitmap_file_header I've never delved into the details of it that far before, but I'm curious about what could be causing it, next week I'll try to compare imageload code to the core code inside of ODB to see if I can spot anything that would account for it.
The BMP file format or bitmap, is a raster graphics image file format used to store bitmap digital images, independently of the display device (such as a graphics adapter), especially on Microsoft Windows and OS/2 operating systems.
The BMP file format is capable of storing two-dimensional digital images both monochrome and color, in various col...
you connect it, and you type "lsusb" in the linux terminal, and press enter, it will list vid and pid numbers of all devices connected to usb
0483 / 5720 is STM's "Mass Storage Device" VID/PID
The flipper does use an STM chip in the main unit
Would you like me to use the firmware that the Dev Board is shipped with?
as long as it has a usable vid/pid that you could reuse
Alright. I'll re-flash the blackmagic firmware and check.
cool. thanks! please ping me with any updates.
Will do. Here is a slightly more helpful way to visualize the difference.
this is why I switched to png as soon as I figured out how to read it
@tulip sleet I pushed a commit enabling octal flash in sdkconfig
https://github.com/adafruit/circuitpython/pull/5999/commits/858e212e34f9ffaaa1c2b5b17331e52bf780b6ad
ok I added it to circuitpy_mpconfig.mk (and used #if), and it works now. Good to know. (And I can PR that too)
👍 they are in alphabetical order, if you did not already do that
Thanks - there are a lot of other ideas that Memfault uses to assist developers in collecting data besides full device coredumps; such as backtraces, debug registers, logs, and custom metrics. ( I have nothing to gain, but have learned from their interrupt blog.
🎉REPL and CIRCUITPY 🎉
Adafruit CircuitPython 8.0.0-beta.6-63-gb8fa2c641-dirty on 2023-01-28; ESP32-S3-DevKitC-1-N32R8 with ESP32S3
>>> import os
>>> os.statvfs("/")
(2048, 2048, 15176, 15172, 15172, 0, 0, 0, 0, 255)
303a/4001 is the VID/PID pair for the Blackmagic firmware.
Thank you @MicroDev1, and thanks @anecdata for the final test!
303a is Espressif's VID. Espressif allocates PIDs to customers here: https://github.com/espressif/usb-pids. But 4001 is Espressif's own PID -- the BlackMagic sw is just reusing that. Ideally the Flipper's developers would submit a PR to that repo to get a PID. You are not an official rep of Flipper, so you can't do that.
pid.codes would not be involved here
I guess I'll head to them for that. Thanks.
Espressif might give it out to you, example: https://github.com/adafruit/circuitpython/pull/6079.
if the wifi module were essentially just a module on a board with no changes, then you could just use the module PID. But you want to add a new board here, right, so there's something different you want to include that does not match an existing board
so what is extra/different on this board?
@solid juniper see last post above ^^
Is there a good way to allocate aligned memory in CP/MP?
Heap blocks are 16 bytes each, aligned
Yeah, any bigger than that though? For a ring buffer aligned to its size.
I don't think there's any API for that. What needs that alignment?
You can setup rp2 dma to work on a ring buffer. It's more efficient if you can use a ring buffer to stream data to/from a peripheral.
but it has to be aligned to the buffer size, hmm?
yes, for the pointer arithmetic to work
i have no answer, sorry, I don't think we use that technique anywhere .
I've set an inverted PWM RGB LED in CircuitPython, since the board's RGB LED is 3 LEDS (Blue to IO4, Green to IO5, and Red to IO6). IO3 isn't broken out, but it is an I2C Pull Up pin. IO45 and IO46 aren't used or broken out, and go to GND. IO0 isn't broken out, but the BOOT button is attached to it.
No worries. There's an old trick where you can allocated twice as much memory and find your aligned chunk inside it. But seems too wasteful for a limited resource microcontroller.
got it, thanks, so would make sense to ask Espressif directly or indirectly for a CircuitPython PID
I can make a PR on their repo.
Lots of examples of getting PIDs for other boards: https://github.com/adafruit/circuitpython/pulls?q=is%3Apr+"espressif%2Fusb-pids"
there's a #ifdef CIRCUITPY_ULAB I noticed that would always be true, wouldn't it ?
https://github.com/adafruit/circuitpython/blob/cc822e0d8d4fd7af22b403835e375c79421ac693/shared-bindings/adafruit_pixelbuf/PixelBuf.c#L43
Neradoc, thank you for your support.
Can you elaborate on the "instability" you encountered in your real use case ?
I use Raspberry pi PICO for controlling Neopixel (900pcs LED, 1 channel) via USB_CDC console from Raspberry pi 3B+(or 4B) serial function node on node-red 3.0.2.
I use Neopixel as a display, therefore long time stable work needed at least 12 hours.
I face 1 or 2 times freeze in one day.
(Fortunately, Neopixel update cycle is not so frequent. About 10 times / 3 seconds. ...
Yup, that's wrong, though I assume it has no effect, since it's just an #include.
Also uses #if instead of #ifdef.
Changes one #ifdef CIRCUITPY_ULAB info #if.
Note: I was testing adding build settings to the make command to make special builds or disable modules for a debug build without editing the files, which works if the setting is in mpconfig.mk and not set unconditionally.
usb_midi is there allready it seems
followed this page: https://learn.adafruit.com/customizing-usb-devices-in-circuitpython/circuitpy-midi-serial
added a "boot.py":
import usb_hid, usb_midi
# On some boards, we need to give up HID to accomodate MIDI.
usb_hid.disable()
usb_midi.enable()
And the device shows up in windows.
woops! Anyone know the status os Venture 13.2 and UF2 ? I'm staying on 13.1... but I have a user reporting he cant copy over CPY firmware onto his ProS3 UFT drive... like what was happening in 13.01
we haven't heard this yet, that's too bad if true. I can upgrade one machine to 13.2 and see what happens
Ok, thanks.. I only have the 1 Mac atm, and cant risk moving to 13.2 if it's busted again 😦
is it a UF2 or a .hex that is not uploading properly/
.uf2 CPY file
It is also still true that copying .hex files larger than 1MB does not work (e.g., on the micro:bit). See https://github.com/ARMmbed/DAPLink/issues/982 for workarounds and further investigation.
He tried dragging and copy -X
I'll try, and complain right away if it's broken again 😦
I'm working with the guy to re-flash everything from scratch
a Mac is all he has? no RPi lying around?
he has a Linux install, and he's also having issues there... so though he is getting into UF2 bootloader mode, I think he's trashed his flash putting things in the wrong place.
I am updating but this is a 2017 Macbook, will be a while
Ok, I'll report back once I have had him erase and re-flash
Yeah, false alarm... an erase_flash and re-flash of the UF2 bootloader got the board back into a usable state and he was able to copy CPY over wit drag and drop! few!
Sorry @tulip sleet
whew, well, I'll upgrade and test anyway, may as well. No problem.
Some modbus support would be very helpful! Many high-accuracy devices are only available with modbus.
Confirming: dragging UF2 works fine on Ventura 13.2.
Woohoo! Yay Apple 😉
Thanks very much for confirming !
dhalbert, I disabled status bar and tried loopback test.
I found extra stuffs were gone, but same output as ESP32-S3.
I think status bar does not cause instability.
PICO : freeze at xxx cycle
xxx abc12345
xxx abc12345
Why do you have esp32c3 so much?
Me:
Preparing the issue now.
It's so easy to reproduce
TLDR; serial is useless
I too have now tested C3 with stackless, all good.
I would have liked to also test the old esp32, but I don't have any, so I will take RetiredWizard's word that it works.
I will publish my memory testing utils later.
does that say beta 5 ?
yep, I did flash latest stackless onto it now though
It has been like that since forever, it's not version specific.
Tested stackless and now threw back in the box of cursed electronics.
Thanks for the update. I am suggesting some copyedits and a cross-reference to the explanation in storage.erase_filesystem().
//| This module is unavailable as the flash is only large enough for one app partition.
//| two identical app partitions, which can contain different firmware versions.
//| :param ReadableBuffer buffer: The entire firmware or a partial chunk. Buffer will be written starting at ``offset``.
//| :param int offset: Start writing at this offset in the app partition.
Thanks @jposada202020, @wtuemura, and @bergdahl!
I asked a question about synchronous PWM on two pins and was redirected here by mikeysklar. It was suggested that this might have general application in other areas.
My immediate application requires synchronized PWM on two pins. Each pin represents half a cycle. Pulses are equally spaced. If the duty cycle is set 50% then each pin would have a square-wave and they would be 180° out of phase. Decreasing the duty cycle preserves the frequency, but the on time of each pin is decreased. The ...
This may be due to library issues in the Wiznet or the MQTT libraries. I'm going to move this to the MQTT library for now. Do you see the same thing if you use WiFi (on another board, obviously)?
I think this would be possible, but there are many variations on the theme here, and I'm not sure we could come up with a useful general API. The capabilities may also vary per chip family. PIO on the RP2040 may make programming it possible in CircuitPython. Otherwise getting into the register settings would be necessary at the C level, lower than Arduino.
In terms of hardware, if you just added an external inverter to the pin, would that introduce enough undesirable phase shift and mess u...
I forgot to add, I am using an ATSAMD51 based board (Metro M4 and ItsyBitsy M4), not an RP2040. I can, of course, bit-bang for testing. My only real limitations are, a) keep the frequency high enough to avoid core saturation, and b) no pulse overlap. So, yes, an inverter would work in the case of a 50% duty cycle. It doesn't work in the case of reduced duty cycle because the duty cycle of the pins must decrease at the same rate to keep the power symmetrical.
You are right, if wanting to u...
I ended up writing a serial transfer program to copy files character by character checking that each one made it correctly to get things on the C3. If I tried to transmit more than one character at a time I ran into problems. Once the code is on the C3 the serial issue isn't as frustrating, occasionally commands typed in the REPL drop a character but probably only when I'm typing fast 😁. I keep one of the C3s on my network with a static IP address just so I can bookmark the webpage as a jumping off point to find dynamic IP addresses of whatever boards I'm working on. It also runs a neopixel color wheel just for fun 😁 At some point if you don't beat me to it, I'll try and nail down a simple script demonstrating the problem and open an issue.
When I first got the C3 it was totally unusable, the REPL was insane so I was very happy when it got some attention during the web workflow rollout and at least became usable.
the moment you throw something like jcurses onto it and do ansi escape stuff, it becomes a meme
Doing proper tags once in a while is refreshing.
You can now sit and relax enjoying the cool repl.
I remember when I was doing the picow-ap I had made it to -150..
I would like to request GPIO pin manipulation by port instead of by bit. In some cases reading/writing to port bits can be slow.
Automated website update for release 8.0.0-rc.1 by Blinka.
New boards:
- m5stack_stick_c
- m5stack_atom_echo
- doit_esp32_devkit_v1
- m5stack_atom_u
- adafruit_feather_esp32s2_reverse_tft
- espressif_esp32s3_devkitc_1_n32r8
- m5stack_atom_matrix
- adafruit_feather_esp32s3_reverse_tft
- e_fidget
- 0xcb_helios
- nullbits_bit_c_pro
- waveshare_rp2040_lcd_1_28
From readthedocs logs:
git clone --no-single-branch --depth 50 https://github.com/adafruit/circuitpython .
git checkout --force origin/main
git clean -d -f -f
asdf global python 3.11.0
python -mvirtualenv
python -m pip install --upgrade --no-cache-dir pip setuptools=0.7,<0.8,!=0.7.5 commonmark==0.9.1 recommonmark==0.5.0 sphinx sphinx-rtd-theme readthedocs-sphinx-ext<2.3
python -m pip install --exists-action=w --no-cache-dir -r requirements-doc.txt
python tools/ci_fetch_deps.py...
Thanks for the update. @RetiredWizard
I will check BPI-Bit-S2.
The following changes are needed:
- python tools/ci_fetch_deps.py docs HEAD
+ python tools/ci_fetch_deps.py build-doc
Add the following if tags are needed.
git fetch --no-recurse-submodules --shallow-since="2021-07-01" --tags https://github.com/adafruit/circuitpython HEAD
git fetch --no-recurse-submodules --shallow-since="2021-07-01" origin HEAD
git repack -d
Came across this while trying to get CP running on the board.
https://files.seeedstudio.com/wiki/XIAO_WiFi/Resources/Seeeduino-XIAO-ESP32C3-SCH.pdf
git repack -d
curious why it's worth spending time repacking when not many git operations will be done subsequent to this.
curious why it's worth spending time repacking when not many git operations will be done subsequent to this.
It exits immediately with the message Nothing new to repack.
See: https://stackoverflow.com/questions/63878612/git-fatal-error-in-object-unshallow-sha-1#comment118418373_63879454
Some kind of MultiDigitalInOut could be interesting. You might investigate PIO on RP2040 if you are using RP2040.
Thanks for all the help with this. I haven't tried flashing a build directly before, so I will give that a try!
I am not sure we need tags for the RTD build. I don't know how to check that without proposing just the first change and then merging it.
Fixes #7507, based on @MicroDev1 's suggestions in that issue.
I was having trouble flashing CircuitPython to the Seeed xiao esp32c3 using the make flash option. With the help of DAN and Neradoc I was able to perform a manual flash and use the make flash option to flash an Adafruit_qtpy_esp32c3 bin but when I went back and attempted to use make flash on the seeed bin it didn't work. After making this change the seeed build now flashes properly using make flash.
I just tried this on 8.0.0-rc.1 and didn't see the issue.
I tried to flash the beta 3 version to confirm the error in the older version but couldn't get it to flash successfully. I'll give it a go again after I get some sleep.
Configure LED pin for STATUS display.
The LED on this board does not go off after reset because GPIO0 on which it is located remains high after reset.
Refer to the description of Chip Boot Control (BOOTCTRL) in this Technical Reference Manual.
But I think it may still be necessary to enable this configuration.
Thank @RetiredWizard for reminding me.
I looked at the original issue again and realized the issue didn't happen all the time so I created a code.py file with the test script and I did get the Unknown system firmware error: 30 message once. I've been trying for a few minutes to recreate it using various power/cycle ctrl-d combinations and haven't been able to make it happen a second time.
This LED can be turned off or on normally in circuitpython.
The main purpose of placing it at GPIO 0 is to allow the user to quickly confirm that the board is powered on.
Okay to produce this reliably:
input('press enter to run code.py....')
from adafruit_ble_radio import Radio
radio = Radio(channel=1)
radio.send('test')
nprint('test done')
from adafruit_ble_radio import Radio
radio = Radio(channel=1)
radio.send('test')
print('test done')
Ctrl-D or powercycle
press enter to get to REPL
type: import test
Those code snippets produce the same error on the Luatos Core-ESP32C3 board on 8.0.0-rc.1 so not Xiao-specific:
press enter to run code.py....
test done
Code done running.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 8.0.0-rc.1 on 2023-01-30; Luatos Core-ESP32C3 with ESP32-C3
>>> import test
Traceback (most recent call last):
File "<stdin>", line 1, in <...
I tried USB_CDC.data and USB__CDC.console both.
serial = usb_cdc.data
while 1:
data=serial.readline()
serial.write(data)
serial = usb_cdc.console
while 1:
data=serial.readline()
serial.write(data)
PICO:
USB_CDC.data -> works very stable more than 24hours
USB_CDC.console -> unstable, I got a message of Reloading.
I can use USB_CDC.data for my purpose but I cannot use USB_CDC.console insted of input()/print().
66731 abc123...
When behavior changes based on "run directly in code.py" vs "in imported code" I immediately suspect objects that are incompatible with the "long lived allocator", which selectively moves some objects from lower addresses to higher addresses at various times, including when a module that is being imported finishes being executed. For example, it could be some native object owned by the Radio object.
@MicroDev1 Thank you -- that one-line fix worked:

In the BLE Workflow, CIRCUITPY_BLE_NAME in settings.toml allows definition of the advertised name. This is useful when multiple boards are within range.
When multiple boards with web workflow enabled on the same network, it would be useful to have an equivalent CIRCUITPY_WEB_NAME.

Does anyone have insight into the IS31FL3741 library / core module development? I'm curious whether the core module class documented here: https://docs.circuitpython.org/en/latest/shared-bindings/is31fl3741/index.html#is31fl3741.IS31FL3741 (not available on very many devices).
Is intended to have the same functionality as the python implementation of a class with the same name inside the library. It's documented here: https://docs.circuitpython.org/projects/is31fl3741/en/latest/api.html#adafruit_is31fl3741.IS31FL3741
They seem to have similar functionality, but perhaps not 100% the same. I don't know whether that is intentional or not though, or whether it would make sense to try to modify one or the other to make them match so one is a drop in replacement for the other.
Who was the author? Scot, or maybe Ladyada?
On the library side the absolute oldest commits are from Ladyada, but several of the early ones are from Paint Your Dragon. I'm not sure about the core side of things.
@lone axle I think gamblor did the core side
Uh oh, todays status file for the meeting seems to have had trouble generating: https://adafruit-circuit-python.s3.amazonaws.com/adabot/bin/reports/circuitpython_library_report_20230130.txt
Yesterday's is good, so I am going to copy from there for the notes doc today.
Oh! I came to bring this up!
I triggered a rerun, not sure if it was a fluke failure or something systemic but I don't think anything was change in adabot to trigger this.
It may generate a new report in time, but worst case it'll help diagnose whether it's an actual issue.
Thank you!
@lone axle Looks like it should generate in time and that it was a fluke failure - want me to update the document when it's done?
Sure, that would be great. Thank you.
@lone axle are you running the mtg or kattni (it's just that you're top of the list in the round-robins, so I wasn't sure)
Updated the doc
I am running today. Kattni asked me to cover for today.
Is there a document for the meeting?
CircuitPython Weekly Meeting for January 30, 2023 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to par...
(I was pulling it up literally as you posted that.)
@timid bolt ^^ (should have replied to your message)
Is there are standard place to find the docs, or do we just wait for the link here?
A message with the link for the relevant (active meeting or upcoming meeting) document is pinned to this channel
thank you
<@&356864093652516868> the weekly meeting will begin here on discord in just under 30 minutes from now. The notes doc is here https://docs.google.com/document/d/1kv7EzMdwVLd8ODEcqrHhSPrz_MGrS5Q9qMI6CgXBbXg/edit?usp=sharing if you'd like to add your status updates and hug reports to it. We look forward to seeing everyone during the meeting!
CircuitPython Weekly Meeting for January 30, 2023 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to par...
You can find old meeting notes at https://github.com/adafruit-circuitpython-weekly-meeting
Hey folks - we're finishing up our internal meeting. Might be a couple of minutes over.
I wrote a relatively quick and simple script to upload changed files to a #CircuitPython board that supports the web workflow. It's not fully featured, but figured I'd share it for others to use. I throw it in a project, and invoke it with PyCharm's run when I want to upload.
You can find it at https://github.com/PheebeUK/circuitpython-upload
Working on a smöl TFT bff for the Qt Py https://mastodon.social/@Oakdevtech/109764516959695403
More small circuitpython displays 🙂
🙂
What if all the pins were near one of the ends?
They could, but I figured it would be better if it was centered.
@ornate breach is it designed to go "under", like the neopixel 5x5 bff is?
Yeah
I also wondered a little bit about interference with the usb connector but it's probably fine
Hmm… I just feel like having the USB uncovered would be good, so you can more easily grip the cable. Definitely not gonna get in the way of the connector itself tho
If done right, you could use a battery bff and have a tiny mobile display
Maybe two versions? :0
🤷♂️
The display components mean you need to add a spacer
So USB shouldn’t be an issue
Just might be a little harder to grip the cable end to pull out
Since you’d need to grab the sides instead of the top and bottom
There shouldn’t be any issue but I’ll try out when ever I get the PCB and parts.
I don’t think it’ll be a problem problem, just maybe less than ideal
@timid bolt in the Status Updates section, I moved your report so it's in alphabetical order, in case you are looking for it
@lone axle Feel free to ping me about the IS31FL3741. I spent a lot of time in that and have done a bit of work getting it running on non-standard displays/boards too.
Will do, thank you!
Ahh, sorry, I didn't know that was the convention.
@lone axle I feel like my wife did some work on making them work with the LED Animation library. I don't know if it's still sitting around or not, but I can check if you're interested.
No worries! We didn't mention it!
@timid bolt the idea it's the host first, then everyone else in alphabetical order. but whatever's in the document, we roll with it
Yep, there is a helper class that Rose made that adapts the glasses to work with led_animation. I think it can become the basis for one for the matrix as well.
Pretty certain I had the animations working based on her work too. Via python or core implementations. Have to go look at my original code again
Ah ok, I didn't realise we pushed it. Huzzah!
Nice ok.
👍
[my colleague just informed me that I failed at alphabetical order 🤣 back to school for me]
Wait @onyx hinge , I would like a CP board to be a SNES mouse as I could not find one and I have a physical game that requires that...
Wondering how hard it would be the opposite of what you are doing, pretending to be a legacy hardware? Like SNES joystick (or mouse), or PS2 keyboard or ...
sounds like you want something like tasbot @thorny jay
TASBot is a tool-assisted speedrun robot/mascot created in 2013, developed by a team led by dwangoAC. The robot takes a list of controller inputs which it then sends to a console such as a Nintendo Entertainment System or Super Nintendo Entertainment System (SNES) directly via signals to the controller ports.
TASBot is known for its appearances ...
For sure!
Emulating a peripheral sounds easier than emulating a whole console
YAY, thanks!!
my gut tells me that rp2040 with pio should be a good platform for making an nes/snes controller emulator but as I don't have either I'm not going to dip my toes in
You "just" need to repeatedly load and scan out an 8- or 16-bit value from the microcontroller, according to the incoming clock and strobe signals.
and of course promptly update the values which will be one challenge
definitely sounds doable with pio
for joypad style just repeating the old value when none is available should be fine; for mouse you'd need to repeat a packet with no additional X or Y movement reported. It should all be possible though
Could the example in the community libraries be the benchmark so others folks could update their work. https://github.com/tannewt/CircuitPython_Example/tree/4a55a4a6d820ac80d511ee7ccc28f9e5b207e189. That way we could track the updates done.
I agree that documentation is far more feasible and digestible as well from the user perspective.
Awesome, thanks y'all!
That was essentially all of my wrap up, so big fan (at least a specific corner of tooling).
I am curious at exploring live plotting and looking to create a matplotlib like library, but that's mostly the kind of thing I want to see this year--anything that makes it easier to 'see if the circuit is working' kind of thing (I'm planning on trying to make a plotting library this year, so who knows if it'll actually happen)
ChatGPT could do it
CircuitGPT
perhaps a minimized PR-type CI that users could use to build on Github, but just for one board
ping me if you need anything with that. I love the idea 🙂
yeah and expensive if you can't do it on github/microsoft's dime
I haven't finished writing my Circuit Python 2023 (which is fine to me, I saw it as more an exercise for me to roadmap what I want to work on this year) so this is my "I need to say it outloud to commit to this project" thing, I will definitely ask for some help once I spin it up
🙂 no worries.
Next meeting is Monday February 6, 2023, at 2pmET/11amPT!
Cheers
thanks for hosting!
Thanks!
Thanks
Thank you all, have a great week!
@blissful pollen circuitpython file "LICENSE_MicroPython" says that asf4 and mynewt-nimble are already Apache-2.0 licensed items. I did not verify this specifically but if accurate it would mean that we've already got Apache 2.0 licensed stuff in the mix
Thanks, I'll cross reference those as well. My other option was to e-mail the author if need be and ask them. Hopefully not needed.
Based on https://github.com/adafruit/circuitpython/pull/7497/commits/78aca074bacb1b428e278adaed9b93240753e68a.
Cache only submodules in tools/, not the whole directory.
List is from:
$ ag "path = tools" --nonumbers .gitmodules |sort
path = tools/adabot
path = tools/bitmap_font
path = tools/huffman
path = tools/python-semver
path = tools/Tecate-bitmap-fonts
path = tools/uf2
path = tools/usb_descriptor
Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1BAM7-G2YJIgL8ptZG8rY5rKig1ptj1nfbDeuzX6dQzA/edit?usp=sharing
CircuitPython Weekly Meeting for February 6, 2023 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to pa...
Directories are allowed here. Only the submodule paths are fed to actions/cache.
Following line does the conversion:
https://github.com/adafruit/circuitpython/blob/72981cf2abf9b58074228062e8d8fdfd1bd53bdc/.github/actions/fetch_submodules/action.yml#L41
From the logs:
Run actions/cache@v3
with:
path: .git/modules/
extmod/ulab
lib/adafruit_floppy
lib/axtls
lib/berkeley-db-1.xx
lib/certificates/nina-fw
lib/libffi
lib/mbedtls
lib/mp3
lib/nrfutil
...
Do you understand why @tannewt found https://github.com/adafruit/circuitpython/commit/78aca074bacb1b428e278adaed9b93240753e68a necessary, then? He saw a build fail that seemed to be due to caching an old version of something (not a submodule) in tools/
@blissful pollen do you know if this python library class: https://docs.circuitpython.org/projects/is31fl3741/en/latest/api.html#adafruit_is31fl3741.IS31FL3741 is meant to be the same as this one implemented in the core module? https://docs.circuitpython.org/en/latest/shared-bindings/is31fl3741/index.html#is31fl3741.IS31FL3741 Or really the question is do they provide different functionality?
To me it looks like two different implementations with mostly the same functionality, but minor differences in the API.
There is code like this PixelBuf wrapper that seems to want to make use of the core module and currently doesn't work with the python library one. https://github.com/adafruit/Adafruit_CircuitPython_IS31FL3741/blob/main/adafruit_is31fl3741/is31fl3741_pixelbuf.py
If those two classes are ultimately providing the same functionalities we might benefit by equalizing the APIs so that either can be used in place of each other (with the core one being likely faster, but not available on all devices.)
It was an older version of the caching code. Perhaps this new version works ok.
aha, ok, I'll close this for now, then
@gilded cradle PlatformDetect had a botched release caused by a fault in my previous PR, fix submitted.
Oh you already have an issue for it
storage.erase_filesystem() hanged on picow once. (I waited 3 minutes)
Powercycling the board, it was not erased.
Doing it again worked.
Weird.
The core was meant to be close the python (as the python class was written first). But they both are basically the driver to the chip at the lowest level that the PixelBuf/DisplayIO type classes can use to access the chip.
Same thing with the _Pixelbuf.py and led_glasses_animation.py. The pixelbuf is meant to work with the core changes I made vs the python only. The speed is the main difference.
Also as of now the IS31FL3741 core code is only compiled in the glasses board, though I have tried it successfully on other boards compiling it in manually.
the IS31FL3741_pixelbuf calls self.is31fl3741.write(self.mapping, buffer) from _transmit, but the python class doesn't have a write(), we had to add it to make it work
Ahh, thank you! I'm going to try tinkering with the them a bit to see if it's possible that we can get it to where led_animations can work the same whether you use the core or the python class.
Yeah, I'm just about to jump back in, and was thinking I would try adding write into that class itself rather than in user code. To try to have the API match closer the core one.
yep
Hmmm I never did upload my full code for the "sports team glasses" to github, but I can find it later if you want an example. I think I used the animation library but maybe I'm forgetting what I did
Definitely happy to look at all the examples I can. Thank you.
@jaunty juniper @tulip sleet thanks for this PR/review. just seeing this. also seeing some guide feedback chatter about this. but looks resolved.
https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/2372
@slender iron @onyx hinge I did not bother to branch 8.0.x yet because there might be a couple more things that would be convenient to get into both 8.0.0 and main with single PR's before rc.2. But if you want to plow ahead on 8.1.0, I can branch.
Thank you!
I figured we would when something for 8.1 is ready to merge
In case it's of help to someone that's more familiar with the workings of the BLE core code....
I turned on verbose BLE and this is the detailed error:
_bleio.BluetoothError: Unknown system firmware error at common-hal/_bleio/Adapter.c:586: 30
I believe the block of code that gets the "30" error code from Adapter.c is:
uint8_t own_addr_type;
// Anonymous addresses are still resolvable. (Following what the NRF
// implementation does.)
rc = ble_hs_id_infer_aut...
sounds good, #7509 and #7510 could go in 8.0.0
I looked briefly for non-long-lived objects but didn't spot any, but thanks, @RetiredWizard, that will help narrow things down.
I'm not in a hurry at this moment
Hi, is there any way to use the python-statemachine module in circuitpython?
do you mean https://pypi.org/project/python-statemachine/ ? It looks like pretty normal python code. Only issue might be its size on various boards. You could just copy it over and try it
anyone know why actions aren't running on this new library repo? https://github.com/adafruit/Adafruit_CircuitPython_SPD1656/pull/1
heh, and now it goes
"Traffic is heavy this afternoon on GitHub CI; we see a clog near ubuntu-latest from the helicopter"
will do, thx
also if it had a lot of dependencies, but I didn't see that with a quick look
OK, found the problem.
I have met this with other applications as well and I was able to implement this here.
As the whole site is unknown (the CA is not as known), you have to download not only site certificate, but whole certification chain (It looks like many certificates one after another). And adding this (in one string) solves the issue.
So steps to solve:
- download Cert chain
- put them as 1 string
- add to context using: context.load_verify_locations(cadata=CA_STRING)
T...
I need to put this in place like this for now. Right now it will show the button, but when clicked it should show an empty menu with the message "Coming soon. Check back later.". Adding #mode=test to the URL and refreshing will show the different menu items. It's currently not completely functional which is why it's disabled by default, but this will allow me to test CORS from the real domain. Once I verify what needs to be done with CORS, I can make those changes and push subsequent update...
Hi. I've added a new Espressif ESP32-S3 board called the Neuron to the Espressif Ports/Espressif/Boards folder. This request includes all of the necessary files to compile CircuitPython. Including boards.c, mpconfigboard.h, mpconfigboard.mk, pins.c and sdkconfig
CircuitPython version
Adafruit CircuitPython 8.0.0-beta.6 on 2022-12-21; Adafruit Feather RP2040 Scorpio with rp2040
Code/REPL
# grab the code sample from https://learn.adafruit.com/introducing-feather-rp2040-scorpio/using-adafruit_neopxl8
Behavior
Sometimes the USB device will disconnect and reconnect.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
157.9fps
154.2fps
159.0fps
156.6...
CircuitPython version
Adafruit CircuitPython 8.0.0-rc.1 on 2023-01-30; Adafruit LED Glasses Driver nRF52840 with nRF52840
and
Adafruit CircuitPython 7.3.3 on 2022-08-29; Adafruit LED Glasses Driver nRF52840 with nRF52840
Code/REPL
Example code from here:
https://github.com/adafruit/Adafruit_CircuitPython_IS31FL3741/blob/main/examples/is31fl3741_native.py
Behavior
On CircuitPython 7.3.3 the example program runs as expected producing yellow ...
@blissful pollen if you have a chance can you you try running the "native" example from the library repo examples folder? I'm finding that the native example seems to have broken behavior on 8.0.0, but is working correctly on 7.3.3. Hoping to get confirmation of that observation from someone else who has the hardware to rule out a fluke or other hardware issue on my end. I've made an issue to track it here: https://github.com/adafruit/circuitpython/issues/7516
Not sure if it's related to #1135, but the json is valid.
I'll give it a shot. Likely cannot get at it until tomorrow evening. Feel free to poke at me if you don't hear after that
With CPv8 we have supervisor.set_usb_identification() which is step in right direction.
Unfortunately "lsusb -v" still shows "CircuitPython HID" on iInterface attribute.
If I have a digitalio pin in "open drain" mode then it needs to be pulled high somehow. The rp2 code does not use the on-chip pull-up, should it? Or does "open drain" mode expect to use external pull-ups?
Hi There. I have updated my Neuron CircuitPython compile files (mpconfigboard.mk) and sdkconfig to include the correct VID information this time. Sorry about the confusion.
Hi There. I have updated my Neuron CircuitPython compile files (mpconfigboard.mk) and sdkconfig to include the correct VID information this time. Sorry about the confusion. I have also cleaned up the pins.c file to remove white space.
I have removed comments from my Pins.C file as this appears to be causing issues
Cleaned Up Whitespace From pins.c for Neuron
Thanks! Just some cosmetic changes.
You can use pre-commit to check the formatting in advance, to avoid whitespace errors and the like. See https://learn.adafruit.com/building-circuitpython/build-circuitpython#install-pre-commit-3096511
These routines are not needed if they do nothing. There are MP_WEAK default versions that substitute for them.
// Use the MP_WEAK supervisor/shared/board.c versions of routines not defined here.
When there are two names for one pin, we usually group them together with whitespace so that's easy to spot. Put the name that is primary (e.g., the board silkscreen) first: that will cause that name to be the preferred print name for the pin. E.g. if your board has TX on the silkscreen, do this:
{ MP_ROM_QSTR(MP_QSTR_TX), MP_ROM_PTR(&pin_GPIO43) },
{ MP_ROM_QSTR(MP_QSTR_IO43), MP_ROM_PTR(&pin_GPIO43) },
If IO43 is the primary name, reverse the order. In either case...
INTERNAL_FLASH_FILESYSTEM = 1
LONGINT_IMPL = MPZ
# The default queue depth of 16 overflows on release builds,
# so increase it to 32.
CFLAGS += -DCFG_TUD_TASK_QUEUE_SZ=32
These have been moved to common mpconfigport.mk and can be removed.
@BrainBoardz You don't have to make a new PR every time the commit history is changed.
Any changes you push to the PR's head branch (main in this case) will be synced in the PR.
Hi, this is a feature request for countio to provide an API that returns an awaitable. The guide on handling interrupts uses polling:
with countio.Counter(pin) as interrupt:
while True:
if interrupt.count > 0:
interrupt.count = 0
print("interrupted!")
await asyncio.sleep(0)
The idea behind this feature request is to support ...
you need an external pullup, the internal ones are way too weak
Got my Seesaw, the little ATTiny817 looks to be working really well. It threw me for a second as it uses UPDI instead of SPI/ICSP or SWD, but Atmel Studio recognises UPDI so it was all good.
Made a little getting started source package which might need a bit of verification from Microchip
and a few additional resources like a Fritzing diagram but it is just 3 wires instead of 6 + StemmaQT
along with a bit of circuitpython busio code to use it as a raw I2C device once programmed over UPDI. This is additional to and alongside anything from the seesaw library, linked with web shortcuts.
this and a bit of 433MHz Doorbell Magic with the receiver from FS1000A, supposedly made by SSS Industrial Doors but quite common radio modules.
it may have some intermodulation with the US version of LoRa which uses a similar frequency, and also the UK version which is double. I called it ShoRa because the range was only 1-2m on low battery.
do we use isort in our pre-commit? maybe not. If we do, we may be needing an update due to some incompatible change that occurred within the last week: https://stackoverflow.com/questions/75269700/pre-commit-fails-to-install-isort-5-11-4-with-error-runtimeerror-the-poetry-co
pre-commit suddenly started to fail installing the isort hook in our builds today with the following error
[INFO] Installing environment for https://github.com/pycqa/isort.
[INFO] Once installed this
We don't, though I've used it personally and was debating exploring introducing it.
I can't think of any repo that uses it that I've encountered, but good to know!
Also, how would I find the block size, block count, etc. of the file system of the pico running CircuitPython. Looking at http://github.com/wokwi/rp2040js but would need that info. Is it the same as MicroPython?
kinda 😦 😦 about pre-commit this morning, can't figure out why it's throwing these messages in my personal project, but only when running under python 3.11!:
src/wwvb/updateiers.py:36:3: E1101: Module 'os' has no 'path' member (no-member)
src/wwvb/updateiers.py:58:28: E1101: Module 'io' has no 'StringIO' member (no-member)
they moved those around to keep people on their toes
@timid bolt are you also "gneverov" on github, or is that someone else? I was going to ping you in a reply to https://github.com/adafruit/circuitpython/issues/7522
CircuitPython version
Adafruit CircuitPython 7.3.0; Raspberry Pi Pico with rp2040
Code/REPL
import board
import digitalio
import time
led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direction.OUTPUT
while True:
led.value = True
time.sleep(0.5)
led.value = False
time.sleep(0.5)
Behavior
BOOTSEL mode works fine. I am able to flash the UF2 file.
But after reboot, the flash storage is mounted, then un...
Does it happen if you flash nuke the board, then re-install UF2? Does it happen in 7.3.3? 8.0.0-rc.1?
For https://github.com/hathach/tinyusb/pull/1779 and maybe other things
CircuitPython version
Adafruit CircuitPython 8.0.0-rc.1-1-g72981cf2a on 2023-01-30; Adafruit Feather ESP32-S2 Reverse TFT with ESP32S2
Code/REPL
>>> import board
>>> dir(board)
['__class__', '__name__', 'A0', 'A1', 'A2', 'A3', 'A4', 'A5', 'BOOT0', 'BUTTON', 'D10', 'D11', 'D12', 'D13', 'D14', 'D15', 'D16', 'D17', 'D18', 'D3', 'D35', 'D36', 'D37', 'D38', 'D39', 'D4', 'D5', 'D6', 'D8', 'D9', 'DISPLAY', 'I2C', 'L', 'LED', 'MISO', 'MOSI', 'NEOPIXEL', 'NEOPIXEL...
I closed the 7.3.x milestone on github
It might be worth checking that the S3 version has this updated as well.
thank you! tested all 3 buttons and they are working.
Yes it is mac-centric. In more than an year of working on Win/Linux with the same kit, I haven't faced such an issue.
I nuked using storage.erase_filesystem(), tried 7.3.3 & 8-rc1. Still facing the same issue. It mounts the storage. I can see my code files but the drive disappears very quickly.
Being "too weak" depends on the application though. If the internal ones are very weak, then it probably doesn't hurt to turn them on anyway to avoid weirdness like:
>>> pin.value
False```
It is me. I am fortunate to have a near globally unique name. 😁
thank you @BlitzCityDIY ! for finding the problem & also testing.
Hi- @gneverov is looking at this kind of thing, and we have been discussing it in discord. It's not clear we can return an Awaitable from C code, but there are workarounds (like passing Events or similar).
FYI, I'm working on a proof of concept that allows native libraries to schedule a callback on the main loop from an ISR, and it does this without relying on an asyncio module implementation being in the core.
My hope is it will be acceptable for all relevant the core libraries to expose wait methods, with typically a small amount of C code, but not necessarily including an async module to save code size if you don't want it. The "wait" methods would throw an exception if there is no main loop set.
Returning an "awaitable" from C code is not in and of itself a problem. You can just go return m_obj_new(foo_t) where foo_t is a type that implements the awaitable protocol.
It doesn't sound much like a board issue, but there's a more thorough flash erase here: https://learn.adafruit.com/getting-started-with-raspberry-pi-pico-circuitpython?view=all#circuitpython. Not too many people on Ventura 13.2 yet, do yo have access to a 13.1 Mac?
it does hurt, because then you don't get the warning about missing pull-ups, and you wonder why nothing is working
Where is this warning?
when you create an i2c bus
Is busio implemented using digitialio? I thought it would be a native implemenation.
bitbangio is implemented using the same functions as digitalio
but the point is, you never want internal pull-ups with open-drain pins
and if you would enable them by default, they would throw off the calculations of external pull-ups that you need anyways
busio is hardware busses, bitbangio is software bus.
busio.I2C tests the pull ups by counting how long it takes for the signal to come back up
they would also sometimes randomly work, leading you to a wild goose chase about why things are not working depending on the phase of the moon
you generally want things to fail as early and as consistently as possible
I see. Makes sense in hindsight. Thanks. I might be helpful to mention the need for external pull-ups in the open drain drive mode documentation.
Tried the nuke.cf2. It didn't help. I don't have Ventura 13.1. I'll try if I can find a friend who still has not updated.
It's just one Pico connected to the mac at any time. I created a fresh new user on my system. So my user profile or configuration is not an issue.
In https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/i2s.html it is detailed that the legacy api using i2s.h is deprecated and may be removed in the future. Instead, a different API from i2s_std.h (or i2s_pdm.h for pdm) should be used now.
I tested with your test program on a 2017 Intel Macbook, and an M1 Mac Mini, both running Ventura 13.2, and I did not encounter this problem.
Are you using a USB hub, by any chance? I was directly connected to both (with a USB-A to USB-C adapter on the Macbook).
Are you using a USB hub, by any chance? I was directly connected to both (with a USB-A to USB-C adapter on the Macbook).
I am using a USB3 Hub but I have also tested it on PC. Your comment really pins the issue down to either the hub or my machine. I have ordered a USB-C to microUSB. After I get it, I will update in a day.
I had a bit of a win a few minutes ago though. I found that if I connect to the Serial Console in the first 5 seconds, it works beautifully as long as I am connecte...
I know that feeling! 😄
Is Kattni short for anything or just an internet nickname you picked up in the olden days of the inter webs ?
For the longest time I went by UBRz and I still use NotUBRz to an extent these days
It was given to me by a friend I worked with decades ago by him writing me a note and addressing it to Kattni, and when I went back to uni after two years off, I decided it was time for a new name, and after trying out nicknames for my legal name, but none of them spoke to me. Then I remembered Kattni, and that was that.
@glenn20 Sounds good. I'd love your feedback on my inline comments then.
I love that, thank you for sharing that anecdote. Finding a good name when the one you were given doesn’t fit is hard.
You're entirely welcome. And fully agree.
@tulip sleet When you're around, I have a question/request. Ping me please!
For the longest time I didn’t like my first name of Seth. I got bullied a lot so I didn’t really want to go by that on the internet.
My name was given to me too :3 I’m curious tho, was Kattni a misspelling or just a nickname he made up?
I was assuming I'd do this when I circle back to USB Host (soon!).
Eventually I was using skerr for university related accounts so I decided it was close enough but not obvious.
He made it up. 🙂
Happy to have this available for testing. One weirdness is the three files named cpinstaller.js, installer.js and wsinstaller.js. Could they be renamed to be clearer?
Oh, wsinstaller.js shouldn't have been included, so I'll delete that. installer.js is the base installer (so it can eventually be reused for wippersnapper) which I can rename, and cpinstaller.js is the CircuitPython specific stuff. I'd like to have the installer eventually live in its own repo, so it will eventually go away from here and possibly the cpinstaller.js may move as well so it could be reused on other sites.
Happy to have this available for testing. One weirdness is the three files named cpinstaller.js, installer.js and wsinstaller.js. Could they be renamed to be clearer?
I have an Amazon Basics USB-C-to-USB-A USB3 hub which is is a poor performer. I was using it on Linux. The aluminum-cased "all-in-one" adapter I have works better. It has 3 USB-A's, HDMI, Ethernet, USB-C power input, etc.
Hehe. Benefit of a made up name is you’re not likely to run into others using it!
Indeed. As far as I know, I'm basically the only one. Katni is a city in India, if I remember correctly. There's a "kattni" on Deviant Art that isn't me. Otherwise, except for names that include "kattni", the rest of them are probably me.
Nice. There are people with various spellings of Kyoshii, but mine appears to be unique
back!
@tulip sleet Welcome back. I was informed that the Reverse TFT Feather board def was updated to include the buttons, but the update is not in a release. I can't link to "latest" for the guide. Is it possible to do another RC tomorrowish? Probably by end of week, I guess.
Yes, I plan to do another one soon. Only one outstanding right now is https://github.com/adafruit/circuitpython/pull/7521
I can probably actually fix that up myself and merge it. When are you publishing the guide? ASAP?
It's a full new micro guide, so it'll take a bit I suppose. ASAP, but that's probably not until the end of the week at this point.
