#circuitpython-dev
1 messages · Page 425 of 1
Fixes #6489 by incorporating https://github.com/adafruit/samd-peripherals/pull/42.
Will merge to main later.
in actions log I see "Cache restored from key: Linux-idf-tools-ce877007ea00fdebf77e4411f91f8667e6ce893604c8d07c9ca35331beb93414-/opt/hostedtoolcache/Python/3.10.5/x64/bin/python-20220404"
@slender iron Okay, I probably just missed the status line when I first started trouble shooting. I tried for a couple hours last night to get my crash to reoccur with no luck, so I'll grab a new build and move on :).
Is it possible for user code to read other values out of .env file? it could be helpful for other credentials or even configuration options maybe if user code can access values from it.
Awesome!
it does do the file read so only do it once when loading the value
Off hand I'm sure that would be useful for adafruit.io too
Would it make sense in librariers that currently require the use of secrets.py to start adding code that will try to access what it needs from os.getenv() first before falling back to secrets.py?
maybe wait until 8.x is stable
7.x doesn't have getenv iirc
@lone axle just pushed a version without the hard coded ip
it should require a password for /fs now too
I should be able to follow your stream
CIRCUITPY_WEB_API_PASSWORD inside of .env is how to set the password that will be then used from the browser client?
Nothing better comes to mind for me right away. I'll let you know if anything does though.
np, we may need more config to enable/disable things too
did you mention at some point Console / REPL being available over websocket or something similar for the web workflow?
ya, that's my plan
not going to do it before I PR though
I still need to do put and delete for files
I'll do serial in a follow up
I'm already doing a lot in one PR
Update frozen libraries for the next 7.3.x release. After this is merged, we can merge from 7.3.x to main to pick this up and recent 7.3.x bug fixes.
@slender iron @idle owl we should start building 8.x bundles, but I can't remember / can't find what to change to enable that
we are
Thanks, it didn't start until last night. I looked yesterday here: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bundles/adafruit/. Lat night is the first one.
fresh from the oven
Hi all, any success getting
i2cperipheralto work with an RP2040? I have a project where I would like to use an RP2040 as an I2C slave (ahem.. peripheral/target) If not, I can try to look into it (if time permits), don't want to duplicate effort if others are working on it. (PS: checked latest 7.3.0b2, not supported) Cheers.
Would you be interested in collaborating on this? I could REALLY use the functionality but I'm not familiar enough with the circuitpython environment enough to t...
Unfortunately I haven't done anything serious with circuitpython either.
Also, I solved that particular problem with a different approach and
have moved on. Good luck.
On Fri, Jun 17, 2022 at 10:23:39AM -0700, im-redactd wrote:
Hi all, any success getting
i2cperipheralto work with an RP2040? I have a project where I would like to use an RP2040 as an I2C slave (ahem.. peripheral/target) If not, I can try to look into it (if time permits), don't want to duplicate effort if others are w...
I'm willing to try to help if I can. I've been playing a bunch with
Circuit Python, although thus far primarily as a developer using circ-py,
not of circ-py. I do know C/C++, although my experience is from a while
ago, and I'm not super-current on all the latest fancy auto-build systems
and the like.
one thing I was able to do a while ago was recompile a qtpy_m0 (atmel-samd)
uf2 file to include the i2c client code, and as I recall, I was actually
able to get this to work. But basically ...
We're happy to give pointers on the Discord: https://adafru.it/discord That's the best place for fast replies.
Generally you'll want to start by copying ports/atmel-samd/common-hal/i2cperipheral/ into ports/raspberrypi/common-hal. Then, delete all of the implementation in the C functions and the samd specific headers. Once you have this, turn on CIRCUITPY_I2CPERIPHERAL in ports/raspberrypi/mpconfigport.mk. At this point you should be able to build a CP binary and import `i2cperiphera...
It's great to see that a fix for this has already been merged - very impressive! I'm guessing from the 7.3.x milestone that there'll be another 7x release before 8; does anyone have a rough idea of when that might be? Many thanks.
I'm willing to try to help if I can. I've been playing a bunch with Circuit Python, although thus far primarily as a developer using circ-py, not of circ-py. I do know C/C++, although my experience is from a while ago, and I'm not super-current on all the latest fancy auto-build systems and the like. one thing I was able to do a while ago was recompile a qtpy_m0 (atmel-samd) uf2 file to include the i2c client code, and as I recall, I was actually able to get this to work.
Discord is a ...
@blissful pollen hi
I threw this together to help myself note the process. I have a build environment that compiles.
https://github.com/im-redactd/circuitpython-dev
I forked and tree'd the i2cperipheral bits here
https://github.com/im-redactd/circuitpython/tree/7.3.0-i2cperipheral
and I've been spending as much time as I can trying to learn the ins and outs of different ports. but I feel like I'm treading water due to the amount of work I have and little understanding
I get that. Anything particular that's holding you up right now? Looks like a good start, I'd work on renaming the files (get rid of the copy) and as Scott mentioned in the issue remove any ATMEL specific code
So if you compare your ports/raspberrypi/common-hal/i2cperipheral/ directory to the at-mel ports/atmel-samd/common-hal/i2cperipheral/ the file structure should match
got it. I think what derails me the most is that I'm referencing the micropython implementation and it doesnt match any of the circuitpython nomenclature that I start getting more confused. I think as a start I'll try to figure out how to find the rp2040 equivalent to all the atmel/sercom calls in the construct method
have you looked at the rp2040 dev guide (forget the exact name)?
only the hardware guide. ultimately this requirement is because I've built some custom hardware and need to i2c peripheral function
do you mean the RP2 SDK specifically ?
Yes, brain is slow today:
https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf
also
https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf
may have some information
thank you, I'll check out that C sdk guide
I'd take a look at the MP SDK calls and try to find them in the SDKs. I can take more of a look later at it myself.
oh ok that's a great idea. walk back from that implementation in MP to the SDK and then rebuild
Also quick hint
mp_printf(&mp_plat_print, "Testing print\n");
printf debugging. that will print something to your serial console.
grepping the code for similar functionality works great too. If you need more of a discussion on the overall layout between shared-bindings/shared-modules and such can always arrange a time for a quick voice chat if you want
thank you
circup throws an error if I try to install a module that already exists on the board:
File "C:\Users\ktritz\anaconda3\lib\site-packages\circup_init_.py", line 536, in extract_metadata
if loc > -1:
UnboundLocalError: local variable 'loc' referenced before assignment
also, it loaded an incompatible .mpy file
yeah that's a bad mpy file
7.3.0
@calm aspen it may help to read the api docs for i2cperipheral if you haven't already. the common_hal functions should mostly match it
that's what happens when circup encounters a bad mpy file, I was looking at a fix to get a clear error message
I was trying to install adafruit_pioasm, does this mean that the bundle .mpy is bad?
you'll have to delete the mpy file on the board
I did and ran it again, but still got an incompatible mpy error
no, it doesn't read the bundle's mpy files
hmmmm
I'm starting to wonder if there might be an issue with the current bundle then ?
oh what version of CP are you running ?
oh
no there's an issue with the bundle
the mpy files contain the python source...
@RetiredWizard from what I understand from your testing, there are issues relating to the bootloader and USB handling which I don't believe are caused by this PR (from A/B testing with and without this PR.) To narrow the focus of this PR to just the 3V3 output, I'll add new issues to track the bootloader and USB behavior.
@blissful pollen I've cleaned up the i2cperipheral.c in an attempt to build a bare bones library. I'm running into compile errors that reference a lot of the variables defined in the shared-bindings. I've grep'd around trying to find how the atmel version handles these but I'm missing something
../../shared-bindings/i2cperipheral/I2CPeripheral.c: In function 'i2cperipheral_i2c_peripheral_make_new':
../../shared-bindings/i2cperipheral/I2CPeripheral.c:73:11: error: 'MP_QSTR_addresses' undeclared (first use in this function); did you mean 'MP_QSTR_address'?
73 | { MP_QSTR_addresses, MP_ARG_REQUIRED | MP_ARG_OBJ },
| ^~~~~~~~~~~~~~~~~
| MP_QSTR_address
did you make clean ?
no
it's required if you add strings
Yup anytime I get a compile error that has MP_QSTR try a make clean
thank you
ok we have a bug in the bundle where single file libraries mpy contain the py source instead of the mpy file
and I know why, so I'm gonna fix that
though I still don't fully know why it worked before
code.py output:
running dir(i2cperipheral.I2CPeripheral)
['class', 'enter', 'exit', 'name', 'bases', 'dict', 'deinit', 'request']
done
progress
@m-mcgowan I can't seem to recreate the bootloader issue I was having when I did the earlier testing. I would hold off on the new issue unless you see the same behavior. If it pops up again for me, I'll try and figure out what the trigger is and open an issue on it if I can make it repeatable.
I'm just stepping down the code. I'm at this line and wondering what to do.
the SDK call is this: https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__i2c.html#ga42571b2db5d1ed0dc083385c230dc9e8
Do I need to pass a struct containing the 2 pins to that or could I make the call twice. one for each pin?
@calm aspen neither
you'll want the i2c_inst_t
looking at common-hal/busio/I2C.c may be helpful too
thank you for that.
I'm sorry if a lot of these questions are basic C.
for this call: i2c_set_slave_mode(self->peripheral, true, *addresses);
is that valid or should I do a check to see how many num_addresses there are and pass addresses[0] addresses[1] instead?
fix for the bundle's current issue of having invalid mpy files (for single file libraries)
https://github.com/adafruit/circuitpython-build-tools/pull/88
Generally the shared-bindings call will check (as it is common for all ports). I usually test with a few bad values to find out later
would a working construct be enough for a i2c client to see the peripheral on the wire?
Not sure on that if its waiting for a response that the rest of the API has to provide maybe not
CircuitPython version
730 & 8a1 bootloader tiny uf2 094
Code/REPL
from wifi import radio as r
from socketpool import SocketPool as q
from adafruit_requests import Session as p
r.connect("ssid","pass")
print(p(q(r)).get("http://wifitest.adafruit.com/testwifi").text)
Behavior
Traceback (most recent call last):
File "code.py", line 3, in
MpyError: Incompatible .mpy file.
Description
220611 adafruit_requests.mpy works fine
220617 ada...
Hello,
I am having an issue with CircuitPython. I am interested in viewing the amount of memory I have available using the micropython.mem_info function. However, whenever I try running this function I receive an AttributeError.
While reading through the docs I noticed that it was stated that the micropython module may unavailable on some builds on CircuitPython. I was wondering if there were any alternatives to this function in the standard library in CircuitPython.
Thank you!
I'm on Sony Spresense running CircuitPython 7.3.0
You’ll want to use gc.mem_free
Oops wrong channel.
gc is garbage collection and you can use it to see used memory and free memory as well as a few other things
This worked
@blissful pollen I2C addresses found: ['0x40'] !
That's awesome!
this is great. on to the next method!
I'll be around on and off all weekend so feel free if you're working on it to still ping me if you have questions I'll try to respond
I really appreciate it. and everyone else that's helped so far
If you have a github site I'd be more than willing to test on the array of boards I have here, as time permits. 👍
I've pulled down CP from the github repository tonight and built it for the ESP32-S3 DEVKITC-1-N8R2 and I'm once again crashing the board into safe mode when I attempt a wifi.radio.connect. The terminal header indicates WiFi: No IP and I've spent some time trying to figure out how I managed to get past this last night with the UM FeatherS3 but haven't had any luck. I flashed an 7.3.0 version and connected it to the WIFI, thinking that if I had a recent connection maybe the microcontroller would somehow pick up the IP address when I re-flashed 8.0.0, but that didn't work either. I also created a .env file with the wifi credentials, but that appeared to hang the board and when I connected to the UART interface it looked like the board was in a boot loop of some sort.
if anyone is up and looking for something to peek at.
https://github.com/im-redactd/circuitpython/blob/7.3.0-i2cperipheral/ports/raspberrypi/common-hal/i2cperipheral/I2CPeripheral.c
I create the object fine. device = i2cperipheral. I then create request = device.request() and the code moves into more methods like the is_addressed and ack. I'm concerned that the request() object doesn't show its properties when I run dir(request). properties like is_read, address are not showing up there.
should they be? I'm trying to step through the code as I think it should work and sort out the library and I'm worried something is broken.
Probably won't get a chance to look till a bit later tomorrow but if you can post a snippet of the python code you're running too I will (I'm not that familiar with i2cperipheral so the python code will help)
here's a gist of the code running on a pico to test. https://gist.github.com/im-redactd/1f53ad885fe108bf0bd5f56ba59db879
the other end is just another rp2040 board running an i2c scan for now.
Basically, you are right. The only restriction is that ring buffer storage type must be kept unsigned.
Otherwiese this approach fails. See the case #6 in the code below.
#include <stdio.h>
#include <stdint.h>
#include <stdbool.h>
int pop_unsigned(bool error)
{
if (error) return -1;
else return ((uint8_t)255);
}
int pop_signed(bool error)
{
if (error) return -1;
else return ((int8_t)255);
}
int main()
{
uint8_t u8_noerr = pop_unsigned(0); // (1) u8_noerr := 255 - ok
u8_noerr = pop_signed(0); // (2) u8_noerr := 255 - ok
uint8_t u8_err = pop_unsigned(1); // (3) u8_err := 255 - wrong
u8_err = pop_signed(1); // (4) u8_err := 255 - wrong
int i_noerr = pop_unsigned(0); // (5) i_noerr := 255 - ok
i_noerr = pop_signed(0); // (6) i_noerr := -1 - wrong
int i_err = pop_unsigned(1); // (7) i_err := -1 - ok
i_err = pop_signed(1); // (8) i_err := -1 - ok
return 0;
}
I'll try to take a look later today. Busy for a while this morning
Finally got around to finishing the manual cleanup of the .pylintrc patch so all the libraries in the bundle should be good
anyone know how i can get only the files required to build for the raspberry pi pico?
no problem! thank you
that's not a thing. if you're building circuitpython you have to pull down the repo since it's modular.
the official guide is here: https://learn.adafruit.com/building-circuitpython - since I'm doing exactly that right now I put together a TL;DR version of that to quickly spin up a dev environment in a fresh VM. linked here if it helps: https://github.com/im-redactd/circuitpython-dev
make fetch-submodules will avoid fetching the bulk of the broadcom SDK, saving a few GB (compared to running git submodule update and truff), but it will still fetch the ESP-IDF for example
hmm, is there not a "slimmed down" version or something?
how do I delete a majority of the submodules and only keep the ones required for rpi pico? is there a list of submodules required for it?
you could delete the other ports before fetching the submodules 🤷
so just delete the directories?
I'm pretty sure I've deleted all the folders under ports except raspberrypi and built for the Pico without problem. I probably did the delete after the fetch-submodules but I'm guessing it would work (and make the fetch-submodules faster) if you did the delete first
Not sure why the request would not show anything. Did you try creating just like device = I2CPeripheral (board.SCL, board.SDA, (0x40, 0x41)) not in the with and then call r = device.request() and do all this in the REPL?
If you're still having issues i'll find a RP2040 board and build it myself to see
hey if there's anyone around, I'd like to bring up again the bundle issue: the Circuitpython bundles are currently unusable. I have a fix, if we could have a look at it ?
https://github.com/adafruit/circuitpython-build-tools/pull/88
.mpy & .py are identical except for version number.
version = "1.12.2" in .mpy
version = "0.0.0-auto.0" in .py
Closing as being handled in 384 above.
Thanks for catching that mpy was uncompiled.
I can look at, do you need /want specific testing done with it? I'm less familiar with the build tools
Ideally local testing would be nice, especially if you can do it on linux
considering the changes, check that the bundles contain what they should, in case I missed something
So if I was building all the bundles I'd run this against a directory where I downloaded all the libraries? Just trying to figure out how to run it myself
you pip install -e . circuitpython-build-bundles (in a venv), checkout the bundle
run update-submodules.sh and the the same command run by the CI if I'm not mistaken
circuitpython-build-bundles --filename_prefix original --library_location libraries --library_depth 2 --package_folder_prefix "adafruit, asyncio"
I've utilized the nRF52840 Dongle (PCA10059) with nRF52 SDK (Segger) projects to use USB while regulating GPIO voltages at 1.8V. I'd love to use CircuitPython for an educational target, but I need to regulate the GPIOs to 2.5V.
I've noticed a curious issue, where the CP USB fails when the REGOUT0 is set below 3.0V. (It works fine at 3V0 and 3V3 settings)
https://github.com/adafruit/circuitpython/blob/main/ports/nrf/peripherals/nrf/nrf52840/power.c
Frustratingly, the Adafruit bootlo...
Where is the update-submodules.sh script from? I think I'm missing some repo to build all this
Ah okay I was missing the name of the adafruit bundle repo, never used/built it before... cloning
@jaunty juniper Success! at least it built without errors. What was happening before that this was fixing? I'll check it is not happening now
if you look at the current bundle from the zip, single file libraries .mpy files actually contain the python source
so for example neopixel.mpy is actually a python file
Just triple checking but they seem to be compiled mpy files now
that impacts all bundles and the learn guides project bundles
I ran it on windows linux and built fine for me so I'll approve it
thanks 👍
Thanks for the fix @jaunty juniper and testing @blissful pollen. I tested the PR branch as well and all seems good. I've merged that and made a new release of build tools. As far as I know the bundle build tonight should use the new one and tomorrows bundle should be fixed.
@blissful pollen same if I initiate it that way.
from i2cperipheral import I2CPeripheral
device = I2CPeripheral(board.GP5, board.GP4, (0x41, 0x40))
print(dir(device))
request = device.request()
print(dir(request))
only thing that request prints is class
That's strange cause as far as I see request is fully within the shared-bindings/i2cperipherial directory. So assuming the request isn't None it should have the dictionary with it
I'm building a samd21 board now just to see what it looks like
If you want to try to trace it the shared-bindings/i2cperipherial/I2CPeripherial.c file defines both I2CPeripherial and I2CPeripherialRequest
I'm looking on an ESP32S2 that I just happened to have hooked up
samd library has the same result.
@blissful pollen looking at the ESP32 implementation. it differs a bit from the samd in the is_address method.
I'm not entering that for loop so it never returns true. in the esp version they just return true since it supports only 1 address.
if I return true then I get the properties
I miss the RP2040 PIO channel 🙂
I'm trying to modify this function in supervisor/shared/filesystem.c to change the code.py to a custom code.py (supervisor/shared/code.py created by me). anyone know how I could do this?
static void make_sample_code_file(FATFS *fatfs) {
#if CIRCUITPY_FULL_BUILD
FIL fs;
UINT char_written = 0;
const byte buffer[] = "print(\"Worked!\")\n";
// Create or modify existing code.py file
f_open(fatfs, &fs, "/code.py", FA_WRITE | FA_CREATE_ALWAYS);
f_write(&fs, buffer, sizeof(buffer) - 1, &char_written);
f_close(&fs);
#else
make_empty_file(fatfs, "/code.py");
#endif
}
in the same directory there is a code.py
i want to read the contents of it into buffer
FILE *f = fopen("a.txt", "rb");
fseek(f, 0, SEEK_END);
long fsize = ftell(f);
fseek(f, 0, SEEK_SET);
char *buffer = malloc(fsize + 1);
fread(buffer, fsize, 1, f);
fclose(f);
buffer[fsize] = 0;
this is my current implementation
but how do I port it to the rpi pico so I can add it to the filesystem.c?
you would need to make your file into a C structure that you can include, or have some pre-processing that does that
remember the C code is compiled it is not run here, there is no such thing as "supervisor/shared/code.py" when the code is later run on the board
oh yeah.. you're right, what preprocessing would I need to do then?
hmmm I don't know
the simplest is to put the whole content of the file into a string
but what do you want to do exactly ?
is there a python or c library that converts a file into a "c compatible string"? like for example,
print("test")
hello()
to
char buffer[] = "print(\"test\")\nhello()";
it would be easy to write such a python converter
well I'm trying to make a framework and I require a final uf2 to be compiled and generated with a custom code.py
does anything exist as of now? or would i have to create one?
one thing you can do is add your script to the frozen modules and just have a simple code.py that imports it
where do i add the script in the frozen modules?
you make a subdirectory in frozen, and look at the mpconfigboard.mk of the Circuitplayground for example to see how to add a frozen module
alright!
where exactly is this file?
ah, thank you!
by that I mean FROZEN_MPY_DIRS etc.
yeah, got it! thanks!
WARNING:root:Unexpected echo. Expected b'%Run -c $EDITOR_CONTENT\r\n', got b'raw REPL; CTRL-B to exit\r'
know why I'm getting this error in thonny?
A quick status update --
many thanks for Scott's getting-started instructions! I've successfully
created a build environment and a hollowed-out version of I2CPeripheral.c,
and have confirmed that I can now "import i2cperipheral" on a rp2040
feather. It doesn't do anything, but at least I've got a working build and
test environment.
There are 9 functions in the .c file that need to be re-implemented. Most
of the logic in there is dealing with "sercom".
atmel-samd/peripherals/samd/sercom.c...
WARNING:root:Unexpected echo. Expected b'%Run -c $EDITOR_CONTENT\r\n', got b''
i get this error after compiling it for the raspberry pi pico, the raspberrypi pico build that i downloaded worked fine
the Adafruit bundle is fixed, is there a way to do a manual release of the community bundle ?
will circup pick it up automatically?
yup
circup would still need a fix if you already have a bad mpy on the board
(but you can just delete it, then reinstall with circup)
This board seems to have a hardware issue that it needs to have TX power explicitly adjusted away from default for wifi to function (I've verified this in Micropython - won't connect at default power but after adjusting it works fine). I don't believe the circuitpython wifi library for ESP32 has a runtime setting for this so it might have to be set in board.c
This board seems to have a hardware issue that it needs to have TX power explicitly adjusted away from default for wifi to function (I've verified this in Micropython - won't connect at default power but after adjusting it works fine and a similar caveat exists in Wemos' arduino documentation). I don't believe the circuitpython wifi library for ESP32 has a runtime setting for this (Micropython has sta_if.config(txpower=xxx) but an equivalent does not appear to exist in Circuitpython) so it ...
Is there a way for curcup to install the py version instead? It was actually useful having quick access to the source
👍
I'm not sure if possible / how to trigger it manually. But I've updated and released NVM_Helper which is in the bundle so it should auto generate one tonight.
nice, we'll be good then 👍
Hi, I was thinking again about this issue and the QWIIC link being dependent on the promicro-rp2040's power stage, I was wondering if it could be a "transient current" issue at the time we turn on the display (while the charge pumps are loading to generate the required 12V).
How could I test this hypothesis?
I had a look at the FAN5331 datasheet and its current limit during startup is 1A but the [promicro's RP2040](https://cdn.sparkfun...
CircuitPython version
Adafruit CircuitPython 7.3.0-dirty on 2022-06-19; FeatherS3 with ESP32S3
Adafruit CircuitPython 7.3.0-dirty on 2022-06-19; ESP32-S3-DevKitC-1-N8R2 with ESP32S3
Code/REPL
import ssl,wifi,socketpool
import adafruit_requests as requests
from secrets import secrets
wifi.radio.connect(secrets["ssid"], secrets["password"])
socket = socketpool.SocketPool(wifi.radio)
https = requests.Session(socket, ssl.create_default_context())
TEXT_UR...
CircuitPython version
Adafruit CircuitPython 8.0.0-alpha.1-13-gd0953e8f8 on 2022-06-19; ESP32-S3-DevKitC-1-N8R2 with ESP32S3
Code/REPL
import ssl,wifi,socketpool
import adafruit_requests as requests
from secrets import secrets
wifi.radio.connect(secrets["ssid"], secrets["password"])
Behavior
The ESP32-S3 Devkit will hard crash to safe mode when the wifi.radio.connect call is made. CP 7.3.0 doesn't seem to have the same issue.
Description
...
I dropped back to the previous repository tag 8.0.0-alpha.1:
Adafruit CircuitPython 8.0.0-alpha.1 on 2022-06-19; ESP32-S3-DevKitC-1-N8R2 with ESP32S3
and wifi.radio.connect did not cause this crash.
Worked just a few days ago, but when using update script, I get this message:
There was a problem: local variable 'loc' referenced before assignment
It has always worked before, and I ty to keep everything up to date... so I am not sure what has changed.
This is the message in full:
"C:\Users\xyz\Desktop>circup update --all
Found device at E:, running CircuitPython 7.3.0.
There was a problem: local variable 'loc' referenced before assignment"
Any ideas?
Forgot to add the script it reads:
pip install --upgrade circup
circup update --all
Like I said, worked 2 or 3 days ago, so wondering what changed.
Hi, thanks for reporting. This is a bundle and circup issue. See https://github.com/adafruit/circup/issues/146
The bundle issue is fixed, and the Bundles have been re-released.
Unfortunately you'll have to manually delete the libraries, and reinstall them.
You can automatically install the libraries used by code.py like this:
circup install --auto
As well as by any other file on the board:
circup install...
Community bundle released, now all that remains is single-file libraries that were released during the bug to their own repo I assume
@jaunty juniper if it's convenient for you please file a bug saying we need tests of the script that led to these problems and assign it to me. It should be doable. (I'm mobile right now or I'd do it myself)
CircuitPython version
boot_out.txt reports --> Adafruit CircuitPython 6.2.0-beta.2-1233-g38015b6ca-dirty on 2022-06-16; Pimoroni Tufty 2040 with rp2040
Board ID:pimoroni_tufty2040
Note, I'm not convinced that the CircuitPython is 6.2.0, as this repo is only 37 commits behind adafruit:main
Repo for custom build: https://github.com/ZodiusInfuser/circuitpython/tree/tufty
Code/REPL
import time
import board
import displayio
import terminalio
import ve...
Hey there,
Is anyone currently working of or thinking about this enhancement? I'd like this feature for a BLE to Ethernet gateway I'm working on.
If there is anything important I should know about the current status of this feature before I dive in, please let me know. Thanks! :)
Thanks for looking at this! There is commented-out code from the nRF52840 implementation that is in the base routines needed.
I don't remember if there is substantial extra stuff that needs to be implemented to do the bookkeeping necessary for HCI. For peripheral mode, I had to write a lot of new code, which is mostly in att.c. The HCI interface is rather low-level in many ways, and assumes a "smart" caller that handles a lot of the state.
@slender iron Curious if you have thoughts about how best to store the pages that will be served for the web workflow? I've got a local project with the /edit/ page HTML and a python build script that minifies it. I'm copy/pasting it from there into the string in the core code.
Should I make a repo from that project to have a central place to house the served pages? Or those could go in the core repo somewhere, or elsewhere?
I think there is some opportunity for an index page served at the root to contain some welcome message and link to the /fs/ page as well as links to documentation and other helpful resources.
like an issue on the built tools repo to add tests to the CI ?
The tools repo is where the test would need to be I think
So that it can find a problem before the pull request is merged
I've seen this some too. It's a TG1 WDT reset. I haven't figured out why.
I'd have a python script generate a c file that gets compiled. Kinda like get_display_resources.py iirc
in tools
I was thinking we could do a new repo for the "online" files and we can direct a subdomain of circuitpython.org to it
maybe local.circuitpython.org
<@&356864093652516868> Just a reminder that the meeting is tomorrow. 25 hours from now. Today is the observation of Juneteenth here in the US.
I see. So a function like this https://github.com/FoamyGuy/circuitpython/blob/6eaa1e5adbc74ff07b63678a555c1c370ef69e9c/supervisor/shared/web_workflow/web_workflow.c#L559-L566 could get refactored to it's own C file and that file can be generated by a script that will minify and/or gzip the page and embed it within the function.
should the un-minified .html file live inside of tools/ with the script or somewhere else?
okay, I'll keep it in it's own place for now. I will tinker with it some more later on today.
thanks!
<@&356864093652516868> Just a reminder that the meeting is tomorrow. 24 hours from now. Today is the observation of Juneteenth here in the US.
backport #6494 and #6497 to 7.3.x: cache key fix
This will definitely be a test of my firmware skills, but I'm willing to try! :) I'm wrapping my head around the circuitpython structure and going to be focusing at first on getting it to compile for a CLUE board and also for an RP2040 (which will be communicating with an AirLift Featherwing for BLE).
Would you mind commenting on the following things for me?
- Could you link more specifically to the commented code you're referring to for the nRF52840?
- I've noticed that on my CLUE boa...
CircuitPython version
Adafruit CircuitPython 7.2.4 on 2022-03-31; Adafruit Matrix Portal M4 with samd51j19
Code/REPL
>>> import displayio
>>>
>>> test = displayio.Palette(10)
>>> test.make_transparent(120)
>>> test.is_transparent(120)
True
>>> for i in range(len(test)):
... print(test.is_transparent(i))
False
False
False
False
False
False
False
False
False
False
>>> test.make_transparent(3)
>>> for i in range(len(test)):
... prin...
The commented-out code is in https://github.com/adafruit/circuitpython/tree/main/devices/ble_hci/common-hal/_bleio, in various files, most notably att.c and Connection.c, but may also be elsewhere.
The nRF52840 implements both peripheral and central mode just fine. If you can use an nRF52840, such as on the CLUE, or an nRF52840 Feather, then it will save a lot of work here. We won't hold it against you if you want to go this way :smile: .
NINA-FW should have what you need. HCI is m...
you may need a delay while the display powers up. also reset may need to be connected
this featherwing is REALLY not designed for anything other than a feather, please use a 128x64 SSD1306 QT breakout instead!
https://www.adafruit.com/product/938
Backport #6346 to 7.3.x so we can update the CP library.
I've noticed a curious issue, where the CP USB fails when the REGOUT0 is set below 3.0V. (It works fine at 3V0 and 3V3 settings)
https://github.com/adafruit/circuitpython/blob/main/ports/nrf/peripherals/nrf/nrf52840/power.c
This code was added because we encountered cases where all of flash was erased (set to all ones), which caused the I/O voltage to be 1.8v. But if the UICR bits are set specifically to a separate value, and the word is not all ones, this code will not be exercised.
...
The CPX CI failures here should be fixed by #6508.
I’ve changed this code to set it to 4 (3.0V still works), and also 3 (2.7V CP boots, even runs Boot.py, but fails to enable USB interfaces and halts.)
What I’d like to do is run the system at 2.4V and still have USB - which is something that can be done using Segger and nRF5 SDK.
I’m starting to wonder if there’s something the TinyUSB implementation is looking for that causes it to be dependent on the main supply regulation. Nordic documentation clearly shows the USB regulation is se...
I've done some more scoping tonight, and best I can tell, the data being sent to the display is clean. Correct number of bytes sent, correct pattern. The only difference between the one that works and the one that doesn't is one receives 0xffe0 for each background byte (yellow in 16bit), and the problem case receives 0xffff.
This puts it back to being something wrong with my initialisation, but as I said before, it matches what we do in C++ and MP. Could it be that the initialisation i...
Since the init looked correct, as a test I tried reducing the parallel bus speed from 10MHz down to 1.25MHz, and that seems to remove the ghosting, suggesting there's some timing issue trying to drive it faster (not sure if on the display side or mcu side).
I would consider this fixed, were it not for the random white pixels it introduces into the last column of the on-screen REPL, and the fact it's well below the speed needed to achieve 60Hz.
What is the wiring to VDD and VDDH? That would determine "high voltage" mode.
Here's the updated test script - the main change is that we don't need to wrap the pins in a DigitalInOut instance. Also the discharge pin is kept as open drain while discharging so that discharging can complete fully.
import board
import time
from digitalio import DriveMode
discharge = board.DISCHARGE_3V3
charge = board.ENABLE_3V3
def disable3v3(drain_duration=0.2):
discharge.switch_to_output(False, DriveMode.OPEN_DRAIN)
charge.value = False
time.sleep(dra...
I am not so sure this is TinyUSB but you might look at https://github.com/adafruit/Adafruit_nRF52_Bootloader, assuming you are using that bootloader.
I built the new PR files into the CP 8.0.0-alpha.1 tag and ran Mat's new script and the voltage now swings between 3.3V and 0V, with or without an LED attached to the 3v3 output.
The PCA10059 I'm using has not been modified, it's operating in the "high voltage" mode.
Yes, I've using the bootloader. I've measured the voltages and I can see it's regulating at 1.8V...but the USB works fine.
After flashing the CircuitPython code, and can verify it changes the regulation to 3.3V. However, I see the USB fail below 3.0V setting.
I'll look at how the USB is implemented differently. It might point to a clue.
The size of the C stack for the main FreeRTOS task, CONFIG_ESP_MAIN_TASK_STACK_SIZE, is set to 8kB here:
https://github.com/adafruit/circuitpython/blob/d0953e8f845a7544a27bea92bbcd533f0a84d493/ports/espressif/esp-idf-config/sdkconfig.defaults#L297
(Confusingly, note there is also an CONFIG_MAIN_TASK_STACK_SIZE, whose value does not seem to affect this.)
If I change this to 16384, then I don't get the error above. The re library we are using uses recursion, and suffers from this st...
Hi @tulip sleet,
I'm the one trying to wrap my head around the BLE central implementation for HCI. 🙂 I have a quick question about CircuitPython code in general: how do the C function names get translated into Python methods when CircuitPython is compiled? For example, in devices/ble_hci/common-hal/_bleio/Adapter.c I was able to alter the message that is raised with mp_raise_NotImplementedError on line 467, and compile the code, put it on my Feather RP2040, and see the message returned when I try to call adapter.start_scan() from the REPL. But I'm still unsure of how the C function common_hal_bleio_adapter_start_scan gets turned into the Python method start_scan().
Sorry if my questions are rather basic.. but I really want to dive into this stuff more deeply. Thanks for any guidance you can give me!
The Python interface is in shared-bindings/. The routines there call the common-hal routines, which are either in port/*/common-hal, or shared-modules/, or in the case of HCI, in devices/.
Thanks! I'll study that
also check out https://docs.circuitpython.org/en/latest/, and these subcategories in the left sidebar
hey y'all! I was hoping to join the meeting today (tonight for me) but the wifi at this place we're staying isn't up to the task of voice calling. I've had a great big vacation with my spouse over the last few weeks but now I'm looking forward to picking up my Adafruit work again next week. Group hug, as I also wrote in the meeting notes.
get that last piece of vacation in! see ya!
the fun's all done, it's just packing & catching flights now
the last pastry 🙂
they do make a good pastry all over europe
Thanks for testing again @RetiredWizard - the PR is ready to merge. 🎉
There was a meeting reminder 24H ago, but not recently (AFAIK).
<@&356864093652516868> Weekly meeting in about 7 minutes! Please add any hugs and updates to the notes doc before we get started! Thanks! https://docs.google.com/document/d/18sH6UlmzVw8ObNTyvUt9biDsBoT6tYAAZ9LwRwhQXow/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for June 21st, 2022 This meeting is 24 hours later than normal on TUESDAY due to the US holiday in observance of Juneteenth. Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go thr...
Happily lurking again this week! Hope everyone is doing well. 🥧
text only this week
@slender iron I need to catchup on the Web workflow... at one point I was looking for a CP web server (to host a single file like this: https://learn.adafruit.com/wordle-personal-esp32-s2-web-server) but failed. Will it be possible to have a web server for CP code purpose? Any way to interface, like CGI?
@thorny jay I haven't thought about hooking user code into it
it will serve html from the filesystem by default
It could be "fun" to click the web page and change a GPIO value. 🙂
it's been june-uary here 🙂 🌧️
I was just going to roll with January, @idle owl
27th month of March 2020 😕
The Hallmark channel is preparing for it to be December, so it's all okay.
No joke, I saw Christmas holiday decorations in my local arts & crafts store.
And I’m here for it because I love Christmas 🎅
But I do enjoy Halloween 🎃
And Thanksgiving a lot
So many great days for great circuitpython powered hacks
Santa will sunburn pretty badly making the rounds in July.
But he'll love the southern hemisphere this time of year.
Which always made me wonder why Santa did the whole earth rather than just waiting until winter in each hemisphere 🙂
Save time delivering presents, especially since like 80% of the earth’s population lives north of the equator
This seems to be text only day. 😦
I was going to try to listen but forgot my headphones 😢
Octopus, I had Octopus G&W!
🦷 time for me! thanks for running the meeting kattni!
Thanks everyone -- another meeting in the bag 🙂
thanks for hosting Kattni
Is that a record time?
CircuitPython meeting speedrun, 100% no-glitch.
time is wibbly-wobbly anyways
CircuitPython version
Adafruit CircuitPython 7.3.0 on 2022-05-23; Adafruit Metro ESP32S2 with ESP32S2
Board ID:adafruit_metro_esp32s2
Code/REPL
Not working esp32-2 repo
https://github.com/CTGControls/CTG_DPS_Python_Ad4116_Adafruit_MetroExpressEsp32S2
Working PI Pico repo:
https://github.com/CTGControls/CTG_DPS_Python_Ad4116_RaspberryPiPico
Behavior
I get:
get_register: got [ 0x80 0x00 0x54 ] from reg [ 0x30 ] using command [ 0x70 ]
...
I have not test without using "adafruit_bus_device.spi_device" as you asked me to in Discord, but I will in the next few days.
The AD4116 datasheet says:
DIGITAL COMMUNICATION
The AD4116 has a 3-wire or 4-wire SPI that is compatible with
QSPI™, MICROWIRE®, and DSPs. The interface operates in SPI
Mode 3 and can be operated with CS tied low. In SPI Mode 3,
SCLK idles high, the falling edge of SCLK is the drive edge, and
the rising edge of SCLK is the sample edge. Data is clocked out
on the falling and drive edge and data is clocked in on the rising
and sample edge.
Given that it says it ope...
@dhalbert The project now works with this non-DMA version 🙏 Thank you so much for making the bootloader for me. And the Error response to command issue is managed by resetting ESP and reconnecting to wifi on exceptions.
I will hang on to this no-DMA version. It looks like you fixed it for the next release, so I'll plan on upgrading.
I was just going to write to you. I fixed it in a different way, which I think will work too. See https://github.com/adafruit/circuitpython/pull/6498 and https://github.com/adafruit/samd-peripherals/pull/42. Try the build artifacts: https://github.com/adafruit/circuitpython/actions/runs/2516315728. Scroll down to see the artifacts. Unzip the file for your board and get the .uf2 you need.
This is rather interesting because many of the high end Analog Device chips do use mode 3 only. Such as:
- AD411x (AD4111, AD4112, AD4113, AD4114, AD4115, AD4116)
- AD717x (AD4172, AD7173, AD7175, AD7175, AD7176, AD7177)
Others use both Mode 0 and Mode 3. Such as:
- AD3552R (give different results if you use one mode over the other)
It looks like AD is using Mode 3 for most of there newest chips as well. I normally always use mode 3 if available as I have seen better results.
As...
It's great to see that a fix for this has already been merged - very impressive! I'm guessing from the 7.3.x milestone that there'll be another 7x release before 8; does anyone have a rough idea of when that might be? Many thanks.
@dhalbert Is planning a 7.3.1 soon. Not sure if it'll have this fix. You should be able to use "Absolute Newest" builds just fine. Nothing major has happened on main yet.
Increasing the stack size sounds good to me.
CIRCUITPY_DEFAULT_STACK_SIZE doesn't impact it because the IDF is managing the stack size for us and I never connected the two.
Going from 8k to 24k seems a bit much to me but 16k would be fine. Remember that we don't use the external RAM for the IDF at all, only the MP heap.
Not going to block this PR but you could use the common_hal APIs here to set the pin value. That'd be simpler and ensure that any future DigitalInOut state is updated. (It doesn't look like any state is stored currently.) Feel free to open another PR for it.
@kstillson I'd recommend starting with: https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/common-hal/busio/I2C.c It already interfaces with the I2C peripheral in the RP2040.
SERCOMs on SAMD21 are generic serial communication peripherals. They do SPI, I2C and UART. Modelling after that code may be more confusing than clear.
What reason does safe mode give for the problem?
This is fixed thanks to @Neradoc
My intention was to have .color_count available as len(palette). However, it looks like there is a bug: https://github.com/adafruit/circuitpython/blob/main/shared-bindings/displayio/Palette.c#L213= Refers to group_unary_op when there should be a palette version.
I don't think I want to expose transparency_index either. I'd rather support multiple transparent colors.
You mean after the reboot, I didn't realize it saved any useful information through the boot. I just reflashed and tried it again, here's the safe mode message:
Adafruit CircuitPython 8.0.0-alpha.1-13-gd0953e8f8 on 2022-06-19; ESP32-S3-DevKitC-1-N8R2 with ESP32S3
>>>
soft reboot
Auto-reload is off.
Running in safe mode! Not running saved code.
You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Crash into the HardFa...
It's strange though, a couple days when I was doing this, it was crashing into safe mode every time. Today, it's still crashing the board every time but it's often coming back to a clean boot (no safe mode).
Thanks for filing an issue!
One thing I did notice is that CPy draws a row at a time, whereas our C++/MP code draws the full screen. I wonder if there is a way to make CPy draw the full screen at once too to speed it up to the display's native 60Hz?
CP does one row at a time to reduce the memory needed. It actually track dirty rectangles and only sends them. Unfortunately, the terminal tends to dirty most of the screen. The code will split large dirty rectangles into smaller ones so t...
Enable UF2 build artifact for Swan R5 - Swan R5 support in tinyuf2 has been merged to main in and will be available in the next release.
The nightly build of the bootloader is available at https://github.com/adafruit/tinyuf2/actions/runs/2517588142
Thanks - I did wonder about that, but like you, I checked that all the state was coming from the peripherals themselves. +1 to using the common hal APIs being cleaner and won't cause any surprises with future mods to DigitalInOut state.
@idle owl just finished listening to the meeting! I'm happy to own the Dependabot introduction. I think the best implementation with the fewest hiccups is to pin major revision as I put it in the notes.
Changing a library to use features added in minor revisions would mean changing the requirement manually anyways like it does now.
But I'm definitely happy to take this on
Great! Then I'm ok with it. Let's start with a small set, as usual, and see how it goes. Maybe logging and the libraries involved with logging would be a good place to start.
@lone axle you should check out code.circuitpython.org too. It uses codemirror 6 for editing
I will check it out. I looked into codemirror first but it seemed to need a build step. Ace was quicker to jump in and use, but def open to any of them.
Do you know what the effective limit of the size of thing that can be sent to _send_chunk() could be? As I added more features it eventually got to a point where the page doesn't load fully any more in the browser. I need to figure out how to troubleshoot it better, but I'm thinking it's not receiving the full page if it's too large and it gets sent all in one chunk. Does that seem like a reasonable assumption? I tried briefly splitting to multiple _send_chunk() without success but intend to tinker with it some more still.
Also, @tulip sleet to your point we could use Dependabot for checking if Blinka updates which I assume is synonymous with CPY changes
So like pin libraries to the major version
e.g., Adafruit_Blinka==7.*
I don't understand what you mean if Blinka updates. I was thinking about building separate 7.x and 8.x bundles, for instance, based on certain versions, but I didn't think Dependabot would help that situation. E.g., we add or remove some API, and want to hold back the change from the 7.x bundle but not from 8.x. For example, I made Pin hashable in 8.x. That could be used in the CP library, but wouldn't work on 7.x. Would also have to hold it back when we update the frozen libs in, say, 7.3.x builds
Not sure what value that would give compared to the dependent libraries (my thoughts and intention were what @idle owl described, sorry I wasn't at the meeting!)
Ah I see, got it
i was just confused during the meeting about the purpose
Actually, on that note, the only remaining thing to think about is whether we want to pin min versions of Adafruit_Blinka. There's definitely value in it, but it also means a looooot of PRs to sift through
we could do that on demand when we make some Blinka change that requires it
@lone axle I don't know of a chunk size limit
That's true, I could explicitly ignore it in the config file
but blinka versions can be required by the pip mechanism, hmm, hmm. I'd say let's wait for a use case
Since they all rely on Blinka, it should be easy enough to change it via a patch so I don't think it's important to have to get it perfect at initial introduction either.
Understand your logic. Multiple transparent colors in the palette would be ideal, especially if represented by a None value like other displayio objects.
I will backport this to 7.3.x. Sounds like a good thing to get in.
Backport #6486 to 7.3.x
Did the serial output that shows on built-in displays by default get scaled up for some builds recently in main branch? The text on my Titano is larger than I recall it I think.
Ok, I have some alpha code that does step accurate stepper control using the RP2040 PIO. Right now the state machine outputs steps to a stepper driver with the option of DIR control using either the state machine or manually with digitalIO. There is an option to enable a counter by tying the output to another pin, which can independently verify step counts. Finally, a jmp_pin can be configured to act as a limit switch which will immediately halt the step output (and require a state machine re...
Backport #6495 to 7.3.x
[adafruit/circuitpython] Pull request opened: #6514 increase ESP main task stack size from 8k to 16k
Fixes #6404.
Increase C stack size for Espressif build from 8kB to 16kB. In particular, #6404 notes a case where re, which uses recursion internally, reached the 8kB stack limit.
This adds bounds validation for the palette_index argument for make_transparent(), make_opaque() and is_transparent() functions on the Palette object.
Resolves: #6507
Oh neat, you can actually use Dependabot for tracking revisions of things in the YAML workflow files (I think)
Probably not what we want, though. Probably would want to patch it as opposed to sift through hundreds of PRs

Add pin definitions for busses:
- board.I2C and board.STEMMA_I2C go to the stemma QT port.
- board.UART goes to the RX and TX pins.
- board.SPI goes to the SCK, MISO and MOSI pins, which despite not being on the silkscreen were already defined with those names and are on the pinout card.
Update frozen libraries again, for 7.3.1.
@slender iron I made a bunch of 7.3.x PR's (mostly backports) which I think are everything we would want for a 7.3.1 release.
What are people's thoughts on getting a PR for a minor revision update? Might be nice to trigger optimize/update a library when new additions are made, but I feel like those dependents rarely change when it happens. My vote is to pin to major versions, and only pin to minor versions (manually, no auto-PR) when updates occur that require them like we already do (i.e., using a feature that was introduced in a dep_module v4.1.0 would go from dep_module~=4.0 to dep_module~=4.1
LIke you say, a minor revision update would not force code that used the library to change. If a specific enhancement was done, then we probably already have the use case in mind, and would know the reason for the update. But finding other forgotten possible updates is something that would have to be done manually. But I think minor version updates happen so often, there would be too many PR's.
Hi Scott-
Thanks to your excellent push in the right direction, Ryan (that's
"im-redactd") and I have made some okay initial progress (
https://github.com/kstillson/circuitpython/blob/main/ports/raspberrypi/common-hal/i2cperipheral/I2CPeripheral.c
).
We did manage to find busio/I2C.c, and we (well, Ryan mostly) have gotten
things far enough along that a client sees the server at the correct
address during an I2C scan. For reasons I haven't had the cycles to quite
figure out yet, we get tim...
The font should have gotten denser. There were two extra rows of pixels in the font that we don't use. It was also rearranged.
k, starting to look now
#6512, #6513, #6514, #6517. I wrote release notes already.
I'd rather not do this in 7.3.x because it could impact the number of sockets we can have open.
I'd rather not do this in 7.3.x because it could impact the number of sockets we can have open.
np, I will move it forward
Huh, weird that it only safe modes sometimes. The next debugging step would to do a DEBUG=1 build and see what the debug UART has for a backtrace. Want to try that?
Thanks for adding these checks! Mind using mp_arg_validate_int_range instead? That way you won't introduce another string to be translated.
I'm glad you are making progress. Don't worry about getting laughed out of town. We appreciate contributions to CircuitPython and are happy to help refine things to get them merged in.
67 checks failed due to xtensa cache key.
@proven garnet Thank you for looking at the duplicate code check failures! I am unsure whether anyone has the cycles to do a full refactor on those libs. I think for now, we should rename these issues to "Code fails duplicate-code check, consider refactor" and then add the duplicate-code back to the pre-commit-config.yaml file. And, add a note to each of the issues saying something like, "A refactor is needed here. When complete, remove the duplicate-code disable from the pre-commit-config.yaml file."
Add duplicate-code disable only to these four libraries.
Most of my stuff I'm doing now is feature additions, so since this is probably higher priority I can shift over. I don't think it'll take me too long, but definitely a little bit to do.
Refactoring can be pretty beastly. I'm not sure that's where we want you to focus your time. I'm almost certain if I look into it, the answer will be to punt it.
I appreciate the offer!
Throwing a 🔧 into it.... Also they would all need to be backwards compatible. Heh.
Either way, I think continue doing what you've been doing. And if you could do the stuff I suggested ^^, that would be amazing. With the issues updated, we at least know where it needs to happen, etc, once we do have cycles.
For sure, I'm on it!
Thank you!
@lone axle did you start a landing page for the CP web workflow yet?
@idle owl can I just force push the previous commit to main? Or do you want to preserve the history of removing and readding?
I mean, force pushing will still leave a history trail. I think that's fine. Easier than the alternative. As long as that was all that was in the previous commit.
Sorry I think I meant reset main to the previous
Nope, not a landing page. Only edit.
Oh right. Either way.
My git terminology is limited to Commit, Push, and There Be Dragons
I remember being there. My list of what I know is longer, but I still have a lot of Dragons.
I need to try out code.circuitpython.org still. I haven't used that on a BLE device yet. On the edit page I was working on I added a "help" button that will open up user to a docs page searching for whatever they have highlighted in the code. It seems like a nifty integration to get help with a specific part of your code quickly. Maybe eventually code.circuitpython.org can have a similar helper feature.
speaking of web workflow, I've been trying to hide blinka and the status bar with code like that and I get problems. It looks like supervisor_start_terminal called by reset_terminal doesn't resize to the dimensions passed, but reserves a line for the status bar
code like that works in 7.3.0
for pos in range(len(board.DISPLAY.root_group) - 1):
board.DISPLAY.root_group[pos].hidden = True
tile_height = board.DISPLAY.root_group[-1].tile_height
delta = board.DISPLAY.height % tile_height
supervisor.reset_terminal(board.DISPLAY.width, board.DISPLAY.height)
board.DISPLAY.root_group[-1].x = 0
board.DISPLAY.root_group[-1].y = - delta
@idle owl repos reset, and I templated what I'll put for the issue comment in the EPD repos issue
in 8 there's an empty line or when playing with possible values for height or y, other kind of issues like the live typing not showing up (screen updates only on enter)
Great!
@jaunty juniper ya, it will always have the title bar afaik. I didn't test the reset
Hey @proven garnet Is there any chance that you may have deleted the commits removing the duplicate-code check from the libraries that it failed on? I recognize this is a kinda weird question but something really odd happened with some of the libraries that we opened issues on (the commits kinda just disappeared from the main branch)
Also @idle owl ^^
@slender iron when you have time, I have a q about the CIRCUITPY_MODULE espressif wroom.c and wrover.c files. I was making something similar for the ESP32, but the pins mentioned in never_reset_module_internal_pins() don't seem to correspond to the pins mentioned in the module datasheets.
Yes.
That is basically what happened.
There's a discussion above.
Ah ok. That confused the heck out of me
@tulip sleet I'm around now but not sure I'll be able to remember 🙂
like for the WROVER
void never_reset_module_internal_pins(void) {
// SPI Flash
common_hal_never_reset_pin(&pin_GPIO27);
common_hal_never_reset_pin(&pin_GPIO28);
common_hal_never_reset_pin(&pin_GPIO29);
common_hal_never_reset_pin(&pin_GPIO30);
common_hal_never_reset_pin(&pin_GPIO31);
common_hal_never_reset_pin(&pin_GPIO32);
}
but the datasheet says
Ah ok now I see it. Thanks for clearing that up for me
maybe the module pin number got mixed up with the GPIO number??
if so, I wonder why it works anyway, maybe it's not necessary
I will go back in time with git to see if it was ever changed
@proven garnet Please add your template reply to the PyBadger issue as well. Thanks!
@tulip sleet what datasheet are you looking at?
the wrong one :), ha, hold on
wrover => esp32s2 wrover
I was looking at ESP32 wrover (bad googling)
so 26-32 are the module pin numbers, corresponding to GPIO33-38
so the q still holds, I think
Done!
@slender iron I think the pin labels are not the QSPI pins, despite FSPIHD, etc. labels. Pins GPIO27-GPIO32 are not exposed. OK.... sorry, this was really confusing. I think I understand now.
The ESP32 modules are quite different. The internal schematics are sort of incomplete
np
[adafruit/circuitpython] New tag created: 7\.3\.1
Sure, I should get a chance to take a look at that this evening.
Due to supply chain issues I am changing from the MX25L51245G 64MB flash to Winbond W25Q512JVEIQ, and I think I wrapped my head around editing the definition files for the flash chips... but I am having troubling knowing where to actually add this file so I can compile it. It looks like these use to be in the devices.h file under supervisor, now it seems like it is under nvm.toml
What seems unclear is when defining this in the board file, I do not see how this references the toml files because naming does not match.
you would put it right next to nvm.toml/flash/winbond/W25Q128JVxQ.toml like "W25Q512JVxQ.toml" I assume ?
and then EXTERNAL_FLASH_DEVICES = "MX25L51245G, W25Q512JVxQ"
One reason in a recent build "EXTERNAL_FLASH_DEVICES = GD25S512MD" worked but I do not see where that directly references with toml files. And it does not exist in devices.h
So you can put multiple flash options?
it's there: nvm.toml/flash/gigadevice/GD25S512MD.toml
yup, many boards have different options for flash, especially with the chip shortage
it finds the chip by SKU inside the {technology}/{manufacturer}/{sku}.toml path
did you type 3 x or something ? bot's a little trigger happy
Not sure what happened.
When I referenced the flash in the past it did not need quotes, is quotes needed only when mulitple are suggested?
I don't think the quotes are needed, but don't take me as a reference on makefiles, I just look at the other boards, what's there should work
❯ ag "EXTERNAL_FLASH_DEVICES = .*,"
ports/stm/boards/stm32f411ce_blackpill_with_flash/mpconfigboard.mk
8:EXTERNAL_FLASH_DEVICES = GD25Q16C,W25Q64FV,W25Q32JVxQ,W25Q64JVxQ
ports/nrf/boards/challenger_840/mpconfigboard.mk
9:EXTERNAL_FLASH_DEVICES = "W25Q16JVxQ,W25Q32FV"
ports/raspberrypi/boards/arduino_nano_rp2040_connect/mpconfigboard.mk
10:EXTERNAL_FLASH_DEVICES = "AT25SF128A, IS25LP128F"
...
one of them doesn't use quotes, some don't have spaces 🤷
Thanks, I will look at some for reference. I appreciate you clarifying, trying to make this update quick so I can test a new build and needing to quickly dump a new memory chip on has been a big distraction.
Just need to figure out where to modify this in my build cycle. Looks like nvm.toml is sub module'ed... I need to dump an edited file into the cloned repo before the build
yeah the downside of nvm.toml is having to PR two repos
Yeah, I need to replace a file in my dockerized build system
@slender iron @lone axle hey I might look into making a circup-like web interface to plug into the web workflow, choosing a library or reading code.py (or others), finding dependencies, and offering files to install. I already made a "bundler" that does most of that but makes a zip https://www.neradoc.me/bundler/ (though it required hosting the bundle zip on the same server, due to CORS restrictions)
Nice! I haven't tried it yet but I think you could PUT request .mpy library files into the lib dir similar to the way the plain text files are saved.
Anybody know where the NVM toml files are when cloning and getting sub modules? I need to dump a custom toml for testing and not sure where to put it
in data/nvm.toml
oh I cut the data/ from the paths I gave earlier, I meant to give them relative to the CP root
NP thanks for being here, saving me a lot of grief.
Automated website update for release 7.3.1 by Blinka.
I tried building CP with the DEBUG=1 flag for the ESP32S3 Devkit and got a Too Little Flash message. Is there something else I need to do?
`Successfully created esp32s3 image.
5665904 bytes used, -3568752 bytes free in flash firmware space out of 2097152 bytes (2048.0kB).
70 bytes used, 8122 bytes free in 'RTC Fast Memory' out of 8192 bytes (8.0kB).
4112 bytes used, 4080 bytes free in 'RTC Slow Memory' out of 8192 bytes (8.0kB).
16383 bytes used, 16385 bytes free in 'Internal SRAM 0' out of 32768 bytes (32.0kB).
212148 bytes used, 213836 bytes free in 'Internal SRAM 1' out of 425984 bytes (416.0kB).
0 bytes used, 65536 bytes free in 'Internal SRAM 2' out of 65536 bytes (64.0kB).
Too little flash!!!`
you can disable modules to reduce the size of the build
@jaunty juniper Okay, I'll give that a try, thanks
@tulip sleet + @onyx hinge + @slender iron : I am catching up on the fixes you have just done for https://github.com/adafruit/circuitpython/issues/6205 + https://github.com/adafruit/circuitpython/issues/6489 and just wanted to say THANK YOU!!!! I have been having sporadic issues with the Matrix Portal but always blamed myself for it. I can't wait to try out 7.3.1 and see how it behaves going forward. The best uptime I managed to see on it so far had been: ~19 days (27769 minutes)
I'm not sure how to pass the name as the last argument arg_name
I tried like this:
palette_index = mp_arg_validate_int_range(palette_index, 0, common_hal_displayio_palette_get_len(self)-1, "palette_index");
But I get build error this way. I found some usages of that function what pass names like e.g. MP_QSTR_usage but I'm not sure in the case of "palette_index" how to get this qstr object.
I have encountered this issue on a Pi Pico running version 7.3.1 (just installed); my boot.py in full is the following:
import usb_cdc
usb_cdc.enable(console=True, data=True)
My code.py is:
import usb_cdc
pos = usb_cdc.data.read(1)
I've found that if I start with a working code.py (e.g. empty, or with the read() line commented out) and then change it to the above, it works as expected. After that, a hard-reset will cause the behavior described in the firs...
So I've tried a few times but it's not initiating safe mode anymore. The crash still happens at the same point but I don't see anything that looks like a backtrace in the debug output.
I (39930) pp: pp rom version: e7ae62f
I (39930) net80211: net80211 rom version: e7ae62f
I (39940) wifi:wifi driver task: 3fce4ee8, prio:23, stack:3584, core=0
I (44866) system_api: Base MAC address is not set
I (44866) system_api: read default base MAC address from EFUSE
I (44876) wifi:wifi firmware v...
I think the build is failing because your fork is a ways behind the main branch. If you fetch the upstream, it may fix the build issues.
Thanks @kylefmohr this PR got old... thanks for the reminder.
@evildave666 and @kylefmohr should we split that WIFI item out into a new issue?
Frequently boards are made live without "all the things" working.
@evildave666 and @kylefmohr should we split that WIFI item out into a new issue? Frequently boards are made live without "all the things" working.
I had a short discussion today in discord with todbot and neradoc about how to possibly address it. It might be as simple as setting an esp-idf variable in the sdkconfig file in the board directory. CONFIG_ESP32_PHY_MAX_WIFI_TX_POWER might be the appropriate one to set.
Missing a declaration in mpconfigboard.h:
#define MICROPY_HW_NEOPIXEL (&pin_GPIO23)
Ah, it seems these MP_QSTR_ things can exist without being explicitly created previously.
Most instances I found using mp_arg_validate_int_range() were in constructor methods with arguments that were defined with MP_QSTR things. I did find one in TileGrid that seemed to be using an otherwise undeclared one MP_QSTR_tile and figured it was worth trying MP_QSTR_palette_index here to see if that would work and it did.
Ended up with this:
palette_index = mp_arg_validate_int_ra...
Looks like Dependabot has a bug handling comparable releases (~=) which is the best way to define requirements, so aside from building our own mini Dependabot it may be worth just holding off until it's patched.
Though it did occur to me during the search we could probably reduce our requirements manifest to one file that setup.py reads and uses similar to how it does with the readme
I have an example here
That would prevent instances where requirements.txt and setup.py get out of sync regarding dependencies, which I've seen occasionally
I only reviewed the last commit. Thanks!
Found some additional info about how these work here https://docs.micropython.org/en/latest/develop/qstr.html
Catch up to 7.3.1 release.
[adafruit/circuitpython] New branch created: merge\-7\.3\.1\-to\-main
Catch up to 7.3.1. This is frozen module updates, plus updating samd-peripherals (#6498). The other code changes in 7.3.0 -> 7.3.1 were all backports from main, so you don't see any code changes here.
[transferred from closed issue]
I have encountered this issue on a Pi Pico running version 7.3.1 (just installed); my boot.py in full is the following:
import usb_cdc
usb_cdc.enable(console=True, data=True)
My code.py is:
import usb_cdc
pos = usb_cdc.data.read(1)
I've found that if I start with a working code.py (e.g. empty, or with the read() line commented out) and then change it to the above, it works as expected. After that, a hard-reset will cause...
@nhedler-cubeworks What is the host computer, and what OS and OS version is it running?
@nhedler-cubeworks What are the host computer(s) and their OS versions? Thanks.
This needs to be tested, it's only compile-tested.
Reason 4 is Association Expired, which is probably routine. It should have tried to reconnect several times after that.
Windows 10 and some kind of Linux, maybe Mint? Two different systems.
[whoops, I intended to approve]
Thanks for adding these checks! Mind using mp_arg_validate_int_range instead? That way you won't introduce another string to be translated.
[adafruit/circuitpython] New comment on pull request #6518: Add board Silicognition LLC RP2040\-Shim
Hmm, seems the CI failed because some dependencies could not be installed?
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/libc/libcroco/libcroco3_0.6.13-1_amd64.deb Could not connect to azure.archive.ubuntu.com:80 (20.106.104.242), connection timed out [IP: 20.106.104.242 80]
E: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/pool/main/g/gettext/gettext_0.19.8.1-10build1_amd64.deb Unable to connect to azure.archive.ubuntu.com:http: [IP: 20.106.104.242 80...
[adafruit/circuitpython] New comment on pull request #6518: Add board Silicognition LLC RP2040\-Shim
The CI failures are network issues for a random build. We don't need to re-run.
The single build failure looks like some kind of CI problem, unrelated to the PR.
Morning everyone,
Having so difficulty getting my Custom PCB to boot using CPy. It uses an nrf52840 SOC by Raytac (the same one as the feather sense).
I've been following the guide on Adafruit's site: https://learn.adafruit.com/circuitpython-on-the-nrf52/nrf52840-bootloader?gclid=Cj0KCQjw2MWVBhCQARIsAIjbwoPe63jZj8Boe6g0EKl_kvhiUnNlHDDgfDsS53FjktVWap3YRAXn4KQaAqOZEALw_wcB
I'm absolutely sure I'm doing something wrong, but not sure what.
Can anyone offer some counsel and/or guidance on how to proceed?
2 "slice step can't be zero" | 'slice step cannot be zero'
I wrote a little script to find "similar" translation strings, based on "edit distance". Some of what it finds is not useful, but some is. Like this pair of message, which are just 2 edits away from identical.
(apparently one is in ulab, and follows the "can't" convention of micropython, while the in cp we changed it to match desktop)
Did you get this working? I think I have a local change to fix this for myself
Please explain what you've tried and what is happening now
@daring pumice do you have a regular nRF52840 Feather? If you could erase it and then add the bootloader and SD, and vet that, I think you can create a recipe that should work for your module.
Hi Tannewt - I will do that, much appreciated.
Just on a call right now but will put that together today. Would you prefer it be posted here or on GitHub?
I do, and that's a good idea. I'll try that after my call and get back.
Thanks again guys - sorry for the bad timing.
@slender iron how did you generate the various config files in esp-idf-config/ I have a start for an esp32, but it has other sections, and I'm not sure where they came from originally
thanks, I was doing some by-hand dedupe,
python tools/update_sdkconfig.py --board=espressif_esp32s3_devkitc_1_n8 --update_all
without update_all it'll just do the board's sdkconfig
that's tools in ports/espressif
there is another script next to it too
@slender iron thanks! got it
@slender iron one more thing: where is the repo to assign creation ids for adafruit? The link in https://github.com/creationid/creators/blob/main/README.md to https://github.com/adafruit/creations doesn't exist
Our C3 board has CIRCUITPY_CREATION_ID = 0x00010001. But I like the numbering scheme you used in the Espressif repo: https://github.com/creationid/espressif-creations
you can change it then 🙂
just can't be all zeros because those are USB
I'll make the repo, then, do you want it in adafruit org or creationid org?
(I don't have permish for the latter0
Please try the tx power suggestion from @evildave666 and then I'll review. I suspect it will work.
rst:0x8 (TG1WDT_SYS_RST),boot:0x2a (SPI_FAST_FLASH_BOOT)
Yup, this is what I've seen too. I'll poke at this after the web workflow stuff is out for PR.
anyone else have an esp32s2 tft feather?
none of my flashing is working
either direct or indirect with uf2
I don't have any particular issue with mine
weird!
I did flash an S2 earlier and discovered I should not use a 921600 baud rate with esptool (that I somehow had in a copy pasted line), but that's all
If i leave tio connected to the ACMx port, it interferes with esptool.py
UF2 doesn't work for it either though
but that is not true with UF2
I tried the UF2 upgrade too
did you start with an erase?
I've got another board working so I'm not blocked
I started with a make flash
it did have the arduino example but now just goes into uf2
if that does not do a full erase first, I'd try that; that's my only suggestion. (Also making sure the board is the board you think it is)
I flashed one to whippersnapper and back last night no issues. To version 7.3.0
I have one on my desk.
I'll take a look later.
yup, full erase fixed it
I can reproduce the issue on the pico with 7.3.1 and main, on MacOS.
The issue seems to happen if the read() is called before the serial is fully available.
Adding a sleep at the start made the board behave as expected again.
This code.py waits for supervisor.runtime.usb_connected, in case it's related (though it might just insert a wait in the code, like the sleep). It has the board appear correctly and prints out values between 100 and 400ms.
import time
import usb_cdc
# time...
This is possibly not a MatrixPortal, but a Circuit Python issue that affects the Matrix Portal.
Nevertheless, let me start here and see how the feedback on fixing this issue goes.
While doing a basic test with Matrix Portal, I have a code that does this:
from alarm.time import TimeAlarm
from alarm import exit_and_deep_sleep_until_alarms
...
def draw_a_blank():
bg_color_palette = displayio.Palette(1)
bg_color_palette[0] = 0
bg_color_palette.make_opaque(0)
b...
This appears to be a core bug. As a workaround, I recommend running displayio.release_displays() before the deep sleep. The matrixportal board isn't designed for sleep or low-power so addressing this more deeply is likely not a high priority for us.
I sort-of reproduced this with the following script on 7.3.1:
import displayio
displayio.release_displays()
import time
import rgbmatrix
import framebufferio
import board
matrix = rgbmatrix.RGBMatrix(
width=128, bit_depth=1,
rgb_pins=[board.MTX_R1, board.MTX_G1, board.MTX_B1, board.MTX_R2, board.MTX_G2, board.MTX_B2],
addr_pins=[board.MTX_ADDRA, board.MTX_ADDRB, board.MTX_ADDRC, board.MTX_ADDRD],
clock_pin=board.MTX_CLK, latch_pin=board.MTX_LAT, output_enab...
If anyone else has this board and wants to get it working before the PR is merged, you can use the standard Pico firmware and the adafruit_st7789 library. Here is a gist with a small demo: https://gist.github.com/todbot/a23c8cb28e5925dfa79e6dba5c9d0962
@idle owl not sure if you saw this but wanted to get your thoughts on a patch like this
It would probably have to be done with my tools but would consolidate everything into one file. Also still sad about Dependabot.
Haha figured
I'll stay posted to see if it ever gets fixed
So we're also eventually planning to move away from setup.py which was apparently always legacy to the pyproject.toml. But there's no ETA on that, and it's apparently super involved. Someone at PyCon this year was looking into it, but I haven't heard anything since.
To the toml file?
Yes.
Well Dependabot is currently a bust so happy to pick it up. Otherwise, I'll just work on some of the stuff talked about in other meetings
@proven garnet I think it's kind of a bonkers update. If you want to look into the process and report back what you find, that would be an acceptable place to start. I don't want to send you off on a massive quest without knowing what's involved with it, because I know Limor has other plans for you. However, I don't know when she'll get to that since it will involve some guidance.
And it's also based on parts availability. So... very uncertain on timing.
Hi! I have a question about displayio.Display (and its subclasses like adafruit_st7789). I made the gist above for an ST7789 display on a RP2040, and the display seems configured as a 135x240 display instead of the 240x135. If I create the display with no rotation parameter and do continuous 135x135 sprite writes, my framerate is pretty good (about 225 msec per frame) but if I set display.rotation=90, then framerate drops to about 550 msec per frame. Is this a known attribute of Display?
@lone axle You might have an idea here. ^^

I'm not sure about performance impact of the rotation property. I don't recall hearing anything about it being limited, but I don't think I've ever measured it in different rotations.
The times I have used different rotations I didn't go back and forth much either so I don't really have a comparison between them mentally.
I just verified the same effect on FunHouse. By default it seems it is rotation=270 but if you set rotation=180 or rotation=0 it is MUCH faster
I’m trying to recall but I think it does the rotation calculation which could be the slowdown. I’ve never timed it either. I currently don’t have easy access to my computer to check either (yay house repairs).
@devout jolt rotation impacts the order pixels are read out of files
what are you displaying?
sprite sheet from OnDiskBitmap
I will try with vectorio stuff
oh ya, that'll do it
displayio tries to always align its output into rows to the display
it's very slow if a row contains a column of pixels from a source bitmap
you can rotate the display in hardware by changing the init sequence
I tried not to do that so that the rows we write would align with the refresh order of the display
specifically the MADCTL register
I don't think displayio is fast enough for that to matter though
well, if rotating 90 degrees makes it noticeably slower, that should fix it
(it will then be slower at 0 and 180 degrees, though)
ya, agreed
@slender iron would it make sense for the display.rotation to use the MADCTL register on the displays that have it?
okay nevermind I guess. I just verified on FunHouse (which has a square LCD to remove that as a variable) and using only in-memory vectorio shapes, and framerate is not dependent on rotation. It is the file read time. Here's the test sketch I used:
import time, random
import board, displayio
import vectorio, rainbowio
display = board.DISPLAY
maingroup = displayio.Group()
display.show(maingroup)
for i in range(20): # demo with a bunch of vectorio circles
palette = displayio.Palette(1)
palette[0] = rainbowio.colorwheel(random.randint(0,255))
x,y = random.randint(0,display.width), random.randint(0,display.height)
ball = vectorio.Circle(pixel_shader=palette, radius=20, x=x, y=y)
maingroup.append(ball)
display.rotation = 0
while True:
t = time.monotonic()
for ball in maingroup:
ball.x = (ball.x + 1) % display.width
display.refresh(target_frames_per_second=60)
print( int( (time.monotonic()-t)*1000) ) # ~210 msec/ frame on FunHouse
@devout jolt the file read time may depend on the order in which the pixels are being read from it
yeah exactly
ya, ondiskbitmap ends up seeking through the file and loading a sector for every pixel potentially
so lesson learned: if you want fast sprites and you can load them in RAM, load them in RAM. thanks sorry for bugging everyone about this
np
If you do still want to save the RAM and use OnDiskBitmap maybe you could rotate the source image inside the file so that it's "sideways" when viewed normally, but correct when viewed on the display with the fastest rotation setting.
Sometimes learning involves bugging folks. 🙂
totes. but it makes it harder to supply one spritesheet that is cross-platform, since everyone's laying out their displays at all the angles 🙂
yep, true that.
Look at them RAM sprites fly!
welcome page:
Speaking of sprites, I had an idea for blinka! Blinka slithering after “AdaBugs” to represent squashing bugs in circuitpython 🙂
Seemed like a cute way to visualize Circuitpython development
is that a <dl> in there?
well, in html you usually display lists with <ul> or <ol>, and dicts with <dl>
though the default style for it is really ugly
@slender iron did you have some trouble with CONFIG_ETH_ENABLED when doing the mdns stuff? It's turning on mysteriously in the ESP32 build, but I have not set it anywhere. It's causing an #include file error.
btw, running the sdkconfig script generates some significantly different files than what is checked in
You are awesome!!! Thanks so much for reproducing it and the work around.
Unrelated question, sort of: if I have a dogwatch enabled and then started
a long deep sleep… would you expect the dog to fire still?
— flaviof
On Thu, Jun 23, 2022 at 5:36 PM Jeff Epler @.***> wrote:
I sort-of reproduced this with the following script on 7.3.1:
import displayio
displayio.release_displays()import time
import rgbmatrix
import framebufferio
import boardmatrix = rgbmatri...
I'm not sure how watchdog & deep sleep interact. It's sure not documented!
update for the list.. nothing but frustration tonight.
I tried putting my test server
https://github.com/kstillson/circuitpython-i2c-notes/blob/main/i2c test server.py
(aka I2C peripheral) onto a qtpy esp32s2, which already supports the
library, and then trying to talk to it from my test client
https://github.com/kstillson/circuitpython-i2c-notes/blob/main/i2c test client.py
(aka I2C host), and couldn't get anything working, not even the address
scan which seemed to work earlier...
I'm not sure how watchdog & deep sleep interact. It's sure not documented!
Interesting. It does indeed seem to trigger WatchDogMode.RESET after I call exit_and_deep_sleep_until_alarms().
I will try explicitly calling watchdog.deinit() before the deep sleep but it would be nice if that happened automatically.
Do you agree @dhalbert ?
Got pyproject.toml working on the BME680 library!
Playing around a bit more tonight and I did get one safe mode reboot which yielded the following backtrace:
I (277665) wifi:set rx beacon pti, rx_bcn_pti: 0, bcn_timeout: 0, mt_pti: 25000, mt_time: 10000
W (277675) wifi: connected
Backtrace:0x4201E385:0x3FCF4F800x4201EEE3:0x3FCF4FA0 0x4201E129:0x3FCF4FC0 0x4201E233:0x3FCF4FE0 0x40380BBA:0x3FCF5000 0x42028BE1:0x3FCF5020 0x4201E5CA:0x3FCF5040 0x4201F36F:0x3FCF5060 0x4202A241:0x3FCF5080 0x42027475:0x3FCF50B0 0x4201210E:0x3FCF5120 0x42...
Rather than pressing Ctrl-D after the original connection script and re-running the script to cause the crash, I was able to cause the crash by running the following script:
>>> import ssl,wifi,socketpool
>>> import adafruit_requests as requests
>>> from secrets import secrets
>>> wifi.radio.connect(secrets["ssid"], secrets["password"])
Starting Connect Loop
Out of Connect Loop
>>> wifi.radio.enabled=False
>>> wifi.radio.enabled=True
>>>...
CircuitPython version
Adafruit CircuitPython 8.0.0-alpha.1 on 2022-06-09; Adafruit Feather ESP32S3 4MB Flash 2MB PSRAM with ESP32S3.
Code/REPL
class RecursiveProperty:
def __init__(self):
self.value = 0 # first: "value" is our backing *field*
def set_value(self, new_value):
"""
A setter for the "value" field
"""
print('In set_value, new_value =', new_value)
self.value = new_value
...
@onyx hinge I think you will see this in your email, but in case not: https://github.com/micropython/micropython/pull/8813 re mp_obj_type_t size
excellent news! should bring us some additional size savings when we can merge it in
anyone have any idea how i can add https://github.com/raspberrypi/pico-examples/tree/master/flash/nuke to the raspberry pi pico build?
so that it'll first nuke the flash memory before flashing the real firmware
@idle owl wanted to ping you on this but figured the AM was better 🥱
Generally the CP builds are loaded by the UF2 boot loader so I would think it needs to go there (assuming it wouldn’t remove the boot loader too). That is found in the tinyuf2 repo.
What's your use case for wanting this? Do you want to clear CIRCUITPY?
before flashing a file, you usually flash nuke.uf2 to remove the old firmware
any idea how?
you don't need to do that
flashing new firmware does an erase first anyway, of the blocks it is going to write
for CircuitPython, you generally don't want to do this, because it will erase what you have in CIRCUITPY
yeah but if the firmware is smaller than the older firmware the other blocks won't be deleted
you can flash on top of the old one
it doens't matter. Those blocks won't be used or read or anything
no, this is a project that generates the uf2 file for you with the code already in it so clearing CIRCUITPY is also a need
if you are flashing CIRCUITPY at the same time as the CircuitPython firmware, then again you won't have to erase anything, because you'll be writing blocks that are part of CIRCUITPY
i want to clear CIRCUITPY awell
when you say "with the code already in it", do you mean code in CIRCUITPY, or frozen?
code in frozen
frozen is part of the firmware
yeah, so nuke erases the firmware
you don't need to erase the firmware; it gets replaced when you load the new UF2
oh
there's no reason to use nuke unless there's some bad code.py in CIRCUITPY that is causing an immediate crash or something like that
and even then you can get into safe mode with a slow double click
every flash block that is part of the UF2 is erased first by the bootloader, and then written
all the frozen code is part of the CircuitPython UF2 - it is just more data that is part of the firmware. The frozen code is not in CIRCUITPY. I hope this makes your life easier.
alright, thanks!
what if i needed to erase the code.py also? cause that is also being auto generated..
how is it being auto generated?
it converts from duckyscript to python.. this project is to turn the pico into a hid device..
by modifying the buffer in filesystem.c
before the firmware is compiled, the filesystem.c file is modified.
do you have a pointer to the code? in your forked repo?
not really, all the script does is replace the text
so you are replacing the "hello, world"
https://github.com/compromyse/raspi-ducky/blob/main/circuitpython/supervisor/shared/filesystem.c#L77
it replaces this line
yeah but in this case I have a different default
rather than print(hello, world), this is my default
import picoducky
main()
are you turning off visibility of CIRCUITPY?
is that possible?
but as of now, no
ah, thanks!
a UF2 is just a bunch of blocks: it could include a CIRCUITPY
where is boot.py located, from this article?
is it possible to use the nuke?
alright!
there is still no reason to use the nuke
you could check always rewrite code.py on restart, or you could check to see whether it's what you want, and rewrite only if it's wrong. See main.c, which checks to see if boot_out.txt needs to be rewritten or not
it's not there by default, you create it
alright!
it's just another file
ah, alright! thanks!
Dear Ken,
Some ideas for your project:
pull-up resistors built into the pcb
You could put any stemma sensor with two connectors, and put it in between your QT RP2040. My guess is that the pull-up present will help, also you will have a sensor and your i2cperipheral so you could test one or the other and compare.
a chain of 2040 boards powering each other and communicating through their stemma/qt connectors with no other soldering / wiring required.
Not exactly your project,...
hey, you are using an RP2040 board right ?
yep
you can make a board with a normal version of Circuitpython and put what you want in CIRCUITPY and then create a UF2 file from that, that contains the entire flash, that you should then be able to flash as a whole on any identical board
you can do that with picotool:
picotool save --all my_full_board.uf2
(the board must be in RPI-RP2 mode)
@jaunty juniper thanks for pointing out the ease of doing this. I had forgotten that
it's really nice for deploying on multiple boards
@tulip sleet I don't remember any ETH issues. I do have to do some manual merging of the sdkconfig files
Ah, it's a <ul>. The file is here: https://github.com/tannewt/circuitpython/blob/cp_webserver/supervisor/shared/web_workflow/static/welcome.html I'd love a small html file with a small css to make it look good (especially on mobile)
Sharing this in case it's useful: I've found the awesome-lint rules to be a bit too strict for me, so for the awesome-microbit list I use awesome_bot instead, mostly to check the links are not dead: https://github.com/carlosperate/awesome-microbit/blob/master/.github/workflows/check-links.yml
Could you use ports/espressif/tools/decode_backtrace.py <board name> to decode the backtrace? (Copy and paste the Backtrace: line into it.) The addresses will vary with your build. Thanks!
Hey, @kstillson do you have a logic analyzer that you can put on the I2C lines? That'll really help you understand what is happening.
@slender iron could i video with you today about the changes I'm seeing made by the tools/ scripts, and the different default values?
thanks!
@evildave666 and @kylefmohr let me know how this fix works for you. I don't have my board with me, but this change did build for me, so I think its good to go.
Oh nice!
You can ping me anytime. I have notifications off when I don't want to get them, and they'll be here whenever I return. 🙂
@proven garnet When we find some overlapping time, I would like to chat about the process and what's involved.
Can we have an example with MP3 playback?
Using the Pico(rp2040) with CPy SPI to generate a sequence of alternating bits at 40KHZ. The configure interface allows one to specify bits. Can I assume that I might be able to set this to bits=16 with value bytes([0xAA,0xAA]). ???
@hidden rain why aren't you using pwm?
the spi peripheral is not going to give you a consistent frequency
For my application, I need near Square Waves. The application was previously implemented on a 16bit TI-MSP430. So, I only need 16bits of alternating squares waves at 40KHZ. If there is a better way, I am open...
Isn’t pwm square waves?
if you need exactly 16 bits at exactly 40kHz, then I suppose pulseio is your best bet
on the rp2040 you can also use pio directly
I will look into PWM. Thanks. However, since you mentioned it, what is the freq accuracy of SPI? is it that its not consistent each time its used?
can you tell us more about what you are trying to do?
Unfortunately I didn't realize how the backtrace decode worked and I don't think the build I have is the same. Although it's possible the only change I had made is adding the debug print statements in Radio.c. If I'm reading the backtrace decode correct the statement being pointed to is:
xTaskNotifyWait(0x01, 0x01, NULL, portMAX_DELAY);
Which actually seems plausible. The decoded backtrace is:
/home/pi/circuitpython/ports/espressif/supervisor/port.c:292
/home/pi/circuitpyth...
As i've indicated, I am porting an application which previously used SPI to generate a square wave at 40KHZ
since SPI is a clock-based protocol, it's the master that controls the clock, and there is no need for a consistent frequency -- so there may be gaps between sending bytes
but why 16 bits specifically?
Its a previously determined pulse width to ring a transducer. Our previous implementation is very accurate.
if you need to send modulated pulses, then pulseio.PulseOut is for you
It sounds like I should in to that ...seriously. But I need some closure on SPI. While there might not be a need for consistency on the SPI clock, wouldn't it be easier for HW implementers create a consistent clock rather than a wondering clock? Just trying to complete my understanding here...
it probably depends on a lot of things. if the SPI module is in some interrupt-driven mode, if you don't service the interrupt within the right window, it might pause the sending and the clock until you have serviced it. depending on what else your firmware is doing, you might not always get the timing right. SPI is intended for sending data, not waveform generation; if you want to use it for the latter, it's going to take a lot of work to get it consistently right, like maybe writing stuff in assembly language level of work
the spi send in circuitpython is blocking, it means that you call it, it sends the bytes you have given it, blocking until they are all sent, and then goes back to executing python code
so you will have inevitable gaps for when the python code is being executed
the only guarantee SPI gives you is that it will send the data you give it at a clock speed not higher than configured
A great little board, comes with two buttons, a LiPo connector, and a 240x135 color TFT:
https://github.com/Xinyuan-LilyGO/TTGO-T-Display
It looks like the TTGO T8 ESP32-S2 is already supported.
https://circuitpython.org/board/lilygo_ttgo_t8_s2_st7789
I get it. So only if the app is in a non-interruptible mode, blocks for 0.4 milliseconds (our app) or so, then I might expect "good" behavior. Ok, all good reasons to use PulseIO facility. Hopefully there are no "gotchas" there equally as bad. Just so I am clear in the SPI interface, the bits argument in configure CAN specify 16 bits, right?
This looks like it's ESP32-based, not an ESP32-C3 or -S2 or -S3.
CircuitPython has not targeted normal ESP32 boards
I think it depends on the port, not sure if it works on rp2040
The RP2040 Datasheet indicates its capable, but CPy might not acknowledge it. (??) Not enough documentation there...!
the easiest way is to try and see
Sure enough! Looking at Pulseio. Hoping I can control if the first part of the signal is high rather than low...
and if pulseio doesn't fit your needs, the pio lets you make a pin output pretty much anything you want, but it's a bit of a learning curve for the pio assembly
I'm afraid it always starts with on:
Pulse alternating on and off durations in microseconds starting with on.
but it's also blocking, doesn't work in background
for background operation it's pwm or pio
I've programmed 6502 and 68000 and old IBM 360 assembly. PIO only has 6 (or 8) commands? Blocking is OK for our app. We had some issues on the older SPI anyway, like Beginning and trailing power spikes, etc....However, its seems I'll need a scope....
I went ahead and rebuilt the firmware without the debug print statements and the resulting decode backtrace is:
/home/pi/circuitpython/ports/espressif/supervisor/port.c:296
/home/pi/circuitpython/ports/espressif/../../main.c:840
??:?
/home/pi/circuitpython/ports/espressif/build-espressif_esp32s3_devkitc_1_n8r2/esp-idf/../../esp-idf/components/esp_hw_support/include/soc/spinlock.h:158
/home/pi/circuitpython/ports/espressif/common-hal/microcontroller/init.c:83
/home/pi/circuitpyth...
Thanks for your help!
we have a guide on pio https://learn.adafruit.com/intro-to-rp2040-pio-with-circuitpython in addition to the good docs from raspberry pi themselves
you can use an rp2040 as a logic analyzer, if that helps...
So use one as a Generator, and one as an Analyzer (using ADC?)
well, it's a digital signal, so not even adc
you'd want to have a loop where you alternately make a pin high or low (possibly with the "side set"), and use the decrement-and-jmp instruction to do the high and low pulse the desired number of times. By using delays ([1]) or NOPs you can ensure the high and low 'parts' are the same in PIO cycles...
does that work ? I remember a project like that but it was in its infancy
OK.. so that algorithm would generate the pulses... so then I would monitor a GPIO pin and slam the results into a buffer at some read speed..?
oh COOL!
you'll need a PIO clock related to your 40kHz output frequency (at least 2x but maybe 4x), but unfortunately the 125MHz base clock doesn't evenly divide down to 80kHz or 160kHz. If you request a frequency that's not an exact division, then there'll be some variation (+-8ns, one clock at 125MHz) of PIO cycle lengths
I can live with that...
pio can read bits in too, there are examples for UART and SPI that show how to get bits in to the microcontroller (in the pico docs if not on learn)
it's hackaday, so who knows, but Arsenijs usually knows what he's talking about
quite exciting...now I just need another 48 hours ... so many projects ... not enough time... can't wait to share with my local micro-controller group
Is there a way to capture the last 30 minutes to a file?
copy-paste, I suppose
Done. Thanks Again...I have a lot of reading to do...(later!)🤓
I wrote up and have a repo on how to use it. a few others tried to make it more robust but my hackster.io write up covered the basics.
Im stuck away from my PC for a bit so can’t find the link.
I know of yours, but that hackaday post seems to be something else
Here is the notes document for next Monday’s CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if you’ll be attending the meeting - it’s super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1ZQVrnwy5uTp5YkvsJUs9dr-UjYWejaTNT2OzaN27UhQ/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for June 27th, 2022 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to part...
I rebuilt a fresh DEBUG=1 image and flashed it and after a lot of attempts finally managed to create a crash into safe mode and caught the back trace. The decode back trace is:
/home/pi/circuitpython/ports/espressif/supervisor/port.c:294
/home/pi/circuitpython/ports/espressif/../../main.c:994
/home/pi/circuitpython/ports/espressif/../../main.c:1001
/home/pi/circuitpython/ports/espressif/build-espressif_esp32s3_devkitc_1_n8r2/esp-idf/../../esp-idf/components/esp_hw_support/include/soc/...
but then the picotool is a dependency to the program.. I was hoping to have minimal dependencies..
a dependency to your creation of the initial image, once you have the UF2 you're good
it's not more a dependency than the environment to build Circuitpython
I guess it depends what you want to do, I don't know your whole context
some unlikely progress on a custom node-red python node called node-red-contrib-empython
which is the micropython javascript emscripten port built and heavily modified
but it's too messy to be able to upload in any meaningful way in its current state and requires httpStatic in settings.js to host firmware.wasm
all said and done, node-red-node-circuitpython? update: I have just made it into a dev branch: https://github.com/TheMindVirus/helpnodered/tree/empython
@idle wharf I'll update my build environment and spin up a build tomorrow for the Lolin board to try on real hardware.
Unless you have a binary at hand.
HI Scott-- thanks; good idea. I do have this little gizmo called a "Saleae
logic analyzer," although the last time I plugged it in was 2018, and I
recall it was quite frustrating to try to use.. But... I'll see if I can
dig it out and make it do anything.. Thanks for the suggestion!
- Ken
On Fri, Jun 24, 2022 at 1:09 PM Scott Shawcroft @.***>
wrote:
Hey, @kstillson https://github.com/kstillson do you have a logic
analyzer that you can put on the I2C lines? That'll really...
@kstillson Download the latest software for the Saleae: they've made a lot of improvements.
I made some changes to the ESP-IDF for my circuitpython fork. How can I upload to github my version of the ports/espressif/esp-idf into my circuitpython github fork so I can save it for posterity?
well, you fork idf as normal, then change the url in the submodules
Ok, I now see the .gitmodules file that you are referencing.
I made my changes to the esp-idf in my local branch of circuitpython. If I fork the esp-idf, will I have to go find my changes and then somehow merge them into my esp-idf fork. Is there any easy way?
you can push your changes to your new repo, since they will be related
or you can cherry-pick from your local repo
Ok, I think I've got it. Thanks @stuck elbow !
I pushed a commit of my code that uses the ESP32-S3 RGB LCD peripheral here:
https://github.com/kmatch98/circuitpython/tree/esp32s3_dotclockdisplay
Also, here are my updates to the ESP-IDF lcd peripheral code that support these changes:
https://github.com/kmatch98/esp-idf/tree/release/v4.4_rgblcd
@kstillson I would be interested in helping test. I have an oscilloscope at my disposal, and possibly a little free time.
does your fork have all your changes?
Not a CP issue, but closely related. Can’t install or run Mu Editor on Apple Silicon (M1X) MacBook Pro. Finder won’t copy app bundle (image) to Application nor(!) to data folder. Attempting to run app from distribution virtual disk (.dmg file) starts up, but quickly crashes (trying to access a file?) Changing System Prefs to give Mu file access didn’t help. Recommendations? Better channel? 🔥
what do you mean by the Finder won't copy ? does it show an error message ? silently do nothing ? what happens ? Is it the same as here ? https://github.com/mu-editor/mu/issues/2274
@jaunty juniper Finder does nothing. Yes, the mu issue 2274 is related -- error report from my colleague, directly on the mu github page.
that issue mentions an error message
Mu issue 2274 is correct, did get an error message in that specific case. The report was from my colleague. We're encountering a number of file io/security/etc. issues that are specific to the following configuration: macOS Monterey, current release (not dev beta), and Apple Silicon. We're also seeing. bunch of serial-over-USB issues specific to this MacBook Pro, but haven't eliminated the USB-C to USB Micro-B cable as a cause.
that kind of looks like a Finder bug, I would try copying to another drive first if you can, or maybe using the command line to copy it ?
or a bug in the APFS implementation on M1 ? 🤷
To avoid APFS security issues, I've asked Mark to try a thumb drive. Will try to do a specific device <-> cable <-> MBP testing matrix within the next day. One issue I'm not an expert on is: What happens in a cable/adapter between Thunderbolt 4/Type-C socket and the Micro-B plug. Just wiring, or is some logic HW involved?
To be specific, one definite serial IO issue is: We have a "simple" [Thunderbolt4/Type-C-socket] <==========>[Micro-B plug] cable. Using it between the MBP and a RPi Pico doesn't work. Pico is not even seen in the Mac System Report | USB list. If, however a different cable setup is used, with a USB hub in the middle, the Pico is seen and serial IO works. ==> i distrust the first cable.
Hello everybody. I'm trying to play wave sample at different pitch, but i don't kwon how to do that. Does anyone kwnows how to make different pitch with audiomixer or other library. Thanks !
I use à Pi Pico code with CircuitPython and I plug a neotrellis to the pico pico . My goal is to play the same sample at different pitch when i press a pad on the neotrellis. My first idea was to make different samples at different pitch with audacity but I got lot of bug when I play and memory is very short on the pico.
@glossy pecan looks like there are several issues related to this filed with mu-editor, you may find it useful to read for suggestions or if you have additional info to add. https://github.com/mu-editor/mu/issues/1847 has the most info [but they believed it was resolved as of December] and https://github.com/mu-editor/mu/issues/2274 which is still open but doesn't have much activity as yet.
I see you already found 2274
Are these just sine-wave tones or are they complex waveforms? See https://docs.circuitpython.org/en/latest/shared-bindings/audiocore/index.html#audiocore.RawSample for some ideas
the sample_rate property of a wavefile is settable, it looks like
@Billy-Bogardus well, any help would be most appreciated. yup- I keep my github repos up-to-date. https://github.com/kstillson/circuitpython has the modifications to try to get i2cperipheral working on 2040, and https://github.com/kstillson/circuitpython-i2c-notes has working notes and the code I've been using on both the host and the peripheral to try to make it go. Thanks-in-advance! :-D
As a related issue to "tearing", here is an issue on the esp-idf:
@kstillson Just had a little time to build for my RP2040 and it looks like something is being inverted on the reading address. Reading 0x3D 0b0011 1101 instead of 0x42 0b0100 0010 attached below are the scope plot and screen shot.

Client_Transmission.txt
[Client_Transmission.csv](ht...
Sounds good!
I'm interested in adding TLS support to the adafruit/Adafruit_CircuitPython_Wiznet5k driver. I’m an expert software developer with decades of experience on a multitude of platforms, but my Python knowledge is fairly basic (I’ve written a few scripts to help with iOS development, and dabbled in CircuitPython). So I decided it would be good to take on this "good first issue", in order to make sure I can update an existing CP library. I'm on an M1 MacBook Pro, I've forked the repo and cloned it, and I installed mypy to see if I could get it to show me the type annotation warnings mentioned in the bug. I can, so all's good there.
Now I’m merrily annotating the file, learning about Python type annotation as I go. My concern is this. The bug says to import from typing conditionally in case the module doesn’t exist. In that case, what happens in the code with all the undefined imports? Are they just None and ignored by CP? @lone axle @idle owl
@native sandal the type annotations are not getting executed when running the code normally, without mypy, they are only annotations
Thanks for confirming that.
I'm running into a new issue. In some instances, if I annotate a method in a class, then references to an import within that method generate an error:
@property
def connected(self) -> bool:
"""Returns whether or not we are connected to the socket."""
if self.socknum >= _the_interface.max_sockets:
return False
status = _the_interface.socket_status(self.socknum)[0]
if (
status == wiznet5k.adafruit_wiznet5k.SNSR_SOCK_CLOSE_WAIT
and self.available() == 0
):
result = False
else:
result = status not in (
wiznet5k.adafruit_wiznet5k.SNSR_SOCK_CLOSED,
wiznet5k.adafruit_wiznet5k.SNSR_SOCK_LISTEN,
wiznet5k.adafruit_wiznet5k.SNSR_SOCK_TIME_WAIT,
wiznet5k.adafruit_wiznet5k.SNSR_SOCK_FIN_WAIT,
)
if not result and status != wiznet5k.adafruit_wiznet5k.SNSR_SOCK_LISTEN:
self.close()
return result
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:151: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:157: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:158: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:159: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:160: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:162: error: Module has no attribute "adafruit_wiznet5k"
If I remove the -> bool annotation, it checks fine.
(but I get an error that the method isn't annotated)
do you have a link to the original file on github?
Line 140 in that file
thanks
I would say this is a legitimate error, there is no adafruit_wiznet5k inside https://github.com/adafruit/Adafruit_CircuitPython_Wiznet5k/blob/main/adafruit_wiznet5k/adafruit_wiznet5k.py
I agree, but that's how the code is written, and it runs, afaik
it might be some quirk of micropython/circuitpython
it should probably be wiznet5k.SNSR_SOCK_FIN_WAIT instead of wiznet5k.adafruit_wiznet5k.SNSR_SOCK_FIN_WAIT
I thought it was doing something I just don't understand. I haven't been able to figure out how to get at the WIZNET5K defined inside to use as a type annotation in this file (for _the_interface)
I tried that, and it couldn't find that either.
This file is also inside that package.
well, assuming I know what a "module" and "package" are
what path are you running the mypy from?
$ mypy adafruit_wiznet5k/adafruit_wiznet5k_socket.py
sorry, thought it was implicit in that. the top level of this repo
yeah, sorry, a bit dense today
Haha no worries
it should work like that, sorry, I can't see where the problem lies
the problem itself is that it is importing the module instead of the package
but why, I don't know
The module is the .py file inside the directory adafruit_wiznet5k, right?
right
That module definitely defines all the things it's trying to use
but at one level lower
I just don't know if import adafruit_wiznet5k as wiznet5k is importing that module or the package
like, start the Python repl, import like that, and execute the print?
or just add it to that code, right after the import, and run mypy on it
Nothing prints, just the errors:
23522 02:28: Adafruit_CircuitPython_Wiznet5k/ (rmann/issue-45-missing-type-annotations) $ /Users/rmann/Library/Python/3.8/bin/mypy adafruit_wiznet5k/adafruit_wiznet5k_socket.py --disallow-untyped-defs
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:28: error: Function is missing a type annotation for one or more arguments
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:75: error: "object" has no attribute "get_host_by_name"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:114: error: "object" has no attribute "get_socket"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:121: error: Function is missing a type annotation
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:142: error: "object" has no attribute "socket_status"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:147: error: "object" has no attribute "max_sockets"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:149: error: "object" has no attribute "socket_status"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:151: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:157: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:158: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:159: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:160: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:162: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:168: error: "object" has no attribute "remote_ip"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:176: error: Incompatible types in assignment (expression has type "List[int]", variable has type "bytes")
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:180: error: Function is missing a type annotation for one or more arguments
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:187: error: "object" has no attribute "unpretty_ip"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:188: error: "object" has no attribute "ifconfig"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:190: error: "object" has no attribute "ifconfig"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:195: error: "object" has no attribute "socket_listen"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:196: error: Module has no attribute "adafruit_wiznet5k"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:200: error: Function is missing a type annotation
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:209: error: Function is missing a return type annotation
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:238: error: Function is missing a type annotation
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:263: error: Function is missing a type annotation
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:272: error: Function is missing a type annotation
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:282: error: Function is missing a type annotation
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:341: error: Function is missing a type annotation
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:356: error: Function is missing a type annotation
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:371: error: Function is missing a type annotation
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:387: error: Function is missing a return type annotation
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:413: error: "object" has no attribute "socket_disconnect"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:417: error: "object" has no attribute "socket_close"
adafruit_wiznet5k/adafruit_wiznet5k_socket.py:421: error: "object" has no attribute "socket_available"
Found 34 errors in 1 file (checked 1 source file)
Perhaps because I'm in the middle of annotating and stuff is breaking? Not sure.
no, I assumed mypy imports the file, but it doesn't, it just parses it, and doesn't execute it, which is correct way to do it
it really feels like the way mypy is resolving imports is somehow different to how circuitpython does it
maybe someone else will have better insights once they wake up
Hmm. @lone axle wrote the bug, perhaps he can shed light on it.
Thanks for trying!
@lone axle My effort so far to address Issue 45 (note I still haven't figured out the import issue, nor how to properly reference the WIZNET5K class type): https://github.com/JetForMe/Adafruit_CircuitPython_Wiznet5k/blob/rmann/issue-45-missing-type-annotations/adafruit_wiznet5k/adafruit_wiznet5k_socket.py
Anyone knows if there is a plan to implement BLE on the ESP32 S3?
I haven't caught up on the full conversation yet, but yes all of the type annotations get ignored by the interpreter on the microcontroller. So it failing the import of typing does not cause any issues since it doesn't ever try to do anything with the types.
what is running the check that is outputting these error messages? Is that pylint or mypy or something different?
Thanks, but the last update is months ago, and I don't understand the feasibility or the issues described there.
well, you were asking about plans, so here you are, it's in the "long term" milestone
Feel free to ping me when you get back to it. I should around most of today. I don't have much mypy experience beyond when I used it to create those issues on the library repos. I'm not sure about any of the specificities of how it resolves imports.
The script that created the issues also checked for only specific types of output from mypy as well, so it's possible that you are seeing warnings and/or errors that we also would have seen when we created it, but wasn't one of the specific lines we were interested in (missing annotations for a function or return one primarily)
Thanks. OK, so I guess not planned anytime soon.
Is planned, but not on a specific timeline is how I interpret the messages in the issue.
classes can be referenced as Strings I think as well. So "WIZNET5K" may work as a type for something that is of that class type.
@slender iron I have a q re espressif never-reset logic when you are free
@violet thistle The issue is that the NimBLE stack doesn't have an API for adding services after the stack is started
we're hoping to find someone with more nimble experience to help us but our own priorities have been on web workflow
<@&356864093652516868> It's about 15 minutes until our weekly meeting! Remember to add your notes to the document. See you soon!
Has anyone tried to get Github CoPilot to generate CircuitPython code?
i wanted to, but I have to switch editors 😦
yeah I'd be grumpy about that too.
Sorry, skipping the meeting with no notes.
np, it's summer!
on one of the hemispheres, anyways
there's more than one hemisphere? 🤯
there are infinitely many
It's happened to us all, Dan
<Lord of the Rings>
typical screenshot of mines of moria
after my time
Ah a map! Thanks!
the orignal rogue is actually still pretty good, I play it from time to time
"roguelike" games were a big part of how I flunked out of university repeatedly from 1994-1998 🤣
@onyx hinge you could pick up usb host if esp32 isn't ready
@slender iron I feel intimidated by the very idea, thanks for your confidence
thach has done most of the work and the API is laid out already
setup.py has been legacy since before we started using it.
python packaging is a land of many contrasts
Thanks all!
Yep, Will send a link shortly.
thanks all!
Thank you, everyone!
Thanks!
👋
We've started working on ESP32 support but won't add this board ourselves because us Adafruit folks don't have one. So, please add it once we have ESP32 support merged in. Thanks!
app_main is the top of the stack. (Am I printing it out backwards?)
What is at /home/pi/circuitpython/ports/espressif/supervisor/port.c:294?
@kstillson I use a Saleae so feel free to ping me on Discord if you need help getting it going.
@tulip sleet https://www.dropbox.com/s/trls34ui2r5r3j2/circuitpython_weekly_meeting_06_27_22.mkv?dl=0 download button top left corner should give you a copy of it.
downloaded! TYVM!!
The one bit that is not in the recording is actually me saying that I have the backup recording running. I keep my local mic muted in OBS when I do the backup recordings outside of my turns to speak and didn't think to unmute when I responded.
(thanks to 300Mb up/down)
❤️ fiber for upload
yes!
Thanks Scott & Billy.. I've got to make a bit more progress on my primary
project today. I'm hopeful/optimistic that I'll be able to get back to the
i2c project tomorrow.. :-D
- Ken
On Mon, Jun 27, 2022 at 2:38 PM Scott Shawcroft @.***>
wrote:
@kstillson https://github.com/kstillson I use a Saleae so feel free to
ping me on Discord if you need help getting it going.—
Reply to this email directly, view it on GitHub
<https://github.com/adafruit/circuitpython/issues...
I really doubt you're reading it backwards :D, someone else must have....
port.c:294:
292 void reset_cpu(void) {
293 #ifndef CONFIG_IDF_TARGET_ESP32C3
294 esp_backtrace_print(100);
295 #endif
296 esp_restart();
297 }
Here is the notes document for next week's CircuitPython Weekly meeting. It is on Tuesday, not Monday (due to a US holiday) 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/1__eWF8gXJ7qx_BpZiPlvGGkT_jtalZ72YbSqG_5ZEM0/edit?usp=sharing
Google Docs
CircuitPython Weekly Meeting for July 5, 2022 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates early. During the meeting, we go through them as a round robin sorted by username. If you can’t make the meeting and would still like to partici...
@lone axle I have a couple of questions about the status light code.
What exactly is the POLL_DELAY and why is it set to 3 minutes? Is that how often it's querying the API?
Yep, exactly right, frequency that we pull the API. and I tried to choose something not too long, but not too short. There is lots of room to move either way and different values could make sense depending on the project and frequency / duration of their actions runs.
OK, got it. So leave it as is, but document it.
Second question is, what scope do I need to put on this API token?
let me see if I can tell what I put on mine. It should be fairly minimal I think since it's only reading and the data is from the public repo.
Right. Agreed, but I'm rarely clear on what that means in terms of check boxes. Heh.
I will find out the minimal requirements. I found mine, but almost certain it doesn't need everything (I re-used one from my IDE)
For circuitpython core repo you can make the token with no scope boxes checked.
Oh noticed you didn't add the buzzer to the code except in setup. Once I get it running, I'll see if I can add it successfully. I'll timebox myself and seek help from you if I reach the limit.
Nice! Thank you.
Sounds good. happy to help if so.
Yep shows green on my end as well atm with prints only, no light. So now it'll just run on a loop and update if/when it sees a new workflow run that isn't the same one that it already showed.
OK, trying to add buzzer before leaving it running. 🙂
@lone axle Ok, I get the idea of how to do it, and where it should go, but I'm going to end up iterating all over the place to figure it out. So I'm tagging you in. (I'm not on the same line numbers as you, I did a bit of linting.) It obviously goes within the ENABLE_USB_LIGHT_MESSAGES at the end following if conclusion ==. But with the existing time.sleep() I'm not sure how to make it happen without buzzing for 30 seconds which is a big nope. I believe the code is send_command(mSerial, BUZZER_ON) and BUZZER_OFF.
I would make a CONCLUSION_BUZZER_TIME I think and then use that subtracted with the conclusion light time to play it. I'll make a new commit in a moment that shows what I am thinking
Ok, thank you!
@idle owl do you want buzzer for failed workflow only? or buzzer on successful completion also?
Any completion. So, failed and successful. Not when yellow.
@idle owl I'm good to meet this week with a list of what's needed for the pyproject.toml switch. I think we have the tools needed to do it. Any time that work well for you?
Anytime works for you? Or does it need to be after work?
@idle owl this commit adds a new buzzer time variable and should turn it own for that many seconds when the light comes on. https://github.com/FoamyGuy/Github_Actions_Status_Light/commit/8ae628a66ba6a987e0cb7518f5a53664d331f576
It can be set to 0 to disable the buzzer. If it does player the buzzer sound it will subtract that time from the light sleep time so that it still turns back off after the configured delay.
I tried this in CPython 3.9.12 and get the same result, so at least CircuitPython is behaving as designed? :-)
% python3 ./recursive-property-tst.py
In set_value, new_value = 0
In set_value, new_value = 0
[... many of these ...]
In set_value, new_value = 0
In set_value, new_value = 0
Traceback (most recent call last):
File "/Users/tod/projects/circuitpython/recursive-property-tst.py", line 16, in <module>
rec = RecursiveProperty()
File "/Users/tod/projects/circuitpyth...
Lunchtime or after 6pm works for me. Both are generally subpar I assume so you can choose 😅
WOW that buzzer is loud. 2 seconds is super long.
6pm tonight work for you?
The name "buzzer" is a vast underestimation of what you're actually dealing with.
@lone axle It appears to go green again even though there isn't a new workflow.
Opening serial port.
Starting Github Actions Status Watcher
Press Ctrl-C to Exit
Fetching workflow run status.
completed - success
GREEN ON
GREEN OFF
Fetching workflow run status.
completed - success
GREEN ON
GREEN OFF```
It shouldn't do that right? It's supposed to know it already showed the status of that run?
correct, it should not show the same one twice. It will start printing the already showed message like this:
Mine is not doing that :/
However it does store the already_shown ones in memory so if you stop and then start again it will show the most recent one again.
Did it print something like: "adding 2570019400 to shown IDs"
I stopped it after three times.
This is everything Fetching workflow run status. completed - success GREEN ON GREEN OFF Fetching workflow run status. completed - success GREEN ON GREEN OFF Fetching workflow run status. completed - success GREEN ON GREEN OFF
No other prints happened.
Did I mess something up maybe?
can you throw your current code in gist or somewhere and I can take a look?
I think I messed something up.
Let me compare it to the original code before I send it to you
I think something got removed.
Letting it loop to test. I accidentally deleted somewhere in my copying and pasting the relevant code.
I think.
Ok, so far so good: adding x to shown IDs
3 minutes is a long time when you're waiting to test. I should have shortened it for testing purposes, heh.
Yes!
@lone axle Turns out I had removed 2 crucial lines of code.
Thank you!
Yep you're welcome. Let me know if anything else arises.
I will! This code is great. And you didn't even have hardware to test it with! Worked on the first try.
Thanks again and I'll keep you posted. Guide for this project is up next. I'll put your name on the code 🙂
Nice! All these years programming and it's still definitely a thrill to get things first try. 🎉
I may adapt it into a matrix portal version. It's a neat idea to have it visible some where at a glance.
Nice!
circuitpython "unix port" manages to get a RuntimeError exception rather than a crash, so perhaps there's something not quite right with the stack limit in the espressif port.
...
File "<stdin>", line 10, in set_value
File "<stdin>", line 9, in set_value
RuntimeError: maximum recursion depth exceeded
@onyx hinge I'm getting this when trying to update my local copy of CP, using make fetch-submodules. ```
From https://github.com/raspberrypi/pico-sdk
- branch 426e46126b5a1efaea4544cdb71ab81b61983034 -> FETCH_HEAD
! [rejected] 1.3.0 -> 1.3.0 (would clobber existing tag)
fatal: run_command returned non-zero status for ports/raspberrypi/sdk
.
make: *** [fetch-submodules] Error 128```
Haven't seen that before.
yeah I know it's been discussed before but I didn't see a resolution when I searched
Hmm.