#circuitpython-dev
1 messages ยท Page 338 of 1
any thoughts about removing all SAMD21 boards from FULL_BUILD and explicitly enabling modules for it? The msgpack PR is using FULL_BUILD and running out of space on 10 boards.
I think it's time to do whatever we need to do to make it possible to add new features with regards to the SAMD21 boards.
@slender iron I don't entirely understand what FULL_BUILD means, but I'm in support of the idea of explicitly enabling modules for those boards. We're doing that already inconsistently, aren't we?
we basically do it for non-express boards already
I like the idea of having the set of modules be consistent
but I'd like to freeze that set for SAMD21 essentially
Looks like a number of SAMD21 boards are out of flash now. In the short term, we can disable them on an individual basis but in the longer term we'll want to follow up with a way to freeze the modules on SAMD21. The spresence build is also failing due to a type issue.
I'm fairly sure I support this entirely. I guess I'd want to know what set we go with before going totally in on it, but I think something like that is worth it for sure.
I'm thinking whatever it supports now essentially.
Ah so a feature freeze basically.
I suppose worst case, if something comes along that seems crucial, we can swap things around? I don't know what that might be, but I imagine it's possible something could come up.
Alright. Yeah I support this.
but I don't want new modules included by default
Consistency is easier to support anyway.
๐ฏ
@slender iron I'll be afk for a while; will finish release later tonight (It just finished building and uploading), with blog post, etc.
thanks! I'll read over the release notes soon
As discussed in #1084, when a VM run ends with an exception, this uses the movable allocation system to preserve the traceback across a soft reload and lets the next VM run retrieve it using
supervisor.get_previous_traceback().Only the last commit is relevant, the next to last is #3454 (which it is not dependent on and could be rebased off if desired) and the rest is #3695 (which is required).
Ok great! Here are my thoughts on below. I haven't read through the PR yet. I'm start...
One minor thing. Overall it looks like a huge improvement. Thank you! I restarted the CI hoping to see how well it fits.
I'd also like @jepler to take a look. He did a number of the displayio uses.
I'm not positive this is correct. Will moved memory still be as root pointers when off the heap?
I'm allergic to goto and think a break is equivalent in this case.
break;
Alarms sounds a lot like interrupt handlers. Even if they don't use interrupts I think it would be a bad idea if they are exclusive to the sleep modules API, especially if true interrupt support is added later on, this could become confusing.
I would very much like to see interrupts outside of waking from sleep.
@slender iron do you have a simple ESP32-S2 application you could recommend to just verify my internet connection is good? TCP-IP would be fine
perfect ty
I don't think it's causing the wifi failures I saw with the additional debug flags enabled, so yeah, I'd like to see it merged.
Alarms sounds a lot like interrupt handlers. Even if they don't use interrupts I think it would be a bad idea if they are exclusive to the
sleepmodules API, especially if true interrupt support is added later on, this could become confusing.
I would very much like to see interrupts outside of waking from sleep.
That was my proposal in this comment: https://github.com/adafruit/circuitpython/issues/2796#issuecomment-724741273. I agree we could add this later, in some way, and that's ...
The lone failure was a network glitch. However, as this PR's home branch is not adafruit/circuitpython, it doesn't actually test s3 uploads which @dhalbert mentioned as a potential incompatibility.
I looked over the aws changes, and I just see this as a possible issue:
https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration.html#cliv2-migration-output-pager
Looks like we should set AWS_PAGER to nothing to avoid having it hang waiting for paging. (I'm surprised that a pager might not notice it's being run in a script and do nothing.)
@tannewt I had one more idea this morning, which is not to move alarm inside sleepio, but instead, just to dispense with sleepio, and put the sleepio functions as functions on alarm. E.g., alarm.reset_reason, alarm.last_wake, alarm.sleep_until(), etc.
Otherwise what I see is that sleepio is almost completely dependent on the existence of alarm, and really serves no purpose otherwise. The opposite is not true as @PTS93 points out.
These are all cosmetic and do not aff...
These steps use ubuntu-latest instead of an explicit version, so maybe we should change them to ubuntu-20.04l. That way they won't change out from under us in two years.
orkflows/create_website_pr.yml
13: runs-on: ubuntu-latest
workflows/build.yml
418: runs-on: ubuntu-latest
workflows/pre-commit.yml
14: runs-on: ubuntu-latest
I had a mistaken commit in there (disabling ulab on some stm boards) so I rebased it out and force-pushed.
I re-tested this one on 6.0. It looks like perhaps it can be closed. Here are the results on various platforms:
SAMD21
starting 300s wait
Mono elasped 300.002789
Clock elasped 300
SAMD51
starting 300s wait
Mono elasped 300.175905
Clock elasped 300
NRF52840
starting 300s wait
Mono elasped 300.000858
Clock elasped 300
ESP32S2
starting 300s wait
Mono elasped 300.004888
Clock elasped 300
@idle owl hi are u around?
Indeed!
running into an issue with the Metro S2 tutorial, AttributeError: 'module' object has no attribute 'Session', any ideas?
changed version?
That would do it, if that's the case ๐
ok, cool
@ionic elk Let me know if that's not it.
@onyx hinge For the SD Cards page in the board selector guide.... "SD Card Enabled" doesn't sit right for the page title. Do you have any suggestions on how to word it?
Or is that good?
That's what I thought
Is it really a list of boards with an SD Card Slot available?
@idle owl yeah my bundle was out of date, thanks!
@onyx hinge Yeah we discussed it in the meeting yesterday.
@ionic elk Excellent!
Well it's the SD Card built in boards, and the adalogger FeatherWing.
we also discussed that it was really "about" datalogging, so listing the pygamer wasn't most sensible
She said put them at the bottom.
right
It's viable, just unlikely to be used as such.
Built In SD Card Slot is kind of long. and Built In SD Card is misleading.
Spacious Storage?
(subcategories: datalogging / big data files like mp3s or bitmaps)
Expandable Storage ?
I like Capable better than "Enabled"
Yeah agreed
I just rememberd this: https://github.com/adafruit/circuitpython/pull/3629#pullrequestreview-521185497
@jepler says:
turns out that when the branch is made in adafruit/circuitpython instead of jepler/circuitpython the upload steps can be tested. Nice, I didn't realize that.
@onyx hinge They're all micro SD right?
I mean they must be.... But now I'm second guessing
grand central is, pygamer is, adalogger feather is ..
there's also this option for adding a (micro) SD https://learn.adafruit.com/adafruit-microsd-spi-sdio
Oh hmm yeah.
I think that's not included though because the Adalogger FeatherWing is plug-and-play on a Feather, that has to be wired to something
that's fine
this is more beginner-oriented and getting those connections right can be a pain
yeah
My MagTag just arrived and is working (maybe they should come with CircuitPython and UF2 preloaded). [I say working, because unfortunatly my FeatherS2 came DoA an the fix might take another 5 weeks to reach me.] Back to MagTag, @slender iron always say that we should use 6.1.0 with all ESP32S2 but when I go on S3, I only see bin and uf2 with a date and hash... I can I tell if it's a 6.0 or 6.1? https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/adafruit_magtag_2.9_grayscale/en_US/
@thorny jay 6.1 hasn't been released yet. Use the most recent .bin file.
@thorny jay 6.1 hasn't been released yet. Use the most recent .bin file.
@idle owl Or maybe I need to check in the artefact of the last commit from the 6.1.x branch?
Possibly? I'm not sure what builds beyond what ends up on S3.
This will be solved as soon as 6.0 is publish as 6.1 will be the bleeding edge and directly available (I assume).
Correct.
@onyx hinge If the SD card slot is connected via SPI SERCOM, SDIO won't work. But if it's connected via SDIO (as in the STM Feather), does SPI work? No reason to include this, so I'm not even sure why I'm asking.
Also is this still valid in CircuitPython: "the SDIO SD card is not yet supported natively" ?
@idle owl on the stm feather you can use the micro sd card and the spi bus simultaneously
Ah ok
I meant does SPI work for accessing the SD Card
like on the Grand Central
or is it totally a separate thing
no, you have to use sdioio, not sdcardio or adafruit_sdcard
right on
the module you use has to match the kind of bus it's attached to
Got it
(you might be able to use a bitbangio spi bus with adafruit_sdcard but it's a terrrrrible idea)
Fair enough
(so don't mention it)
tries to remember if he tested it during that guide I think it doesn't work, but can't remember the details
@thorny jay 6.0.0 is stable. We simply haven't gotten 6.1.0-alpha/beta.0 out yet.
@onyx hinge Also is this still valid in CircuitPython: "the SDIO SD card is not yet supported natively" ? (or did you answer me and I missed it)
Product copy.
Towards the bottom
@tidal kiln Quick question about your edits if you're around
yep
Did you remove "Adafruit" from the product names in the paragraph below the product element? Or did I inconsistently forget to include it. I didn't want to trounce your edits if that was you.
you mean like "Adafruit Itsy" vs. just "Itsy"?
i don't think i did. and if so wasn't intentional.
sure. np.
@onyx hinge Says you're editing a page in my guide. Can I take over?
yeah oops
no worries ๐
just looking
I'm trying to build 6.0.0 for the grand central but I'm getting this error ```arm-none-eabi-gcc: error: unrecognized command line option '-Wimplicit-fallthrough=2'; did you mean '-Wno-fallthrough'?
../../py/mkrules.mk:55: recipe for target 'build-grandcentral_m4_express/py/mpstate.o' failed
make: *** [build-grandcentral_m4_express/py/mpstate.o] Error 1
@golden jay what is arm-none-eabi-gcc --version? You may be using an older compiler. You need 9.x
I ran through the update procedure here with no luck: https://learn.adafruit.com/building-circuitpython/build-circuitpython
@tulip sleet arm-none-eabi-gcc (15:6.3.1+svn253039-1build1) 6.3.1 20170620
So does that mean V6.3.1?
that is really old. did you download the latest version as explained in the guide?
you can't use the version that comes with your version of linux
you download and unpack the version from the ARM website, and then you need to add it to your PATH, before the system-installed version
Ah that would explain why updating the package didn't do anything then. Thanks, I'll make sure I go to the ARM site.
That is the case for almost every distribution. I also fell into that trap, adam ๐
Also watch out on Arch based distros. Their version is too new and can cause other issues.
Good to know! I'm just running ubuntu on WSL right now, just still picking up details like these
I pushed it to an adafruit branch as well, run results will be at https://github.com/adafruit/circuitpython/actions/runs/368709935
@tulip sleet I know you're in sleep land but do you have a few minutes to help me with this guide page? It's the Chipsets page in the Which CP Board is Right for You? guide, the page that explains why one mpu is better/different from another. I copied down everything Limor said in the meeting yesterday, but it is super sparse and I'm not sure how to fill it out more.
@tulip sleet @onyx hinge do you know if we turned off some aspect of the ESP-IDF native reporting to reduce the messaging over the UART bridge? I'm noticing that I don't see ESP_LOGE messages anymore. Is this intentional?
@ionic elk Oh hmm. You can probably help. This is a guide page explaining, essentially, the pros and cons of each MPU used on CP boards. We evidently forgot STM32F405, so I don't have any notes on it. What would you say, in the context of the other microprocessors we use, are mostly the pros, and maybe a con to that proc?
Hi, I think I'm still getting this bug today, even after updating my board (Feather S2) to the newest firmware from S3 and the 20201117 library bundle. Issue happens even if I use the firmware directly referenced in the commit for this fix (f8eed1f).
Interestingly, the examples from this bug (thingspeak.com, io.adafruit.com) do appear to work properly now, but my own domain does not. I'm suspecting that it's an issue with my SSL certificate chain based on the [SSL Labs report](https://www....
@idle owl Oh yeah, would love to see the full guide page when you have a draft! In my opinion, the STM32 has the advantages of being a fast all-rounder board that's great for people who want to take extra steps with their project/learning process - it is much easier and cheaper to connect a debugger to a ST board compared to an Atmel one (a STLink probe is only $2 compared to a $400 Jlink), and the peripherals and memory are more powerful than other current feathers. ST F4 boards can also be programmed without an external programmer at all using DFU, and are very hard to brick.
Thank you for helping out!
But I would say a lot of the biggest pros of ST might be for people who use the Feather as a starting point and reference design for their own PCBs. There are a LOT of ST chips of widely varying price and performance, and they all share a lot of code, so it's pretty easy to move between them. So you can start out with a powerful overkill chip to try things out without memory pressure, and then optimize down to something that's super cheap when you want to make a product, and you might not even need to change your PCB
This guide is more a beginner thing so I think your first point is far more relevant, but that is good to know.
Yeah it's just a note for people who are trying to learn for the future - everything from the H743, which can run the original Doom, down to the F103s, which can cost under a dollar, all share the same codebase and most of the API.
It still requires some extra steps to install CircuitPython, right?
So it's a nice platform to learn if you want to do lots of different kinds of projects
As in it's not a UF2 bootloader
At the moment. We do have a UF2 bootloader for it though, I'm not sure why they still aren't shipping with it.
Oh hmm ok.
User installable UF2 bootloader?
We're probably not shipping it because of existing stock, and/or it's difficult to update the testers that flash the boards in the first place.
There's always a lag on updating what ships.
With DFU you gotta use brew install to get a thing, connect a wire, and then run a command. So it's a little more technical in that beginners might have to use the terminal, which can be intimidating
If you're on windows there's a downloadable GUI utility, but you have to give ST your email to get it, which is annoying and silly
You can install the bootloader yourself, sure, though you'd have to get it off github, build it, etc. So better for developers and stuff.
Oi yeah.
And at that point you're probably fine just using an STLinkV2 off amazon, or the DFU. STLinks are this $2 debug dongle and they're really fast and easy for development. But again, better for devs.
I remember buying them for the STEMMA connector and then getting outright halted when I Realised there was a whole thing to install CP.
or people who want to become devs, which is what I'd emphasize
Ah fair enough
I think I have enough! Thank you so much!
I'm struggling with this page ๐
Does it also have more memory than the nRF? I feel like the answer is yes
Good luck! These are just my opinions that kind of messaging is def more up to you and Ladyada and stuff I'd figure. I'm looking forward to seeing what you write though, I've wanted to make a guide like that for a long time on my personal site
Thanks!
I'm pretty sure it does yeah
double checking
Yeah it has about 4x as much. 1MB vs 256. Or 2x depending on how you measure the NRF I guess, @tulip sleet would know more
Ahhh. I was reading the thing wrong. Yeah.
Not sure which number to go with.
I'll wait until Dan's around to tweak it any more than I already have.
Again, if you aren't bound to the feather, the ST chips have ridiculous variability on that front, anything from like 128k to 2MB
192k of RAM as well which I also think is the highest offered
In this case, it's explaining the different MPUs separately from their boards, but it's in the context of the boards, so it kind of means in the context of the Feather for now I suppose.
until we get the i.MX feather in I think it's the highest performance board in basically every category, with the exception of wireless
Huh. Fair enough! ๐
Hi
I would like to add a new board from Electronic Cats to your repository.
I await your review, I thank you for your attention
@idle owl note I'm probably biased because I deal with a lot of people who say they want to "upgrade" their skillset at my local makerspace, so I tend to slant everything I work on with that kind of language. How to move past dev boards into your own stuff, etc. Totally up to you whether it's appropriate for this case or not.
That makes sense. Thank you so much for your help!
@ionic elk I am not aware of any deliberate change, certainly not on my part. Did you forget to build with DEBUG=1 ? no recent changes in ports/esp32s2/esp-idf-config/ that look related.
I'm building with debug on now, we didn't used to need that but maybe we only message with it on now
@dhalbert merging sleepio into top level alarm is ok with me!
@idle owl I dunno if this will be useful but I found it to be a fun read https://jaycarlson.net/microcontrollers/
Cheers, I'll take a look!
Thanks for submitting this.
Please change your features to match the items in the list on this page:
https://learn.adafruit.com/how-to-add-a-new-board-to-the-circuitpython-org-website/adding-to-downloads
Also, you will need a space between the hyphen and the item or they will all appear on one line.
kind of technical but there are some little contextual notes at the start of each entry which are nice
Nice
On revisiting it, I should maybe take back that it's a "fun" read. There are interesting parts of it which are less technical and more informative from a broader industry kind of viewpoint. But I'd definitely just skim for the good bits, there's a lot of technical jargon that doesn't apply to feather tier boards
I was skimming ๐
My MagTag just arrived and is working (maybe they should come with CircuitPython and UF2 preloaded). [I say working, because unfortunatly my FeatherS2 came DoA an the fix might take another 5 weeks to reach me.] Back to MagTag, @slender iron always say that we should use 6.1.0 with all ESP32S2 but when I go on S3, I only see bin and uf2 with a date and hash... I can I tell if it's a 6.0 or 6.1? https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/adafruit_magtag_2.9_grayscale/en_US/
@thorny jay It will come with UF2 and circuitpython eventually. It's a chicken and the egg problem. We don't want to ship it until we've had enough testing and we can't have enough testing until we have hardware available for people to test with. You are an early adopter. ๐
@idle owl Or maybe I need to check in the artefact of the last commit from the 6.1.x branch?
@thorny jay Most recent builds will be from the main branch and will be 6.1.x. I'll do a release of 6.1 today so the tags are updated again.
Right now, circuitpython.org/download is a bit confused. For some board it show 6.0.0 as current and 6.0.0-rc2 as bleding edge. Where for other like MagTag it is only go to S3.
But'll survive.
Also watch out on Arch based distros. Their version is too new and can cause other issues.
@bronze shadow @prime cove I develop on Arch so you shouldn't see any issues, just more free flash space than the older GCC version gives.
@thorny jay that seems correct to me. it'll make more sense when we have a 6.1 pre-release
@slender iron Dan's evidently out - and I know he's busy anyway. Do you have a few minutes for a chat about the Chipsets page in the Which CP Board is Right for You? guide, the page that explains why one MPU is better/different from another? I copied down everything Limor said in the meeting yesterday, but it is super sparse and I'm not sure how to fill it out more. I also got help from Lucian on STM.
yup!
@slender iron do you know about our ESP builds not logging over UART anymore?
I've disabled msgpack for the builds that are tight on memory.
Regarding the spresence :
First error is:
In file included from ../../shared-module/msgpack/__init__.c:29:
spresense-exported-sdk/nuttx/include/inttypes.h:185:31: error: unknown type name 'wchar_t'
185 | intmax_t wcstoimax(FAR const wchar_t *nptr, FAR wchar_t **endptr, int base);
| ^~~~~~~
I added #include <stddef.h> as the first import, now I get the error below....
Ah no Jeff was right, we just moved all messaging to debug
That sounds nice to me too :)
@slender iron do you know about our ESP builds not logging over UART anymore?
@ionic elk It should be enabled if you build with DEBUG=1
The import multiterminal is not available.
I'd like to use it for repl over BLE (using the BLE uart class).
multiterminal only ever worked on the ESP8266 port, which is now discontinued. We would like a BLE REPL, and it's in our long-term plans.
Uploads in adafruit branch build look fine! Thanks for doing this!
For some reason, the checks are not re-run. I'd expect them to pass, but how can I know?
@bronze shadow @prime cove I develop on Arch so you shouldn't see any issues, just more free flash space than the older GCC version gives.
@slender iron I had lockups when I froze in adafruit_ble using Arch. It only affected some functions, but building with the same code on Ubuntu with the recomended gross compiler
@tannewt Just seeing this now. Can we merge and deploy this so @tylerdcooper can review how it looks?
I can update it based on his redlines/feedback. The content looks good, just needs the new images as far as I can tell.
Would you be interested in a PR where the terminal compatible with UART, etc:
class myterminal:
def write(text: bytes) -> None:
pass
def read() -> bytes:
pass
def in_waiting() -> int:
pass
These functions would be called from supervisor/shared/serial.c, with the api in shared-modules/multiterminal.
@jepler @tannewt I believe this one is fixed by #3691 and the initial issue of this post was fixed by adafruit_requests.py >= 1.7.5
@tulip sleet Scott helped me out, FYI! Hope everything's going well with sleep ๐
it's ok ๐ I have a lot to do, but a lot has already been done, also
Fair enough. Progress is good regardless.
@slender iron what kinds of errors do you want for failed UDP transactions? I see some OS error codes and mp_raise_BrokenPipeError for TCP but that isn't appropriate for UDP, right?
@ionic elk try and determine what CPython does. It's usually OSError with error codes from the underlying socket implementation
Ok, I'll check out the CPython errors
Hmm, cpython just calls Py_XDECREF(addr) and then returns NULL. I'm not sure what that means in practice, since sock_recvfrom_into isn't referenced elsewhere
@slender iron do we return NULL for other calls as an error? I don't see examples of us doing that, at least not the way CPython does.
nah
@dhalbert excellent. Looks like you have to re-review since I had entered this in draft state
Looks good to me! Just needs a merge.
The bastble build is broken. Looks like it needs a function name updated: https://github.com/adafruit/circuitpython/pull/3662/checks?check_run_id=1410247014
I think it's not green just because of the one failing build (which is just network trouble).
@ionic elk I did a little slumming in Python (2.7 because it's what I had handy but I bet current is similar) and the error setting code boils down to: return PyErr_SetFromErrno(socket_error); -- it's a bit indirect so but the effect is to use the underlying error code translated to Python
Congrats to the team on the CPY 6.0.0 release! ๐
@slender iron It's already beta-level?
I'm not up on what's going into it, so I'm unaware.
I think so. folks are using it and we won't change too much
we may stay in beta for a bit though
Fair enough. No objections here then.
@iot49 disabling is totally fine. @kamtom480 may know what the issue is.
I'm not sure why the CI didn't run. I'll look into it.
I look forward to have some time to try MQTT, sometime soon.
This PR implements the sendto and recvfrom_into functions in socketpool/Socket, enabling datagram send and receive. Tested on Saola 1 Wrover with Scott's modification to the Adafruit NTP library:
https://github.com/tannewt/Adafruit_CircuitPython_NTP/blob/raw_ntp/adafruit_ntp.py
Note that I had to replace instances of time.gmtime with time.localtime to get this to work, since gmtime is not implemented in Circuitpython. code.py sketch is as follows:
import wifi
import s...
I knew something was wrong, but I could not describe it better.
@slender iron we could consider to update the cacert.pem in ~/circuitpython/ports/esp32s2/esp-idf/components/mbedtls/esp_crt_bundle/ to the current Mozilla bundle.
@onyx hinge interesting, where do I call that in practice?
@hearty tapir I have some changes already to switch to a bundle that matches the nina-fw
that was my plan
I'll add you as a reviewer hang on
any idea why the CI isn't going?
@ionic elk I think the closest CP equivalent is mp_raise_OSError(int errno_);
welp, now I see new builds
Ah, I think you need to fix the merge conflict before the CI can run because it runs on the merge.
@onyx hinge Yeah I've seen that used elsewhere in the shared-bindings Socket.c, but I wasn't sure what in mperrno to use for a datagram send failure, so I was trying to figure out what aligned properly to CPython
Thanks @DavePutz! I agree it can be closed. Both monotonic and time use the RTC now.
@ionic elk the linux man page can be really helpful. see https://linux.die.net/man/2/sendto
The system calls send(), sendto(), and sendmsg() are used to transmit a message to another socket.
the errors section in particular
@slender iron ok, yeah that seems pretty thorough
on a standard desktop system, recvfrom() returns a negative value for failure and sets the global errno value to a common value like -ENOSMURFS if there were insufficient smurfs available
I'm having trouble finding out what lwip_recvfrom does, it returns a negative number in case of error but beyond that ... ?
Wait, I guess I'm still missing something. On error, -1 is returned, and errno is set appropriately. so, what is the appropriate value for errno?
I'd rather not merge as-is because of the duplicated images. Here is the homepage:

am I misunderstanding what errno is?
esp-idf's code is written like there's a global errno value, shivers examples/protocols/sockets/udp_server/main/udp_server.c
// Error occurred during receiving
if (len < 0) {
ESP_LOGE(TAG, "recvfrom failed: errno %d", errno);
errno is a global (or thread-local) variable whose value is set by certain functions in the standard library. Besides "pointers can be NULL", "errors are signaled through a single, global number" is probably the 2nd worst mistake of C/Unix.
@iot49 My preference would be to finish the proper CircuitPython BLE support that uses nordic uart for REPL and a custom service for file transfers. We have an old issue for it here: https://github.com/adafruit/circuitpython/issues/1010 and I'd love to chat with you about next steps if you have cycles to work on it.
Basically, I want it to be core to CircuitPython, not just a hook from the VM, because it can work outside the VM then too.
speech, I guess
Lol yeah I had just found that same article and was reading it
anyway. my PR is up, I just put in some broken pipe errors which are probably wrong
I see mp_raise_OSError(0); is called in other Socket functions, I'm not 100% sure what that does?
https://github.com/adafruit/circuitpython/issues/3686 it leads to this issue
(lwip source)``` err = lwip_recvfrom_udp_raw(sock, flags, &msg, &datagram_len, s);
if (err != ERR_OK) {
LWIP_DEBUGF(SOCKETS_DEBUG, ("lwip_recvfromUDP/RAW: buf == NULL, error is "%s"!\n",
s, lwip_strerr(err)));
sock_set_errno(sock, err_to_errno(err));
done_socket(sock);
return -1;
}
so it really is setting a global errno value, how quaint
consider OSError(0) to mean I meant to figure out the appropriate error number
https://github.com/adafruit/circuitpython/blob/main/extmod/modlwip.c#L213 lower level lwip APIs like lwip_recvfrom_udp_raw return ERR_xxx values and in the micropython lwip bindings this is how they're translated to CircuitPython MP_Eyyy values for OSError raising
0, /* ERR_OK 0 No error, everything OK */
MP_ENOMEM, /* ERR_MEM -1 Out of memory error */
MP_ENOBUFS, /* ERR_BUF -2 Buffer error */```
@iot49 Regarding the spresence, could you rename the read and write function? I think the problem is in the header of the read and write functions in Spresense which are not compatible with your read and write functions.
but at the level you're working (lwip_recvfrom) there's already been a translation from those errors (returned as negative small integers) to newlib errno numbers and stored in a global errno value
Discussing this indirectly on Discord, @tannewt said
consider OSError(0) to mean I meant to figure out the appropriate error number
@ionic elk I expect this isn't particularly helpful to you, I'm just boggling about the layers upon layers of error handling for something "so simple", and yet it ends up difficult just to show the right error to the user/developer.
@onyx hinge all good, there's definitely a lot of layering in the IDF. I can't say I understand it as well as the ST HAL just yet
Makes sense, @tylerdcooper is working on getting a rpi image for that new spot.
The added commit should fix the mimxrt10xx and esp32s2 failures (and not break the rest). Will absorb this into the first commit on the next rebase (unless there are objections).
However, could someone who is familiar with that port take a look at ports/cxd56/supervisor/port.c? Its port_fixed_stack() has previously returned NULL, but from the way the port_{stack|heap}_get_{limit|bottom|top}() functions look, I would say that it does have a fixed stack.
Regarding the code size, it ...
Anyone else having basic connection issues with MagTag ESP32S2 and latest CP 6.0.0-260-ga0d305042? I'm getting "Connection Error: Unknown failure"
No, but does it need to? gc_collect_ptr will do nothing with a pointer that does not point into the heap. And as long as it does point into the heap, itโs not needed because itโs covered by the linked list. (In fact, even then gc_collect_ptr would do nothing with it, because it points into the middle of a GC block, after the supervisor_allocation_node header.)
But thanks for reminding me to take a second look at these, I may have made mistakes in similar cases.
Itโs not exactly equivalent because that wonโt skip the setting of the flags. That doesnโt matter here because weโre only changing garbage, but conceptually itโs wrong.
I donโt particularly like gotos either, but in this project I use them when they make for the shortest code. Iโll see if I can find a more elegant solution here.
@devout jolt don't use 6.0.0
it's old for the ESP32-S2
you can be the first to use 6.1.0 beta 0
๐
I was using the magtag latest build off S3. But I just tried 6.1.0-beta.0 and same problem
hrm
mine was working with a build from yesterday
though it was a debug build
I'm trying a build from the 6.1.0-beta.0 tag now
I'm getting some really weird results. Sometimes it soft reboots, sometimes it says "no SSID" when it had just printed out the SSID in question, sometimes it just hangs on connect
and sometimes it gives that "unknown failure"
it'll be just my luck that it broke today ๐
at least I'll have done the release notes
one fetch on mine worked ok
are you using bin or uf2 to update?
always the .bin. I don't know how to get UF2 bootloader to appear. Double-tap reset doesn't work for
So I'm encountering the following with the latest main (not in 6.0.0) on the feather S2:
The following boot.py
storage.remount("/", False)```
Results in the following boot_out.txt
```Adafruit CircuitPython 6.1.0-beta.0 on 2020-11-17; FeatherS2 with ESP32S2
boot.py output:
Traceback (most recent call last):
File "boot.py", line 2, in <module>
RuntimeError: Cannot remount '/' when USB is active.```
I just tried 6.0.0-rc.1-213-g61bf0e99c (the earliest one for MagTag). It does connect to my AP that runs the authoritative DHCP server, but I get "unknown failure" on the AP that's just on ethernet (and uses the authoritative DHCP server)
@jaunty juniper please file an issue. sounds like a tinyusb bug
@devout jolt has it ever worked?
@slender iron with the 20201110 firmware (g61bf0e99c) the MagTag will connect on the WiFi AP that hosts the DHCP server, but "unknown failures" on the AP that gets DHCP over Ethernet. Your "firmware.bin" gives that same result too. (Also, I realize I never tested my ESP32S2 Saola1 CP scripts on my other WiFi AP that isn't a DHCP server)
it almost seems like an early timeout on wainting for DHCP results (like if they don't show up within 5msec)
So I'm encountering the following with the latest build from S3
The following boot.py (no matter if using True or False)
storage.remount("/", False)```
Results in the following boot_out.txt
```Adafruit CircuitPython 6.1.0-beta.0 on 2020-11-17; FeatherS2 with ESP32S2
boot.py output:
Traceback (most recent call last):
File "boot.py", line 2, in
RuntimeError: Cannot remount '/' when USB is active.```
uh oh. the website data file is too large again
@devout jolt
the previous bin was old too
Here's what I'm testing with:
import time
import board
import busio
import supervisor
i = busio.I2C(sda=board.SDA, scl=board.SCL)
i.try_lock()
i.scan()
supervisor.reload()
####################################################################
####################################################################
####################################################################
####################################################################
#######################...
While I didn't get anything sensible out of my debugging efforts today (I'm not getting full tracebacks in gdb so it's hard to interpret where I am) I noticed that there (A) seemed to be problems with background ticks and (B) maybe something scheduled from an interrupt was taking too long. Beyond that, I don't have a good explanation, but since making these changes I have seen my test program on #3572 stop crashing on the Kaluga, and I also edited-and-reloaded a bunch of iterations of a temp...
you can be the first to use 6.1.0 beta 0
@slender iron That solve simpleclock that was crashing on me.
๐
@slender iron that firmware.bin about 50% of the time hard-reset, kicking out the CDC and MSD on wifi.radio.connect() Correction: it only seems to hard-reset on ctrl-D continue, not if I connect after it's started up
hrm
my script is:
import time
import wifi
ssid = "todbot-back"
password = "maxwellcat" # hack me plz
print("scanning...")
for network in wifi.radio.start_scanning_networks():
print("\t'%s'\t\tRSSI: %d\tChannel: %d" % (str(network.ssid, "utf-8"),
network.rssi, network.channel))
wifi.radio.stop_scanning_networks()
print("connecting to:",ssid,"passwd:",password)
wifi.radio.connect(ssid=ssid, password=password)
print("connected.")
while True:
print(time.monotonic(), "loop")
time.sleep(1)
k, let me try it
yup, I'm seeing the usb crash too
oooh, and I got unknown failure
and now my usb is unhappy
I'll keep poking after I fix the website
I'm bad at doing multiple things at once
@slender iron doh! Another data point potentially: On Metro ESP32S2 and CP 6.1.0-beta.0, similar results of "Unknown failure" on AP w/extern DHCPd and strangely hanging on the AP w/ the DHCPd. But only on Ctrl-D or code-save restart. On hard-reset, the above script comes up fine
Yeah, not working very well here too. Now corrupted file system and code.py (and one font file) is broken beyond repear. Also stuck on "Connecting" in various example. Time to sleep for me.
seems like it's gotten worse
@devout jolt mind filing an issue? I've gotta finish some website updates before I can focus on this
@slender iron no problem. I wish I could characterize it better than just "dudn't work fer me"
no problem. I can reproduce it which is good
Definitively something USB related. When working stand alone on battery, the clock work. When connected to USB it was stuck on connecting (from what I could see on the console).
Tested on Metro ESP32-S2 and MagTag. This was also present in a debug firmware for MagTag provided by @tannewt on 17 Nov 2020.
On CircuitPython-6.1.0-beta.0, the wifi module will sometimes hard-reset on wifi.radio.connect(), using a small connect script (*) This seems to only occur on Ctrl-D and save-on-reload restarts. When starting from hardware reset / power-on, the script works.
Also on CP-6.1.0-beta.0, it seems the ESP32-S2 WiFi cannot connect to APs that are not DHCP servers...
yah i2c works fine now... weird but effective :)
dunno why this works but it does!
Reported by @jedgarpark. The error comes up after a while of pressing the buttons, but he's not able to figure out if it is some specific pattern. It works fine about 95% of the time. It looks like simpleio attempts to use audiocore if there's a ValueError thrown from pulseio.PWMOut().
Here's the error:
Traceback (most recent call last):
File "code.py", line 81, in
File "adafruit_magtag/peripherals.py", line 71, in play_tone
File "simpleio.py", line 80, in tone
NameError: ...
This should more permanently fix the automatic update. The stable switch made the file larger because of all the additional boards and languages.
@tannewt Your plans are much further reaching.
I believe both are needed. multiterminal is more generic, e.g. also works for sockets, and can be abused to capture stdout.
My specific need is to control a robot wirelessly (for obvious reasons). I program via jupyter (https://github.com/iot49/iot-kernel) and manage file upload/download over the repl. A dedicated solution (with microcontroller support) would be faster, but I have not found this to be a limitation in my experience.
No...
In a Library, would we want to keep backwards compatibility like this between Sprite and TileGrid?
# 4.0.0 Beta 2 replaces Sprite with TileGrid so use either.
self._sprite_class = getattr(displayio, "Sprite", displayio.TileGrid)
or is it okay to remove that at this point?
After doing tests with Metro ESP32-S2 with the Arduino IDE, the second part of this issue (Connection Error: Unknown failure on a secondary AP) is not unique to CircuitPython. Perhaps ESP32-S2s cannot connect to Apple Airports in AP mode or to APs that forward DHCP over Ethernet.
@lone axle a rule of thumb would be, if we no longer produce a 4.x bundle then we would not need to keep workarounds or backwards compatibility for 4.x. Since that was from before stable 4.x, the case to remove it is even stronger.
(right now we make a bundle for 5.x and 6.x)
users can always get the older releases of the library via github
MagTag looks so good, I canโt wait for a stock alert โค๏ธ
@iot49 Thank you for renaming the read and write functions. The second problem is in the Spresense SDK configuration. I will fix this. You can disable msgpack for the Spresense for now.
I would like to add some sort of frequency measurement error correction to this ...maybe in a subsequent PR.
Looking from the point of view of implementing a main loop for async, would there be a way to wait (sleep until) on several different conditions at once? For example, a timeout, a pin raise, a socket connection, a user input on STDIO and a UART transmission? Because that's what we would ultimately need.
So I have been playing with MagTag and the SimpleClock code I found in the LearningGuide repo. Except for all the improvement on the core, I feel that we need a RobustClock that can serve as a template with better handling of exception, network error, ... I would even think that we need some kind of watchdog that once enabled requires your to send a keep alive message or else it reboot.
I guess that kind of remark would be true also for PyPortal and PortalMatrix.
But when you have that thing on the fridge, and the only thing it display is an error message... you start thinking about ways to "auto-resolve" them.
I took picture of the screen each time I had error, and I'll try to share them.
Also, I would love to see support or code for multiple SSID, trying one, or if not available, another one. Some of my error related to not beeing in reach with the main SSID. (you know my vilain lair is rather big).
So that would be multiple SSID and multiple password.
@deshipu Yes, multiple alarms/conditions can be enabled at once. Also, there is provision to get the alarm that caused wake-up + parameters associated with it.
What I'm worried about the most is that there won't be alarms available for some of the conditions we want to wait on. But I suppose we can just keep adding new kinds of alarms?
Alarms are implemented as separate modules and there availability will vary on a port specific basis.
Another thing is that we want to be able to wait on an explicit list of alarms, not necessarily on all alarms that are enabled. That's because there may be user alarms created and enabled independent from the async main loop, that we would need to ignore somehow.
I would like to point anyone looking for updates regarding deep sleep api to issue #2796, where the api is being actively discussed
Subsumed by #2795. Closing and will copy over the example.
There will be alarm.sleep(alarm1, alarm2, ...). That will do a light sleep until one of those alarms is triggered.
For deep sleep, alarm.wake_after_exit(alarm1, alarm2, ...) will awake and restart code.py when one of the alarms is triggered.
The names above are tentative; I'm still thinking about the best naming.
For an async loop, I proposed above that alarms that trigger will put themselves on a queue, but the API and semantics are not yet specified. You don't have to be asleep...
Ligh sleep example, copied from #2795. Exact function names may change, and sleepio has been eliminated in favor of putting everything in alarm.
Here is an example:
import sleepio
import time
import alarm.pin
import alarm.time
pin0_alarm = alarm.pin.PinLevelAlarm(board.IO0, True, enable_pull=True)
time_alarm = alarm.pin.TimeAlarm(time.monotonic() + 10.0)
while True:
# start with a light sleep until an alarm triggers.
alarm = sleepio.sleep_until_alarm(p...
@microDev1 I will close this in favor of the PR I will be submitting, if that's OK with you.
@dhalbert that looks good, I suppose I got confused by the triggered alarms being stored on a single queue. To implement this, we need to be able to remove the alarms we are waiting on from the queue, but at the same time leave all the other alarms in there. That doesn't sound like a queue data structure anymore. Unless you want to just put the event that don't match our list back on the queue?
@deshipu In the sleep case, there is no queue. I was making a strawman proposal for non-sleep event queuing. I think it needs a lot more thought, but could be added to alarm at a later date, or it could be a separate module. Let's discuss this in a new issue, thought at the moment I will not have time due to working on sleep. Also I think we can learn from what the sleep use cases end up being.
@thorny jay Again, it's just early. I have a demo I want to work reliably as well and I'm debugging it's issues.
esp32s2 question -- does anyone know if this doc (GPIO25/26) is just wrong? Other things refer to GPIO17/18 as the DAC. https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/i2s.html#_CPPv424I2S_DAC_CHANNEL_RIGHT_EN
I2S_DAC_CHANNEL_RIGHT_EN = 1
Enable I2S built-in DAC right channel, maps to DAC channel 1 on GPIO25I2S_DAC_CHANNEL_LEFT_EN = 2
Enable I2S built-in DAC left channel, maps to DAC channel 2 on GPIO26
vs our AnalogOut code: ``` if (pin == &pin_GPIO17) {
self->channel = DAC_CHANNEL_1;
} else if (pin == &pin_GPIO18) {
self->channel = DAC_CHANNEL_2;
@onyx hinge are you trying to access the built-in dac using i2s ?
yeah that's what I'm up to
I've refactored the i2s code so it can be shared with AudioOut
I already tried that ....unfortunately built-in dac control using i2s is not supported on the s2.
I mentioned this earlier but I think you missed it
idf docs have errors and/or are not updated with the recent changes
>>> import digitalio
>>> pin = digitalio.DigitalInOut(board.IO0)
>>> pin
<DigitalInOut>
``` this doesn't seem right -- why can I make a DigitalInOut from IO0 while it's already a part of an SPI object?
bug
@slender iron OK I'll check if there's an issue and file it if not
@analog bridge do you have any links about i2s / dac / esp32s2 or is it just based on your own experimentation?
components/soc/soc/esp32s2/include/soc/i2s_caps.h:#define SOC_I2S_SUPPORTS_ADC_DAC (0) // ESP32-S2 don't support ADC and DAC ah
I was looking for that line... I thought it was in an example
@analog bridge do you think there's a different way to do it, or are we limited to i2sout?
@thorny jay Again, it's just early. I have a demo I want to work reliably as well and I'm debugging it's issues.
@slender iron No worries, I know this is alpha, very new hardware, ... I was just reporting the experience I had and the need for the python code to be robust (and for the clock specifically, it could continue even without being able to do the hourly check) I tried to put some exception handeling, but it is not enough. I need to check the pictureI took to see the various error I encountered. One hardware problem I had this night is the green "power" LED. I don't care if it consume power, but it is a light in a very dark room, and I also like to sleep in the dark. I am sure this is your case, so I will be interested in your solution (masking tape? unsoldering? can it be controled by software?).
... I would even think that we need some kind of watchdog that once enabled requires your to send a keep alive message or else it reboot.
@thorny jay my PR for watchdog support on the esp32s2 got merged recently.
@thorny jay my PR for watchdog support on the esp32s2 got merged recently.
@analog bridge Much needed, great. You kind of want the stuff to restart if something goes really wrong. One worry I have is how to maintain a "state" between restart, so that the software can return to the same "mode" as before the crash (example: "I was showing weather forcast"). Is there some kind of NVRAM were we can write some information, or would you do that on the flash? It need a place that survive a "reset by the watchdog" and where you can frequently write without destroying the hardware.
This may be a board issue - just tested this on a regular sized pyportal and it works as expected.
Going to get my pynt swapped out and see if it follows on the pynt
Lets just use this transparent background png of the Pi 3 for that image for now. Not the same dimensions, but it should work fine. @tannewt Let me know if you had something else in mind.

@analog bridge did you happen to investigate this suggestion of SPI3 -> DAC in the reference manual? (page 641)
nope
figuring why i2s control wasn't working exhausted me too much and I moved on...
@slender iron is spi3 already "dedicated" to something? seems like it's fairly special
@thorny jay I have to check for whether a wdt reset will clear ram or not but if it does than for preserving state you will have to use watchdog mode RAISE which raises an exception that you can catch in your code and then set state in flash using nvm
there's sure no example or code for PWM3/DAC that I can find
@dhalbert I believe that API pattern is suitable for integration with the tasko event loop. Looking forward to playing with alarms, thanks for working on this!
hmm single channel samples to i2s is missing
I noticed that it was possible to create a DigitalIO from some pin while the pin was already in use by an SPI instance:
>>> spi = busio.SPI(board.IO0, board.IO1, board.IO2)
>>> import digitalio
>>> pin = digitalio.DigitalInOut(board.IO0)
>>> pin
tested on a kaluga with a 6.1-ish firmware
Pull in latest changes, including the library and contributing script updates.
@thorny jay I feel the same about the green power LED. I haven't looked into how to disable it. worse case I solder it off. ๐
@onyx hinge I don't think spi3 is used
a socket connection, a user input on STDIO and a UART transmission
This is exactly why I don't want us to think about async now. When we do async I think we'll want to look at all of our existing APIs and provide async friendly versions. This is a huge task and a distraction from adding sleep support that is broadly useful.
@jepler Want to close this? We can reopen if it crops up again.
This could be caused by filesystem corruption.
@onyx hinge Jeff, in the workflow file, is there any particular reason for using python 3.8? micropython tries to be 3.5-compatible. In any case, the problem is that the test scripts fail locally, while they succeed on github. The snag is that we can't add new tests, because we can't generate the expected output files for them. E.g., this https://github.com/v923z/micropython-ulab/blob/init/tests/initialisation.py spectacularly falls through: https://github.com/v923z/micropython-ulab/pull/228/checks?check_run_id=1420028333 Do you have a clue as to what is going on here?
What I mean by "outside the VM" is the code that runs after a crash or code.py completes. If you use multiterminal to update files, then you risk locking yourself out by an error. How are you handling that currently?
@lapis hemlock interesting, I'm not sure
@kamtom480 would know about the stack on the cxd56.
while it installs python3.8, the tests should be invoking python3.5 (which we're depending on being installed in some other way)
env MICROPYTHON_CPYTHON3=python3.5 MICROPY_MICROPYTHON=micropython/ports/unix/micropython micropython/tests/run-tests -d tests
@slender iron Scott, is there any way to fix the following: 253. + 238. + 248. -> 739.0000000000001? This happens on the unix port. This came up first during testing of ulab, but then I figured that it is not a ulab issue per se, it comes from micropython itself.
I have no idea
Great. Now that makes us two.
that's odd, the arithmetic should be exact
I think this is a rounding error.
The question is, why it is displayed in this particular way.
bug exists in MicroPython v1.12-676-gad95c0590-dirty so consider reporting it upstream (while understanding that it's difficult for us to take fixes from them)
I wonder if github is failing to do proper diffs for us
Even better: this is exact 253.0 + 238.0 + 248.0 + 253.0 + 238.0 + 248.0 -> 1478.0
it's a display error, not an error in the value
I think you are right: 739 should fit in any float representation exactly.
$ ./micropython -c 'import struct; print(struct.pack("d", 253. + 238. + 248.))'
b'\x00\x00\x00\x00\x00\x18\x87@'
$ python3 -c 'import struct; print(struct.unpack("d", b"\x00\x00\x00\x00\x00\x18\x87@"))'
(739.0,)
or more to the point, ```>>> 739.0
739.0000000000001
the floating point number to be printed gets scaled so that it has just one digit to the left of the decimal place: ```265 f *= *neg_pow;
the float-printing routine is certainly not designed to give an accurate result in all cases, but .. this is still an unfortunate consequence of the implementation.
this is py/formatfloat.c
I have just checked, this is not port-specific.
@onyx hinge Do you think I should open a ticket, or leave it at that?
in circuitpython we're unlikely to address it ourselves
I don't know what mircopython will do with the report
I meant in micropython. If there is a reasonable fix, I would port it to circuitpython
agreed, we can probably port a change to formatfloat.c to circuitpython
you probably are aware, printing floats accurately is a huge problem and most implementations that do it need lots of code and also perform multi precision arithmetic with allocations. those strategies won't be appealing in micropython
but maybe a special case for numbers that are exactly 32 bit integers would be feasible to add
@lapis hemlock did you try putting in a PR to install python3.5 instead of 3.8, to see what happens? I still don't know what's going on with that test. we got off on a tangent..
@lapis hemlock we got off on a tangent..
@onyx hinge That's right, I also got hung up on the float issue. I am going to open the ticket, and then see to the workflow file.
Hi everyone, anyone know if I make a circuitpython driver for some sensor like this one for example https://github.com/adafruit/Adafruit_CircuitPython_SHTC3 is there a place where third party libraries are listed where I could have mine listed too? I also saw the CircuitPython_Community_Bundle, maybe this is where I should aim for my driver to get added?
@candid granite The Community Bundle is exactly the place to aim.
@tannewt Fair enough. I think that leaves two use cases, I suppose: waiting on an interrupt pin of a sensor, and waking up periodically to make measurements? Maybe also a soft power button?
@lapis hemlock did you try putting in a PR to install python3.5 instead of 3.8, to see what happens?
@onyx hinge That doesn't fix the issue. I still have a couple of things to try out, though...
Regarding the float printing โ this may be relevant: https://github.com/micropython/micropython/issues/5284 (from https://forum.micropython.org/viewtopic.php?t=7177)
@lone axle Are you around?
@opal crystal Thanks for pointing this out. So, this is a known issue.
@idle owl yep, whats up?
Hmm... Maybe I'm missing something. First off I feel like I shouldn't be using MagTag to test your Slideshow update. Second, should the simpletest work with the json file or is there some other thing that has to happen?
(Switching to a PyBadge)
Ah yeah, I tested only on PyPortal so far. The simpletest can be used to test it but you would need to paste the text json file into the root of CIRCUITPY instead of images/ like it is in the repo
Ok
I actually just noticed that the simpletest is using / for the folder. I had assumed it was using the images. I think that is why I put the text in there.
Simpletest isn't working.
Had to remove the BACKLIGHT line altogether to make it work on PyBadge which makes me wonder if we should have it in the simpletest, but....
It either skips your file, or it says RuntimeError: No valid images or text json files
Small update: upon reboot of problematic AP (Apple Time Capsule w/ external DHCP), Metro ESP32-S2 connection results:
- Arduino ESP32-S2 "idf-release/v4.2" : connects
- CircuitPython 20201011-40a3d11: connects
- CircuitPython 6.1.0-beta.0: does not connect, and often hard-resets
I can try it out on that device. perhaps there is something I have in my local one that accidentally didn't make it into the commits.
Alright. I'll comment on the PR so this is somewhere useful.
I will be working on it a bit more tonight. I would love to get those last two items implemented before it gets merged anyhow. I'll check it out on the magtag as well when I am working on it.
@lone axle MagTag support in Slideshow was something I was hoping you'd sort out as well. The display requires a refresh() where others do not, so you'd have to figure out how to incorporate that cleanly. I'm not sure it's reasonable to do and may simply require another example, but having a single simpletest run on multiple things without significant changes would be ideal.
The REPL connection library (https://github.com/iot49/iot-device) I have is very reliable. Plug, unplug, press reset, whatever - the devices come reliably online on go off. Very reliable; I never got locked out (try if you like :).
However I once corrupted the flash when editing directly on it. Now I edit my sources on the host, and update with rsync (my implementation, runs over the REPL, however it is connected, soon by BLE). This way I also always have a backup (on the host).
I won't be able to test again until next week if you're getting back to it tonight, so no worries on implementing more features. You have time.
I would make a note that you are going to do that though so someone else doesn't test/merge it.
Yep, it is in there now. Ladyada got to it before mine arrived to tinker with it. But I got it tested out over the weekend and it's already merged. So MagTag is working correctly with images. But I haven't tested it with the text slides yep.
Oh right on. Good to know.
I think the simpletest needs some tweaking then.
Because it didn't work with either MagTag or PyBadge out of the box. ๐
agreed. I'll try to sort that out as well I can put a fix for it in the same PR if that is okay.
That would be fine. Just make a note of it.
@tannewt Sorry to bother again - do you have an idea how to fix the remaining (new) 3 errors, all of the same format:
Run actions/upload-artifact@v2
with:
name: espressif_saola_1_wrover
path: bin/espressif_saola_1_wrover
if-no-files-found: warn
env:
pythonLocation: /opt/hostedtoolcache/Python/3.8.6/x64
With the provided path, there will be 36 file(s) uploaded
Error: read ECONNRESET
@onyx hinge One indicator of the perpendicular (non-tangential) problem is that the latest version of micropython does not produce the expected files. There is actually no output for a test script that has never been run. I don't quite know what this means, though...
@idle owl Ah I see what the deal is. The text slide support requires adafruit_display_text also, but it has a try/except to fail gracefully if it's missing.
@lapis hemlock is this a change in micropython?
@lone axle I had an old version of it temporarily and removed it and get the same error
Let me add it
I should document that more clearly in the comments / docs for sure. Maybe even print a warning in the console.
-If a test fails, run-tests produces a pair of <test>.out and <test>.exp files in the current
+If a test fails, run-tests produces a pair of <test>.out and <test>.exp files in the result
directory with the MicroPython output and the expectations, respectively.
I guess so. I just pulled the latest changes, and re-compiled the firmware, and since then I haven't seen the .out/.exp files.
@lone axle Traceback (most recent call last): File "code.py", line 11, in <module> File "/lib/adafruit_slideshow.py", line 237, in __init__ File "/lib/adafruit_slideshow.py", line 239, in <listcomp> File "/lib/adafruit_slideshow.py", line 205, in _check_json_file OSError: [Errno 2] No such file/directory: '//.fseventsd'
- cmd_parser.add_argument('-r', '--result-dir', default=base_path('results'), help='directory for test results')
is there a "results" folder/directory?
Hmmm, not sure about that one. Will check into it though.
@lone axle Updated the PR. Thanks!
".fseventsd" is normally an empty directory, not sure what that means for the message ... supervisor/shared/filesystem.c: res = f_mkdir(&vfs_fat->fatfs, "/.fseventsd");
er no it has an empty file no_log inside it
is there a "results" folder/directory?
@onyx hinge No, there isn't.
Thinking of it,
This certainly would be a bad idea - code.py:
while True: pass
I protect in boot.py against this in boot.py:
try:
# CircuitPython specific
import board
import digitalio
import storage
with digitalio.DigitalInOut(board.D0) as mode:
# mount CIRCUITPY if D0 pulled low ...
mode.pull = digitalio.Pull.UP
storage.remount("/", readonly=not mode.value)
except ImportError:
pass
...
@onyx hinge And watch this: ```cp 00smoke.py 01smoke.py
cd ..
./build.sh
....
...
pass tests/00smoke.py
Traceback (most recent call last):
File "tests/01smoke.py", line 1, in <module>
import ulab
ModuleNotFoundError: No module named 'ulab'
FAIL tests/01smoke.py
01smoke.py is a verbatim copy of 00smoke.py, and it passes only, if I also copy 00smoke.py.exp onto 01smoke.py.exp. Shouldn't the test scipt run, no matter what? The ImportError is definitely too early for anything.
./micropython/tests/results/tests_cholesky.py.out
I am most probably bewitched.
inside the micropython source inside ulab?
I see them now. A most unusual location.
so next problem .. why it gets an error importing ulab
run-tests can work in one of two ways: first, the output of micropython compared to the output of desktop python3. second, the output of micropython compared to an ".exp" expected file
if there's no .exp file it runs the same program with python3 (or 3.5 or 3.8 or whatever...) and (A) that has to succeed and (B) then that's used as the expected output for comparison
but of course you can't import ulab
so instead you have to manually create the expected file. This USED to be possible by running micropython's run-tests in an unusual way but it's not now so I won't bother saying what that unusual way was
./micropython/ports/unix/micropython tests/cholesky.py > tests/cholesky.py.exp && git add tests/cholesky.py.exp so instead you can just do this, except change the test name
in 3 places
unless your changes to output formatting mean that cpython3 numpy output and ulab output can be compared directly
we MIGHT want to just take a copy of run-tests (a python script) at some ref where we control the behavior, instead of needing to adapt to changes in the script in micropython
so instead you have to manually create the expected file. This USED to be possible by running micropython's run-tests in an unusual way
@onyx hinge Well, this is somewhat exasperating, I must say.
The tests are trivial in the sense that we have only textual output, so can't we just run micropython with the test script, catch the output, and compare it to .exp? We would have to compare the output to numpy, but we have to do that only once, at the time of creating the .exp file.
I wonder, why this has changed in micropython, but this is rather inconvenient.
And how is it in circuitpython? We could live with checks against circuitpython, if it comes to that...
Looks good to me, only one small style note.
We try to avoid any use of goto in port implementations. Please add a flag and conditional for the multilevel break.
@onyx hinge Hey buddy. How's it going? I need git help.
Text is fine.
Actually, one step back. Is there a way to verify that a submodule is up to date?
Before I try to figure out how to update submodules.
by "up to date" you mean matches whatever rev is commited in the superproject?
Um...
By up to date I mean the submodule is even with itself.... Specifically, on circuitpython-org, is adabot up to date
with the current changes to Adabot
Wait I clicked on it in GitHub. And it shows me the latest changes to Adabot
you want to know if circuitpython-org has the latest changes to adabot
and now you know?
But I think I answered my own question after rethinking it.
I believe so?
Do you know much about GitHub Actions?
I pretend to, like I do with a lot of things
Because this is a weird one, I re-ran a job and it's not seeing the updated submodule. It's installing from an old version of requirements.txt, I don't even have to wait for it to fail the whole job. I know it's wrong within 30 seconds or so.
We have to wait anyway because we hammered the API w/in the last hour with too many requests to do another full run.
Are you still adding features to this, given that it's in draft? Unfortunately I don't have the hardware to test it. No real comments on code style, since it's all ported code, which we give a pass on for things like gotos, etc. Feel free to un-draft whenever you like. Should be fine to approve unless @tannewt wants a second test opinion.
But it installs dependencies before beginning requests, so it's possible to see it's not right before we get to that part of the job.
can you point me at the run?
but of course you can't import ulab
@onyx hinge I could catch that at the very beginning like ```try:
import ulab as np
except ModuleNotFoundError:
import numpy as np
But that would imply that the workflow has got to install numpy, too.
@onyx hinge Maybe old jobs simply won't see new modules?
๐คทโโ๏ธ
@lapis hemlock what I mean is,
[0. 0. 0.]
$ ./ports/unix/micropython -c 'import ulab as np; print(np.zeros(3))'
array([0.0, 0.0, 0.0], dtype=float)
``` the output are different
@idle owl right, when you use the "re-run" button it uses the particular ref, which is before the commit that changed the adabot submodule
@lapis hemlock I'm working on scripting it a bit better
@onyx hinge This might be a bit more difficult, since, at least, in circuitpython, you have sub-modules that don't exist in numpy.
whee, got most of minimqtt working with cpython. ๐ก
@idle owl I think we can change the workflow so that you can trigger it from the web ui
@onyx hinge Hmm.
let me prepare a PR so you can see what I mean
in a repo of mine for some random thing, I have a workflow that can run as a cron .. yup
Excellent. Test bed.
@onyx hinge With the latest micropython, I can't just run an arbitrary script on the command line. This used to work: ./micropython /dev/shm/micropython.py , but not anymore.
@lapis hemlock probably there will be some problem with it but https://github.com/v923z/micropython-ulab/pull/229 is what I'm thinking
Subsumed by #2796. The original issue has a low-power implementation for nRF. We are doing ESP32-S2 first, but can open issues for other ports.
@lapis hemlock hum that is not something that I encountered yet
That line produces the garbage in the expected files, like ```micropython: ../../py/argcheck.c:111: mp_arg_parse_all: Assertion `(allowed[i].flags & MP_ARG_KIND_MASK) == MP_ARG_OBJ' failed.
CRASH
wow that's not right
if they've entered an unstable phase of development, maybe ulab needs to check out a specific revision like their last stable release
if they've entered an unstable phase of development, maybe ulab needs to check out a specific revision like their last stable release
@onyx hinge We could do that.
@lapis hemlock probably there will be some problem with it but https://github.com/v923z/micropython-ulab/pull/229 is what I'm thinking
@onyx hinge Thanks, I have merged the changes. That fixes the problem with the missing .exp files, but the issue with the crash report still persists. I will try to roll backmicropythonto a point, where it works again.
I have to take off now, but many thanks for your contributions!
This was a rather intense evening.
see you!
So long.
@prime flower "got most of minimqtt working with cpython" yay excellent
@onyx hinge yep, thanks jeff! Going to convert all the recvs into recv_into with a shared buffer next, and then creep into ssl-specific code.
this is different than adafruit io mqtt? or under it?
It's the circuitpython mqtt client. Adafruit IO Circuitpython uses it.
got it
I was just ruminating about how adafruit io http isn't working with esp32s2 right now
as far as I know/knew
ideally it will after tomorrow ๐ , i was waiting for the ssl issue to be resolved.
yeah it was a chicken and egg problem I suppose
also a lack of time on my part between school/work. I don't expect blocks, but I havent tested sending requests to IO with the ESP32S2 yet
believe me, I'm excited for the magtag on my desk to display a data feed from IO ๐
@cwalther You're right. cxd56 has a fixed stack so function port_fixed_stack() should return true. Could you change it?
@prime flower if you need any help testing i've been working on updating a project that's reading IO data. So far its in Arduino just doing HTTP requests by hand - which is painful ๐
@blissful pollen that'd be great - with ESP32S2?
Yup my magtag is sitting beside me right now
oh...I updated the ESP32S2 guide to include the new HTTP stuff!
for arduino
You should be able to use WiFiClient unless you mean by hand as in writing client.printlns for requests..?
Oh cool I'll take a look. Does the library allow you to retrieve the last X data points or just the most recent? I've been trying to average data out
I was using WiFi client and then parsing the JSON, just sending HTTP by client.println() is annoying and parsing headers, etc.
They only allow retrieval of most recent since thats the most popular request from users, you could add it to the Adafruit IO Arduino/Adafruit IO CircuitPython library if you'd like
Cool, I've been waiting to start playing with the CP library for it and will take a look at it for sure
Why do you need to retrieve X data points? Are you graphing on the magtag?
Averaging the last few data points - say for temperature over the last 5 minutes. Or pressure changes over say 6 hours. Graphing is a "nice to have" idea on my mind still
silly question about support for esp32 and CircuitPython :
Now that support for the esp32s2 is being added, how hard it would be to support normal esp32 but without native usb ? I know that CircuitPython relies a lot on the ease of usage of having native usb, but would be cool to use it on "old" esp32 as it is more well documented and have a bigger community than micropython IMHO
Yeah, that's currently not possible with AIO CP, but the AIO API (https://io.adafruit.com/api/docs/#get-most-recent-data) supports it. I'd looove to have a way for IO to perform the averaging instead of the device.
@jovial topaz Our principle is that it's not CircuitPython without the workflow experience that USB provides. Conceivably that workflow could be provided via BLE or Wifi, but that would not be easy.
We had CircuitPython for the ESP8266, and dropped it for several reasons. One strong reason was that it was an outlier in terms of how you had to use it (no CIRCUITPY, etc.)
OK, Iโll change it here. Would you also like a PR to change it in the current code, independently of this one? Iโm not sure if this will go into the next stable release.
@slender iron I haven't seen much about ESP32-NOW, is support for that on the docket? or already done and I don't know about it?
gotcha @tulip sleet . I think CircuitPython is awesome beyond the nice USB workflow. I would prefer to use it over micropython, as the CircuitPython libraries and tutorials are much better.
I have a LOT of esp32 here that I used to give some Arduino workshops here in Brazil, but I was planning on move to CircuitPython that seems nicer for new devs. I know that would still go thought the "hassle" of using something like ampy to transfer files, but I made some tutorials using Jupyter Notebook + esp32 + micropython (https://www.youtube.com/watch?v=PTYXsgUSoxs - it's in PT-BR) and the experience was nice even without native usb. The problem is that Micropython libs are not well documented as CircuitPython ones, so is a bit harder for newcomers
And here in Brazil is really easy to get the "old" esp32 and like I mentioned before, I already have a bunch. I ordered yesterday some esp32s2 from AliExpress to try it with CircuitPython to collab a bit more on the project. Overall I just wish that I would have better access to boards with CircuitPython support here in Brazil haha
But thanks for the feedback @tulip sleet
@slender iron I haven't seen much about ESP32-NOW, is support for that on the docket? or already done and I don't know about it?
@ionic elk It's not on my radar to support
@slender iron are there other ways to connect between multiple ESP32s on the same wifi network? That was my primary interest in it, since the S2 doesn't have bluetooth
I have no idea
well, just tossing it out there - device-to-device wireless communication seems like it'd be neat to have
you can call the circuitpython module soonio
@onyx hinge I haven't even seen that one
One of my favourite scenes from Spaceballs the movie
@jovial topaz Adafruit_Blinka has support for pyboard, and indeed, one of the original motivations for Blinka was to run CircuitPython libraries on top of MicroPython. That has been eclipsed by supporting various Linux boards, but the support is still there. Would that help you?
I'm glad you appreciated it
I'll check it out @tulip sleet , I thought Blinka was just for SBC/Linux hosts
I'm just looking at it now, to make sure the support is still there, but it looks like it.
seriously though espnow looks interesting -- seems devices will need to be on the same wifi AP but you can send unreliable messages between them using the HW address. I assume it's unreliable "ethernet" packets from what I can see. optional encryption, not sure how you get the keys
discovery via use of the broadcast address? shivers well what else will you do
huh no it seems to be independent of an AP. interesting-er
let's get the basics working reliably first
I mean I'm not the expert on wireless stuff but device-to-device communications has always seemed like a big pull for a device, so you don't have to rely on an external lora or something
I might give it a try outside of Circuitpython in the meantime
would be nice to have something like that for my alarm clock
you don't have an access point already?
If you mean me, my alarm uses NRF20L01s lol. Not the greatest. Also unsellable due to certifications
I can't tell if espnow is exclusive of wifi or both can be used at once
certainly seems to imply it
implementation is in a binary blob, but it does seem to "be there" for esp32s2 components/esp_wifi/lib/esp32s2/libespnow.a
https://blogs.arubanetworks.com/industries/802-11-action-frames/ I did not know what "action frames" were. here's an overview
Anyone with a working gray scale example for the MagTag willing to share the code? Mine only displays black and white... ๐
what build are you using? does it have board.DISPLAY?
@cwalther Ok, I understand. In that case, I will test this change tomorrow and if everything works, I will create PR.
@slender iron It did not. It does now. ๐
So how would I use that board.DISPLAY stuff?
In the current code (before my change) itโs a bit more involved than just changing a false to a true, but you should be able to copy the code from the mimxrt10xx and esp32s2 ports. I can do it if you want, but I wonโt be able to test it.
I installed adafruit-circuitpython-adafruit_magtag_2.9_grayscale-sv-20201118-8ac9b17.bin and it reports 0 byte available of 963K byte for the disk. That does not sound right...
ya, the latest has been a bit unstable
@onyx hinge Did you end up doing up the thing with being able to trigger the job manually? I was going to say maybe don't, if you haven't, but, it occurs to me that if it's still not working, or for future use, it might still be worth it. So I'm apparently still interested?
@idle owl whoops I thought I shot in a PR for it
Maybe you did and I missed it?
maybe I didn't click submit
Tag me on it please ๐
@onyx hinge .... that's it? Hah!
you have to KNOW what it is though
I guess!
the connect does a second scan
@slender iron does it pick the AP with the lowest RSSI from among those with the same SSID? I don't see a CircuitPython-leveldisconnect, does automatic reconnection happen in circuitpython code or espi idf? n/m on the second question, I found the event handler
@onyx hinge So, once that's added, it shows up able to be run manually? There's so many options in the example, they're not needed?
I trust you, it just seems too easy.
once that is in main, the page within actions should have a new button to click
(or master)
Great!
It worked!
yawsssss
Whee and failed! ๐ This was the test run, so this is not a surprise.
huh ERROR: Invalid requirement: 'requests-cache=0.5.2' (from line 10 of adabot/requirements.txt)Hint: = is not a valid operator. Did you mean == ?
in adabot?
yes
@onyx hinge ok now I need to submodule update circuitpython-org. Do I run git submodule update and then commit/merge? Or is there sync and init and all that involved?
Or is there a way to update only the adabot submodule?
Which would make me much more comfy
@idle owl In the submodule, "git checkout master; git pull" (if the branch is called master)
that will change the checked out files in the submodule to be the tip of master branch, just like "git pull" always does
there's nothing in the submodule folder :/
ok better do submodule init/update then
ah ok
in the outer world
after the submodule update, go into the submodule and do the steps I said
ok
then go up to the top directory, "git add adabot" "git commit adabot" and write your commit message
does it have the right content or the wrong content?
correct
@onyx hinge On branch adabot-update-18-nov Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: adabot
OK try git commit
@idle owl yeah looks good to me too -- did you find where you can click to verify it?
Click to verify it?
click the "1 files" link https://github.com/adafruit/adabot/compare/9c67b7f923226b628c691a48987d9eaae2940051...665d9ae7f8109d6552ff8821ee052619cba78a8e
I mean, to double check
Yes!
happy to help with gaps in your knowledge
Now we wait another 20 minutes for this to run or fail eventually!
or we fall asleep first
.. it seems to make the esp-idf grumpy.
This was to avoid an error in debug builds but the cure is worse than the disease.
esp_err_t esp_event_loop_create_default(void)
{
if (s_default_loop) {
return ESP_ERR_INVALID_STATE;
}
How about tracking if netif has been started once and only get the loop when it hasn't been?
I attached to the native UART on MagTag. These are the backtraces I got when the usb disappeared or the serial connection hung.
? Backtrace:0xfffffffd:0x3ffe9280 0x400e2bc9:0x3ffe92a0 0x40036827:0x3ffe92c0 0x40037c4d:0x3ffe93e0 0x4003b6f5:0x3ffe9400 0x4003982b:0x3ffe9440
got ['0xfffffffd', '0x400e2bc9', '0x40036827', '0x40037c4d', '0x4003b6f5', '0x4003982b']
??:0
/home/tannewt/repos/circuitpython/ports/esp32s2/build-adafruit_magtag_2.9_grayscale/esp-idf/../../esp-idf/components/esp...
untested, because I don't want to mess my magtag demo up :) but it builds
@slender iron @ionic elk looks like maybe the implementation of calibrated ADC on esp32s2 is incomplete? uint32_t reading = adc1_get_raw(ADC1_CHANNEL_5); uint32_t voltage = esp_adc_cal_raw_to_voltage(reading, adc_chars); is suggested https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/adc.html but we don't actually call esp_adc_cal_raw_to_voltage that I saw
I'll have to check my notes, but I'm pretty sure that you literally can't yet on the ESP32-S2
The ESP32 and the S2 have different voltage curves
When I started on the S2 ADC stuff, we had to update the IDF because even the basic ADC calibration stuff had only been implemented that month. I can check in again on where things are at. If there is calibration, it's probably just a bit of smoothing at the ends
From what I recall the S2 also caps out entirely at about 2.6V and will not go higher, even at 11DB attenuation
OK, it came up in the internal meeting so you may get another ping about it ๐
Happy to take another look stuff might have changed
It needs to do the bitmasking that was only added to ColorConverter
in #3611
@ionic elk esp32-s2 at 11dB should go to 3.3V
it's just optimal between 0.150-2.6V
I saw it once with a correct password. Retrying may still fail
but at least it'll try first.
@todbot, this may help you too.
@onyx hinge Is this not what we need? https://github.com/adafruit/circuitpython/blob/8ac9b176c961faf7672f081953de6f78ec3005e2/ports/esp32s2/common-hal/analogio/AnalogIn.c#L92
@crimson ferry mea culpa
- Don't add full urls because they are too large.
- Remove the unstable version when it starts with the current
version. - Ran
black
As predicted, this over-filled the metro_m0_express:
Build metro_m0_express for de_DE (clean_build) took 38.73s and failed
make: Entering directory '/home/runner/work/circuitpython/circuitpython/ports/atmel-samd'
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
QSTR updated
253780 bytes used, -84 bytes free in flash firmware space out of 253696 bytes (247.75kB).
I'll see what I can do.
Makes sense comparing this to #3611 so approving but also looking for a retest from PaintYourDragon before merging
I had thought maybe the tick disable problem in #3710 could have fixed/improved this. However, now this seems to be resetting the magtag each time I reload the test program. Not good. I did my testing with the artifact from #3718 which doesn't have the fix from #3716 which is causing general instability so maybe not a good test.
Certain BMP varieties fail to load or display as intended. Behavior varies depending on image type, size, and whether using displayio.OnDiskBitmap vs adafruit_imageload library. (Last image is skipped because it's known that imageload doesn't handle 24-bit BMPs -- this is NOT a bug report or feature request for that -- the other images represent the issues being raised here.)
Test platform is Adafruit MagTag running adafruit-circuitpython-adafruit_magtag_2.9_grayscale-en_US-20201117-a0d305...
As a circuit python user with an esp32s2 board (specifically the Feather S2), I want to be able to be able to use socket bind/accept/listen so that I can create a TCP server on the device that can receive incoming connections.
Just tried this on MagTag (build 20201119-4543735 aka 6.1.0-beta.0-13-g4543735f2).
No change compared to CirPy 6.1.0-beta.0. That is: On power-on it connects, but Ctrl-D reload causes hard-reset.
I can confirm this bug to be present on other peripherals and not just related to spi.
Unless thereโs a .UF2 to test against, Iโll take your word for it.
Making a command line tool for working with my CircuitPython boards. First thing I implemented was "backup" so that I can grab a snapshot of the current state in a zip file. https://github.com/bcr/blinka-cli
...are there other ways to connect between multiple ESP32s on the same wifi network?
@ionic elk ESP-MESH seems to be promising
@dhalbert As discussed earlier on discord, there is still some work left to be done on the alarm modules... I have already got changes on my local branch. I am waiting for the api changes before pushing them.
@microDev1 I did not realize you were still working on these. I am working in https://github.com/dhalbert/circuitpython/tree/sleep, but it does not even compile yet and has rough edges. I push regularly for backup purposes and just merged from upstream.
The API implied in the #2796 is still a moving target, and my branch is the latest, though the API hasn't been re-reviewed completely by @tannewt yet.
I am very focused at first on the narrow path of getting DurationAlarm to work, beca...
Spresense also has a fixed stack, so port_fixed_stack() should not return NULL.
It was pointed here: https://github.com/adafruit/circuitpython/pull/3695
@cwalther Thank you for finding this. I created PR.
@tannewt soo can I put the precompiled python data to the internal flash on the samd51 and tell the samd to execute a file from the sd card?
@lament sentinel that looks awesome. Thanks for sharing. I love the idea of CLI to backup devices. I am interested to see what other helpful utilities can gets added too.
@lone axle I am adding a BOSSA updater to it now. I have some old boards that need upgrading to CircuitPython
@lament sentinel be very careful with bossa. The default value of the --offset argument was changed around 1.8 or 1.9, and is now 0x0. If your bootloader is not protected, it will overwrite the bootloader with whatever you're uploading.
๐ฏ % true. I mostly bricked a Lora Feather that way. Wouldn't have been able to get it back to working without help from Dan ๐ .
@tulip sleet bruh tell me about it. I am super duper aware and have been reading every page to make sure I got this right. I understand the v1.7 change for offset, I understand the SAMD21 offset 0x2000 vs SAMD51 0x4000. And I am going to put dire warnings on it and explain exactly my plan for executing bossac before I do it
@lone axle yes, this is part of the motivation, to get this right. And I will make sure to ask for reviews and make it as clean as I can so we get this right
it was a :๐คท forehead-slapping change, and has still not been fixed
It is fully my intent to understand the BOSSA version and behave appropriately, I feel you. I once accidentally changed the default address for another update tool I made and bricked myself ๐ โ part of the reason I am so careful
is it possible to use a manually created displayio.Palette + displayio.Bitmap with MagTag's EPD?
@tidal kiln I don't know why not
do you know what the palette values should be?
trying several things and only getting black/white
I could be wrong of course ๐
is it due to this bug? https://github.com/adafruit/circuitpython/pull/3719
@tidal kiln maybe try with an artifact from that PR and see if it works?
thanks. looks like it maybe related. let me try that....
@PaintYourDragon there are but because of a problem in github there's a trick to getting to them. (the main page of artifacts isn't paginated, so it just shows 100 of them.. github have not fixed this bug yet)
Go to a particular build (this is the magtag build, but it doesn't matter)
https://github.com/adafruit/circuitpython/runs/1421596580?check_suite_focus=true
find where it says "artifacts: 175" and you can get the whole list of 175 artifacts. adafruit_magtag will be in there.
Hey CircuitPythonistas- I haven't been active in a while but I'm still around and I wanted to thank all of you for the 6.0 release. I promise I'll be back soon to cause more trouble. ๐
@ivory yew ๐
@tidal kiln fixed it for me .. before I just got two colors, now I get 4. The color values I used were 0x000000 0x555555 0xaaaaaa 0xffffff
@ivory yew as always the community will be here for you when you have the time & spoons to engage with us again!
@lone axle @tulip sleet PS C:\Users\bcr00\Source\bcr\blinka-cli> python .\blinka.py --verbose bossa --port COM5 DEBUG:root:options = Namespace(verbose=True, quiet=False, locale='en_US', command='bossa', bossa_path='C:\\Program Files (x86)\\BOSSA\\bossac.exe', port='COM5', func=<function do_bossa at 0x000001EF4C0FFF70>) INFO:root:Using en_US for the locale INFO:root:Executing ['C:\\Program Files (x86)\\BOSSA\\bossac.exe', '--port=COM5', '-i'] DEBUG:root:returncode = 0 DEBUG:root:Stdout is b'Device : ATSAMD21x18\r\nVersion : v2.0 [Arduino:XYZ] Mar 5 2016 17:46:52\r\nAddress : 0x0\r\nPages : 4096\r\nPage Size : 64 bytes\r\nTotal Size : 256KB\r\nPlanes : 1\r\nLock Regions : 16\r\nLocked : none\r\nSecurity : false\r\nBOD : true\r\nBOR : true\r\n' DEBUG:root:key = 'Device' value = 'ATSAMD21x18' DEBUG:root:key = 'Version' value = 'v2.0 [Arduino:XYZ] Mar 5 2016 17:46:52' DEBUG:root:key = 'Address' value = '0x0' DEBUG:root:key = 'Pages' value = '4096' DEBUG:root:key = 'Page Size' value = '64 bytes' DEBUG:root:key = 'Total Size' value = '256KB' DEBUG:root:key = 'Planes' value = '1' DEBUG:root:key = 'Lock Regions' value = '16' DEBUG:root:key = 'Locked' value = 'none' DEBUG:root:key = 'Security' value = 'false' DEBUG:root:key = 'BOD' value = 'true' DEBUG:root:key = 'BOR' value = 'true' INFO:root:Address for device ATSAMD21x18 is 0x2000
@onyx hinge thanks! that was it. works now. thanks for the tip in the issue thread about how to get the artifact also!
you're welcome, and thanks for doing testing!
Is there an alternative to esp_log stuff ?...I tried ESP_LOGI but it just doesn't seem to work for me.
mp_printf(&mp_plat_print, "i=%d\n", i);
ESP_LOGI should appear on the debug uart depending on esp-idf configuration flags though
there does seem to be 5 levels of log, I don't know which level we are running in cpy.
It's hard to see the intended change from all the black changes (formatting with black first as its own commit can help with this in the future!) but it looks OK.
@lone axle @tulip sleet Version checking
Shorter output sorry about that INFO:root:Executing ['C:\\Program Files (x86)\\BOSSA\\bossac.exe', '-h'] DEBUG:root:returncode = 1 DEBUG:root:final_version 1.9.1 DEBUG:root:Comparing BOSSA version 1.9.1 to >=1.8.0 DEBUG:root:BOSSA version is cool
there isnt 'precompiled python' in the sense that it is executed. python is interpretted only. you can use mpy-cross to mpy'ify a py file, that only makes it more compact (bytecode conversion). then import it as any other python code
i'm getting a hard reset on magtag when running the bitcoin fetch example a second time
slightly modified example to just print to serial
from adafruit_magtag.magtag import MagTag
DATA_SOURCE = "https://api.coindesk.com/v1/bpi/currentprice.json"
DATA_LOCATION = ["bpi", "USD", "rate_float"]
magtag = MagTag(
url=DATA_SOURCE,
json_path=DATA_LOCATION,
)
magtag.network.connect()
resp = magtag.fetch()
print("Bitcoin =", resp)
results:
Adafruit CircuitPython 6.1.0-beta.0-13-g3e6661bc9 on 2020-11-19; MagTag with ESP32S2
>>> import fetch_test
Connecting to AP ----
Retrieving data...Reply is OK!
Bitcoin = 18023.4
>>>
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Hello World!
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 6.1.0-beta.0-13-g3e6661bc9 on 2020-11-19; MagTag with ESP32S2
>>> import fetch_test
Connecting to AP ----
hard resets after that
@tidal kiln want to file an issue or try and debug it?
i should probably just file an issue
take it i'm not doing anything obviously wrong? (just got magtag two days ago, so only just starting to kick the tires on the thing)
I'm getting a hard reset on the Feather S2 when connecting to wifi for the second time too
@jaunty juniper what version are you running?
@slender iron is info above enough to add to issue? or need anything more?
the 6.1.0 beta, but I have had that happen for a while, but it seemed intermitent and I had other problems to look at first
the beta is pretty broken I think
we have a fix that we're waiting on the CI for
I think the last commit before it starts with a18 iirc
is it the event loop deletion PR that would fix things?
yup
This is a modified version of the bitcoin example:
from adafruit_magtag.magtag import MagTag
DATA_SOURCE = "https://api.coindesk.com/v1/bpi/currentprice.json"
DATA_LOCATION = ["bpi", "USD", "rate_float"]
magtag = MagTag(
url=DATA_SOURCE,
json_path=DATA_LOCATION,
)
magtag.network.connect()
resp = magtag.fetch()
print("Bitcoin =", resp)
which is saved as fetch_test.py to the MagTag's CIRCUITPY folder. Then, connect to REPL and:
Adafruit Circu...
too much good stuff ๐
@tidal kiln could you try with the older a18 build?
your issue might be the same that beta.0 has
a185549 the one right before the beta release tag?
@tannewt Fair enough. I think that leaves two use cases, I suppose: waiting on an interrupt pin of a sensor, and waking up periodically to make measurements? Maybe also a soft power button?
Yup, I think we get pretty far with just pin level alarm and time based alarm.
beta.0 is broken. Please use the a18 build until #3716 is merged into main.
Sounds like this might be related to something known.
Issue does not occur with adafruit-circuitpython-adafruit_magtag_2.9_grayscale-en_US-20201117-a185549.bin
@slender iron a18 works
๐ thanks!
np
@iot49 Those are network failures. You don't need to worry about them.
@slender iron getting my alarm branch to compile... what was your last idea about the rgb led status animation? It returns a count of how many times it's been run? Originally you were returning a bool, but parts of the code are trying to return a count. Would the caller stop calling it after <n> cycles?
a18 indeed works for me too
i will just do boolean for now, based on what the caller is currently trying to do
tested non-tall version, rotation works great!
tested on hardware, not stylistic review
@tulip sleet I'm not sure. don't read too much in the code I sketched out ๐
Hi, guess who just had the idea to order a magtag and now is pretty disappointed?! ... ๐
Please find another way to make it fit.
I don't want to switch to errors to TERSE. Good error messages are critical when beginners are beginning to learn to code. It is not something we should sacrifice to have dynamic EInk rotation.
This is not even being sold for double its price on eBay ... so the community really loves the product, you can tell ๐
@kahveciderin I'm not sure what you are trying to accomplish.
@todbot I think you are hitting a separate issue. This was only intended to fix the "unknown failure" on connection.
It's hard to see the intended change from all the black changes (formatting with black first as its own commit can help with this in the future!) but it looks OK.
Yup! Sorry about that. I was thinking it had already been run through black when I ran it.
This should be fixed by #3716
@jepler want to get this in to the beta?
Could anyone, please, run the following code on bare metal? import ulab as np print(np.array(range(2**8-5, 2**8), dtype=np.int8))
This doesn't work on the linux port, while is OK in micropython. I am trying to find out, whether this is a peculiarity of the circuitpython unix port, or more general, but I haven't a circuitpython board handy at the moment.
Naive question, but on second thought (ref: Discord comments on WIFI_REASON_...) do we care what the reason is once we know we're in SYSTEM_EVENT_STA_DISCONNECTED state, unless we want to log it or raise it to the user? All reasons mean we're already disconnected, and we need to re-connect (unless scanning or intentionally disconnecting (which we don't yet have an API for).
@ladyada yeah that was what i meant
@tannewt i am trying to execute a file from the sd card, without the external flash.
@lapis hemlock ```Adafruit CircuitPython 6.1.0-beta.0-11-g8ac9b176c on 2020-11-18; FeatherS2 with ESP32S2
import ulab as np
print(np.array(range(28-5, 28), dtype=np.int8))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OverflowError: value must fit in 1 byte(s)```
@opal crystal Thanks! The same as on the unix port.
This appears to be related to https://github.com/adafruit/circuitpython/issues/2579, which is a closed issue.
The error is most probably caused by a call to item = mp_binary_get_val_array(...); mp_binary_set_val_array(...);
To be a bit more specific, https://github.com/v923z/micropython-ulab/blob/31d0bec9fe58c5170865a7f77609cd89296b6eed/code/ndarray.c#L868-L871
Is searching the circuitpython code on github disabled? Whatever I do, I just get a listing of matching issues, but no references to the code.
Thank you! Can confirm now, this fixes grayscale handling with imageload.
@lapis hemlock same here, I just tried to search for "esp_wifi_start" and don't get any results in "Code". This appears to be a sideeffect of being a forked project (from micropython)
@hearty tapir This is quite bad.
@slender iron So, perhaps, it would be high time to just start from scratch, and open a new repository for circuitpython.
The two projects have considerably diverged, so there is not too much to lose.
UPDATE: PR #3719 (now merged) fixes the imageload (bottom row) thresholding error; those items can be ignored.
WRT OnDiskBitmap: looking more carefully, it appears that black is transparent in all three cases: 4-bit paletted, 8-bit paletted and 24-bit RGB. (Compare the upper & lower 8-bit images with the #3719 fix, they should be identical.) Orโฆhereโs a photoโฆ

Looking a...
@lapis hemlock no way. it's important for us to connect back to it and we intend on merging mp changes in again at some point
@slender iron I noticed that my featherS2 is not using the "best Wi-Fi AP in reach" but chooses the one that it finds first. (channel 1 vs. channel 6)
The last time I reviewed this in the default configurations of ESP-IDF, it should choose the best AP in reach (RSSI-wise). Unless you'd tell me this was intentional?
@lapis hemlock shouldn't the code should fail, because 251 is not representable as a signed 8-bit int?
@onyx hinge No, it is simply re-casting the byte. That is also the numpy behaviour.
It is similar in python int8(250)
returns -6.
We can conditionally remove the offending lines from the test, because ulab.__version__ already tells us, whether we are running in circuitpython, but I think it should be fixed at some point. I can open an issue, if you want.
@lapis hemlock looks like we made a change in circuitpython that introduces this behavior (different from micropython) -- https://github.com/adafruit/circuitpython/pull/1879
.. to align with python3 array.array: ```Python 3.7.3 (default, Jul 25 2020, 13:03:44)
import array; array.array('b', (251,))
OverflowError: signed char is greater than maximum
Oh. So what do we do now?
because you can only have one "expected" text, I'm not sure how you can use an is-circuitpython block in a testcase
I have overlooked this. So we are doomed, that's what you are trying to say, aren't you?
Well, we could have two sets of test scripts in two different folders.
That should fix it, right?
Maybe in ulab, if CIRCUITPY, you need to use your own copied and pasted implementation without overflow checks, instead of calling mp_binary_set_val_array
We could have a hacked copy of the mp_binary_set_val_array function, if #CIRCUITPY is set, I am OK with that.
Desperate times call for desperate measures.
@lapis hemlock no way. it's important for us to connect back to it and we intend on merging mp changes in again at some point
@slender iron You could still have a non-editable, non-forkable mirror of your repository, so that it could be searched.
The last time I reviewed this in the default configurations of ESP-IDF, it should choose the best AP in reach (RSSI-wise). Unless you'd tell me this was intentional?
@hearty tapir This is the default behavior afaik. You can do a scan and then tell connect what channel to start with from CP.
@slender iron Ok, I got it. The API defaults to "WIFI_FAST_SCAN" which means : "Do fast scan, scan will end after find SSID match AP". The other option would be "WIFI_ALL_CHANNEL_SCAN" which again would default to the strongest AP, but this time it knows it.
ah
The typical use of connect, in all examples I've seen is connect(ssid, password)
The remaining/open question is just how many have multiple APs ๐
we could do fast only if channel is provided
(or if the bssid is provided)
sure. I couldn't remember if we allow that
raises hand has multiple APs with same SSID at home
This is possible. I just try to suggest that if "channel" or "bssid" are not provided, the function should do a full scan instead of fast scan. I can look at that if you want ๐
but "me against C" is still a little bit of a struggle ๐
Maybe in ulab, if CIRCUITPY, you need to use your own copied and pasted implementation without overflow checks, instead of calling mp_binary_set_val_array
@onyx hinge This won't be enough: thenumpy-compatible andcircuitpython-compatible versions will have two different call signatures for functions. C.f.np.sin(...)vs.vector.sin(...).
I would just have two separate folders for the two cases.
@hearty tapir even if channel is provided, may want to do a full scan since APs often (usually?) auto-select their channel and there's no way to predict any channel:RSSI relationship
it's true, if you want to switch the micropython version that you test to use numpy-compatible conventions and you don't want to use import ulab.vector as vector except NameError import numpy as vector or something like that
It is enough to change the lines MICROPY_MICROPYTHON=micropython/ports/unix/micropython ./run-tests -d tests; in the build script, and point to the test-numpy, and test-cpy folders, right?
yes most likely
thank you !
Thanks - I'll use this in the alarm PR. I have to change stuff there anyway.
tested on hardware, not stylistic review
Whenever you connect to your Wi-Fi network / SSID just with the following code the first AP that matches the SSID will be chosen, even if there is another AP with better signal strength (RSSI).
wifi.radio.connect(mysecrets["ssid"], mysecrets["password"])
This commit will enhance the function to do a full scan (across all channels) whenever channel/BSSID are omitted.
@crimson ferry I didn't see your comment. Pull-request 3727 will do full scan if channel/BSSID are not given
If you want to give this a try (given you have a featherS2), this is the binary: https://benny.servebeer.com/nextcloud/index.php/s/fKAKWAQaRFK8WJK
is this where to go for the ESP32S2 toolchain?
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/tools/idf-tools.html#xtensa-esp32s2-elf
also seeing python scripts in github workflow?
@hearty tapir This will be really nice to connect to the best RSSI by default. I did a little more reading and WIFI_FAST_SCAN can't sort by RSSI anyway. I'll load it up on a few devices when some of the other changes get merged in too. Thanks!
@tidal kiln I went through the same. I just ended up going for ./install.sh in the ESP-IDF folder that you find after the fork / git clone. This will give you all you need and you can get it back by ". ./export.sh" as well for the next shell
thanks. "get it back"? it doesn't install globally via the script?
It does, but when you shut down your computer / restart whatever - you have a new shell. You then do ". ./export.sh" in that ESP-IDF folder
there is probably a way to automate this, but I simply do it manually when needed.
Indeed it does. Thanks!
Adafruit CircuitPython 6.1.0-beta.0-25-g2f1460904 on 2020-11-19; MagTag with ESP32S2
>>> import fetch_test
Connecting to AP ----
Retrieving data...Reply is OK!
Bitcoin = 17899.7
>>>
soft reboot
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Hello World!
Adafruit CircuitPython 6.1.0-beta.0-25-g2f1460904 on 2020-11-19; MagTag with ESP32S2
>>> import fetch_test
Connecting to AP ----
Retrieving d...
Awesome! One small thing but good otherwise!
Please set the FAST method in an else. Otherwise you won't be able to switch between the two.
@lone axle @tulip sleet https://github.com/bcr/blinka-cli/blob/master/commands/bossa.md
Automated website update for release 6.1.0-beta.1 by Blinka.
New boards:
- adafruit_magtag_2.9_grayscale
- targett_module_clip_wroom
- targett_module_clip_wrover
- ADM_B_NRF52840_1
New languages:
- sv
- en_x_pirate
- ja
- en_US
- pl
- nl
- cs
- it_IT
- fil
- fr
- pt_BR
- es
- de_DE
- hi
- ko
- ID
- zh_Latn_pinyin
- el
well that language list isn't right ๐
Glad you finally released en_US
at least the script ran this time ๐
@lament sentinel nice! maybe a --dryrun or similar param would be helpful too. So it will do everything up till the final flash and then just print a message and stop