#circuitpython-dev
1 messages · Page 330 of 1
is there a bit which says which KIND of packet the filter matches?
you do specify extended vs std when creating the filter
oh that helps then!
Sorry to just jump in, but I have an NRF52840 board that I seem to have stuck in read-only and can't get unstuck. I have tried flashing several firmwares to see if that was the issue, but no change. Suggestions?
the above is just saying that for std ids, the registers that would filter the bottom 18 bits of an extended ID are matched against the first two data bytes
@pastel panther OK but if we don't let the user specify these bits in the Match constructor then .. they simply can't take advantage of the functionality
@bronze shadow I've never seen that issue
@bronze shadow you mean the CIRCUITPY filesystem exists but is read-only to the PC? Or something else?
Yeah, I can mount the drive, see my files, but I can't delete any of them.
I can write in the bootloader, therefor change the firmware, but once in circuitpython, I can delete nothing.
supervisor.erase_filesystem is the sledgehammer for such conditions. If you're on a Linux system as the host, I have experienced that nothing automatically runs and corrects filesystem errors; in some such cases Linux decides to make the device RO without explaning anywhere but in the kernel message log
@onyx hinge right; I think that means that I'll always have to use a mask for 11-bit ids to only match against the 11-bit id
ah, my bad. I thought you meant flashing over something like swd
I am on a linux filesystem. I'll see if I can sledge it. Much appreciated.
@mdroberts1243 I think those are the boards with the _stage module enabled. It calls set region to update itself here: https://github.com/adafruit/circuitpython/blob/main/shared-module/_stage/__init__.c#L46
I think you'll want to pull the parameter out of the display object like the other params.
@onyx hinge that said I don't think that behavior would or should require api changes
it's just that the MCP is limited
Can you tell me more about what you see in rgbmatrix?
In the cases I'm interested in the new allocations would likely match previously-freed ones, but of course not necessarily in the same order.
@slender iron I'm working on bringing things over to the new IDF submodule, and one of the things I'm noticing is that a LOT of includes are not being found? It seems like in some cases, the organization of the folders has completely changed. Is that something you did, or Espressif?
That was it. Much appreciated. I haven't seen anything like this before. I'm on the nice_nano which only has access to alpha/beta 6.0 firmwares if it's relevant at all. I try to stay on stable, but I don't have anything stable for this.
If folks are unhappy perhaps I can write a software filter
@bronze shadow woot! hope that gets you on the way again
@slender iron thanks for your patience, I'll get this PR updated just as soon as my local pre-push checks are in order.
@ionic elk do you have an example?
I'll make sure that send takes an mp_obj_t
using mp_obj will future proof those methods for other message types too
What do I need to write here to default the argument to None !? { MP_QSTR_mask, MP_ARG_OBJ, {.u_obj = mp_const_none_obj } },
@slender iron did you see what I mentioned earlier about a non-scrolling terminal? Did it make any sense?
esp-idf/components/soc/include/hal/i2c_types.h is now in components/hal/include/hal
and tons of other stuff like that
it was sort of a follow-on to what Limor said about potentially having a useful epaper console if partial updates are feasible
@ionic elk ah ya, looks like espressif: https://github.com/espressif/esp-idf/commit/5425ef4ee442acdc7f6398e22c2b95eb3c82dac2#diff-8a0049a32578e4c2c823dfa68b1b3c2c
@ionic elk want to update to the commit my branch was based on to start?
looks like it was: c77c4ccf6c43ab09fd89e7c907bf5cf2a3499e3b
Not sure what that would gain - if they swapped everything out manually, we just gotta do that too
Just means going over the various includes and either adding them to the makefile includes list or changing the full path
it'll reduce the number of changes
I've been doing "esp-idf/component" includes that may not work with -isystem too
It looks like rgbmatrix_rgbmatrix_make_new can be called from Python with argument width = 0, and then that goes through common_hal_rgbmatrix_rgbmatrix_construct (bufsize) → common_hal_rgbmatrix_rgbmatrix_reconstruct → common_hal_rgbmatrix_allocator_impl → allocate_memory. Although, thinking about it now, when calling from Python the Python heap will be available, so common_hal_rgbmatrix_allocator_impl would go there, not to the supervisor heap. So maybe it’s impossible after ...
could add -isystem esp-idf and then have the includes be "component/..."
I've been doing "esp-idf/component" includes that may not work with -isystem too
Yeah, for the "-isystem" to affect how warnings are produced for the header, it has to be from that -isystem path, not just happen to refer to the same file
Update to the commit your branch was based on... maybe I'm misunderstanding. I need the ADC Conf and other recent updates, what would be the objective of just updating to an old version that doesn't have them?
so e.g., #include </usr/include/stdlib.h> and #include <stdlib.h> are different
Right, exactly. I'm getting a lot of that one undef error too, which means I gotta fix it for everything
it makes it a two step process. 1) switch back to the espressif and then 2) update to the latest version
But it's not that big a deal I just was wondering why everything was switched up
kk
width=0 or height=0 should be errors, feel free to make it so!
just a big list of changes I'd have to get to next anyway, no need to break it up.
okie
@onyx hinge
Okay, but not today. Meanwhile, here’s the zero-marker version. The nonzero-marker one is still at cwalther:alloc-nonzero.
When it turns out that some of these options are never used, always used with the same value, or always used together, we can then remove or combine them. My current expectation is that
reload_on_successwill stay,sticky_on_reload(the controversial one from the last few posts) will stay if we can’t agree on a default value for it, and the rest can go.
This is fine for a prototype here but I wouldn't want to merge it in the "maximally configurable" state because removing APIs is muc...
Last question, @slender iron @onyx hinge I notice a lot of includes for a file like esp-idf/components/hal/include/hal/i2c_types.hare structured as esp-idf/components/hal/include in the makefile and hal/i2c_types.h as the include - as in, the directory below the file is included in the #include statement. Is this good practice to retain? Is it using these include locations to also find the actual source .c files, which tend to be in the include/ part of the path? I can't seem to find direct references to the idf source anywhere else so I was wondering if black magicks are involved
@ionic elk when we include the idf header in circuitpython I prefer the highest level components/... path so that all idf includes are grouped. The more detailed -isystem directories will be needed still for includes included by idf headers.
@pastel panther which device is that?
hmm, that doesn't seem to be super consistent at the moment. So you mean you want as many files as possible to be using their full path, starting from the esp-idf/, with the exception of those that cause errors due to a lack of isystem?
@onyx hinge the MCP2518FD swoon
ah
I actually prefer the opposite. Doing the docs first lets me brainstorm the API with examples that don't work and function docs that force me to explain how things should work.
I think adding docs now will help clarify what exactly we're doing for the game case.
Seems fine, the double-grep issue is minor so please merge if you don't care to do anything about it right now.
Thanks, looks good to me!
@ionic elk I think from circuitpython you can always do paths that start with components and have -isystem esp-idf
then you also need -isystems for everything the idf needs (which should already be -I now)
I think that may be broadly true but I'm finding some exceptions. /esp-idf/components/esp_wifi/include/esp_wifi_types.h was included as a full path, which causes it to throw an undef
I'm with @tannewt on the docs first or even tests first but that's a bit harder of a pill for some to swallow. Having an explanation of how the code should work before you write it makes you consider how you want it to work in more detail than you might if you jumped in. Additionally it is helpful when collaborating because it gives you a concrete example to discuss and make changes before you've done the work
right, I expected you to remove the esp-idf from the start of those imports
otherwise they are found through the ports/<port> include directory
Oh, just components/esp_wifi/include/esp_wifi_types.h you mean. We don't have an -isystem esp-idf/, should I add one? Or is that added somewhere else?
Added UnexpectedMaker FeatherS2 pre-release
Here is a better link: https://github.com/adafruit/circuitpython/pull/3463/checks?check_run_id=1175885989#step:22:7
You need to add the new board name here: https://github.com/adafruit/circuitpython/blob/main/.github/workflows/build.yml#L423
Ok, I hope I did it correctly!
@slender iron What's the state with UF2 for esp32s2? Will APA be added? I know shipping with UF2 is the ideal, but if the APA doesn't work, I'm not sure I should use the UF2 yet.
@slender iron noticing that esp-idf/components/log/include/esp_log.h is included directly in shared-bindings/socketpool. Might be worth checking out when you have a sec. Not sure how to refactor it.
nevermind, it's trivial to just move back into common-hal
@atomic summit We won't be adding APA support soon. I want our energy to go into unifying the bootloader into one repo/source. That way new ports of the bootloader will have all the "standard" features.
@ionic elk go ahead and remove it.
Ok, cool. So it's ok for me to ship without the uf2 then? I'm planning on shipping beta1 once it's ready.
sure, up to you. we'll have docs on how to add it later
Cool, thanks 🙂
Hello all. Hope all is well. I'm new to the group, yet over the past month I purchased a bunch of the sensors for use with an itsy m4 express. I have a question, from one sensor example to another, I see mixed use of <i2c = board.I2C()> and <i2c = busio.I2C(board.SCL, board.SDA)>. Seems like some things in the busio library do not work all of the time. What is different between the board.mpy and busio.mpy (which I never found, I assume is embedded maybe in board.mpy)? Sorry for what might be a dumb question.
hey @tropic brook #help-with-circuitpython might be a better place to ask 🙂
if the issue persists, you might check the library repos for open issues
I thought that was my current local, sorry.
no problem 🙂
When connected to an access point, this adds the following (super helpful, for me at least) information to wifi.radio:
- RSSI
- Gateway
- Subnet
- Primary DNS
When not connected, these all just return None. I made sure RSSI is always the current one while walking around closer and farther from my AP in case someone wants to build a WiFi mapping toy robot, but I use it primarily for monitoring the current connection.
Forgot to add BSSID (and maybe regular SSID) so those are up next, and then this would be ready for review.
In #3482, @cwalther noticed that it was possible for RGBMatrix to perform zero-byte allocations. This reflected inadequate argument validation, not an intent for this configuration to work.
This will be very useful! Encryption type is another element commonly returned by Arduino and CircuitPython ESP32SPI.
@tannewt I made the change to _stage and rebuilt the Grand Central M4 Express just to make sure nothing was broken. I had to resolve one conflict and merged it in. But now the checks are queued and seem to be stuck. It is the checks that I want to see!
-mark.
Sadly my program is too big and ugly to post as-is. If I find a reduced test case I'll post it.
I think the test at https://github.com/adafruit/circuitpython/blob/main/shared-module/displayio/__init__.c#L43-L44 can be removed with or without this, because of background_callback_run_all()s checks for !in_background_callback -- https://github.com/adafruit/circuitpython/blob/main/supervisor/shared/background_callback.c#L71-L75
@tannewt The checks failed. Failing in a different way then before and the various board builds didn't run at all. The only thing different was I was asked to resolve a conflict, which I did, accepting a bunch of changes to seeduino wio terminal apparently in order to add my quirk to the end of the display construct. In ports/atmel-samd/boards/seeeduino_wio_terminal/board.c
Anyway, things seem to have regressed and I'm at a loss to interpret the failure.
This PR updates the make translate script to include the following changes:
ports/esp32s2directory is now included inTRANSLATE_SOURCES.ports/esp32s2/esp-idfandports/*/build-*directories are excluded from translation.circuitpython.potnow includes strings being referenced from header files.
@idle wharf @teal bear re Visual Studio Code & CP: I found https://github.com/joedevivo/vscode-circuitpython on Saturday, and only spent a few minutes with it, but it looks very promising. On Mac I hit this issue https://github.com/joedevivo/vscode-circuitpython/issues/24, and also found I had to switch to any other linter than PyLint to get completions to work. I'm looking forward to using it more.
@ionic elk - thanks for working on merging the latest esp_idf into CP. Note that it may break things; I tried compiling uf2-esp32s with the latest esp_idf, it compiles, and I didn't notice any concerning warnings. But it just locks up once flashed. Just doing a clean and re-building with @slender iron's version included in the esp32s2 port of CP just works. I started to try and trace down where the lockup is, and it seems to be in tinyusb. Here's where I got to: https://github.com/adafruit/uf2-esp32s/issues/12
I have applied your change but glitch still happens.
It could happen somewhere between turning off bitbang mode and turning on SPI mode
bitbang_jtag_off() # NOTE TCK glitch
spi_jtag_on()
https://github.com/emard/esp32ecp5/blob/master/circuitpython/jtag.py#L39
@slender iron uf2 on saola-wroom is magic. I can now hand out a few modules to beginners/robot-kit-helpers and just send them a UF2 file as needed. And thanks for adding time stamps to the YouTube deepdive. Super helpful to be able to jump to the UF2 discussion and get a better understanding of where things are going when there's not enough time to enjoy the whole session. I have another dev interested so hopefully this week, but probably next week, we'll start learning how to get the rotary encoder driver working.
at ESP32-S2 I unmounted USB-storage drive from PC
and tried to rename a file, not permitted because of read-only filesystem?
os.rename("file1.bin","file2.bin")
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 30] Read-only filesystem
The file system is by default mounted read-only to avoid corruption when it's modified through USB. You have to re-mount it as read-write to perform any file operations. See https://learn.adafruit.com/circuitpython-essentials/circuitpython-storage
Small suggestion, I think a link to esp32s2 page in esp-idf would be more relevant.
More information about the `esp-idf` can be found [here](https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/).
Can someone please help me. I purchased several microcontrollers from Amazon the other day, and I can't get any of them to work correctly. None of them show up as a drive in windows10. I've tried installing different drivers, tapping reset 2 times for bootloader mode, and multiple usb cables all without success... They all show up as "usb serial" in device manager, but no new drives show up for me to upload or modify code..
These are the models I purchased..
- Xiuxin 2pcs/lot ESP8266 NodeMcu Lua WiFi Internet Development Board CP2102 Wireless Module Works with Arduino IDE/Micropython
-Seeeduino XIAO The Smallest Arduino Microcontroller Based on SAMD21,with Rich Interfaces, 100% Arduino IDE Compatible, desiged for Projects Need Arduino Micro,3 pcs
-SparkFun Thing Plus - SAMD51 Development Board Powerful microcontroller with Qwiic connect system and integrated regulated LiPo charger No Soldering required
I don't think those come with CircuitPython
esp8266 is not supported by circuitpython anymore
the two samd boards probably come with an arduino bootloader and not UF2 like the CircuitPython boards do
you would need to refer to their documentation to confirm that
hmm, the description at https://circuitpython.org/board/sparkfun_samd51_thing_plus/ says it has UF2
so double pressing reset should get you a XXXBOOT drive
right, but upon double pressing the reset button, i don't get a drive. On any of the boards. That's why I'm looking for help. I'm stuck and can't seem to figure out where to go next.
@glossy wasp Some of those boards you mentioned would not be expected to show up a drive I think, especially esp8266 will not I think. But the Spark Fun SAMD51 Thing Plus should I believe, according to it's product page it comes wit hthe UF2 bootloader.
what is your host PC? Do you have any other USB thumb drives or storage devices that you can try with the same PC and cable? if so do they work properly?
Also when you double press reset on the Spark Fun SAMD51 Thing Plus do you see anything happening on the D13 LED?
Any Travis experts available? I make a PR to the ESP32SPI lib and I get a failure however it is not verbose. https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/pull/107/checks?check_run_id=1182647884
@balmy stirrup I'm not sure if we've changed the actions recently, I could definitely be wrong. It looks to me like it failed during the Black formatting because it found that some of the files would get reformatted. Typically (in my experience) you've got to run black on that code locally before pushing it in order to get past that actions check.
It is kind of odd though because the text output showing on that page makes it seem like it did run Black and did reformat those files. That is odd to me because I am more used to it checking to see if black would reformat anything, rather than actually doing the formatting.
@lone axle Thanks. I am not sure if it is some glitch that the team can manually pass through or if I need to amend something.
Are you familiar with running Black code formatting locally?
Unfortunately not.
If it were me that would be the next thing I try. run black on these two files:
adafruit_esp32spi/adafruit_esp32spi_wsgiserver.py
adafruit_esp32spi/adafruit_esp32spi.py
and then make a new commit and push.
This page covers the process of getting set up and running the black formatter: https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/black.
@lone axle you are awesome! Got it working and it is doing another progress check now. Thanks!
It seems like this commit is where it changed: https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/commit/2077d83a49a0e614fae232f8792dcf6c980909ea. The "Check Formatting" hook is the one I am more familiar seeing. It looks like the Black formatting was moved into the pre-commit hook and now has some extra configuration files.
Nice! I see it did make it past the black formatting this time. So that was likely the issue even though it looked a bit different than I am used to. Next up it's got some PyLint things that it wants resolved.
@lone axle unfortunately it failed again but now I have a more helpful message.
Thanks again!
Yep, you are welcome. This other page in that same guide shows how to set up and run PyLint locally if you want to do that: https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/run-pylint. I find its easier when I can check those things locally without pushing to github.
@balmy stirrup I ran into the same issue yesterday, I feel your pain! Understanding black/pylint is a bit of an art in itself.
LIke foamyguy just said I (try) to remember to run them locally now to save time (try!)
Any forecast on when the CircuitPython drivers for the 128x64 OLED Featherwing display will be released for the M0 and M4 Feathers?
first time building CP in long time on linux.... is there a better tut for the ARM gcc toolchain?
CPy gurus, I need your help. I'm trying to develop a native module and I can't get my head around the shared-module vs shared-binding convention. ok, module has the implementation, but what does the binding have? memory allocation stuff to not mix with the garbage collector? also I see calls to common hal, why? also multiterminal for example calls a common hal function that does not exist anywhere in the tree. are they auto generated? Is just this module wrong? I'm trying to create just a helloworld module (return a const char* from a function call) - are there any such examples?
EDIT: I think that this kind of help is better suited for here and not #help-with-circuitpython, right?
This is the tutorial I follow when I make builds of Circuit Python: https://learn.adafruit.com/building-circuitpython.
i downloaded it and extracted it, not sure what to do with it now
yeah it seems to assume i know what to do
"put the unpacked toolchain into an appropriate directory.@
like desktop folder or downloads?
@slate scroll this is probably a good channel for your question since it deals with the core project code.
help-with-circuitpython is more suited for users rather than developers.
@upbeat plover you need arm-none-eabi-* packages - most distros have these available. then just cd ports/<MCU architecture> and then make BOARD=<myboard>
@upbeat plover I don't think the directory you put it in is super important. If I recall correctly I think I put it either directly in my home directory, or perhaps in ~/bin/ as long as you target the file that you downloaded with this command:
tar xvf <name of the .bz2 file you downloaded>
and add it to the path correctly with the next command:
export PATH=/home/$USER/bin/gcc-arm-none-eabi-9-2019-q4-major/bin:$PATH
I think you should be good to go.
this command which arm-none-eabi-gcc will let you check to see if you are set up properly also. If you run this and get output that points to a file then it means you are set up correctly I believe.
ty @lone axle
working i put it in my user folder
well i built CPX to test, i had to ```
export PATH=/home/$USER/bin/gcc-arm-none-eabi-9-2019-q4-major/bin:$PATH
No I don't believe so. I think you just have to do it once to get it added to the path and from then on it's saved in the path so you don't have to add it any more.
um.. that setting lives until you exit that shell
that's the stuff you need to do on a debian like box
Ah yeah, you are right. My linux instincts are not so great yet. I don't ever have to run that command any more. But it turns out I had added it to my .bashrc file so it gets set up that way every time.
bingo.
@upbeat plover see above ^^ that export PATH command would actually be temporary (until you logout of the shell). To make it more permanent you can paste it into your .bashrc file.

I believe the above properties are also read-only; can you clarify that in the docs?
@slate scroll I removed the mute, but you shouldn't mention so many people
woops, didn't know that
That's OK
CPy gurus, I need your help. I'm trying to develop a native module and I can't get my head around the shared-module vs shared-binding convention. ok, module has the implementation, but what does the binding have? memory allocation stuff to not mix with the garbage collector? also I see calls to common hal, why? also multiterminal for example calls a common hal function that does not exist anywhere in the tree. are they auto generated? Is just this module wrong?
was more or less what you'd written
good, good
shared-bindings should just have the most basic implementation of the Python APIs themselves. They shouldn't do any work besides basic argument validation, and then turn around and call functions in shared-module (for device-non-specific code) or common-hal (for device/port specific code)
so with a primary exception being constructors, the shared-bindings fuctions are almost trivial, like this getter: ```STATIC mp_obj_t canio_message_extended_get(const mp_obj_t self_in) {
canio_message_obj_t *self = self_in;
return mp_obj_new_bool(common_hal_canio_message_get_extended(self));
}
even return mp_obj_new_bool(self->extended); is too "specific" for shared-bindings
when it comes to creating objects, the convention is to allocate the memory and set the object's type within shared-bindings then do everything else in a "construct" function: ``` canio_message_obj_t *self = m_new_obj(canio_message_obj_t);
self->base.type = &canio_message_type;
common_hal_canio_message_construct(self, args[ARG_id].u_int, data.buf, data.len, args[ARG_extended].u_bool);
the definition of the structure (canio_message_obj_t in this case) should be in the shared-module header, and the definition of the public functions such as common_hal_canio_message_get_extended should be in the shared-bindings header (this was something I didn't pick up on right away)
with that background/exposition I'll try to answer more specific questions if I'm watching .. and tannewt may have corrections to make, he chose this model of how to split stuff up so he's the ultimate authority
ooooooh, now it makes sense. if by watching you meant watch the fork, here: https://github.com/dzervas/circuitpython (any input more than welcome). I'll try to implement little by little and ask away
thank you!
I mean I try to keep an eye on discord 🙂
https://docs.micropython.org/en/latest/develop/natmod.html 😱 are native mpy modules supported on circuitpython? can I just write an external module in C and load it as .mpy???
oh no, it's not...
@onyx hinge are the bus state counts a standard feature in CAN devices? The MCP doesn't support it directly so I'd have to implement it myself
@pastel panther yeah those are just registers I can read on both of these MCUs
Have you seen anything about how they might be used or how important they are?
http://www.can-wiki.info/doku.php?id=can_faq:can_faq_erors the error counters seem to be part of the CAN spec
@onyx hinge sorry if I wasn't clear, I am talking about bus state counts
you did say bus state
@slender iron I tried using tud_mount_cb() callback for checking usb connection. It works only when there is a short delay before the usb connection check, since usb mounting process takes time.
@pastel panther What's your suggestion, just drop 'em ? Permit them to always read as 0 or -1 if not implemented?
I suspect you can't really implement them, because you can't count the times the controller entered a state. you can count times you caught it transitioning to a state, but that's all
Right
I think I'm suggesting that I don't implement them because a> they'd be correct-ish at best and b> their utility is ???
I suppose you could use it to see if the state was thrashing? 🤷
I assume it is in (some) CAN HW because somebody found it useful. I can join you in shrugging.
yea, someone put it there, presumably not because they just felt like it
@slender iron doesn't like having properties that exist for one port but not another. that tends to point towards just leaving them out, once we know not all HW supports it.
but, for instance, we have the microcontroller temperature property there, it might just always return NaN on a particular HW
-> returning -1 or None is an option
Let me see what the 2518 has
doesn't look like it corresponds either, though it has some other interesting diagnostic bits
right
EFMSGCNT<15:0>: Error Free Message Counter bits
yar
I'm inclined to throw an exception if it's called and document the behavior; 0 would be misleading and -1 or None or something would still have to be handled in whatever code would consume it so being explicit about "THIS DOESN'T WORK" makes the most sense to me
yar
lol
they've seen my desk
We can sure add "Raises AttributeError if the implementation does not provide this information"
bueno
those 3 properties right?
yes
//| """The number of times the controller enterted the Error Passive
//| state (read-only). This number wraps around to 0 after an
//| implementation-defined number of errors.. Not all
//| implementations support this property. If the property is
//| unsupported, AttributeError will be raised."""
I'll correct the double-dot but otherwise is that text good for you?
This is the case on the SPI implementations MCP2515 and MCP2518.
commit message will state this so we know why
is that accurate from what you know?
yes
OK pushed, thanks
seems like you can just leave the property out entirely, that'll get you a nice AttributeError 🙂
my code needs more cushions, too bad if they have to be whoopee
I already have 'em and I can document their behavior if I leave 'em in
Any forecast on when the CircuitPython drivers for the 128x64 OLED Featherwing display will be released for the M0 and M4 Feathers?
@hazy plover Follow along with this pull request that adds support: https://github.com/adafruit/circuitpython/pull/3450
@onyx hinge @pastel panther I'd recommend dropping those properties
start with a minimal API and add things as you need them
rather than adding them without knowing their utility
we (I) included them so that we would have feature parity with micropython.
I can drop 'em if that's better
@slender iron I'm stuck on PR 3450 due to checks failing for unknown reasons. Happened after I was told to resolve a conflict (not really a conflict, just new code butted up against a modified call)... I merged with the 'main' and now checks don't pass at all. Can't interpret the results.
@onyx hinge we don't need to have feature parity with micropython
@grim dagger yup, I saw. I got a late start today because I went grocery shopping
the precommit failure is due to trailing whitespace
looks like the test run is going now
it's pretty easy to setup pre-commit to automatically fix things before you commit them: https://pre-commit.com/
@slender iron Thanks. I couldn't find the pre-commit piece.... didn't run locally for me.
@onyx hinge What is the behavior if the Listener is deinitialized?
This makes sense to me, thank you! The changes to circuitpython.pot also appear as expected.
@pastel panther All of read, in_waiting, iter and next will raise an exception if the object has been deinitialized. not sure why I only called it out in the one case. mp_raise_ValueError(translate("Object has been deinitialized and can no longer be used. Create a new object."));

//| CAN and Listener classes change hardware state and should be deinitialized when they
//| are no longer needed if the program continues after use. To do so, either
//| call :py:meth:!deinit or use a context manager. See
//| :ref:lifetime-and-contextmanagers for more info.
I'll remove the specific note on __iter__ it really applies to all methods and is just the standard thing that core objects do when they've had deinit called.
"ever time" should say "every time".
Instead of "the patched version" consider saying "the specific version". We may go back to not having local modifications to esp-idf if @hierophect succeeds but it will likely fall behind official esp-idf.
I'm almost done moving us back to the official IDF - the reason for needing the patched IDF had to do with undef preprocessor errors that are prevalent in the IDF itself and were conflicting with our general policy of using -Werror. By marking them as system files, we can get around this problem, it's just taking a little while as a lot of includes have to be renamed.
Making a note that reinstalling the IDF after version changes is probably a good idea though.
@slender iron @grim dagger I have been watching that pull request. When I attempt to run it I get the following error:
File "/lib/mdroberts1243_displayio_sh1107.py", line 55, in init
TypeError: extra keyword arguments given
And nothing is obviously wrong to me.
looking for a quick "No" because of a gh comment: "could change the CircuitPython and micro:bit modes to transfer files through the serial interface" (instead of the mounted fs)
@hazy plover you'll need to install a new version of circuitpython to match the new library
@hearty forge thank you for the heads up on that. I am indeed now running into an issue connecting now that I'm past the include errors and the project is compiling.
@slender iron
boot_out.txt says this:
Adafruit CircuitPython 6.0.0-beta.0 on 2020-09-21; Adafruit Feather M4 Express with samd51j19
Is there a newer version?
yup, you'll need one from the PR itself
click artifacts in the top right and download for your board
it'll be a zip with circuitpython builds in it
@slender iron
That did it.
I'd like to suggest that the pull request page note that for those of us who don't know to do that.
Thank you.
go ahead and add a comment. not many people test PR builds
Closes #3419
It looks like wifi.radio.connect() is missing a call to esp_wifi_set_mode() which is probably why scanning, and then connecting works, but connecting without a scan makes the board wait indefinitely.
Rather than copy the same logic checks to change the mode only if it's different, I just added a call to start_station() and it seems to work as expected. I suppose another fix could be to call esp_wifi_set_mode() in connect().
Ok, @FoamyGuy please remove that outer display check. If you don't have time, let us know and we can finish it. Thanks!
I added reuse of holes that fit exactly, however without checking in what circumstances this is actually used.
My first attempt recovered the ptr of a reused allocation by adding up neighbor lengths, which works but is a bit involved. So I changed things to keep the pointers around all the time. To mark an allocation as freed by the client, I no longer set the ptr to NULL, but store that marker in the length too. We still need the length, but because a valid length is always divisibl...
@hazy plover Thanks for testing! @slender iron The PR is going through checks, albeit very slowly for some reason! Running pre-commit locally cleaned the first few steps up nicely.
@onyx hinge Ok, I think I've got the MCP lib releasable; can you give it a test with the SAM-E when you have a few?
@pastel panther ping me again tomorrow if I haven't gotten to it. is the PR in the obvious place, or is it the tip of main/master?
the tip of master
This looks good to me! Thank you for iterating on this.
It has been nice working with you on this, thanks so much
@grim dagger cool! ya, I think there are a lot of builds happening now. will take a look shortly. it's queued up
same!
I'm thinking I may do my email / PR review routine on my stream friday
hopefully this won't be our last CAN-venture
@slender iron I think that is a great idea, a lot of folks don't understand or see how that works. of course, even I might discover that I'm doing it differently than you
This needs to be in the same branch as #3463. Ping me on discord if you need help with that.
Agreed. The “maximally configurable” state was never meant to be merged as is, it’s just a prototype for people to play with to figure out what we need. I was making progress on the “retrieve last exception” front when the supervisor heap bug distracted me, so as far as I’m concerned, we’re closing in on that.
kk, 🙂 I'll have jumped the shark when people watch me do email
(I mean I'd be surprised if we do it the same .. it's just, I would call myself a pro but know I should still learn better habits and tricks)
All fair points, but I’m not here to argue about that. For the purpose of this discussion, the point is moot because the docs are there now. (I can look into adding tests.)
Looks good! Just needs a make translate for the new messages. Thanks!
@slender iron that's a good idea for your stream. I've been meaning to ask on here about how to go about reviewing PRs and what is expected. Probably something I can do more easily at the moment that isn't devoting hours at a time to one task
great! I'll certainly cover that during the stream
I feel like I may have done a review on stream already
Maybe, sounds vaguely familiar but I cannot recall. I saw the CP webpage stuff on what is open but is there any general guide to giving PRs?
Bummer. It could be that we need polarity in the SPI constructor so that it doesn't enable the pins without switching it: https://github.com/emard/esp32ecp5/blob/master/circuitpython/jtag.py#L62-L65
Another alternative would be adding a native JTAG primitive that can do it under the hood. That would give you more flexibility.
@blissful pollen not that I can think of
the design guide is probably a good place to start
for circuitpythonisms
Cool, I have a fair bit C experience (and now some python) so even if there is something that is being neglected or needs a second set of eyes happy to look at it. I'll start poking around more
ok awesome!
Thanks for adding these! Just a couple ideas/comments about the API. Code looks good, just want to make sure it's the API we want.
What do you think about re-using the Network object to represent the current network? I think it has all of the ap_ attributes you want here. Then you can just return None or a Network object.
Do these three properties need to be ipv4 specific? Could they just be gateway, subnet and dns and either return IPv4 or IPv6 addresses? Maybe we'd need to return more than one object then?
@grim dagger looks like your PR has an accidental tinyusb change in it
That was forced upon me!
I was asked to resolve a conflict and accept the merge... it didn't look like a conflict to me at the time.
I've made no other changes... is it easy to back out of?
did you do it locally?
I did it in the PR web page and the changes were reflected in my github I believe
@slender iron I think this is the culprit: https://github.com/adafruit/circuitpython/pull/3450/commits/b1e1237887945f6499b8884594b14e8bc4c5afbd
that seems like it should have done the right thing
you can pull the changes down locally
and go into lib/tinyusb and checkout what commit that main has
this happens when you do a git pull but don't update submodules
Is this needed still? rows_per_buffer is 1 so it should be equivalent to the starting value.
Note that the one build failure is a clone failure and can be ignored.
@wemos Are you planning on updating this with a valid USB PID?
@UnexpectedMaker You'll want to make the change on this PR's branch. I closed the other PR.
@microDev1, @jedgarpark, @tannewt, @hierophect - thanks for the feedback.
I think I've got the picture right now:
- there will (always?) be a local copy of esp-idf as a module
- as much as possible it will be an up-to-date reference to a point in the original esp-idf source history
- but there may times when it has CircuitPython specific patches (bugs, incompatible updates, etc)
- using the esp_idf version from CP is expected to work; using the official esp_idf should work- but if it do...
Yes, polarity would beter fit in the constructor.
If you could add JTAG accelerator module using SPI or
something else, that would really be excellent and speed
up FLASH over JTAG up significantly!
JTAG traffic is 99.9% same as 8-bit SPI but at command transitons,
it needs to shift few bits, typically 1-4 bits clocking data over TMS line.
This cannot be replaced by clocking full byte, 8-bits.
Added unexpectedmaker_feathers2_prerelease to build.yml
@UnexpectedMaker You'll want to make the change on this PR's branch. I closed the other PR.
Done - I think!
when you edit the file in github and go to save do you have two options?
@tannewt Ok, 3rd times a charm? It didn't like me doing it from my other Mac for some reason.
This PR has now been updated. Pleaser delete the other one I created a few mina ago _ I don't seem to be able to delete it myself.
I just re-did it properly (not in github) and updated my original PR.
👍
pls delete the other "wrong one" <- sorry
I don't see a new commit on the PR
No, I updated the previous commit, is that ok?
pushing again...
we're lenient about commit structure
we just want folks to contribute 🙂
there we go
yes but now there is a file conflict
oh, now there's conflicts? I pulled before I pushed
pulled from where?
my fork and fetched latest from remote
This looks good to me. It's a bit complex but it's an advanced API and I'm not actually sure what we'll want. I'm fine if you want to undraft it and then we can merge.
@ionic elk - let me know if I can help with trying to find the cause of tinyusb/uf2 not working with the latest esp-idf. @slender iron suggested in the github issue to look for changes to how esp-idf is initializing the pins used for USB. I don't know what I'm doing, but I can look for/filter changes 🙂 And if you've already figured it out, would appreciate a pointer to what the change is so I can go take a peak and learn a bit more 😉
Nope. Not required. Tested on Grand Central M4 Express (slower than STM32F405... need to get that I2C solid!). Another commit coming...
@slender iron I've completely destroyed my fork 😦 . Trying to fix it
there's stuff missing from my fork now... my prerelease folder is empty
yeah, was rebasing
I stopped the rebase
why?
cause I have no idea what I am doing... hahaha... gonna try again
wanted to start again from "known good state"
"what does git status show?" deserves a t-shirt!
I do everything on the command line
Your branch is up to date with 'origin/UM_S2_Boards'.
nothing to commit, working tree clean
Ok, gonna start again....
gonna do it from the command line...
you've got this!
CONFLICT (content): Merge conflict in ports/esp32s2/boards/unexpectedmaker_feathers2/mpconfigboard.h
so I edit this file in vscode and fix the conflict ?
yup, it should be red in git status too
you'll want to make the same change in your prerelease board too
if it exists in this commit
yup
hmm... no, all my changes from the last commit to master are gone...
all of the removal of the dotstar stuff etc
my fork is screwed.
did you delete them in a follow up commit?
I deleted them days ago..
you may be in the middle of the rebase still
and did my PR
the files are not there in adafruit/main
so they had to have "not been there" in my fork
but now they are back somehow
you had three commits to your branch
you deleted files in the third commit
the top of git status usually has useful instructions
rebase is redoing the three commits based on a newer version of main
if you are on the first commit still you can delete those files now
I think it's fixed...
no, I lost microDev's changes
let me put them back in
oh, no, he only changed my feathers2, not my pre-release
fixing that now
Just an observational comment: I recall in my internship this summer. I worked very hard maintaining the bitbucket repository. I fixed so many issues with feature branches, merge conflicts, accidental master branch commits. good times.
the discourse here brings back those moments hehe..
lol
i am slowly learning by breaking my own repo.
also I am glad that i never convinced a friend's company to move to Git 5 years ago. They would have done 'bad' things to me
I've had to re-clone the CP repo like 4 times. 😉
Kattni has a great guide on GitHub and how to setup your remotes.
i've done the same. i now have it dialed in 🙂 Were more boastful words ever spoken?
tbh i did learn the incantation about submodules, esp-idf and tinyusb. And nobody can convince me that submodules are 'perfect'
Looks good! Just needs a make translate for the new messages. Thanks!
As originally written, the TRANSLATE_SOURCES_EXC was incorrect. If more than one build directory existed, "make translate"
(and make check-translate) would error.
I corrected the problem, commented it, and added a number of additional exclude directives. This decreases the length of time it takes to "make translate", which is always nice.
I reviewed the PR and should have caught this, but did not.
cc @microdev
This looks good to me! Thank you for iterating on this.
Conflict fixed and also got a straggling (read-only) change request addressed
I'm curious about everyones experience with boot up time. Having never played much with CPY in the past, spending all of my time in MPY - I'm seeing a massive discrepancy in board boot up times between the 2.
I'm sure if has something to do with the USB stuff, but my TinyPICO's boot MPY and start cycling the APA in a smidge under 2 seconds, and my FeatherS2 takes over 5 seconds to do the same.
The first issue is, for "wake from deepsleep to do some processing and then sleep again", that's a lot of extra battery capacity lost
but it also, when I run off battery, I don't have any power LED on, or any visual indication the board is powered (on purpose of course) and the extra boot time makes it seem like the board isn't working...
If I plug my ItsyBitsyM0 in, it boots CPY in less than 2 seconds and the APA starts it's rainbow.
I've never noticed any of my boot ups be that slow. I have an ItsyBitsyM4 sitting here I'm working on and it is just over 1 second to start
there are some deliberate delays during startup. One example: ``` if (!skip_boot_output) {
// Wait 1.5 seconds before opening CIRCUITPY_BOOT_OUTPUT_FILE for write,
// in case power is momentary or will fail shortly due to, say a low, battery.
mp_hal_delay_ms(1500);
these need to be carefully (re)considered, because it does represent a trade-off
another is in wait_for_safe_mode_reset()
@onyx hinge Are they general delays or just in the ESP32S2 port?
I've noticed esp32s2 boots slower... PyPortal outputs from my code in ~2s or so, esp32s2 more like 4s or so. Worthwhile to note that esp32s2 is doing startup of the network stack in that interval as shown in the debug console.
One thing it does before any user code, and I think before CP init code is to start the chip as Soft AP. I don't know how much time that takes, but I wonder if it's necessary (I wish it wouldn't do that, but it may be buried deeper in the IDF than we can access).
It also does a RAM test, but so does my TinyPICO in MPY, which is why my TP takes 2 secs to boot.
Build is failing due to a missing step, or step that isn't triggering?
Failing step is Upload mpy-cross builds to S3, but the log shows no content for that step; ie the previous steps last output is the line before the step after the erring step...
2020-09-30T00:16:58.5222843Z Artifact mpy-cross.static-x64-windows has been successfully uploaded!
2020-09-30T00:16:58.5329121Z Post job cleanup.
I did a idf.py erase-flash in the esp32s2 directory and it generated a build folder.
Instead of build- *, I think build* would be more appropriate.
TRANSLATE_SOURCES_EXC = -path "ports/*/build*" \
That’s good to hear, my thinking was to reduce the complexity a bit and only keep what we need before merging. I’m not sure yet what that is either, but we’re not done yet figuring it out. It partially depends on how the “retain previous traceback“ feature comes along (expect a PR on that later, maybe tonight) and on resolving divergent opinions.
(By the way, I found the artifacts – top right of the build output. A text search would have found it… Will probably rebase so we get the latest ...
Did anybody wrote something in CircuitPython to receive (or transmit) the Covid-19 tracing advertisement? The application is now available in my country, and it use the Google/Apple protocol. I would be interested in monitoring the number of unique advertisement received and display something on the CLUE to tell me if a lot of people arround me are using the application (and if they are not, make the sale speach to suggest they do). [I can find a lot of other use if I can start to advertise, but let's not make it too easy to have "hacking" with this]. Here are the documentation I found: https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf?1 As soon as I have time, I will try nRF tools on another phone to sniff that, maybe dump what I see from the CLUE and work on something. But if there is code arround doing anything already, I am interested.
@slender iron I tried the following wake stub implementation in esp-idf and it does work but I can't get it to work in cpy.
#include <stdio.h>
#include "freertos/FreeRTOS.h"
#include "esp_sleep.h"
RTC_DATA_ATTR int wake_count;
void RTC_IRAM_ATTR esp_wake_deep_sleep(void) {
esp_default_wake_deep_sleep();
static RTC_RODATA_ATTR const char fmt_str[] = "Wake count %d\n";
esp_rom_printf(fmt_str, wake_count++);
}
void app_main(void) {
esp_sleep_enable_timer_wakeup(1000000);
esp_deep_sleep_start();
}
Hello , I updated your README.md file that will help to everyone while communicating .
The build failure should not prevent this being merged, it was just network flakiness.
I'll leave approving the wording to someone else.
This PR is not ready for merging yet, but it's been coming up in other conversations, so I'd like it to be available for others to look at.
Up to now, the ESP32S2 port has been using a modified version of the ESP32-IDF (IoT Development Framework, the core framework for developing on the ESP32-S2 with all HAL APIs, drivers, FreeRTOS components, etc) forked by @tannewt. This was because the IDF itself contains a lot of undef type preprocessor errors that conflict with our use of -Werror,...
i have no problem with my IDF local with https://github.com/espressif/esp-idf/commit/6c17e3a64c02eff3a4f726ce4b7248ce11810833
I am not fully aware of what and when cause the issues, but we can start to go through commits list. There is an issue with persistent mode as mentioned by @me-no-dev in this tinyusb pr https://github.com/hathach/tinyusb/pull/492 . I am not sure if the work on IDF got updated with this, or fixed else, maybe it is just pin config changing that happens as last time.
Without minimizing the amount of work this actually required, the changes to this point look quite sensible to the point of being simple and straightforward (to read).
I am surprised that the PR does not include a change to the esp-idf submodule itself, but that is presumably due to its draft state.
I am surprised that the PR does not include a change to the esp-idf submodule itself, but that is presumably due to its draft state.
You can't see the Submodule changes? Should be visible in .gitmodules and as a ~1000 file submodule update further down the file list. They're visible for me, is it possible you expected the module change to be at the top and missed that it was further down? I'm not sure why it did that this time, normally it puts submodule updates at the top of the changel...
Yeah my bad, it's there. It just, uh, looked different than I was looking for (because it didn't call out the list of files modified in the submodule)
I may just return to bed, I'm not doing so good at detail oriented stuff today.
I didn't see anything that looked like the former, and missed the latter even as I was going through and checking off each patch as viewed
like I said, not a good day for detail oriented work so far
Lol it's fine, I don't know why it didn't do the big update list either
I had to track it down too
maybe it was just too long to list
@onyx hinge do the STM and SAM-E both support something approximating these errors?
sam e5x:
I wonder what constitutes "successful reception"; using this register to check for a transmit error seems iffy if it can be cleared by a reception.
ok, they're probably in the spec then
I find it hard to believe that they would clear without any input from the user/program? I don't think the mcp behaves that way but I should check.
@onyx hinge is that reg shared between all of the tx buffers or one per buffer?
that is a register for the whole CAN peripheral
which is why it talks about a successful reception
I don't think we should try to figure out how to best interpret each error. My gut says we should subclass an appropriate exception as CANError which can have subclasses for each of the above errors, or whichever subset is common. My brain hasn't fully weighed in
I think you'd want to throw Python exceptions for the receive-type problems even less than you'd want to throw an ACK error for a transmitted packet. Which Listener's receive() should throw an exception if there was a FORM error on the bus?
scope my above comment to TX only
OK, so by my reading ACK is only relative to TX. So is BIT1? but BIT0 can pertain to this device trying to drive the bus with an ACK bit i.e., its participation is not because it originated the packet
hm, yes
I think I'm ok with ignoring BIT0 for now? or make it a flag the user can select?
I'd hate to add more knobs. Does your HW know the difference between a BIT0 and a BIT1 error anyway?
when MCP2515 tries to transmit and detects a CRC error, it doesn't retransmit?
nope
errr detects a non-ACK condition I guess
I read this as yes, it will retry:
I added the ability to set the transmitter power on the nrf52 devices. I also modified the Adafruit_CircuitPython_BLE python file and will commit those changes as well. Other devices will need to have the hal interface added or a dummy interface created if not possible. Alternatively a compile time flag could disable this for all but this particular device.
Good point regarding the knob count
Is a CRC error actually signaled differently on the bus than a "failed to ACK"? On SAM, the CRC error pertains to reception only.
on MCP which side(s) does CRC Error pertain to?
👀
it's lunchtime here, bbl
👋
Did anybody wrote something in CircuitPython to receive (or transmit) the Covid-19 tracing advertisement? The application is now available in my country, and it use the Google/Apple protocol. I would be interested in monitoring the number of unique advertisement received and display something on the CLUE to tell me if a lot of people arround me are using the application (and if they are not, make the sale speach to suggest they do). [I can find a lot of other use if I can start to advertise, but let's not make it too easy to have "hacking" with this]. Here are the documentation I found: https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf?1 As soon as I have time, I will try nRF tools on another phone to sniff that, maybe dump what I see from the CLUE and work on something. But if there is code arround doing anything already, I am interested.
@thorny jay I want to but had no way to test. I suspect a phone app won't see the broadcasts because the OS won't pass them on. I'm happy to help you do it though. I think it's as simple as monitoring advertisements.
@analog bridge Maybe there is an IDF config we need to set.
@slender iron I was suspecting the way we build cpy.
The default wake stub is weak linked and a custom wake stub replaces it.
This is just an initial pull request to discuss the additional device implementation details an or compiler flag. It will fail build test for those devices. Also I elected not to preform transmitter value checking. It can be added at the expense of code size.
@analog bridge Maybe there is an IDF config we need to set.
@slender iron No real plan to advertise, right now, because I have no way to test. If I could filter out the incoming advertisement, somehow only remember one copy and forget after 15 minutes of no advertisement... I should be able to tell the number of actif user arround the CLUE. I am trying to go above the simpletest I found. Here is what I have seen: <Address 73:7f:80:ca:bc:6a> <ProvideServicesAdvertisement services=<BoundServiceList: UUID(0xfd6f)> >
Advertisement(data=b"\x17\x16\x6f\xfd\x43\x51\xf7\x75\x99\xbb\xd6\x97\x51\x8d\x54\x37\x74\x75\x9e\x62\xaa\x59\xd8\x85\x03\x03\x6f\xfd")
@thorny jay I agree it's interesting to monitor the volume of advertisements
looks like you spotted it with the 0xfd6f service uuid
If you are in crowded place and you see no advertisement... quickly explain the interest of the app and run away. If you see a lot of advertisement... your CLUE turn Yellow or Red and you run away.
@hierophect thanks for the very clear summary; I was curious what the -isystem was changing.
@hathach thanks for a known good working point.
I have a mostly-admin task day today, so I'm going to learn about git bisect and start working from espressif/esp-idf@6c17e3a to the current latest, and see if I can find the point where it stops working.
@thorny jay summary: don't leave your house
Right now I do something like that... but I have no clue what I am doing:
from adafruit_ble import Service
from adafruit_ble.uuid import StandardUUID
class COVIDService(Service):
uuid = StandardUUID(0xfd6f)
@thorny jay I think it's good to track adoption
that looks right
the advertisement's data_dict property could be helpful too
it splits things by adt type
@grim dagger I'm going to fix the tinyusb submodule for you
its the only thing that needs changing in your PR
@slender iron Thanks! Please let me know what/where you had to make changes... I still don't think I know what you mean if it's not the merge that I was asked to do!
when you did the merge, I don't think you updated tinyusb locally
but you did add it to the next commit
when you did the merge, I don't think you updated tinyusb locally
@slender iron If I did, I was thoroughly ignorant of doing it! 😳
I'm kind of interested in looking into the I2C issue on STM but don't know where to start. I bought a bunch of QT-Stemma boards to play with and I2C is an important bus in general anyway.
I'd start by seeing if the stm hal gives more detail when hitting the failure
ok, I force updated your branch
it's a super common mistake
@slender iron Something you could explain in your upcoming stream?
did git rebase -i HEAD~3 and deleted this commit https://github.com/adafruit/circuitpython/pull/3450/commits/4a3635a06a20155d3dac08aa82831993b064884e
makes a doc for the livestream
ok, its in the doc
forgot to make a notes doc for the cpy weekly too
did
git rebase -i HEAD~3and deleted a commit
@slender iron Should I be doing something on my local repository before tackling another project? Do I need to do that rebase for example?
generally I start a new branch from adafruit/main
so git fetch adafruit, git switch adafruit/main, and git switch -c new_branch_name
-c for create
I guess I could wait unitl the Quirk is in the main. Would be nice to use the display since I'm quite familiar with it now.
The display gives me the quickest route to an Error 5
should be an hour or so after CI is happy
Here is the notes document for Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1rBN-zWSQYxJcHMfXdScKoHzltA9OOPbG7ger_TUHXu4/edit?usp=sharing
@julianrendell Did you see microdev's comment about the link?
Woot- I'm liking git bisect!
0aa1c1302705b16fa5560ee4491a12e42631fe7f is the first bad commit
commit 0aa1c1302705b16fa5560ee4491a12e42631fe7f
Author: me-no-dev <hristo@espressif.com>
Date: Fri Aug 21 01:44:11 2020 +0300
Fix USB CLK always reset and USB with swapped pins not working
components/esp_system/port/esp32s2/clk.c | 1 -
components/soc/src/esp32s2/usb_hal.c | 1 -
2 files changed, 2 deletions(-)
@cwalther I also realized this approach here is very similar to what we'd need for setting the USB descriptor from boot.py. #1015
I was translating CircuitPython and found this;
// Output a user safe mode string if it's set.
serial_write_compressed(translate("You requested starting safe mode by "));
serial_write_compressed(BOARD_USER_SAFE_MODE_ACTION);
serial_write_compressed(translate("To exit, please reset the board without "));
serial_write_compressed(BOARD_USER_SAFE_MODE_ACTION);```
I am quite certain that type of string concatenation is unlocalizable.
@cobalt grail what would be better? we can change it
Of course we can. 🙂
Not sure. The BOARD_USER_SAFE_MODE_ACTION comes from the board specific file.
@atomic summit please allow maintainers to update your PRs. yours is still broken but I can't fix it. Made a PR to your branch instead: https://github.com/UnexpectedCircuitPython/circuitpython/pull/1
I would change the last one to simply "To exit, please reset the board normally" or something like that.
The string translates fine to swedish, but not all languages have that heritage.
isn't the issue that it's assuming the sentence structure?
Yes.
could we put a %s in the first bit and pass in the second?
Maybe something like "You have requested starting in safe mode, reason: %s"?
In my mind that does split it into 2 separate sentences. Not sure that how other languages work? 🙂
I’m unfamiliar with USB and don’t know what a descriptor is, so I can’t comment in detail, but one thing to note is that the more pieces of information we save using this approach, the more carefully we need to think about their interaction. If one needs to be cleared and another one is newly set and a third one needs to be preserved, and not all of this is known at the same time, in what order do we do what so we don't leave holes and waste memory? I‘m actually working on planning that throu...
@slender iron A version of usb check implementation in deep sleep PR might fix issue #544. https://github.com/adafruit/circuitpython/issues/544
@cobalt grail I think it reads better as one sentence but I agree the format doesn't generally work now
Of course it reads better. In english. 🙂
hey all, I am using the feather M0, and whenever I disconnect the usb it always goes into safe mode. Any way to prevent this?
how are you disconnecting USB?
Im just using it to charge the also attached battery
its fine until the battery runs out, as soon as it "dies" from no power
it 100% comes back in safe mode every time
my problem is i have this in an enclosure, I dont want to have to take it apart just to hit the reset button every time it loses power
Just to make sure we understand... Unplugging the USB does not immediately put the device into safe mode correct? It only goes into safe mode after spending some time unplugged and having the battery run empty is that right?
@lone axle do you have time to update: https://github.com/adafruit/circuitpython/pull/3449 ?
i should ammend that to say, it appears that when I lose power it goes into safe mode upon next boot
regardless of if it lost power from battery
or being unplugged from usb
i swapped it with a playground express and the same behavior happens
what original board are you using?
feather m0
Curious if adafruit_ble is getting stripped from being shipped with Cpy6, or if that's just a beta thing.
@cursive pike we have seen similar issues with solar power
@thorny jay I see those BLE advertisements occasionally at my desk with a CPB, I've just left this running. Some devices are far more chatty than others. ```>>> for adv in ble.start_scan(Advertisement, minimum_rssi=-128):
... uuid = adv.data_dict.get(0x03)
... if uuid == b"\x6f\xfd": ### little endian
... print("{:.3f}".format((time.monotonic_ns()-start_t)/1e9), adv.address, adv.rssi, adv.data_dict.get(0x16))
@slender iron you think its related to the battery side on the m0?
@bronze shadow I don't know what you mean by stripped
@cursive pike safe mode power issues are usually triggered by brown out detection
On 5.* I can import it, but the import fails on any board running 6 beta or alpha.
@slender iron I can try to make the changes on that PR. Taking a look in one moment.
id love to be able to optionally disable safe mode 😦
@bronze shadow importing what?
If the devices boots up not in safemode with insufficient power I think it could get into a more broken state though.
I don't think it's useless if it prevents the device from getting into a corrupted state.
I cant be having to open it up every time the battery dies just to hit reset
@slender iron import adafruit_ble fails on Cpy6 on all of my boards.
i mean it is if its in an enclosure the way its behaving
because I have to unscrew the cover and hit the reset button when i plug it in
I'm currently testing on an NRF52840 based nice_nano
I think RESET is broken out to a pin isn't it? You could run some wires out to a button on the external side of your enclosure. Or sometimes I see people make enclosures with strategically placed holes that a pokey bit can fit into in order to press reset.
@cursive pike we may want a similar change as this: https://github.com/adafruit/uf2-samdx1/pull/111 it makes the bootloader wait for power to be ok
but only for SAMD51
hmmm if the m0 has reset on a pin that may be useful
you can also reset from the cpy repl
or cpy code in general
@bronze shadow what is the error on import?
ImportError: no module named 'adafruit_ble'
looks like it does right next to the CHG indicator LED
@slender iron that may do the trick, how do I load this out
I'm using the download links from the web, not building source.
did you put it on the filesystem? it's not built into the binary
only _bleio is built in
I'm having a hard time cleanly checking out between different versions of the ESP-IDF. for whatever reason it really, really doesn't want to delete the components/cmock/ directory? git reset --hard won't touch it, git clean -fd won't touch it (Skipping repository components/cmock/CMock ???), literally the only way to do it is manually rm -rf components/cmock/CMock. Not a hugely big deal but what's up with that?
@thorny jay I see those BLE advertisements occasionally at my desk with a CPB, I've just left this running. Some devices are far more chatty than others. ```>>> for adv in ble.start_scan(Advertisement, minimum_rssi=-128):
... uuid = adv.data_dict.get(0x03)
... if uuid == b"\x6f\xfd": ### little endian
... print("{:.3f}".format((time.monotonic_ns()-start_t)/1e9), adv.address, adv.rssi, adv.data_dict.get(0x16))
@simple pulsar Thank you, all help are welcome as I have no idea what I am doing... but this code I made should run for ever and display any new code I would see: https://gist.github.com/dglaude/87cd56f6da418e44d961c445478b8e95
Trying to scan for Corona virus app using "Exposure Notification" protocol. (With CircuitPython) - coronalert.py
I'd like to put together an alias that can cleanly update a submodule, so it'd be nice to put together something that doesn't leave these dangling directories around without needing to specifically go in and delete them
@slender iron im not sure I follow, how can I call reset in safe mode?
@tannewt I think the latest commit removes the check you were referring to. Let me know if I've misunderstood and removed something different, or if I missed something else that needs to go with it.
I did not build this or test on a device after the latest commit. I can try that out later tonight.
@cursive pike connect to it over serial and call microcontroller.reset()
- USB serial
what do you mean?
@idle owl do you have time this week to polish up this driver and release it: https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_SH1107 It's for the 128x64 OLED
oh you are saying this gives me the ability to reset without opening up
right
@slender iron I must have overloaded the controllers ram as our project always does. I was getting errors that weren't actually there. Thanks!
I get you but, this wont be near a computer, so I may need to wire up a reset button i think
you could also look at the bootloader change I linked. we probably need something similar for the SAMD21
Green LED!
@hierophect @hathach @me-no-dev: the following patch gets (CircuitPython) UF2 working:
git diff 406ms Wed 30 Sep 18:43:32 2020
diff --git a/components/esp_system/port/esp32s2/clk.c b/components/esp_system/port/esp32s2/clk.c
index 0306d5d02..041efc699 100644
--- a/components/esp_system/port/esp32s2/clk.c
+++ b/components/esp_sys...
@slender iron You'd need to run it by Limor.
Yup! Thank you. That is what I was thinking.
.. what if blinka could do USB HID (pi zero in gadget mode) ..
@idle owl kk, will ask on slack
@pastel panther I'm back finally, I feel like we had not really come to a good spot on the exception-throwing behavior of send..
@onyx hinge I'm almost ready to push a PR to address your feeback; I'll tag you in it
@ionic elk - I've managed to find the change that breaks uf2 for esp32s2 with the latest upstream esp_idf, bring it forward, and verified that uf2 works with the two line patch. Details added to the CP PR#3492.
@onyx hinge please re-review https://github.com/adafruit/circuitpython/pull/3482 when you get a chance
I'm trying to get PRs in before tagging beta.1
@onyx hinge I agree about the send behavior being tbd; regarding the timeout exception for send, I'm removing it.
Regarding the other error types like CRC failz, the MCP doesn't record them. AFAICK, the retries from those errors are automatic and they only serve to increment the related error count
@thorny jay Ah, we have basically the same code. I think generating them is far more tricky, you need AES128 (chip has enc in hardware but it's not exposed in CircuitPython), SHA-256, approximately correct time, and there's no point sending them unless the device is participating fully in some way. Plus it warrants a lot of scruntiy to avoid generating accidental junk.
@slender iron OK, I'm still not sure I've quite wrapped my head around the fix so I'll look closer. What's my deadline?
I'm going to try and tag tomorrow
no worries if it doesn't make it. I just thought it might be close
@simple pulsar Obviously you know much more than me about this protocol. And also it took me hours to find the right way to filter on the interesting advertisement (and this with hint from @slender iron). I am now moslty interested in avoiding duplicate and finding a quantity of unique ID in a sliding time window. And that would be the "density" indicator.
You shouldn't need an extra flag. _bleio should be enough granularity.
You'll also need to edit ports/nrf/common-hal/_bleio/Adapter.h to add a tx_power field. That is why the CI is failing.
@simple pulsar This article explain some hack and responsability: http://www.davidgyoungtech.com/2020/04/24/hacking-with-contact-tracing-beacons
I could see how two devices in separate location and communicating over internet could create a multiverse that link two places.
Just forwarding advertisement from one place to the other... in a replay attack.
@thorny jay I looked at this briefly a while back when I was curious how well the distance estimation worked. It's designed to prevent tracking so if devices implement it properly and have the BLE private address thing then you won't be able to track over a long period but you could get a decent view of density by looking at the last few minutes of time.
@simple pulsar I have read somewhere that on some device the MAC and the advertised message do not change at the same time... and that permit to link one message to another and keep tracking the same device.
@pastel panther ok I think that will better align you with what the core canio does.
@thorny jay Synchronising the two sounds tricky to me. The spec says you should change at the same time but I don't see how an app with bog standard APIs can do that, but I've not looked into it. There might be a callback for private address changed.
@thorny jay I was using dict objects to store addresses in a simple ble scanner and that would MemoryError strangely quickly. I'd keep an eye out for that. Maybe some primitive, pre-allocated fixed size arrays would work better and just sacrifice the fast lookup.
There it is, action shot: https://forums.adafruit.com/viewtopic.php?f=53&t=164851#p811436
@simple pulsar Did you write advertisement code (that look realistic enoug). I might be running out of cellular phone to properly test whatever I am doing... but I have at least 4 Adafruit board that could beacon (and maybe change ID at the click of a button): CPB, ItsyBitsy nRF, Feather nrf52840, Feather Sense and... maybe one day use the AirLift FeatherWing to advertise... and of course the CLUE that would be my detector device.
@julianrendell thanks for putting in the work to help track this down! I've also been circling this issue and your contributions have been super helpful.
In general, our goal is to transition completely over to the IDF as soon as possible. We need the latest changes to the ESP-IDF in order to enable the ADC calibration measures that allow ADC readings to be accurate to within 0.1V, and we don't want to be operating off a fork anyway (see the PR description for why that was done at all). S...
Not for exposure notification, but I have written code to send out custom advertisements (and receive them). It's a bit big because it does other things but you can see it in https://learn.adafruit.com/rock-paper-scissors-circuitpython - I also noted on the last page https://learn.adafruit.com/circuitpython-ble-advertising-beacons and https://learn.adafruit.com/bluetooth-le-broadcastnet-sensor-node-raspberry-pi-wifi-bridge
@simple pulsar I think I am going to borrow a lot of code from you. 🙂
After a git mistake... I've just recompiled CP clean using esp_idf patched as per above, and at least the uf2 build appears to be working (REPL appears in mu.)
@hierophect - you're welcome.
Here's what I've done:
- figured out the point in esp_idf that caused adafruit/uf2-esp32s#12, discovered it's two lines, pulled it forward into a locally patched version of esp_idf based on pulling latest of esp_idf
- verified that gets uf2-esp32s working
- recompiled CP with patched esp_idf, dropped the generated uf2 on to the working uf2-esp32s and done minimal verification (Mu sees it and
print("hello")works from the REPL)
I understand and agree r...
Also fix two bugs:
- Crash when resetting board.SPI when it hasn't been inited.
- Reading back the output value is always false. Fixes #3353
Do we believe we can fix this? Or should we make it a long term issue? Is it still an issue?
metro tested for sure! did not test other parts of PR
Ach, I figured out that the ADC calibration changes are actually the oldest of everything, which is why I had my timeline confused. So it's actually entirely feasible that by using the pre-break version, we'll also solve the ADC issue, and don't have to deal with any of the breaking file changes. Giving it a shot now.
Yes! New product, the 64x64 matrix... please update all your learn guide for this (selfish because that is what I have been doing lately, as I only have a 64x64 and the M4 Matrix Feather Wing): https://www.adafruit.com/product/4732
@hierophect I've just checked and discovered that CP and uf2-esp32s are pulling in different versions of tinyusb.
My suggestion is that we aim to:
- keep this PR working with latest IDF, with all the needed changes due to things moving in IDF and using
-isystem - pull in the latest TinyUSB into a branch of uf2_esp32s2 and ask @hathach for help with getting that to work with the latest (unpatched) esp_idf
- verify the updated TinyUSB works with CP, both as a "full flash" and as a UF2 a...
You'll also need to edit
ports/nrf/common-hal/_bleio/Adapter.hto add a tx_power field. That is why the CI is failing.
Damn I forgot to commit that file! Good catch that explains some failures.
I believe it is an int8_t in the Soft Device API.
You shouldn't need an extra flag.
_bleioshould be enough granularity.
Because the shared-bindings Adapter.h and Adapter.c have been modified and so has the init.py in the Adafruit_CircuitPython_BLE library (Which I haven't submitted a pull request for that yet because I didn't have time on my lunch break). Won't the other devices need to have a dummy implementation of the get_tx / set_tx functions in common-hal? If so I will take a look at the other devices and implement the hal ...
Without minimizing the amount of work this actually required, the changes to this point look quite sensible to the point of being simple and straightforward (to read).
I am surprised that the PR does not include a change to the esp-idf submodule itself, but that is presumably due to its draft state.
Ok, I reverted the changes representing the ESP-IDF's refactor from components/soc to components/hal, along with the system binary name change also included in that commit (5425ef4). Confirmed working on my Saola 1 Wrover!
I'm merging this into my ADC branch so I can continue work on that. My input would be to merge this change, and simply revert the above commit (e01e8dd) when TinyUSB is updated to work with the latest ESP-IDF version if we have a compelling reason to need it.
Actually, I spoke a little too soon there. TinyUSB does need a change for this to work. In src/portable/espressif/esp32s2/dcd_esp32s2.c, we need the includes altered to use the -isystem path, or they will throw undef errors:
-#include "driver/periph_ctrl.h"
-#include "freertos/xtensa_api.h"
-#include "esp_intr_alloc.h"
-#include "esp_log.h"
-#include "esp32s2/rom/gpio.h"
-#include "soc/dport_reg.h"
-#include "soc/gpio_sig_map.h"
-#include "soc/usb_periph.h"
+#include "comp...
@slender iron https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_SH1107/pull/1 If you want this released this week, it needs to be merged before the CE meeting. The examples should be tested again because of Pylint changes, but eh.
If you use the version in esp_idf does that bring problems for the other CP platforms?
I’m out of time for now, but I’d be curious to try the tinyusb from latest idf with uf2_esp32s2 and CP and see If that works- ie brute force copy and replace. Maybe they’ve added a fix and have yet to PR it to tinyusb.
At this point it feels like a big enough problem to try and fix sooner than later- seems like it’s accumulating technical debt.
@idle owl I can look now
What time is the stream tomorrow?
mine? it's friday at 2pm pacific
im stuck.... trying to get CursorControl to work with feather_m4_minitft_featherwing but i need board.JOYSTICK..... i got seesaw and the featherwing frozen libs..... but not sure how to add joystick to pins.c
why do you need board.JOYSTICK?
for cursorcontrol
maybe the library needs to take a pin in instead
@slender iron Library is ready to go, docs are set. https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_SH1107
@slender iron How do I allow maintainers to updater my PRs?
Oh, only on creation? I cant see a way to change it now. I never knew that was even possible, sorry 😦
np, now you know
For greater collaboration, you can allow commits on branches you've created from forks owned by your user account.
Thanks for the PR, I've merged it. So does that automatically update my original PR now? Or do I need to do something else?
ya, it was made to the branch of your PR
the merge and my commits are at the bottom here: https://github.com/adafruit/circuitpython/pull/3463
Long term ugly bug!
I pull images for WROVER-S2 on daily basis and this crash is still here.
If I develop something, 1 linux crash per day is minimum :)
If I just try few commands if it works, no crash.
On 9/30/20, Scott Shawcroft notifications@github.com wrote:
Do we believe we can fix this? Or should we make it a long term issue? Is it
still an issue?--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github...
Scott asked me to review this PR particularly to decide whether it should go into the next beta release which is coming real soon.
At this time, I think we should skip incorporating this PR, and reevaluate after beta.1 goes out:
- I was not really able to give this code a thorough code review, I only did some testing
- It is not fixing a specific known crash, but rather seeks to address a deficiency of some internal core code that we have (accidentally or by design) mostly worked aroun...
@dhalbert mentioned in https://github.com/adafruit/circuitpython/issues/2818 that there's separate control over advertising tx power and packets for connections. Are both of those values or some global value being set by this change?
@slender iron https://github.com/adafruit/Adafruit_CircuitPython_DisplayIO_SH1107/pull/1 If you want this released this week, it needs to be merged before the CE meeting. The examples should be tested again because of Pylint changes, but eh.
@idle owl FWIW, I just retested the library and examples on Grand Central M4 Express with the SH1107 OLED and they all worked fine.
@grim dagger Much appreciated.
@slender iron Speaking of tinyusb, I have synced my github fork to adafruit and locally pulled it down, deleted the old branch and annoyingly I see a lib/tinyusb mentioned in the git status. Nothing I've tried gets rid of it:
<pre><font color="#8AE234"><b>mark@mark-ubuntu-8460p</b></font>:<font color="#729FCF"><b>~/circuitpython</b></font>$ git status
On branch main
Your branch is up to date with 'origin/main'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
<font color="#CC0000">modified: lib/tinyusb</font> (new commits)
no changes added to commit (use "git add" and/or "git commit -a")
</pre>
@grim dagger did you do git submodule update lib/tinyusb?
That worked, thanks! That command isn't on any of my cheat sheets even!
🙂
I'll google it 😉
it checks out the correct commit of the submodule
@dhalbert mentioned in #2818 that there's separate control over advertising tx power and packets for connections. Are both of those values or some global value being set by this change?
@dhalbert Is correct according to Nordic API reference there are 3 types of power roles.
Enumerator
--
BLE_GAP_TX_POWER_ROLE_ADV | Advertiser role.
BLE_GAP_TX_POWER_ROLE_SCAN_INIT | Scanner and initiator role.
BLE_GAP_TX_POWER_ROLE_CONN | Connection role.
My implementation strictly se...
Maybe instead of a property this should simply be an argument added to the start_advertising method?
Maybe instead of a property this should simply be an argument added to the
start_advertisingmethod?
I think this may be a better solution. The original .tx_power was added when I was not as aware of the many variant ways of controlling tx power. Another place to look is what the bleak-related and Bluetooth HCI interface provide, so we can make this work across other platforms. I think it may not actually be possible to change the power in the ESP32 HCI firmware (I cannot remember a...
Maybe instead of a property this should simply be an argument added to the
start_advertisingmethod?I think this may be a better solution. The original
.tx_powerwas added when I was not as aware of the many variant ways of controlling tx power. Another place to look is what the bleak-related and Bluetooth HCI interface provide, so we can make this work across other platforms. I think it may not actually be possible to change the power in the ESP32 HCI firmware (I cannot remem...
So sorry to trouble the folks on this forum w/question from help-with, but I'm wondering if there may be something missing from tutorial documents describing how to get Adafruit LED Matrix, Metro M4 Express, and CircuitPython working with a 32 x 32 LED Matrix Panel.
I built a second LED Matrix Shield - continuity tested the cut for M4 (no connection) and the wire from CLX to A4 (connection). Same result with both shields + with separate Adafruit 32 x 32 Matrix LED Panels (5 mm and 6mm). If I take the sample code here:
https://learn.adafruit.com/rgb-led-matrices-matrix-panels-with-circuitpython/example-simple-two-line-text-scroller
But update the code above with the Shields Up code from here:
https://learn.adafruit.com/rgb-led-matrices-matrix-panels-with-circuitpython/metro-m4-express
updating the width to 32. I get something that looks like this:
https://youtu.be/siX0fwvexiA
So I'm wondering if there's something wrong with the docs, demos, tutorials, etc. I'll post over on the CircuitPython forum to see if those folks have any idea. Thanks!
Here is a gist with the code: https://gist.github.com/gallaugher/c5cf4990b84d323646ecfabe7073ee53
I'm using CircuitPython 5 for the Metro M4 Express + this is what my Lib folder has installed - no errors in serial monitor, so I assume I've got all of the lib files needed.
I had missed one instance of that boolean variable being used. The latest commit takes care of that.
I did also build this version tonight and run it on a PyPortal and verify that the adafruit_sdcard and ondiskbitmap are still working properly.
Gateway and subnet are coming from the same esp_netif_ip_info_t that you got the ip address from so they're always going to be ipv4. I just matched the naming scheme you used for the existing ipv4_address property honestly - it's easy enough to drop the prefixes, but I do think it's nice when everything was grouped together when you dir() the wifi.radio object.
For DNS, though, esp-idf's DNS type (esp_netif_dns_info_t) contains both esp_ip6_addr_t ip6 and ```...
I think I have a generic solution that will work for any number of items (as long as they all fit on the stack at once). Implementing and testing it will probably take me a few days though.
I think you're right, I'll try that. That'd avoid pulling out everything individually and would probably be nicer to interact with too.
Actually, I spoke a little too soon there. TinyUSB does need a change for this to work. In
src/portable/espressif/esp32s2/dcd_esp32s2.c, we need the includes altered to use the-isystempath, or they will throw undef errors:-#include "driver/periph_ctrl.h" -#include "freertos/xtensa_api.h" -#include "esp_intr_alloc.h" -#include "esp_log.h" -#include "esp32s2/rom/gpio.h" -#include "soc/dport_reg.h" -#include "soc/gpio_sig_map.h" -#include "soc/usb_peri...
I can imagine that the memory exceptions are going to be particularly difficult to handle. especially when they happen with a small allocation and there is little memory left to process it.
Thanks for the comments! I have no problem with waiting until after beta.1, or even after the 6.0 release.
There is some likelihood that my work on #1084 will trigger the bug fixed here, and therefore become dependent on the fix, but I don’t think that is a problem.
Maybe I can do some testing on #3473 too if I’m getting impatient, although I don’t have an nRF52 and a Sharp display. As far as debugging is concerned, making the bug easier to trigger seems like a good thing…
@cursive pike I am playing catch-up. Was this issue mentioned? https://github.com/adafruit/circuitpython/issues/2694 It’s a more thorough discussion. If you wanted to make a custom build for now, not going into safe mode is a small change.
Thanks for the thread, I think it describes a bit the behavior I am seeing, I just don't see that it came to any resolution?
The CSR definitions in fomu only use csr_writel() and csr_readl(). These appear to compile down to the same instructions under the new hw/common.h
Overall it looks good. Congratulations on the port! There are just a few macro guard comments that need to be updated, but otherwise I think it looks good.
I agree I think it will be nice to add a cleaner way to breakout the digitalio, once there are a few different variants.
For now it does work just using #ifdefs
I'll work on a "standard" GPIO module for the SoC and add that in next.
I've also been playing around with Github CI. Here is the first step of that, the SoC built and uploaded with Github Actions: https://github.com/gregdavill/OrangeCrab-examples/actions/runs/282262646
yay I think I just squashed that sharpdisplay memory corruption bug I was seeing but couldn't reproduce on command!
[runs a series of 100 restarts of the calcuator app before truly celebrating]
Is it possible to use an rgb led with pwm instead of a Neopixel/Dotstar, there seems to be support for it in the esps2 port? If I try to use 'CP_RGB_STATUS_X' CP doesn't boot 😦
It was incorrect to NULL out the pointer to our heap allocated buffer in reset, because subsequent to framebuffer_reset, but while the heap was still active, we could call get_bufinfo again, leading to a fresh allocation on the heap that is about to be destroyed.
Typical stack trace:
#1 0x0006c368 in sharpdisplay_framebuffer_get_bufinfo
#2 0x0006ad6e in _refresh_display
#3 0x0006b168 in framebufferio_framebufferdisplay_background
#4 0x00069d22 in displayio_background
#5 ...
@blissful palm I think you'll probably have to put in some work first. I don't know a specific direction to point you, though. I am just recalling that there are some third party nRF52840 boards with non-smart status LEDs and there were some problems there as well. The issue I'm thinking of is https://github.com/adafruit/circuitpython/issues/2707 so it's not a "wouldn't start at all" problem on nRF, it just doesn't work to switch off between supervisor-controlled and python-controlled modes, looks like.
On my Argon the Status LED is not lit at all in CP. IT is red briefly after RESET then off. I can set it manually.
On the Xenon the Led is red briefly after RESET then white all the time.
However one commenter notes that the colors don't seem to be correct anyway
Ah ok looks like it is broken then.. thanks @onyx hinge , if I get a mo I will take a look at the code..
didnt test but code looks good!
@blissful palm thank you! If you end up with notes but no fix you can add it to #3497 or start a fresh issue. I don't think this is a code path any Adafruit products require so we're going to need community help on this one
To be honest, I don't like this change since IDF move files around quite a lot and there will be more mcu such as esp32s3, it is better if we could use the default include path set by IDF toolchain. Though if you think it is a must, please try to submit PR to tinyusb to see if it could pass the ci buld with stock IDF (which lots of people will also use as well), I am not sure if
componentsis one of included path.
@hathach the issue is that we need these files to use the -isystem path,...
@onyx hinge I was just poking around could not see what is causing it to not come up, will look at bit further..
Due to an existing limitation of being unable to re-allocate a freed supervisor heap entry, framebuffer displays used more memory than necessary, particularly on the second and subsequent runs: The preserved-over-soft-reset display has its framebuffer moved to the supervisor heap, but we release that display with release_displays() and then create a fresh one which places its framebuffer on the GC heap.
A newly exposed problem, where framebuffer displays would cause a leak of the terminal ...
.. implement #3498 but for rgbmatrix. will require the same infrastructure commits to be merged in first.
TFW you were sure you pushed exactly that fix yesterday, but obviously didn't
@microDev1 does this address your concern? I did it differently than you suggested
@slender iron Hey Scott, did you see my mention in the IDF change PR? Our current issue is that TinyUSB has a number of the problematic file includes that throw undefined errors, but Thach is uncomfortable with putting in the full file paths since the idf changes them so often, which I get. Do you have any ideas about how we should get around this with -isystem? I kind of feel like I'm missing something - does every external lib we might use need to interact with our makefile include conventions to avoid undef errors?
@ionic elk I haven't gotten through email yet
I'm not sure what you mean
I think you can just -isystem the specific paths that the idf needs
the includes from tinyusb need
in the the same way you'll need specific paths for subincludes in the idf
@tannewt I was considering the following to be the final form of the api.
import alarm
import alarm_io
import alarm_time
import alarm_touch
alarm_io.enable(board.IO6, level=1, pull=True)
alarm_time.enable(2.5)
alarm_touch.enable(board.IO8)
alarm.disable //Disable all alarms
alarm_io.disable //Disable all io alarms, similar for time & touch alarm.
//Go to light/deep sleep on code.py exit based on usb connection check.
- In `alar...
@analog bridge sorry I haven't gotten to the sleep stuff. I got sucked into bug fixing imx rt
Looks great! Thank you!
Sorry, I thought this was more complicated than it actually was. It just needs an update to override the esp-idf/components/log/include/ that tinyusb uses in this case. So no TinyUSB updates should be needed.
@slender iron you're right, I was overthinking it. Just needed an extra include that TinyUSB uses, to override what I guess is an IDF default?
@slender iron np...... couple updates. I got the usb check working. As for the wake stub, it does work in cpy version of esp-idf, I compared the sdkconfig of cpy and the idf project and didn't find any config that could interfere with wake stub.
what is a default?
@analog bridge does the wake stub get flashed to a separate location?
it gets flashed in RTC_FAST_MEM region
@cwalther Sorry to distract on this. A USB descriptor defines what type of a USB device something is such as keyboard vs audio. It's similar to this because we'd construct it in boot.py and save it as a byte string. USB is initialized after boot.py and then lives through all subsequent code.py. So, it's a similar case of save a byte string from the VM and then move it into supervisor memory to init TinyUSB with. It shouldn't add complexity because it won't change after boot.py.
@analog bridge isn't that sram?
I'm not planning on adding a JTAG module myself. I would review and merge one though.
@slender iron I think it is...... just realized one difference between the config was that psram was disabled in idf project
ah
on to doing a re-test. Will replace idf sdk config with the cpy one
@lunar crown one thing I checked on the imx was that the flash wouldn't be read while running a simple loop
though that was a while ago
I don't think we use the fancier floating point hardware either
@slender iron I suspect that you need fairly large TC-RAM space and lock the VM, all common I/O drivers and used ".mpy" files into TC_RAM to get consistent performance better than M4E.
I think you are right that it will vary more widely
given the main bus is 1/4 the speed
I'd expect the VM itself to run faster in TCM
Yes, and the QSPI bus is about 1/16 speed
one possibility is that the cpu is clocked slow 🙂
right, that's why I was seeing if a simple loop had to fetch anything over QSPI
I can build CP on a Linux machine, including generating the ".bin" file required by the Windows-only Teensy loader. So need to sneaker-net the binary to a Windows machine to load into Teensy. PJRC seems to have blocked all direct access to all normal programmer interface on Teensy, so really bad platform to develop on. Have I missed something?
I was using teensy loader on Mac just fine
SWD isn't available on teensy for security reasons I think
what linux distro are you using?
Yes, that is what Paul says.
I am running 20.04 LTS
it should be possible to load using that
I did not know about a Linux version of the loader. Thanks
np
Are there any common (free?) tools that allow you to determine CPU speed, and monitor paging activity?
to confirm CPU speed I usually output a PWM signal off the same clock. not sure how to do it off imx
for paging you can scope or logic analyze the CS line of the flash chip 🙂
PWM clocks and all other IO normally on totally different clock trees than CPU. Marketing literature very proud of that.
that was the approach I used on samd
@hathach the issue is that we need these files to use the -isystem path, or they will cause errors like
error: "CONFIG_IDF_TARGET_ESP32" is not defined, evaluates to 0 [-Werror=undef] #if CONFIG_IDF_TARGET_ESP32while compiling. @tannewt do you have any suggestions?
Sorry, I thought this was more complicated than it actually was. It just needs an update to override the esp-idf/components/log/include/ that tinyusb uses in this case. So no TinyUSB updates should be needed.
I am glad...
That is probably who NXP marketing was shooting at.
I will look at that, and ask question on iMX-RT forum.
kk, I'd suggest getting a dev board from nxp as well. it'll make it all easier to poke at than the teensy
Agreed. I have 1010, 1020, and 1050 EVK boards, but not 1060
oh! well they should work very similar
can you reproduce the issue on any of the others?
Well, al the TC-RAM sizes are different. For big (750k +) program like CP. the biggest TC-RAM might be real important.
if you can get the small tcm working it'll benefit them all 🙂
I don't think it's full now
R
How do we get a case where we're starting the terminal but already have an area for tiles allocated? I'd expect it to be released when displays are.
Looks good! Thank you!
Looks good! Thank you!
Failure was due to network issue.
I'd prefer each alarm type to be it's own object rather than just enable. There is no need to disable because alarms should be reset after one of them wakes up the cpu. (The code.py will reset it if desired.)
I likely won't have time until next week to help with this. #2796 is really what I'd like to see.
Ok, I think the prefix is fine since it's possible to have both ipv4 and ipv6 versions of these.
@slender iron its not psram
Venlig hilsen
Michael Skov
Huslodsvej 55 1 TV
7000 Fredericia
(+45) 25 30 30 73
b@michaelskov.dk
Michaelskov.dk
Den 1. okt. 2020 kl. 20.05 skrev Scott Shawcroft notifications@github.com:
@tannewt approved this pull request.
Thank you!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
@slender iron I think @onyx hinge invited an unwanted guest. He mentioned cc @microdev
I don't have anything for the core
I've just got weblate-es to 100% again, but they eventually get merged...
Swedish translation is now 100%
alarm.disable is there just to demonstrate the function call.
@slender iron I am trying to use CP_RGB_STATUS_LED I have defined the 3 CP_RGB_STATUS_X pins and this seems to prevent CP from coming up (no usb) is there something I could be missing that you might be aware of?
do we have pwm output already?
Ah is it not yet supported on ESP32-S2?
¯_(ツ)_/¯
I think heirophect did add it
but there may be a bug
I'm canceling some CI builds to unclog things
@slender iron psram is not causing wake stub to not work
any <@&356864093652516868> that would like to see more SPI support in CircuitPython libraries, we're discussing it again here:
https://github.com/adafruit/Adafruit_CircuitPython_Register/pull/35
more opinions are welcome and encouraged!
@balmy sail ☝️
@analog bridge whoops, I'm sorry
@slender iron the last API refinements of canio got in right? Anything else is not urgent
ya, think so
TFW you just spent 1025 minutes scoping the wrong pin
@slender iron @blissful palm we should have PWM? I did that like a month ago. Is it not working?
@ionic elk PWM status LED
it's use from the RGB status neopixel isn't I guess
Also, my ESP32-S2 PRs are failing CI, I'm getting this error The following Python requirements are not satisfied: gdbgui>=0.13.2.0
is that happening for everybody or did I mess something up?
Oh blegh how recently did they fix it? We're doing an old version of the IDF (August 25) because TinyUSB doesn't work with master right now
not sure
It doesn't affect my local builds, I guess it's just a CI thing?
ya, it's a python environment thing
do you remember the problem you were seeing on the imx rt 1050?
Just that it wouldn't start
I was having all kinds of problems loading it too
Something was wrong with the flash
kk, I'm looking at that now too
Cool I haven't really touched it since, happy to try it again if you find a lead
@slender iron unrelated but do you still use Sublime?
yup
I was irritated by the fact that Goto Definition doesn't find enum values this morning, looked it up and found they had a fix PR... that hasn't been looked at since 2019. Seems a little concerning
Yeah I should probably just get more comfortable with that kind of search. Still, though, I'm not sure how I feel about being on an unmaintained project. I guess people like VSCode these days, right?
I tried it but didn't like all of the popups
Testing Message
Testing RemoteTransmissionRequest
can_frequency=42000000
baudrate=1000000 clocks_per_bit=42
clocks_to_sample=37 clocks_after_sample=5
divisor=3
tq_per_bit=14 tq_to_sample=12 tq_after_sample=2
Test messages of length 0
Test messages of length 1
Test messages of length 2
``` hey something's starting to work! my bit timings are wrong though.
I've got 14/15 the requested baud rate somehow. ow.
ok whew next problem is filters
If anybody is interested in the work in progress code for canbus on stm32: https://github.com/jepler/circuitpython/tree/canbus-stm -- basic transmission and reception at 1Mbit work, filters don't work right yet
the stm documentation of CAN filters has left my head broken
@ionic elk 'pulseio.PWMOut' works for me..
@slender iron the ESP32S2 ADC seems to cap out at 2.6V, even at the highest attenuation settings. It isn't anything being done by the calibration process - even the raw readings cap out at 2.6V. The modules seem to indicate that the VDDA is set to 3.3V, so I don't think it's a hardware issue either
kk
The documentation is a bit confusing as to whether this is intended? On the ESP32, readings go all the way to 3.3V but become less accurate at the end. On the ESP32-S2, I guess they just outright cap it https://docs.espressif.com/projects/esp-idf/en/release-v4.2/esp32s2/api-reference/peripherals/adc.html#_CPPv425adc1_config_channel_atten14adc1_channel_t11adc_atten_t
Anyway. Anything special I should do to reflect this in documentation or exceptions? Or just leave it as is, maybe make a note in the port readme?
Is there a webserver library for the esp32s2?
@wooden lichen not yet.
there are two pieces needed. 1) split the wsgi server out of esp32spi and make it work with cpython sockets and 2) add bind and accept support to esp32s2 sockets
In circuitpython is there a way to receive a timer callback after XX milliseconds? I couldn't see a module that offers this functionality in the docs.
no, we don't have any sort of concurrency now
Ok, thanks @slender iron 🙂
np, there is a big long issue about it if you are interested
shakes fist at weblate
This PR adds the AnalogIn module to the ESP32-S2 port. The IDF documentation underlying this module can be found here. The ESP32-S2 has more limited configuration options than the ESP32 for its ADC, so we assume the default settings of 13 bit width for measurements and an attenuation of 11DB for the maximum voltage range.
Also unlike the ESP32, the S2 appears to have a hard cap of 2.6...
yup 🙂
excuse my silliness, but why doesn't pin.value = not pin.value work in CPY?
update
I just fixed it
(in the metro esp32s2 PR merged today)
reading back the output value was broken
hahaha, I just build like 30mins ago
hrm
ok, will re-pull and re-build 🙂
with what commit?
looking now
should be fixed by f303
#3495 ?
yeah I have it
hrm
only commit I don't have is #3485
does it have this change: https://github.com/adafruit/circuitpython/pull/3495/files#diff-b573ba1a5a9d20cfb3208ba9abf2770eL90
ok, so it seems when initialising the led, it doesn't understand it's current state?
that's why my code isn't working.
I don't know what you mean
if pin 13 was an output, already high.... and I called led13 = DigitalInOut(board.LED) led13.direction = Direction.OUTPUT on it again
it resets it to low
I expected it would keep it's state... but I'm not sure why i had that assumption...
direction sets it low
so don't worry, I've already adjusted my code.
there are two pieces needed. 1) split the wsgi server out of esp32spi and make it work with cpython sockets and 2) add bind and accept support to esp32s2 sockets
@slender iron How does the wsgi functionality in the esp32spi library compare with the https://github.com/adafruit/Adafruit_CircuitPython_WSGI library ?
thanks!
Ok, i'll do some code comparisons. tx !
thank you!
Oooer, I was about to ask about this today!!!!
I need AnalogIn for my FeatherS2 - as I have the ALP light sensor on board.
Thanks for getting this underway @hierophect !
@slender iron How does the wsgi functionality in the esp32spi library compare with the https://github.com/adafruit/Adafruit_CircuitPython_WSGI library ?
the Adafruit_CircuitPython_WSGI is providing a WSGIApp and in the example it still uses esp32spi.
ah interesting! so it should really be an example?
I compared the example in that the WSGI repo to https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/blob/master/examples/server/esp32spi_wsgiserver.py and they were pretty close to each other
If we trust google (and my ability to use it) I also didn't find any learn guides which had adafruit_wsgi.wsgi_app in them...
But that could be wrong...
I can search more thoroughly with git grep a neat trick I only just learned about recently, I have a local copy of the learn guide repo already.
No usages of adafruit_wsgi in the learn guide repo.
I didn't know that was a thing... Can we expect a @lone axle deep dive on that ?
Heh, I've only started to scratch the surface with it. In it's most basic use it will search the whole repo for strings and show you occurances. But it's got many extra bells and whistles to tune the search and output.
very cool !
ok, beta 1 tag incoming once I merge the last translations
thanks scott!
🎉
Automated website update for release 6.0.0-beta.1 by Blinka.
New boards:
- unexpectedmaker_feathers2_prerelease
- adafruit_metro_esp32s2
From the docs, I assume there is no way to obtain the current time at millisecond granularity?
time.monotonic is based on the RTC so you can likely use it
Ah, right! Thanks! 🙂
Thanks again, monotonic works great! No ns granularity required 🙂
the ns version is a bit better because it doesn't use floats
but it uses long ints which aren't always available
Unless I'm reading the API Reference wrong, ESP32-S2 ADC1 and ADC2 will allow full-range voltage, but Espressif says most accurate readings at 11dB are between 150 ~ 2600mV (better linearity at the high end than ESP32).
11 dB attenuation (ADC_ATTEN_DB_11) gives full-scale voltage 3.9 V (see note below)
Note
At 11 dB attenuation the maximum voltage is limited by VDDA, not the full scale voltage.
SoC | attenuation | suggested range (mV)
ESP32-S2 | 11 | 150 ~ 260...
I would like to be able to have the option of ST-Link debugging... Is it possible to run circuitpython on a Nucleo-64 STM32 L476 board? “L” boards are all I have lying around.
I'm experiencing a double start of "code.py" with beta 1 when powering the board from USB.
My APA cycles through a rainbow in code.py and I can see it goes from red to blue then turns off and then starts again at red.
This doesn't happen in beta 0 with the same code, and doesn't happen if I power the board from external 5V with no USB connected.
It also doesn't happen from a soft reset, so I suspect it's something to do with the mounting of the USB.
Rebased to fix trivial merge conflict and get a new build. No content changes (so don’t bother re-reviewing). More changes forthcoming, but they’re not ready yet.
OK, just so I get a rough idea to keep in the back of my mind while I implement the generic system, to make sure it will be ready for it:
- Does the supervisor allocation containing the USB descriptor have to live forever (until poweroff/hard reset), or can it be freed after TinyUSB initialization (i.e. before the first code.py run)?
- How many bytes roughly is a typical USB descriptor?
- What happens when the Python functions that set up the USB descriptor in boot.py are called in code.py...
@slender iron Thanks!
Would a webserver even work properly without some concurrency?
nvm, having socket only would make it easy to port over some webserver code from micropython!
This adds handling of GameOver exception as SystemExit in anticipation
of the new way of starting games from the menu.
Smoke-tested on PewPew Standalone 10.2, GameOver in Othello working fine. (Although the display is very flickery and it runs more slowly than with CP 4.1.0, but that is obviously unrelated.)
Ugh, I think the changes around system tick and sleep modes have broken it. I didn't have time to test it, but I've heard reports that gamepad, which also relies on system tick, is unreliable on SAMD21.
I have been receiving some reports that the gamepad library and the _pew library don't work reliable on SAMD21 on 6.x. I suspect it's related to changes around the system tick. I didn't have time to investigate this properly yet, but I'm creating this issue to let everyone know that there is a potential problem.
@cwalther I reported https://github.com/adafruit/circuitpython/issues/3504, hopefully I will be able to look into it this weekend.
@slender iron do you know if GCLK0 is now used for something internally in the SAMD21 port?
because it seems like its settings are being reset, which breaks _pew
I'm looking into it now, and it seems like the timer is getting triggered in a very uneven way, which results in flickering.