#circuitpython-dev
1 messages ยท Page 26 of 1
Invalid settings.toml is something ignored.
All current getenv code ignores errors (web-workflow & bt-workflow).
The mp_memory_t struct handles storage and get_allocation_length() is used for both pystack and heap now.
The only review comment I do not know what to do about is https://github.com/adafruit/circuitpython/pull/7585#discussion_r1107752669
I took care of the rest.
Stackless works the same way it did before.
I am pretty much done.
Tough now it fails on m0 for flash size.
40 bytes is 40 bytes
An idea for saving space would be to seperate all strings into words and store and deduplicate translations.
So, I have reduced it's footprint to a minimum, if flash size fails again what do I do?
Yea no, my changes ain't saving anything
still need 40 bytes
I did deduplicate the messages a bit, hope this helps.
Yea this isn't going anywhere, I'll have to remove something to make space.
That code was never updated for pystack so it should have been gone already.
Maybe you did this already: look for mesages in locales/circuitpython.pot that match what you want to say. A number of these are parameterized with %q, which will substitute a QSTR. This saves space if the QSTR is already defined for other reasons, such as that it's an arg name:
mp_raise_BlahError_varg(translate("Invalid %q"), MP_QSTR_buffer);
for example, will print "Invalid buffer". "Invalid %q" is already used lots of places. MP_QSTR_buffer is really common so it's "free" (no new storage cost) to use it.
What is runtime.py in cp root? It seems to remove #include "supervisor/shared/translate/translate.h" from all the files.
no idea, looks like somebody's temp script?? I'll look at a blame
part of https://github.com/adafruit/circuitpython/pull/6440. I think maybe @slender iron wrote it to automate a mass edit and it got checked in by accident.
the merges aren't going onto S3, only the releases?
Thanks for looking into this! I have some comments. Mostly, I want to ensure we are in sync with upstream micropython (and ensuring we file an issue or PR with them if we've discovered a problem in shared code) and understand the locking rules a little better for myself.
I guess that this is not fixing any specific issue, since the mdns issue was resolved by #7589?
Most of this file is copied from micropython's implementation (in their source tree at extmod/modlwip.c)
I notice that this one is not present in upstream micropython. We should raise an issue with them. It could clarify whether this is not needed, or whether they have a bug that would be fixed by this.
I did a quick analysis and I think this addition is probably not necessary, but it could also be that I'm fuzzy on the rules and requirements for using these ENTER/EXIT macros.
This f...
another set of calls to check with micropython about.
I compared this to https://github.com/raspberrypi/pico-examples/blob/master/pico_w/wifi/tcp_client/picow_tcp_client.c#L190 and I don't know WHY (i.e., failed at finding specific documentation) but it seems like neither pico-sdk nor micropython guard tcp_new .. the pico example does a bunch of calls and then guards only tcp_connect, which is very ... specific.
(I won't call out additional sites where you added the enter/exit cal...
(I inquired why micropython wrote the macro so that it was used without a trailing semicolon but there didn't seem to be a definitive answer)
Oh I didn't know that, I got the space under control, but no reason to not optimise further. Thanks!
That may be a new CI bug. Do you have a specific one you expected? Was it a merge to 8.0.x or main? tagging @analog bridge
I have a fix for it ready in #7594
since 8.0.2 ...I can get them from the actions, but my first go-to is usually S3
The S3 upload is broken in main
ok, thanks
@analog bridge ok, I will finish reviewing and approve. ONly q I had was why the stubs changed from .zip to .tar.gz?
maybe people need .zip stubs?
oh, challenge level has increased, looks like actions only have the affected board builds now (makes sense)
do all the editors handle .tar.gz stub files?
The zip earlier was broken post ~6.x.x somewhere. It was erroneously converting .tar.gz to .zip by just swapping the extensions.
oy vey
Even earlier the .zip was just enclosing .tar.gz requiring two programs to de-compress it
only mention of stubs I see is here: https://learn.adafruit.com/welcome-to-circuitpython/pycharm-and-circuitpython
Also fixes main merge builds not being uploaded to AWS S3. (per discord discussion)
ok, will merge 7594
Thanks! This may be very helpful for people. We probably really need a Learn Guide page to explain it, bmaybe in the Building CircuitPython Learn Guide.
@tulip sleet FYI, the mpy-cross directory has changed as per our earlier discussion.
https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/mpy-cross/
You may want to move the previous builds in OS specific directories.
thanks, will do, and will change doc as necessary
@analog bridge please do write up all the changes that a PR does to summarize, so it's documented what is being added and changed
btw I had no idea you could do a GUI for a workflow run -- that is remarkable!
You need to call socket.close() to release the resources of the socket.
Yeah, sorry. I admit I was being a tad precious by changing the semicolon just because it annoyed me.
You are probably right. I didn't check the context functions are called from. I just put it everywhere just to be safe.
tcp_new definitely needs the lock since it calls LWIP_ASSERT_CORE_LOCKED. This was one of the first asserts that fired for me in my testing.
I did this work hoping it would fix the mdns issue, but it ultimately did not.
My general process for making this change was to define:
#define LWIP_ASSERT_CORE_LOCKED cyw43_thread_lock_check
This turns on LWIP's built in checking to find places where the lock is not held. Every time the assert fired, I added a lock. This happened a lot. After a while I worked out which LWIP functions are calling LWIP_ASSERT_CORE_LOCKED and just added the lock to all call sites of those fun...
Despite precedent, I don't think that is a good practice. If I make a typo in my settings, I'd benefit from a diagnostic telling me so, instead of scratching my head wondering why nothing happened.
Looks good to me! But @tannewt has to approve. Thanks for working on this and persevering making changes.
I think just "Invalid CIRCUITPY_PYSTACK_SIZE" is probably good enough, and it uses existing strings; I agree ignoring is not so great. It will push the user to documentation.
This change is going to expose a lot of issues. The current issue in CI is that getenv support is being built even if it is disabled in the config. Let me know if you'd like me to keep pulling on this thread, or if you'd rather just let it be.
Yup, looks like something to remove
I was going to do a PR to remove the asyncio Python sources, so I will do that there too. Maybe some other cleanup too.
running that script still removes that line in like ~218 files
@lavish saffron __del__ isn't called immediately it will be called when gc.collect runs. You shouldn't rely on when it would be called. This is why CircuitPython objects usually have deinit() and socket has close()
We would usually use -Og, but you said that didn't work. if -O1 works, let's leave it and add a comment about what was tried and what didn't work.
This should probably be promoted up to mpconfigport.h. It should be on for all but the smallest builds.
This makes sense, because supervisor/supervisor.mk only compiles this file if CIRCUITPY_WEB_WORKFLOW = 1
I think I would rather have this kind of checking in the .mk files. If you do provide these messages, I would make them say CIRCUITPY_WIFI = 0, but this file is being included for clarity. But the corresponding C files should not be being compiled. If they are not, then there would be link errors, which is how things would be caught.
If it's violating assertions then we should fix it.
Thanks for clearing that up. I'll try adding a gc.collect() before checking the socket status list. If that doesn't work, I'll gently tap my head on the desk for a while and see if any other solutions present themselves.
Could you post the jupyter file as well? Thanks!
I think this might be the console uart used for ESP32 and C3 in production builds. (Starting early might be ok still though.)
Got my first supervisor.SafeModeReason.HARD_FAULT in the wild, and the board reset into safemode.py , then boot.py, then code.py. Took a licking and kept on ticking. ๐
hm, last post was blocked but I can't spot anything questionable
so are you doing a microcontroller.reset() in safemode.py?
yes
excellent, glad it worked for you!
there was a wildcard match to a spanish vulgarity on "input/output". I think we will fix that
@adriangalilea Please post a video of what you are seeing. There's a chance that the neopixel is misbehaving.
Not sure how to interpret this. Auto-reload was off, I wouldn't have expected the code to restart until after the serial disconnect due to hardfault, and the reset in safemode.py:
RuntimeError: Input / 0utput error
Code done running.
Auto-reload is off.
code.py output:
[tio 12:33:49] Disconnected
[tio 12:34:07] Connected
Thank you! Looks like only M0 without external flash won't have it.
Alright, I am done with it too.
I tried to further optimise strings, but couldn't.
Should no other changes be requested this PR is final.
CIRCUITPY_PYSTACK_SIZE has never been used as a string before. It's just a nameshake with the #if.
The plan was to get rid of all the compile-time settings for stacks in favor of this implementation.
However they both remained in the end.
I do not see a better name that isn't also used by #if's.
And there is no real risk of users confusing compilation settings with settings.toml variables.
Pretty much nobody will be using stackless after this pr is merged.
There will be no benefit...
Yea no, if I use invalid %q I cannot put a \n's
you can write the newlines separately
Yea, \n's are needed so that we are not displaying the warning on a used line. And using multiple writes increases binary size. We have 104 bytes free. I don't wan't to play with core anymore. Me ooga booga :b:ython.
free flash size isn't happy
we can add about 1 big line.
Nothing more.
104 bytes.
we will need to turn this off on some builds
But.. It works on all builds as of now?
yes, but I just pushed safemode.py, which will grow builds. Builds always grow, and then we need to trim them.
we can turn this off on Trinket M0, etc.
is it condtionalized so we can turn it off?
So.. Do I make more #if's?
currently no, it replaces ALL pystack alloc logic
yup CIRCUITPY_SETTABLE_PYSTACK or whatever you want to call it
Well I will #else the old barebones logic.
the basic pystack logic can stay the same, but the reading of a value, etc., could be conditionalized
Correct, this is just an optimization for the build to fail at compile time instead of link time, because I'm impatient waiting for builds.
A typical scenario is I'm working on some module, and I sneak in a dependency on another module by including its header file. This compiles fine, but if the other module is not in the build config I happen to be using, I will get a link error. I think it would be hard to check this in .mk files since .mk files don't know what header files C files are inc...
is PYSTACK on on the smallest builds?
reading is enabled by getenv
It seems to be some extra 'blank' characters in the strings to translate, is this wanted?
it seems weird to me that you are passing a struct (vm_memory_t) around by value
Deque is used by wifi, and not all rp2 boards have wifi, so that's why I put it at the board level.
wink wink, idk how to alloc objects
hmm, there should not be; I actually removed some \ns.
I only supervisor allocs
gotcha (y)
lemme look
๐ no problem
@brazen hatch I'll reply in the PR
kk
OK, there are some strings with newlines hence the characters you are seeing. So include a newline in the string you translate, at the place indicated. They were there before, but maybe you personally just haven't encountered this yet.
i would hope weblate lets you include newlines
Ok will do ๐
See https://github.com/adafruit/circuitpython/pull/6474; we generally want deque on; only turning it off on the smallest builds.
thanks for your translation work!
Thanks for continuing to revise this. I wonder if we should sit on it until 9.0 because we're removing a function.
I think you should switch this to allocate_pystack and then return the allocation instead of a new type. The heap allocations can then stay where they are.
Strings take up a lot of space and I don't think these will be hit very often. I'd rather omit them or reuse an existing message.
My preference would to be always passing in a pystack and having it NULL when disabled.
to "return" multiple things you can pass in pointers to assign to
The Wiznet5k socket.close() implementation does not prevent future calls to e.g. socket.bind(). Is there a way to have the socket instance kill itself, or will I need to set a _closed flag and then check this before each method call?
@timid bolt I have an i7-8700 (6 cores, 12 threads) I got from https://dellrefurbished.com (always find coupons: 35-50% off). Next significant step up for me would be a i7-12700 with lots more cores and threads, but not feeling the need yet. Other folks have much faster machines.
The issue with that approach is that it proliferates #if MICROPY_ENABLE_PYSTACK checks throughout the code. That's how we landed on the vm_memory_t abstraction.
dell outlet has the 12700's; no off-lease ones in dellrefurbished
Me with my overclocked Pi400 asserting dominance.
I as always did all of the pystack stuff from it.
it is amazing for openocd
But does the difference really matter in this scenario? It's not performance critical, and RVO will make it equivalent anyway.
this is the first place that'd use that pattern
my suggestion of the pr was to move the heap allocation back to where it was
and only factor out the pystack allocation
@slender iron when you set up the ACeP epd did you use an existing python library like https://github.com/adafruit/Adafruit_CircuitPython_UC8151D or did you end up creating something new at the python layer to get it going in addition to the changes in the core?
Fair enough.
Thank you!
Right, that makes sense. bill88t had something like that originally, but I suggested the creation of the vm_memory_t struct to reduce and contain the amount of #if needed in the code. You could still pass vm_memory_t to start_mp by reference.
The heap allocation happens regardless though so I'd separate it out
Did it now, one question, how do I send \n seperately now?
I can't find any related ref
serial_write()?
oh, ok, thanks
So something like this?
serial_write("\n");
serial_write_compressed(translate("Invalid %q", "CIRCUITPY_PYSTACK_SIZE"));
serial_write("\n\n");
Almost, you'll want MP_QSTR_CIRCUITPY___PYSTACK___SIZE I think
to make it a qstr
(instead of the string)
Oh I do not know qstr's. Imma copypasta and worry later.
they are weird
serial_write_compressed won't be aware of %-formatting.
alrighty let's see if it works.
QSTRs also need a make clean
(qstr is usually the only time I need a make clean)
I rather wait.
i am moving the mpy-cross executables around; i forget what platform we build linux-aarch64 for.
is it 64-bit raspbian or something else?
ya, probably raspberry pi
there are plain raspbian builds; i assume they are 32 bit
thats what the broadcom port is for
here here
OH
broadcom port is 64 bit iirc
Linux Pi400 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux
Though android should also report the same under termux and stuff
And mayhaps m1-2 macbooks under asahi
references to raspbian are for arm32 or whatever you wanna call it.
I can confirm this as I have used em.
i am moving things around with the S3 web gui. aws-cli is so terrible for this the gui is actually easier, and it's pretty clunky
Ahh I can feel my module breaking
I had like a month ago made a module specifically for automatically downloading mpy-cross'es
based on board version
it constructed the url
Do not mind I will fix it.
I am duplicating the 7.3.0 and 8.0.0 ones there because we depend on them for library building. Then I will fix that and then get rid of the top level ones
well, I will not leave the raspbian ones there ..: ๐ you will notice
I wonder if it would be possible to archive the en_US PR builds on a small selection of boards, like the pico for RP2040 boards, before cleaning up S3, for bisecting purposes ?
You can always remake them locally, it takes 20s.
i only delete the PR builds after a few weeks or a month
and I leave all the releases there (beta.n, etc.)
yeah that has not been enough in a few cases in the past
once you narrow it down, we can do regular git bisects
gcc didn't like qstr
i deleted them because the list is very long and it obsucres the older builds
Or I shouldn't tr it?
in addition to being hundreds of thousands of files
@tulip sleet you may want to drop a note to the author of pipkin (which is vendored into thonny) about the location of mpy-cross https://github.com/aivarannamaa/pipkin/blob/7f33dc9768a0e0d65498446ba65bf0119ec7e9ed/data/circuitpython-mpy-cross.json#L3
oh bleah, ok
@brazen hatch the usage is not right. Here's an example that's closer to what you need: py/builtinhelp.c: mp_cprintf(MP_PYTHON_PRINTER, translate(" is of type %q\n"), type->name); but instead of type->name you'd have your MP_QSTR_... identifier.
mp_cprintf takes a compressed string (result type of translate()) . but printers take a first argument specifying the KIND of printer, MP_PYTHON_PRINTER or &mp_plat_print typically. And translate takes 1 arg, not 2
These functions are so complicated omg. Thanks so much for explaining!
You are welcome ๐
is pipkin vital to the operation of Thonny? It already had some obsolete and deleted executables in that list.
I opened an issue: https://github.com/aivarannamaa/pipkin/issues/7
yes, I think it's part of how files are installed via the embedded version of pip
huh WHAT
- Why did it make it 3 long? Wasn't that an escape?
- Why did it spam
\t????
The current code is
serial_write("\n");
mp_cprintf(MP_PYTHON_PRINTER, translate("Invalid %q"), MP_QSTR_CIRCUITPY___PYSTACK___SIZE);
serial_write("\n\n");
I will change it to a single _ and try again
however about the \t idk
main.c: serial_write("\r\n");
in there, \n is the move down character, (newline or line-feed) \r is the move to beginning of line character (carriage return)
mp_printf turns '\n' into '\r\n' (because stdout is in text mode) but not serial_write
Isn't that.. windows only?
How come I have never run into this whilst making jcurses..
because you are probably writing via sys.stdout
yea, pretty much
Well, learned something new today.
Wait, does that work on it's own?
Can I use it to go to line character 0?
That would be a big optimisation as I use move for all ops right now.
print(end='\r') works similar to on host computers
@brazen hatch I was guessing at how to escape the underscore. Must not be needed
lol, if it doesn't work imma do \_
Meanwhile toasty pi400
temp1: +48.7ยฐC
Ambient is like 10.
HAHAHAH IT DOESNT EVEN BOOT NOW
Hi,
Please see the attachment. I included both mqtt and adafruit_requests samples.
for code session 1-7, it runs perfectly, the light is blinking for Pico W.
But mqtt and adafruit_requests sessions both are not working.
This isn't working
it seems to somehow nameshake with something
I will have to openocd it.
Found it.
Hardfault since heap and stack are not alloc'ed
so no mp_cprintf
ah bummer
I think that just doing one print for "Invalid CIRCUITPY_PYSTACK_SIZE" is the best way to go about it.
@tulip sleet I think we should rebase our changes onto the idf whenever we update it
@brazen hatch works for me
isn't really true
(and I can't find my changes easily)
makes sense; my PR cherry-picked the changes, so you can look there for now. It will be a new branch anyway at this point
for v5
that is part of the reason why I made a new branch -- it was really hard to do diffs, etc.
so I made a new branch, which was more draconian than rebasing
The pystack code is currently running on a 3-times desoldered pico.
Done and pushed. Now for which boards do I set CIRCUITPY_SETTABLE_PYSTACK to 0?
The ones that fail to build due to being too small. You probably want to do all of the SAMD21 non-external flash builds, and maybe all SAMD21 as well. mpconfigport.mk has conditionals for this.
you don't necessarily need to do it per board
Did as discussed on discord. [Link](#circuitpython-dev message) to nearby message.
Did as requested. Personally I liked the struct more.
The requested changed have been performed. Please review them at your discretion.
Question:
because we're removing a function.
What function?
This is the type of creature comfort that might not be as appreciated later because it solves a problem too effectively.
So I just wanted to say thanks while it's still fresh, @dhalbert.
Unless I am forgetting something this pr removes no functionality whatsoever.
You could have
supervisor_allocation *pystack = NULL;
and avoid the #else branch.
it removes runtime.next_stack_limit
Oh, it was broken already. It did nothing.
yep, I think that's all it removes
On my Mac, when I do a new clone of the circuitpython repo then run make fetch-submodules, then "git diff" I see ```jerryneedell@Mac-mini circuitpython % git diff
diff --git a/ports/broadcom/firmware b/ports/broadcom/firmware
--- a/ports/broadcom/firmware
+++ b/ports/broadcom/firmware
@@ -1 +1 @@
-Subproject commit bf96d0eda5952595d717fedb797aeb168483e9fa
+Subproject commit bf96d0eda5952595d717fedb797aeb168483e9fa-dirty
Its not big deal since I am not using broadcom, but it results in "dirty" builds. Any idea why?
I believe that's the part that requires a case-sensitive filesystem ?
go in it and git status
on APFS there is no cost to adding a case sensitive partition, so I do my CP stuff in one (as in it doesn't reserve space for it so both partitions can grow and shrink however much they want)
jerryneedell@Mac-mini firmware % git status
HEAD detached at bf96d0ed
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: modules/5.10.82+/kernel/net/netfilter/xt_DSCP.ko
modified: modules/5.10.82+/kernel/net/netfilter/xt_HL.ko
modified: modules/5.10.82+/kernel/net/netfilter/xt_RATEEST.ko
modified: modules/5.10.82+/kernel/net/netfilter/xt_TCPMSS.ko
modified: modules/5.10.82-v7+/kernel/net/netfilter/xt_DSCP.ko
modified: modules/5.10.82-v7+/kernel/net/netfilter/xt_HL.ko
modified: modules/5.10.82-v7+/kernel/net/netfilter/xt_RATEEST.ko
modified: modules/5.10.82-v7+/kernel/net/netfilter/xt_TCPMSS.ko
modified: modules/5.10.82-v7l+/kernel/net/netfilter/xt_DSCP.ko
modified: modules/5.10.82-v7l+/kernel/net/netfilter/xt_HL.ko
modified: modules/5.10.82-v7l+/kernel/net/netfilter/xt_RATEEST.ko
modified: modules/5.10.82-v7l+/kernel/net/netfilter/xt_TCPMSS.ko
modified: modules/5.10.82-v8+/kernel/net/netfilter/xt_DSCP.ko
modified: modules/5.10.82-v8+/kernel/net/netfilter/xt_HL.ko
modified: modules/5.10.82-v8+/kernel/net/netfilter/xt_RATEEST.ko
modified: modules/5.10.82-v8+/kernel/net/netfilter/xt_TCPMSS.ko
looks suspicious -- thanks
@jaunty juniper Yay! -- problem solved by using a case sensitive file system. No more dirty builds!
Regarding supervisor.runtime.next_stack_limit, it was never updated for pystack. Discord talk [link](#circuitpython-dev message).
If it served some purpose I will gladly put it back, but from what I understood it's an old implementation of this PR basically, configurable stack.
gcc just keeps removing the pystack argument cuz it is static WHYYY
tried NULL and (supervisor_allocation *)1
what do you mean?
look at ci
๐
It builds and works locally in either configuration (py)stack(less)
you needed to remove the volatile but leave it null
nop, that was the original
what was the error with that?
gcc optimises start_mp(heap, pystack) to start_mp(heap)
the avalanche that ensues is pretty simple, not enough arguments
70 checks failed
Meanwhile locally it works.
So I have no idea as if I fixed it.
I gotta commitspam
I don't think its that smart
Well, that whole , pystack didn't delete itself.
Something did it.
it works on mine but not on CI.
I blame gcc.
it could be a caching issue on the CI
๐ thanks for working on this
Thanks for the all the help. I couldn't have made it here on my own.
it says it's in run_safemode_py which is from the safe mode PR, which I don't think you rebased on ?
No??
WHAT?
I just updated from main a few hrs ago.
Didn't rebase, just update.
was that merged?
like 3h ago
so github auto merged that ?
I would expect it to complain about a conflict
yeah that's surprising
did it pretend a merge on main<-settings-toml-pystack and fail on that??
That would make sense
Well that then means I just have to update my branch. Again.
my update was like 6ish hrs ago
ya, I don't think this is a cache issue. Its a hidden automerge
github should make that clearer
if I rebase locally git is very unhappy, really weird that github took it
updated and put the good'ol snippet in safemode func.
I found that function while troubleshooting. I donโt know what to do with it though.
- If I add a print in that function, I guess I would have to recompile CP to troubleshoot?
- If I can just add a decorator to the exported python function (under which module/name would I find it), Iโve no idea what to do with the info next.
Let's hope when I wake up it's a โ
๐ค
Here is a UF2 for youthat prints on every USB write:
sparkfun_pro_micro_rp2040_usb_write_printing.uf2.zip
int32_t tud_msc_write10_cb(uint8_t lun, uint32_t lba, uint32_t offset, uint8_t *buffer, uint32_t bufsize) {
(void)lun;
(void)offset;
autoreload_suspend(AUTORELOAD_SUSPEND_USB);
const uint32_t block_count = bufsize / MSC_FLASH_BLOCK_SIZE;
fs_...
2. If I can just add a decorator to the exported python function (under which module/name would I find it), Iโve no idea what to do with the info next.
There is no exported Python function to decorate, sorry, it's C code.
Code stopped by auto-reload. Reloading soon.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
...............write lba=0x21, block_count=1
Code stopped by auto-reload. Reloading soon.
I erased the storage as requested. That was successful as I saw the label of the drive change.
When I add en empty line to code.py:
Code stopped by auto-reload. Reloading soon.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
.......write lba=0x45, block_count=1
Code stopped by auto-reload. Reloading soon.
write lba=0x21, block_count=1
write lba=0x2, block_count=1
write lba=0x51, block_count=1
write lba=0x21, block_coun...
I am doing the same as you, on Ubunut 22.04, and I don't see any writes.
I think lba=0x21 may be directory metadata.
Are you running tracker? tracker daemon -p would say what tracker processes are running.
How long does it take before you see the lba=0x21 write?
When you say diff the file, do you mean you were doing something like diff /media/username/CIRCUITPY /dev/null?
What does mount -l |grep CIRCUITPY say?
On mine:
$ mount |grep CIRCUITPY
/dev/s...
- I don't know what tracker is but here's what I get:
> tracker3 daemon -p
Found 1 PIDโฆ
Found process ID 2441 for โtracker-miner-fs-3โ
- About 30-40s. Doing an actual write to the file does trigger the auto-reload immediately.
diff --brief path/to/source/code.py /path/to/CIRCUITPY/code.py.
> mount -l|grep CIRCUITPY
/dev/sdc1 on /run/media/rarnaud/CIRCUITPY type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=ascii...
> gsettings list-recursively | grep -i org.freedesktop.Tracker | grep removable-devices
org.freedesktop.Tracker3.Miner.Files index-removable-devices false
I've added a .nomedia at the root of the drive which is supposed to disable tracker. I still get the auto-reloads.
Not sure if it means its indexed or not:
> tracker3 info /run/media/rarnaud/CIRCUITPY/code.py
Querying information for entity: '/run/media/rarnaud/CIRCUITPY/code.py'
No metadata available for that URI
Data object โ/run/media/rarnaud/CIRCUITPY/code.pyโ currently exists
Web workflow requires auto-connect, using CIRCUITPY_WIFI_SSID and CIRCUITPY_WIFI_PASSWORD. These also automatically cause the webworkflow to start, web server on port 80, mdns and all. If CIRCUITPY_WEB_API_PASSWORD is not set, the home page shows up and cp/version.json, but the file browser and REPL return an empty page.
Auto-connect is useful, for development in particular, by not having to wait for reconnect on auto-reload (even though the user code should probably manage disconnec...
What is auto-connect?
to make the web workflow accessible the board must connect to an access point using credentials in settings.toml, instead of waiting for the user code to connect
@tulip sleet The main commits aren't tagged with 8.1.0-alpha.0.
I thought I tagged main at the point of the 8.0.x branch. hmm
maybe I didn't push that tag, but I thought I did it from github
Did you make that tag earlier?
I think it uses date-time for a tie-break or is it semantic versioning?
If a single commit has two tags.
the commit has three tags, hold on
well not three, but two:
commit 5f43a63a701447595e5647621769e1ca9289ac85 (tag: 8.1.0-alpha.0, tag: 8.0.0)
Merge: 3a82730eb fab1bb5f2
Author: Mark <56205165+gamblor21@users.noreply.github.com>
Date: Fri Feb 3 18:09:51 2023 -0600
Merge pull request #7546 from FoamyGuy/is31fl3741_fix
fix for native is31fl3741
maybe just create alpha.1 now with the latest commit
sure; you just want a distinguishable latest tag, right?
yes, or else the main commits are listed below 8.0.x
I could label the commit right after alpha.0 as alpha.1, would that be better? And I'll delete the alpha.0
I am not sure, the commits above it already have 8.0.0 something, if you tag 8.1.0 aplha now, that version would change
those commits are not on the 8.0.x branch, so not sure what you mean by 8.0.0 something
i am not going to move any tags
yeah that makes git freak out
i can make latest main be 8.1.0-alpha.2. If I want to create an alpha.1 further back, I will do that later. We are not going to release any alphas for 8.1.0 anyway, we were planning to start with betas
so these are just placeholder tags
howzat sound? we have plenty of integers ๐
seems fine to me ๐
i deleted 8.1.0-alpha.0 in github, but the deletion didn't seem to propagate down when i did a git pull --tags locally. So I just deleted it locally
8.1.0-alpha.2 is on the current tip of main
if you want to sync with remote's refs git fetch origin --prune --prune-tags
When you run fatrace, do you see it report activity at the same time as the autoreload?
This is key and I should have paid more attention earlier.
sudo fatrace -c md5sum(141934): RO /run/media/user/KEYBOARD-L/code.py md5sum(141934): C /run/media/user/KEYBOARD-L/code.py
Something is running md5sum on code.py. It might not be tracker, but it is something. Also, whenever something does a read on a file on CIRCUITPY, a write is done to note the access. And why...
ah good, I tried --prune, didn't know about --prune-tags
Do you have an editor or something running that might be checking to see if code.py was changed periodically? Could be a tab open on VSCode or something like that.
You can now make custom board builds in your fork. See https://github.com/adafruit/circuitpython/pull/7594#issuecomment-1432525280.
We now implement caching in most places and I don't think that there is a need for using a docker image in CI now.
We can still however publish a docker image with all the CP deps as a package.
I've recently been playing with audiomp3.MP3Decoder and audiopwmio.PWMAudioOut on the rp2040 and find these clicks at the start and end of each track really distracting!
For reference I have a number of instrumental mp3 files encoded at 8kbps / 8Khz / mono. I've attached one here.
Breathing In And Out.zip
import os
import board
import audiomp3
import audiopwmio
import random
audio = audiopw...
@analog bridge the merge-queue-test repo was private, which caused to it use up all of the limited free quota for the circuitpython GitHub org and stall further actions. I made it public, which makes it unlimited.
it's kicksat-sprite, which has a lot of stuff squeezed into it, and a lot of stuff removed. One thing to turn off first on that board is CIRCUITPY_RAINBOWIO, which is not needed in its use case (cubesats ๐ )
turn it off in the board's mpconfigboard.mk; note list is alphabetized.
I tested flashing via idf without tinyuf2.
This page says it is 4MB: https://www.waveshare.com/wiki/ESP32-S2-Pico. But yours is 8MB? Is it clearly a genuine WaveShare board?
Also yes, the board is genuine.
CircuitPython version
Adafruit CircuitPython 8.0.0-28-g8abce77971-dirty on 2023-02-17; Waveshare ESP32-S2-Pico with ESP32S2
Code/REPL
>>> help("modules")
__future__ digitalio msgpack sys
__main__ displayio neopixel_write terminalio
_asyncio dualbank nvm time
_pixelmap errno onewireio touchio
adafruit_bus_device espcamera os ...
Added safemode checks for pystack alloc, it will use build default on safemode
similar on
Adafruit CircuitPython 8.0.0-rc.2-6-gb03eed32f on 2023-02-03; Adafruit Feather ESP32-S2 TFT with ESP32S2
This may be a CP-specific problem. I rebuilt micropython with ulab and help("modules") enabled, and get no duplicates. but, ulab submodules aren't listed either; mp treats submodules a bit differently than cp):
jepler@rat:~/src/micropython-ulab$ ./micropython/ports/unix/build-2/micropython-2 -c 'help("modules")'
__main__ mip/__main__ ucryptolib ure
_thread termios uctypes urequests
_uasyncio uarray uerrno ...
Heads up @v923z - the "ulab" label was applied to this issue.
ulab is in both shared-bindings and extmod. I haven't looked in detail but perhaps that is the reason.
Thanks for the quick fix!
@bill88t maybe you can give this a quick test?
@gamblor21 Is this ready for re-review? Could you re-request a review from @tannewt if that's true? Thanks.
@onyx hinge can you re-review https://github.com/adafruit/circuitpython/pull/7548 when you have a chance? Thanks. I'm trying to get stuff into the next beta release (not imminent, but hopefully soon).
Changing this to draft for now.
@jepler Do you think this is still in the mix, or is #7589 the real fix?
@gamblor21 Is this ready for re-review? Could you re-request a review from @tannewt if that's true? Thanks. Also mark conversations if resolved as appropriate.
It is, requested and updated the comments.
I do plan to watch how this is adopted and used to make tweaks if necessary. I did run it on RP2040/ESP32-s2 and M4 MCUs.
@tulip sleet am I right that (1u << 32) - 1 is well-defined in C, as 0xffffffff if unsigned is 32-bits?
I would be wary, what about just -1?
well, it's from converting the bits-per-value into a maximum value for the range checking ... this is what I suggested to foamyguy, but it's clever:
mp_uint_t value = (mp_uint_t)mp_arg_validate_int_range(mp_obj_get_int(value_obj), 0,(1u << common_hal_displayio_bitmap_get_bits_per_value(self)) - 1,MP_QSTR_value);
or MAX_UINT32 or whatever it's called
#7589 is probably the real fix. It was sort of surprising mdns worked at all without it.
I'm pretty sure it's right for everything but 32 bit depth and think it's right for bits_per_value == 32.
I think that 1 << 32 is going to become zero
yes I think it becomes 0u, and when you subtract 1 you get the maximum value due to unsigned wraparound
i think we have to look at the standard
Hello team, this is a PR for implementation of analogbuio module for espressif port. I have tested the code on ESP32S2 board adafruit_feather_esp32s2. The code supports other version of ESP32 chip however it is not tested. Please note this code is compatible with ESP IDF version 4.4.x. There have been changes in ESP IDF 5.0 implementation of ADC DMA and the module will have to be updated when CircuitPython moves to ESP IDF 5.0
Test code:
import time
import board
import analogbufio...
yeah it's undefined in C, drat it.
no, just a program that printed an error using -fsanitize=undefined
I think the standard is something you have to pay for -- I forget
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv) {
int n = atoi(argv[1]);
printf("1u << n = 0x%08x\n", 1u << n);
}
$ gcc intshift.c -fsanitize=undefined
$ ./a.out 31
1u << n = 0x80000000
$ ./a.out 32
intshift.c:6:37: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int'
1u << n = 0x00000001
it most languages "x << y" == "x << (y % 32)", which is why 1 << 32 == 1.
there are legitimately distributed "draft C / C++ standard" documents that differ in unknown but probably extremely minor ways from the actual paid specs
it seems like a hack around ISO charging for standards that the C / C++ committees are well on board with
OK, I will close this for now.
Thanks. Sadly, we're going to have to do one more iteration of this.
I was wrong when I stated that this was a correct way to get the maximum value, including for 32-bit bitmaps:
(1u << common_hal_displayio_bitmap_get_bits_per_value(self)) - 1
we'll need to define a function to return the maximum bitmap value and then call it in these cases. It'll apparently need a special case for 32-bit bitmaps.
:-/
(see previous comment, I suggested something that was not correct)
This seems to be correct without any special cases: (UINT32_MAX >> (32-n))
This is changed in the latest commit.
Made draft due to tasks still to do.
Made draft due to awaiting VID/PID.
Made draft due to awaiting VID/PID.
Made draft due to awaiting updated VID/PID.
@fonix232 Is this ready now that you updated the PID, or does it need testing? Also @tannewt suggested renaming the board to include the flash size .(Are there multiple versions?)
I couldn't find a C specification for shift operators, but here is the Java specification mentioning the "mod 32" behavior, which is probably inspired by the de facto C behavior.
https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.19
Changed to draft due to awaiting VID/PID.
Converting to draft while awaiting VID/PID.
ok, all the board PR's awaiting PID's are now draft, with task(s) to be completed. This will save me looking at them over and over.
I usually do -label:board
โ๏ธ on that. I was reviewing what might be almost ready for beta, and the state of many was not clear.
where can I find the svg of CP8 logos?
I think it is an Illustrator file internally; we have PDF and JPG
thanks!
I was thinking of replacing the README artwork with latest release ones.
Requesting rerun for job https://github.com/adafruit/circuitpython/actions/runs/4205278661/jobs/7297306949
It failed due to submodules setup.
need to wait for the workflow to finish before a re-run can be triggered
I read that as Connection confused. And it still made sense.
Thank you for this! One structural comment.
I think you'll want to do all of the below initialization at read time. Doing it here will prevent a second bufferedin on a second pin. if you do all the init and deinit in the read, then you an share amongst multiple objects.
Thanks @MicroDev1. I'll close this.
@brentru You know mqtt and jupyter. Any ideas?
@jepler may have added this when testing the gif writing
2 boards have failed due to git issues, can they be individually rerun?
https://github.com/adafruit/circuitpython/actions/runs/4205278661/jobs/7297306949
https://github.com/adafruit/circuitpython/actions/runs/4205278661/jobs/7297328519
Thanks your for your suggestion! The intention of this PR is to support recording audio via ADC DMA https://github.com/adafruit/circuitpython/issues/7454
The python application would typically look as follows:
Initialize the analogbufio
Read and process samples in a loop
Dinitialize analogbufio
Loop in second step above would be required on ESP32 boards without PSRAM support where amount of RAM is limited. The ADC DMA samples would be read into same buffer again and again and would b...
Thanks for working on this! Additional comments to @tannewt's.
Can you avoid this checking by validating the buffer data width?
It looks like from the example that the allowed sample size varies per processor. It would be good to validate this by checking the element size of the array that is passed in, and raising errors if they don't fit. There is already a check for this in shared-bindings/analogbufio/BufferedIn.c in ...readinto() there. Additional checks should be added here. It's a choice whether to make sure the sizes match perfectly, or allow 16 bit samples to be written to a 32-bit buffer.
We try to reuse error messages when possible. mp_raise_ValueError_invalid_pin() will just say "invalid Pin", which might be enough if we document the limitation to ADC1.
See locales/circuitpython.pot for a list of existing error messages.
yup, you should be able rerun just the failed jobs
Plot twist I can't. Prolly no perm.
k, lemme look
BTW, see https://github.com/adafruit/circuitpython/actions/runs/4205312574/jobs/7297211968 pre-commit section for formatting changes. Also, we use spaces after commas in arg lists.
it's queued I think
looks like another run is already going
yeah
arm / build (meowbit_v121)
Started 21m ago
...
Waiting for a runner to pick up this job...
Thanks! Let's hope it finally passes.
I ran make fetch-submodules and it returned this before it started: ```# This update will fail because the commits we need aren't the latest on the
branch. We can ignore that though because we fix it with the second command.
(Only works for git servers that allow sha fetches.)```
I've never seen that. What does that mean?
it says that every time
pretty sure that is cuz it's on custom branch/fork
tbh though, I have never built directly from adafruit/circuitpython/main
the message is hard coded in the makefile
the actual presence of the errors that it warns you about, might depend on whether you are in main, a tag or detached head
Least boilerplate message.
I don't know how makefiles work, should that actually be printed out or is it unintended ?
https://github.com/adafruit/circuitpython/blob/0a5fb31ce18f9a0c9c3969b969f5c24d61bd9040/Makefile#L327-L332
I believe it prints because it's indented
Sorry it took me a bit to get back to you. Please ping me on Discord or here if it's longer than a full work day. Just a couple more API questions.
Why do you need custom control of this? Could this library manage the dirty rectangle?
//| """Loads one frame of a GIF into memory at a time.
I think most of our APIs use float seconds. Do you really need millisecond resolution?
According to teacher chatgpt, comments are being printed always, it's just that the others are not in a target.
So it can be moved outside of the target if we want to hide it.
Shall I pr it?
ya, I think moving it would prevent it from being printed
@MicroDev1 What do you think about simplifying this? It'd be awesome to get this merged so it can be in 8.1
I tried unindenting them, it made them not print (while the commands after it did run, this is no python and I'm lost), does unindented mean not in a target too ?
no, it should mean that the target is over, you prolly made the commands run always
pr'ing it
aaah
In ports/espressif/esp-idf/components/hal/include/hal/adc_types.h the structure adc_digi_output_data_t is used to return data read from DMA. The actual ADC sample data is maximum up to 13 bits however it contains additional bits to identify channel and unit. Since for analogbufio we only return the sample values only 16-bit buffer would suffice. I will update the code accordingly and add checks to verify if application has provided 16-bit buffer.
I used it in testing, but thinking about it now cannot think of a valid use case. Removed it (though the common_hal_ call still has it in case it is ever needed).
Switched all the times to float seconds.
If I were to create a template repository for using rp2040js within GitHub Actions, would people prefer TypeScript or JavaScript? Maybe I'm the only one who might use it, but if there are others, I'd love to tailor it to that.
I'm leaning towards TypeScript, for what it's worth, but could easily be convinced either which way.
@slender iron and @jaunty juniper - tagging you because you expressed interest
Also @analog bridge since I think you were looking into this a few months ago
no preference either ๐คท
Oh neat!
I tested gifio in the unix port when implementing gif writing. However, there are not currently any automated tests that use it (e.g., to verify that gifio still operates properly) so there's no "real regression" (such as reduced testing) due to disabling this.
Thanks for all this work! Having a motivated project is great!
In the long run, I am still advocating to pass a struct to the display init functions. The number of args is unwieldy. Doesn't need to be now.
We could copy this into our S3, as we do with ARM gcc, to avoid depending on Nordic.
Did you mean to declare this as uint32_t? I though that's what the comment would imply. And you cast it to uint8_t below.
buffer is already uint8_t ? See above.
Is this going to run a lot more often because it's on tick rather than task? Is that OK?
I'm the one running either md5sum, diff, or cat. So that call is not unexpected. fatrace logs the access right away, but as we can see in the logs I've provided, no write is done. The auto-reloads happens some time later (35-40s). Maybe when the system performs a sync on the device?
I'm running this because I'm working off a git repository and auto-uploading any changes on the file as I saved it.
Here's the disk info:
> sudo fsck.fat -v -n /dev/sdd1
fsck.fat 4.2 (2021-0...
Github really isn't happy today.
do github worker vms even have a watchdog?
or will this run perpetually?
And wait a moment, aren't you guys paying for CI? Someone should prolly cancel it cuz it hang.
Blessed are the folks at GitHub for free runners

Also, I think there's a time limit
If I wake up tomorrow and it's still going I will kek like no man has kek'ed before.
Usage limits are 6 hours for a job and 35 hours for an entire workflow
I am more concerned as to why you know it.
I could tell you I googled it, but maybe I'm lying?
I definitely remember seeing that there were usage limits recently, that's why I remembered
It could be that Fedora has a delayed sync for some reason compared with Ubuntu. I'm otherwise at a loss, since it's not reproducible for me under otherwise identical circumstances. I have been mentioning wireshark monitoring. Do you want help setting that up? wireshark is not going to tell you who did the USB transaction, though.
- Install wireshark with
dnfor whatever (it's been a long time since I used Fedora). - Check that
usbmonis in your kernel. Read https://fedoraproject.org/wiki/Usbmon and follow its instructions. It looks like it's already part of the kernel. On Ubuntu, I have to load it. - Add yourself to the
wiresharkandusbmongroups (per the link above). You will need to log out or even reboot to make this take effect, depending on how your desktop login works. - Start wireshark and look ...
OK, I won't bother with wireshark then. I might play with sync to see if it changes the behavior, but I agree that the issue does not look like it's related to CP.
I'll just rsync the content of the drive locally, and diff with that, and copy the file when needed. That's good enough of a workaround for this weird situation.
Thanks for your patience; closing.
Thank you for your effort trying to get to the bottom of this!
As a final comment, if I run the cat and a sync immediately after, the auto-reload occurs right away.
As a final comment, if I run the
catand asyncimmediately after, the auto-reload occurs right away.
interesting!
The message All UART peripherals are in use was incorrect, since it would be shown when reusing the same peripheral while the other was free. SPI and I2C also only say "peripheral in use".
I remember as a mount option noatime. It's about not recording access time. It's default on rpi installations.
Perhaps ubuntu has it in the defaults mount flags while fedora doesn't.
autoreload should perhaps not trigger on file property changes.
it doesn't know anything except block number
so it doesn't know anything about what the filesystem is changing
bummer
it would have to double-buffer the drive or something
Nah, the better way would be to try to understand the write
but that would be slow on an mcu
I'm pretty sure there is no good fix for this
Perhaps suggest noatime for experts.
But not even those who know how to are gonna bother.
I at least make boot.py's JUST for disabling autoreload
Also, another concern of mine. Isn't the boot_out.txt spamming writes on every boot?
That could wear out flash really quick under some deployments..
I really should check that.
Cuz ljinux's"bootloader" spams the same message every time.
Though I guess if it's an stdout capture and save, the comparison should only happen once.
Though I still should check.
Yea the comparison is in the end.
Whoever coded it like this, you have my thumbs up.
Excellent code.
it is, but I don't understand where it gets the output into the right place for the comparison
(that would be jepler)
It seems to do just memory comparison from the read file. And it tries to skip it by comparing the len.
So if diff len, just don't compare
I am more perplexed as to how f_close isn't needed.
oh ok setting boot_output to non NULL is responsible for mp_hal_stdout_tx_strn writing into it
but I don't get that line:
(void)found_boot;
some C magic I don't know about
I think (could be wrong) it is to get rid of unused variable warnings the compiler tosses.
ah makes sense
does this get_pixel_shader function exist somewhere? I tried accessing it with gif.pixel_shader like it would be for ondiskbitmap, and gif.get_pixel_shader() but got 'missing attribute' errors both ways.
Perhaps this was leftover from ondiskbitmap and isn't actually used for Gif since it's palette / color converter works differently?}
Hi all, I have a "is this possible, if how" question. Running a matrix portal M4 and having fun displaying data from MQTT with miniMQTT library. If I had a .png image URL as a value in MQTT, is there any way I could display that on my board? I get I could copy the image to the portal and display it that way but was curious if the URL option (or something like it) would work.
Hey and welcome, ChipDipson! I think you'll get better help in #help-with-circuitpython. We discourage crossposting in general, but in this case I'm suggesting it. Feel free to post your question in that channel. This channel is more for development discussion. Cheers!
@idle owl -- thanks new here and wasn't sure the distinction between channels
No worries! We're here to help.
@bill88t You legend!
sudo mount -o remount,noatime /path/to/drive solved the issue :)
CircuitPython version
CP800b6 daily
Adafruit CircuitPython 8.0.0-beta.6-43-g1c1cf1cf5 on 2023-01-18; Raspberry Pi Pico W with rp2040
Board ID:raspberry_pi_pico_w
Code/REPL
negative number of bytes to read: -115
Behavior
use: CP800b6 latest ( from 14. and 18. ) ( with bundle /lib/ from 15. and 17. )
on a PICO_W ( nuked )
to connect to a local broker ( RPI mosquitto) OK
BUT
to a remote broker TLS ( HIVEMQ ) ERROR
always get error at subscri...
Bruh that was actually it..
Both mount descriptions, for Fedora and Ubuntu, above have relatime, which is supposed to suppress writing about plain accesses, but not modifications. But glad this solves the problem for you!
Ok, this is pretty much functioning well at this point. I'm putting this in a draft because I want to polish it up a bit more and add some things like showing a link to the Code Editor if credentials have been added. I still haven't figured out a good way to get the IP address without logging into the REPL (for when install is done using the CIRCUITPY drive). I'll probably just show the circuitpython.local in that case.
There are some binaries included. Those are temporary because my compu...
Thanks @jposada202020, @wtuemura and @bergdahl.
@jepler @dhalbert What do you think about converting peripheral in use messages to a common function with QSTR.
Hi, @proven garnet. Thanks for looking into it. Yes, I was looking into implementing it in CI and have also done some work locally to get a CLI version going for rp2040js and even esp32js with success. The people at Wokwi have done an amazing job.
An issue I quickly ran into while trying it out was that the website has a peripheral simulator engine for things like gpio, wifi etc. which is closed source. The ...js libraries only contain the processor's instruction set so you can imagine a hardware with peripherals stripped from it, meaning there is no peripheral interaction which leads to things like this:
import board
import digitalio
led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direction.OUTPUT
led.value = True
print(led.value) # This is False in rp2040js but works correctly in the website
This basically limits the usability to checking things which are already being checked by the UNIX port + checking whether or not the firmware itself boots.
I prefer TypeScript too.
oh the peripherals are closed source ? ๐
Can I use tailscale on a circuit python board
It's a wireguard VPN with a coordination server
is there a command to cleanup all the GPIO pins in circuitpython?
or is there just deinit() and you gotta call them got all the pins individually?
got should be on
you can reset the board
Using the mp_raise_ValueError_invalid_pin() in commit https://github.com/adafruit/circuitpython/pull/7602/commits/ead5751803ae2c770ec5923c5c996cb1f33aa930
I have committed the changes as per all the review comments received so far. Except for the translation related pre-commit failure everything seems to be fine. Please let me know how to resolve translation related error and also additional review comments if any.
Following is the updated test code and output:
Test code:
import time
import board
import analogbufio
import array
import supervisor
import gc
SAMPLE_RATE = const(40000)
CAPTURE_TIME_SECONDS = const(2)
ADC_PIN ...
For the translate issue, at the top level of the repo, do make translate. That will change locals/circuitpython.pot. Commit and push that.
You can run pre-commit locally to save the round-trips to GitHub. See https://learn.adafruit.com/building-circuitpython/build-circuitpython#install-pre-commit-3096511 and the links it references.
Thanks for persevering with all the formatting changes!
@tannewt may comment further next week on this. I'm not sure the other analogbufio has this use case. So we may want to make the semantics consistent, perhaps even through an API change or addition. For instance, maybe continuing or continuous or some similarly-named boolean flag might make sense.
I don't see any uses of bytes_per_sample at all besides the reference in the signature. Did you mean to check that it was 2?
Interesting, I didn't think about that. For what I originally started this for, peripherals aren't needed so it didn't make a difference - I'm basically calling gc.mem_free() and seeing the differences between imports for library changes.
@jepler @dhalbert What do you think about converting
peripheral in usemessages to a common function withQSTR.
If it can be refactored, that would be great, like the pin message refactorings.
Yes, the check is for printing the returned result from DMA engine which depends on ESP32 chip version it might be 2 byte result or 4 byte result depending on chip version. The variable bytes_per_sample is provided by the application hence it is not used here.
If supporting DMA on multiple pins simultaneously is the original use case then we need to brainstorm on how to handle this in case of ESP32. The ESP32 DMA engine provides use of two masks for ADC1 and ADC2 units which selects pins to be used for DMA operation. Based on pins selected by this mask the DMA starts collecting samples from these pins. The DMA read result provided by adc_digi_read_bytes consists of bits for DMA Unit, channel number (pin) and sample value. So the application has t...
bytes_per_sample is set in the Python API interface, based on the whether the array passed in is bytes or halfwords: https://github.com/adafruit/circuitpython/blob/508f2015b68042c25256a8f57dd37e5aec2c48c5/shared-bindings/analogbufio/BufferedIn.c#L144-L149
I'm actually confused why your example in the top post works at all, because it looks like the validation in the lines above should reject the 'L' array.array. Your check_valid_data does not throw an error if the size is a mismatch,...
The sample python code and the C code have been updated by later commits. The previous sample was only tested for ESP32S2 chip and not for other versions as noted in my original post. (Even the modified sample is used with ESP32S2 only). Hence 'L' array.array was never used. It would have thrown error if tested for other chips. Please refer to updated sample it no longer use'L' array.array
As per updated code the returned sample value is always 16-bit for ES32-nn. The applicatio...
Thank you! The latest commit changes the maximum value computation to use the new one that you mentioned.
I tested it successfully with this change on a Feather ESP32S2 TFT with both upper and lower bounds for the value input.
Once again, I think I am done.
As a final note, I remind you all that the old next_stack_limit was already broken and did not provide any functionality.
Should you guys still want it back in and removed at 9.0, I will gladly put it back, however it will still do nothing.
The weact studio boards use the Adafruit VID, with a PID from Raspberry Pi, assigned to the YD RP2040
This one: https://github.com/raspberrypi/usb-pid/commit/690a77c1e3061db7aa20557bd422ba0b707a190c
https://github.com/adafruit/circuitpython/blob/508f2015b68042c25256a8f57dd37e5aec2c48c5/ports/raspberrypi/boards/vcc_gnd_yd_rp2040/mpconfigboard.mk#L1-L2
https://github.com/adafruit/circuitpython/blob/508f2015b68042c25256a8f57dd37e5aec2c48c5/ports/raspberrypi/boards/weact_studio_pico/mpconf...
how does a build know the size of the flash on RP2040 ?
is it static based on the flash chips in EXTERNAL_FLASH_DEVICES, or is it dynamic as it detects the flash chip ? What if we set something like:
EXTERNAL_FLASH_DEVICES = "W25Q16JVxQ,W25Q128JVxQ"
CircuitPython version
Adafruit CircuitPython 8.0.2 on 2023-02-14; Adafruit Feather ESP32-S2 TFT with ESP32S2
Board ID:adafruit_feather_esp32s2_tft
Adafruit CircuitPython 8.0.2 on 2023-02-14; Adafruit Feather RP2040 with rp2040
Board ID:adafruit_feather_rp2040
Code/REPL
import time
from displayio import ColorConverter, Colorspace
cc_888 = ColorConverter(input_colorspace=Colorspace.RGB888, dither=False)
results_histo = {}
for i in range(1100):
...
Should this be the header image in README
https://github.com/MicroDev1/circuitpython/tree/patch#readme
I am second guessing this maximum on the value_count Prior to this change it was possible to pass a number up to 65536. The docs make mention of 8, 16, and 32 bits per pixel in the bitmap and capping this at 32767 makes it so it wouldn't be possible (or at least easy to create) a Bitmap that has 32bits per pixel unless I'm misunderstanding how something works.
I'm still trying to wrap my head around how Bitmap + ColorConverter function together as compared to Bitmap + Palette which ma...
are there multiple branches getting merged as S3 builds... in other words, does Absolute Latest have everything to date, or do I need to know which to download to have a certain feature?
safemode.py is in 8.0.x, lwip mdns fix is in main, but not vice versa, if I'm reading the tea leaves right
can something be merged to multiple branches?
Short answer is yes something could be merged into a branch but not in all of them (like main is ongoing but 8.0.x is branched off for now) and generally you would pull the individual PRs or the whole branch into main
I've heard talk of an 8.1, is there also plans for an 8.0.3?
we have a stable 8.0.2, so I'm not really clear on why there are two active branches that are different right now
so nothing on S3 has safemode.py?
oh, right, I had it backwards
8.0.x was merged back to main last before that
oh wait wrong lwip PR
I think
if 3 > 2
it's all a bit confusing
I'll go with S3 for now, I want safemode.py on all the things
circup over web workflow occurred to me this morning, and found there was already an issue ๐
but I need to switch all my codes over to stay connected rather than connect only when necessary
I don't currently use circup, that that may be enough motivation to switch
grepping the git log is a possibility to find that info, searching for "7589" in https://github.com/adafruit/circuitpython/commits/main over multiple pages is not a guarantee until you go back in time enough pages
oh I wouldn't function without circup, manually copying files ? no thanks !
yeah, there's a lot of steps to figure out if something is where you might want it
I have a script that's built up over the years
I call mine discotool, it's on pypi ๐
there are certain libs I always want, then it also depends on how much flash there is and what the board capabilities are, if I want .py versions... many variables, not just related to the current project on that board
circup via web workflow poses questions of detection and selection of the board, I was thinking maybe it could detect and list boards and prompt the user (with an option to bypass the prompt)
I have an item on my long-term to-do list to re-implement my script with the file API
wouldn't you point it to a known device, not broadcast to all
like, I know all my IP addresses
(I don't know all my MAC addresses) ...well, other than in dhcp file)
you can use a requirements.txt file with circup for libs that you want to always install
so I'd probably have half a dozen or so requiorements files
That's nice but it would have to change per version.
that does give me ideas of things to add to my web workflow app, I want it to be a tool that manages boards, like automatically do backups, browse them and restore per board... Having presets of libraries to install, or like "templates" could be interesting
https://github.com/Neradoc/discotool-circuitpython-manager
PR will be submitted soon but the problem was in shared-bindings/displayio/ColorConverter.c in displayio_colorconverter_obj_convert(...)
_displayio_colorspace_t colorspace;
colorspace.depth = 16;
The colorspace object is never initialized and later in the code colorspace.reverse_bytes_in_word is referenced. If it is incorrectly set to non-zero the function fails.
(right now you can upload a directory by selecting it in the upload dialog adding automatically finding and installing the requirements.txt would complete that)
Is there a good reason esp32 S3 has CIRCUITPY_PARALLELDISPLAY disabled?
ports\espressif\mpconfigport.mk Line75
safemode was merged to main. lwip fixes were merged to 8.0.x. I don't think they were merged to main yet -- we tend to do those merges in batches.
I will be doing an 8.0.3 pretty soon.
in a matter of days
8.0.x doesn't pull from main right ? It's just for quick fixes. But 8.1.x will start from main ?
right
but we merge frequently from the latest stable branch (in this case 8.0.x) to main
Maybe not; if you enable it does it work for you?
missing i2s_dma stuff, I'd forgotten there were issues there, but should be resolvable in theory.... undefined reference toi2s_lcd_driver_init'`
Fix for #7609
The output colorspace struct was created every call to convert but the structure was not initialized leading to random values. Specifically reverse_bytes_in_word was referenced in the conversion function with never being set. This lead to unpredictable behavior.
Moved the colorspace object to the class structure so it can be reused and is properly initialized. This also allows the output colorspace to be made to be configurable in the future.
Tested on a KB2040.
...
Messed up and included my GIF PR in this. Will resubmit, don't have time to fight with git.
Fix for #7609
The output colorspace struct was created every call to convert but the structure was not initialized leading to random values. Specifically reverse_bytes_in_word was referenced in the conversion function with never being set. This lead to unpredictable behavior.
Moved the colorspace object to the class structure so it can be reused and is properly initialized. This also allows the output colorspace to be made to be configurable in the future.
Tested on a KB2040.
``...
CircuitPython version
Tested with CP 8.0.2 and CP 20230218-12d3640.
Code works properly with CP 7.3.3.
Code/REPL
import time
import board
import busio
e5_uart = busio.UART(
board.TX, board.RX,
baudrate=9600,
timeout=0.01
)
while True:
out_bytes = bytes('From QT Py\n\r', 'utf-8')
e5_uart.write(out_bytes)
in_bytes = e5_uart.read(10)
if in_bytes:
print(in_bytes)
time.sleep(1)
Behavior
I ...
I have a project on the Unexpected Maker Feather S2 that enters safe mode with "Crash into the HardFault_Handler." or "Internal watchdog timer expired." This project doesn't have issues under 7.3.3.
Unlike anecdata's project, mine uses adafruit_mqtt not the adafruit_httpserver or adafruit_request libraries. Mine also seems to run for a couple days before crashing. I can open a different ticket, if people think my issue is unrelated.
CircuitPython version
Adafruit CircuitPython 8.0.2 on 2023-02-14; Seeed XIAO nRF52840 Sense with nRF52840
Code/REPL
import atexit
import time
import supervisor
import adafruit_ble
from adafruit_ble.advertising.standard import ProvideServicesAdvertisement
from adafruit_bluefruit_connect.packet import Packet
from adafruit_bluefruit_connect.color_packet import ColorPacket
from adafruit_ble.services.nordic import UARTService
ble = adafruit_ble.BLERadi...
Okay, how totally insane am I to try and consider using the esp_lcd_panel_i80 driver for displayIO on the S3? (Ive seen it done for esp-idf/arduino) I'm desperate to see the 8bit parallel display on the LilyGo/TTGO T-DisplayS3 working in displayIO, but stumbled on the lack of ParallelDisplay support on the s3. I'm no novice, but equally don't have an oscilloscope, just a pico (https://github.com/fhdm-dev/scoppy). I was hoping to cobble something together, but realise it's a bit above my comform zone / skill level
Reproduced. Thanks -- I am taking a look.
@willow totem there is a custom and optimised version of MP with the parallel ST7789 at https://github.com/russhughes/st7789s3_esp_lcd which would be a good start
I tested this change with the reproducer code from the issue on a Feather ESP32-S2 TFT, can confirm I no longer see the different returned values with this build. 0x00ff00 in always results in 0x7e0 out with this version.
CircuitPython version
Adafruit CircuitPython 8.0.2 on 2023-02-14; Adafruit Matrix Portal M4 with samd51j19
Code/REPL
import time
import board
import terminalio
from adafruit_matrixportal.matrixportal import MatrixPortal
# --- Display setup ---
matrixportal = MatrixPortal(status_neopixel=board.NEOPIXEL, debug=True)
# Create a new label with the color and text selected
matrixportal.add_text(
text_font=terminalio.FONT,
text_position=(0, (m...
Installed 7.3.3 as well and it has the same error:
Adafruit CircuitPython 7.3.3 on 2022-08-29; Adafruit Matrix Portal M4 with samd51j19
Traceback (most recent call last):
File "code.py", line 4, in <module>
File "/lib/adafruit_matrixportal/matrixportal.py", line 33, in <module>
File "/lib/adafruit_matrixportal/network.py", line 31, in <module>
File "adafruit_portalbase/network.py", line 28, in <module>
File "/lib/adafruit_io/__init__.py", line 21, in <module>
File ...
How did you install the adafruit_io library ? It looks like you took the wrong files.
The library should be copied from the bundle: https://circuitpython.org/libraries
Copied them over from adafruit-circuitpython-bundle-py-20230218 initially, and just retried with `adafruit-circuitpython-bundle-8.x-mpy-20230219 but wasn't working.
Then I decided to completely delete the lib directory and go back through 1 by 1 and adding them from the most recent library folder and it worked!
Not sure which library was wrong, but getting rid of all of them seemed to fix it
Looks like you got this: https://github.com/adafruit/Adafruit_IO_Python (which is not in the bundle)
Instead of this: https://github.com/adafruit/Adafruit_CircuitPython_AdafruitIO
Glad you got it working now.
In the "ports/stm/supervisor/internal_flash.c" file
In the "supervisor_flash_read_blocks" function
`uint32_t count = (sector_size - (src - sector_start_addr)) / FILESYSTEM_BLOCK_SIZE;
count = MIN(num_blocks, count);
if (count < num_blocks && _cache_flash_addr == sector_start_addr) {
// Read is contained in the cache, so just read cache
memcpy(dest, (_flash_cache + (src - sector_start_addr)), FILESYSTEM_BLOCK_SIZE * num_blocks);
} else {
// The r...
Thank you so much, got the board happily i2c-ing but display-less ๐ I've gone down the micropython rabbit hole before but forgotten my progress in that direction as was more obsessed with circuitpython and smoking too much as usual. Good old russhughes and other open source gems, warms the heart 
Alright, demo code and instructions for using CircuitPython (with optional filesystem) added upstream to rp2040js!
Instructions are in the README, hoping to have a template action ready next week - https://github.com/wokwi/rp2040js
Hoping for a release to npm soon for that.
This is just amazing.
-
Fixes #7612.
-
SERCOM USART TXPO computation was not correct on SAMD21 for TX pins using pad 2, due to changes introduced in #6434. SAMD21 and SAMx5x are different: SAMx5x does not allow pad 2 for TX. In addition, checking for allowed pins based on their pads was not as rigorous as it should have been. Code is somewhat restructured.
-
Signature for
busio.UART()was missing several arguments and did not account forNonevalues. -
Did more pin validation in
shared-bindings`busio.U...
I am going to do an 8.0.3 soon. I changed the base to 8.0.x and there are no conflicts. @FoamyGuy Thanks for the review.
Addresses https://github.com/adafruit/circuitpython/issues/5136 for rp2040 for me with the code & mp3 listed in https://github.com/adafruit/circuitpython/issues/5136#issuecomment-1434157983
During the testing of this change, in the construct and stop functions I sprinked a bit of:
printf("quiescent_value: %d\n", self->quiescent_value);
...
printf("\nslice top / cc: %d / %d\n", self->left_pwm.top, (uint16_t)(pwm_hw->slice[self->left_pwm.slice].cc));
To see what ...
it's perfectly fine, you are just more likely to get a better answer there
<@&356864093652516868> Reminder that the weekly CircuitPython meeting is tomorrow, Tuesday, at the regular time, due to a US holiday today. If you want to start on your notes, here is the notes doc: https://docs.google.com/document/d/1CmvwiKPFPOibcQyH-xomxXlqLq3m5JrL8zcmr3qE5Qw/edit?usp=sharing
Thanks @dhalbert. I'll try this out out SAMD21 and SAM5x boards I have which expose the right pins for flow control.
Test program I used to find working combinations, a variation on https://learn.adafruit.com/circuitpython-essentials/circuitpython-uart-serial#wheres-my-uart-2985036. Generates thousands of combinations, and takes a while to run. Includes cases where pins are None.
import board
import busio
from microcontroller import Pin
def is_hardware_uart(tx, rx, rts, cts):
try:
p = busio.UART(tx, rx, rts=rts, cts=cts)
p.deinit()
return True
except Val...
When the merge happens I should retest picow-ap disconnection, should I not?
Is there something in the change log about that? I only noticed we could now get RSSI and BSSID.
(Moved this to #help-with-circuitpython
#help-with-circuitpython message)
Why do we keep the CYW43 driver under lib instead of sdk/lib? Don't we want to keep the CYW43 driver in sync with the RP2 SDK?
Anyone know offhand why the maximum frequency I can set the SPI bus on an RP2040 in CP is 31.25Mhz when in Arduino (and the specs) seems it will go to around 50Mhz?
raspberry-pi/sdk is a submodule. The cyw43 library is a separate submodule. Did they merge it in the latest pico-sdk?
So, I believe that the flash size is detected on run on RP2040 and it uses the flash settings to switch to fast mode. I know we had issues with boards using a new chip, but can we use something like this to make a single build for multiple sizes, maybe support some pico clones with bigger flash without adding builds ?
EXTERNAL_FLASH_DEVICES = "W25Q16JVxQ, W25Q128JVxQ"
Like the WeAct Studio Pico where we have builds for 2MB and 16MB but not for the 4 and 8 variants. I tried putting the 4MB pico lipo on a 16MB pico lipo, or putting the 16MB WeAct on a RPi pico and looked liked it worked.
What is the catch ? Is it using the defined chip settings (for the wrong chip) or is it using default settings and not run it in quad speed or whatever it is ?
raspberry-pi/sdk/lib/cyw43-driver is a submodule of raspberry-pi/sdk, in our current pico sdk.
I am not sure it is up to date. And we have a fork of the cyw43 driver right now
The reason is historical, and may still be relevant
we did the port immediately after the library became public
when we move to pico-sdk 1.5.0-something, we can re-examine this
i think the cyw43 driver was getting fixes faster than the pico-sdk was being updated
Right. So there are two open issues: update pico sdk and update cyw43 driver. But it possible that the former would take care of the latter, if we didn't have our own fork of cyw43-driver.
right, for sure, worth adding a comment to those issues to note they are linked
and see what's fixed in our fork
Also the cyw43 submodule of pico sdk, just points to the origin (georgerobotics). So if we just wanted the latest cyw43, we could pull the latest inside sdk/lib/cyw43-driver and not need our own fork.
soounds good - I think it's really that we had fixes that were not upstream at the time
If we use the cyw43 driver from inside the pico sdk, #7595 would automatically update cyw43 driver.
How to treat the flash chips is handled in the stage 2 bootloader, which is generated from a template: circuitpython/ports/raspberrypi/gen_stage2.py and stage2.c.jinja. It looks like gen_stage2.py makes sure that the critical settings of all the listed chips match (e.g. all have qspi, etc.). Then it uses those common settings to generate the right thing in stage2.c. (I did not know this off the bat -- had to read the code.)
so we can't list disparate flash chips that vary in certain parameters, because the stage2.c builder will complain.
Yeah I think we went with the non-nested submodules so that we did not have to update pico-sdk and cyw43 in lock-step or maintain our own pico-sdk fork. there are other decisions that would have worked equally well / have different caveats.
In the current case, we did carry one difference compared to upstream pico-sdk of the time, so that it could cooperate with our mdns-related needs.
Hi all ... trying to get my MetroESP32-S2 to connect with my home mosquitto mqtt server using Circuitpython. I tried my own program then fell back to trying the example on adafruit's website. I replaced the adafruit information in the secrets.py file with my own information but when I try the mqtt_client.connect() it get a repeated connect fail error.
I have successfully pinged the host that mqtt is running on from the metro (which says the Metro is connected and the host is reachable) and I can successfully send/receive messages in node-red. Any suggestions?
secrets = {
'ssid' : 'OurHouse_GWF',
'password' : '#########',
'broker' : '192.168.86.71',
'broker_username' : 'rick',
'broker_key' : 'password',
'port' : 1883,
}
Hello all! I posted a PR to add a Packsize of 2200 to match the battery I am using. I apologize if I missed reading any docs on submitting PRs. I'm not in any rush, I was just wondering if you had any feedback or whether this was something that could get added? https://github.com/adafruit/Adafruit_CircuitPython_LC709203F/pull/23
HI, this q is probably better asked in #help-with-circuitpython . This is a channel for core dev questions and discussions. If you do ask in the other channel, say what versions of sw you are using. There are mqtt issues, and you might look at the issues for the library on github as well: https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/issues
no problem, it just requires some research on our part, since you are guessing at something. I assume a modified version of the library is working for you now.
Yes, I am testing the change with my Feather: Adafruit CircuitPython 8.0.2 on 2023-02-14; Adafruit Feather ESP32S2 with ESP32S2 I'm happy to do more research if I can. From the GIF that jposada202020 posted on Github, eyeballing the chart the value looks like 47 or 48, so my guess is pretty close I think ๐ฅฐ
Thanks Dan I did ask over there and didn't get a response. I'll keep digging but I have dug a lot in the last week and it pains me to ask for help.
so you are saying it works with adafruitio but not with the server you are using?
Can you use tcpdump on the server running MQTT ?
No I did not test with adafruitIO. I think I'll try that next.
But I have seen lots of people that successfully connect and publish/subscribe to adafruitIO.
Yes, depending on how align is your line the value could be 47 or 48 ๐
Yes I can and I don't know why I didn't think of that.!! Thank you!
When I get back to tinkering (some time this week) I give these things a go.
No problem. That's how I got InfluxDB writing working ... Just tcpdump'ed the traffic from the Python API, and hand-wrote a POST request to it. Only 5-6 lines of Python instead of the very large InfluxDB client ๐
Awesome Idea! I installed influx two weekends ago and plan on using the node-red to write and query.
Thank you for doing this work! We haven't tested it yet, but we will.
There is some audio ramping code in https://github.com/adafruit/circuitpython/blob/main/ports/atmel-samd/common-hal/audioio/AudioOut.c for DAC audio output. It sounds like you developed this independently, but it might be worth taking a look at that.
Thanks @Atalanttore @jposada202020 @wtuemura @bergdahl !
Adafruit HUZZAH32 Breakout uses a 4MB flash WROOM-32E module.
- There is an LED on GPIO13, which is used for CircuitPython status.
- There is a button on GPIO0, which is used to enter boot mode. It can also be used to enter safe mode, when the LED flashes multiple times during boot. Tested this.
- Pins are plain
IOnn. There are no default I2C, SPI, or UART devices, per discussion with @ladyada - Touched up formatting of
adafruit_feather_huzzah32/mpconfigboard.mkfile.
Tested with...
that will be useful for a lot of #vintage ESP32 boards
Hi There:
I have completed the .md file for brainboardz_neuron in the _board directory and I have added the (original, large and small images) for the brainboardz_neuron to the assets/images/boards/ folders. If this can get merged and become active I would greatly appreciate it. Thanks for all the help!
After some more experimentation I set the maximum value_count to 65535 which is the same as the effective maximum prior to this change it allows 16bit bitmaps with rgb565 colorspace
Hi There:
I have completed the .md file for brainboardz_neuron in the _board directory and I have added the (original, large and small images) for the brainboardz_neuron to the assets/images/boards/ folders. I have also updated the Features section of the .md file to be compliant with the instructions on this item.
If this can get merged and become active I would greatly appreciate it. Thanks for all the help!
Ah yes, I hadn't seen the (samd specific) ramp functions in https://github.com/adafruit/circuitpython/blob/main/ports/atmel-samd/common-hal/audioio/AudioOut.c#L58 - they've got a bit more going on than the basic / naieve ramp I threw in here. I did very little tuning on my ramp, other than initial versions with ~10 steps over shorter timeframe being able to be audibly heard.
RUN_BACKGROUND_TASKS; certainly seems like a good idea, though shouldn't this be included in any delay functions?
T...
CircuitPython version
Adafruit CircuitPython 8.0.2 on 2023-02-14; Raspberry Pi Pico W with rp2040
Board ID:raspberry_pi_pico_w
Code/REPL
import os
import wifi
ssid = os.getenv('CIRCUITPY_WIFI_SSID')
password = os.getenv('CIRCUITPY_WIFI_PASSWORD')
print("Activating Access Point SSID...", ssid)
wifi.radio.start_ap(ssid, password)
Behavior
code.py output:
Activating Access Point SSID... ReS_AP01
Traceback (most recent call last):
File...
Thank you.
I tested this out locally and it looks mostly good. One tweak to the purchase header is the only improvement I could find.
Thank you.
I tested this out locally and it looks mostly good. One tweak to the purchase header is the only improvement I could find.
Testing (with a lot of tracing) has shown that the 116 is, in fact, an MP_ETIMEDOUT error code being returned from lwip_tcp_receive in common-hal/socketpool/Socket.c. I am unsure why the value is 116, as MP_ETIMEDOUT is defined as 110 in py/mperrno.h. Adding a "keep_alive=100" to the MQTT initialization in the supplied script avoids the timeout in my testing. There may well be some issue here that is keeping the error from being properly reported, perhaps because at some point the return va...
Hi foamguy:
I made the change as requested and committed it to my branch. I'm a bit
unsure whether I need to submit another pull request. Github is new
territory for me.
If I commit to the main branch is that ok? I could do another pull request
but I think that is not how changes are supposed to work. Sorry for
the confusion.
On Mon, Feb 20, 2023 at 9:53 PM foamyguy @.***> wrote:
@.**** requested changes on this pull request.
Thank you.
I tested this out locally and ...
@BrainBoardz once you have created the PR you can add new commits to the same branch (BrainBoardz:main in your case) and the PR will automatically update to reflect the new commits. The PR tracks the branch if/when it changes, so there is no need to make a new PR, making new commit(s) is good enough.
The latest version looks good to me. Thank you!
Hi There:
That's awesome news. Not only did it get posted (yay!) but I now understand
how the process is supposed to work. Thanks for all the help!
bye for now,
On Mon, Feb 20, 2023 at 10:16 PM foamyguy @.***> wrote:
@.**** approved this pull request.
@BrainBoardz https://github.com/BrainBoardz once you have created the
PR you can add new commits to the same branch (BrainBoardz:main in your
case) and the PR will automatically update to reflect the new commits. The...
CircuitPython version
Adafruit CircuitPython 8.0.0 Beta 6.
Code/REPL
https://github.com/SeanCline/RabidKeyboard/blob/main/firmware/code.py
Behavior
I designed and built a keyboard using the KMK firmware. After using it for a few months, I noticed some weird ghosting on two key combinations.
- When pressing LeftGui and LeftShift, LeftControl sees a phantom p...
There are currently limitations in the Pico W implementation due primarily to external submodules. This will hopefully improve in the future. But for now, here's a summary of the limitations:
https://github.com/adafruit/circuitpython/pull/7101#pullrequestreview-1188988867
Basically, a device can either be a Station or an Access point, and since the example above starts web workflow and therefore becomes a Station, it precludes the device from becoming an AP.
The explanation for that code is here: https://github.com/adafruit/circuitpython/pull/5031. I don't remember the details now, but I thought it would fix the problem because of the active driving. Apparently this is not always the case.
I'm a little confused by your suggested change, because it waits for all the keys to be unpressed, according to the comments. But that would stall the scanning, (wouldn't it?), for the time you held down a key.
Wow, that was a quick response! And #5031 sounds like my exact problem.
I thought it would fix the problem because of the active driving.
The active driving does look like a good approach. It's possible my keyboard is just particularly bad when it comes to parasitic capacitance and inductance and it takes a bit longer to drain them via active driving.
I'm a little confused by your suggested change, because it waits for all the keys to be unpressed, according to the comments. But...
Nice work @DavePutz. For the record, the value of 115 matches MP_EINPROGRESS in circuitpython/py/mperrno.h, might be related considering the single zero byte returned from the function.
Turns out next_stack_limit has some purpose. I put it back.
If CI doesn't pass I will just disable settable pystack for the failing boards.
I have an idea, how about a wifi.radio.bg_connect that is enabled automatically when web workflow is configured and can be toggled at any time? Should this property be enabled, while backround tasks run, the wifi connection can be attempted automatically.
Though the more I think about it I think it should be a class..
wifi.radio.bg.connect
wifi.radio.bg.enabled
wifi.radio.bg.attempt_interval
Thank you so much @anecdata . It Works for me your explanation and the code shared. I deleted the lines of wifi configuration in the settings.toml and changed my code to this lines:
if wifi.radio.ipv4_address_ap is None:
print("Activating Access Point SSID...")
wifi.radio.start_ap("Cookie", "franemma")
else:
print("Access Point SSID already active...")
This scheme is neccesary to avoid an error when AP is already started. And when a i need a change in AP parameters i code ...
You can use mp_hal_delay_us() to delay for microsecond-resolution intervals. This is a busy-wait loop, so don't do it for long.
I see you are using an RP2040. I was going to suggest that it might help to set the drive strength higher, but we have already set the drive strength for DigitalInOut's to 12 ma.
It does have an LED on IO13. If that is not typical, maybe I should make an even simpler one. But if you use IO13 for something else, it will stop using IO13. The only issue is if there is something hardwired to it that would be upset at uncontrolled transitions. (And you could turn it off early in the boot process.)
There are some edge cases where the IP address may be None or "0.0.0.0" while the connection is being made or possibly while the connection is being broken. Milliseconds typically, but you might encounter it.
@gamblor21 @FoamyGuy @tannewt Anything left to do on this before merging?
One thing I have noticed regarding resizable pystack is at some point (differs port-to-port) increasing the size doesn't increase max recursion size.
For esp32s2 that is 3.7k for pico 7k.
Though stackless is still available for those who need it.
I will prolly end up using it too for simplicity.
I will make one attempt at having that one board pass with rainbowio
Didn't ci used to only redo the checks for the boards affected? What a bummer
@tulip sleet responding here as Iโm at work and my phone isnโt signed in to GH. The GIF pr just needs the last commits to be reviewed - as far as I know thatโs all thatโs left.
I Think this is good now. Tested the latest version successfully the other day. The now removed extra function def was only thing I saw to change and that has been done.
iirc RP2040 is dynamic. Most ports will find the matching flash device and use it
Probably just a clock miscalculation
@jaunty juniper here is how rp2040 knows flash size: https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/supervisor/internal_flash.c#L71-L83
Great. Thanks!
On Tue, Feb 21, 2023 at 11:59 AM Melissa LeBlanc-Williams <
@.***> wrote:
Merged #1151 https://github.com/adafruit/circuitpython-org/pull/1151
into main.โ
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython-org/pull/1151#event-8573176190,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AU2ZOBNQO3P4BLZD6A753BTWYTX6FANCNFSM6AAAAAAVCPSYE4
.
You are receiving this because you were mentioned.M...
FWIW, I've also been looking into pwm audio performance. A more fundamental cause of the "pops" is that the output is being driven as single-ended, so there is a DC bias in the signal, which causes the pop when the output is started/stopped. Amplifiers and especially speakers expect double-ended output, which also has no DC bias so implicitly removes the pops. (I.e., you want alternating current flowing through the speaker coil so that the cone moves in both directions.)
Most MCUs have PWM modules that support an inverted output. Yes, so you have two pins and one is the inverse of the other.
๐
The rp2040 has this, which is what I'm using. But even back in the day the atmega328p has this as well. It basically provides a H bridge, which is useful in other applications too.
ya, sounds familiar with the pwm work on imx rt I've been doing
that will produce more volume too right?
Yes, for directly connected speaker it is 2x (or 4x?) more volume. But for amplifier it doesn't matter. I guess it doubles the dynamic range for the amp and speaker too.
One mystery solved; the #define of ETIMEDOUT in /arm-none-eabi/include/sys/errno.h is 116. Now the question is whether that error should be returned to the user, or perhaps a retry in the minimqtt library, or maybe increase the default value for TLS connections from 60 in the library. @kllsamui , are you able to test with your original setup and verify that a keep_alive of 100 is sufficient?
<@&356864093652516868> Reminder that the weekly CircuitPython meeting is today, Tuesday (due to a holiday yesterday), at the regular time. Add your notes here: https://docs.google.com/document/d/1CmvwiKPFPOibcQyH-xomxXlqLq3m5JrL8zcmr3qE5Qw/edit?usp=sharing
It's ok to me to make web workflow use the API_PASSWORD to get going.
Skipping the meeting without notes.
It seems that work, family, Nvidia driver on Ubuntu and the analysis of a modification of evoting legislation proposal did eat all my energy.
Keeping up with Adafruit streaming is the only CP activity I had.
Looks good! Thank you for the quick fix
Will wait for @stonehippo to test before merging.
Alright and kicksat-sprite doesn't need to have rainbowio disabled. It just won't have resizable pystack.
So this pr removes no functionallity from any board.
[adafruit/circuitpython] New comment on issue #7615: Uncorrected read of STM32 internal\_flash cache
I think you are right that this is a bug! Are you able to fix this and make a PR? Thanks!
kickstat-sprite has no use for rainbowio. The board is designed for space satellites, which don't need NeoPixel animations. If you can enable pystack on it with rainbowio disabled, that is better, since it's more likely to be useful for how it's used.
This looks related: https://github.com/WeActStudio/WeActStudio.RP2040CoreBoard/issues/2
Maybe the quickest way to fix is to request a pid.codes PID.
@tulip sleet if melissa doesn't make it I can read the blinka section
tnx!
I'm here
May I join (listening-only) when it starts?
@brazen hatch yep, now's a good time to join
[and if you're a Mastodon person you can use @Anneb@octodon.social and #circuitpython on your post/toot]
I think it uses openocd
Need to write some @micropython or @CircuitPython with your board but don't have a PC around ? How about using your phone or tablet ? Here is how with #blueio832mini + #blueioterm App for iOS & Android
@crowd_supply @circuitcellar @matt_trentini @adafruit
Cool. I think in such caserecv_into should raise an exception. The _wait_for_msg() will deal with it:
# CPython socket module contains a timeout attribute
if hasattr(self._socket_pool, "timeout"):
try:
res = self._sock_exact_recv(1)
except self._socket_pool.tim...
Sorry no voice today
I think folks will be excited by that
wifi audio with scorpio and asyncio? ๐ฏ ๐
Jepler does this involve a floppytron in any way?
I'm actually doing it on pico-w. But I guess it should work on any rp2040 with wifi.
@midnight ember no, though with the floppy featherwing you can access the step & direction pins of the floppy drive so you could maybe make it make some noise
No more chip shortage song? ๐ฆ
I have unused floppies. I guess I am making an alarm.
Hope you get better soon Tekktrik. ๐
Thanks Dan for running the meeting!
Thank you danh for hosting the meeting.
Thanks
Thanks danh!
thank you!
Iโm pleasantly surprised to find that my workโs wifi let discord audio through. It didnโt last time I tried
Has anyone thought about DNS caching, either in Requests or in the core? DNS seems to get called for every connect, and takes a relatively long, indeterminate amount of time.
Fixes #7606. Instead of returning an errno (which seems to lose the negative sign along the way and so will be interpreted as a received count) instead raise an OSerror with the errno in socketpool_socket_recv_into(). Tested using TLS with a local mosquitto server and io.adafruit.com.
I believe dns is pretty much fully implemented in the lwip library. Check to see if they have an option do to caching.
I just ran a quick test:```py
for _ in range(0, 10):
start = time.monotonic_ns()
ipv4 = ipaddress.ip_address(pool.getaddrinfo(HOST, PORT)[0][4][0])
print(f"DNS took {(time.monotonic_ns() - start) / 1_000_000} ms")
hm, I don't see anything obvious about caching in the espressif docs or nongnu.org/lwip
anything we can do to async these long-running things is a big win too (wifi connect, dns, tcp connect, etc)
Here is the notes document for next Mondayโs CircuitPython Weekly meeting (Feb 27, 2023). 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/18-Buy1i0z-7l-fJlpYge63EPgbZoqKBTd8YRQOKy9cU/edit?usp=sharing
The lwip docs are not great. I'd look in the code for a #define that might enable the caching.
That's the great thing about having an async api: you just need to add await in front of your call to gethostbyname and your program can do other work while the dns is resolving.
This makes complete sense to me; thank you very much @DavePutz. I will backport this to 8.0.x after it is merged.
It's the reverse, task is more often than tick. The old task naming originally threw me off because I didn't know it depended on tick enable.
This sadly doesn't build. 400 more bytes are needed.
Do I cut more corners or just revert?
In the future I plan on creating tmpfs on CP.
It will be very useful for ljinux (/dev, /tmp)
It will be an independent library ofc.
I will try to make it run code on virtual files like gpio for example.
echo 1 > /dev/gpio/1/enabled
Do MCUs typically have enough RAM to make tmpfs useful?
Allow me to introduce you to psram my boi. 8 whole megabytes!
I am pretty sure that you would still not be able to download many files, but I guess it's better than breaking the board flash
If only could mount more psram as dram sticks or download more psram
Heap swap would be nice, but flash would die
Perhaps on a sdio-connected sd it would makd sense swapping
Ahh I can smell it, iowait in the air,
Every pi user's nightmare
Does rp2040 have psram? I think no.
Yea it sadly doesn't.
Pretty sure it doesn't have support for it either.
If it had i'm sure board makers wouldn't hesitate to plop some in.
Though 140k usable ram isn't little. Considering my bloat project fits in 40kb, you can do quite a lot in it.
Well, I'm jealous of your 8 MB of ram. It would certainly make buffering audio easier.
external psram is kinda slow, so I don't expect it perform well for audio
Ljinux booting on external psram may take up to 40 seconds.
rp2 is 7s
can anyone tell me whether i'm in the right ballpark with this board definition? just double checking before i make a fool out of myself blindly submitting a PR...
From a first glance it looks good to me.
I have no knowledge of the board though.
I would try enabling ESPPSRAM64 though.
this module only has 32 mbits... i think the newer WROVER-E modules have 64 but i am not sure if they're using them on this board
Well you can always just try a local build to see what work and what doesn't.
i have it up and running locally now, which is pretty cool. i like being able to run code in the REPL
blinked an LED too
Oh wait that's legacy esp32
yeah, no USB on this one
well, web-workflow is your friend
yep. kinda neat to be able to edit code directly on the device through my web browser. i'm living in the future, man
can't fathom all the hard work that went in to get it to this point
I wonder if ljinux would run on that..
If it did you could use nano on the board itself
i've seen a couple of proof of concept level demos of linux booting on the esp32, via a RISC-V CPU emulator
I have no legacy esp32's so I can't port or test.
terribly terribly slow though
I'm talking ljinux, linux for circuitpython
oh well
If you need any help on the board port feel free to ping.
I'm not very experienced on the topic (I have only ported one), but i'm glad to help.
thanks!
I thought we could only await asyncio. functions like await asyncio.sleep(), anything within a task can still block?
Right, it doesn't work today. But part of my ambition is to asyncify everything! ๐
https://gr.mouser.com/datasheet/2/1127/APM_PSRAM_QSPI_APS6404L_3SQR_v2_3_PKG-1954826.pdf
Waveshare esp32s2 pico has this psram chip.
It says, 84MHz for Linear Burst operation, 109MHz for 32 Bytes Wrapped Burst operation at VDD=3.3V+/-10% and 133MHz for 32 Bytes Wrapped Burst operation at VDD=3.0V+/-10%.
But 3.0V +/-10% is within the 3v3 range.
So couldn't I set CONFIG_SPIRAM_SPEED_120M=y? It certainly boots with it, but is that an overclock?
And does circuitpython even use "Wrapped Burst operation"?
The board feels much faster with it enabled.
Hmm, chatgpt is very well versed in based software.
But let me actually verify cuz I don't trust it.
you should ask bing, and see if it yells at you
@slim basalt feel free to submit a PR we're friendly ๐
It will prolly tell me to run it in 120Ghz.
The board will become an led.
roger that
thank you!
i have a feeling i messed up the pin list but will need someone else's eyeballs to tell me what
generally we just merge it and others can fix as they find issues
sweet
since we don't always have boards
yeah this is a pretty unique board, i doubt there's anyone but me even interested in running circuitpython on it...it was more designed as a demo for espressif's audio framework
I don't think that gets us anything because the next step is to "install" other commands. If they wanted it cached, then they should have packaged it in a standard way.
you can add a link to schematics and pinouts if you have them ready, makes it easier to double check, though if you have it running and test some of the web examples out there, it should be mostly fine
that's a good idea, is there a way to define that link in the board files, or should i just put it in the PR description?