#circuitpython-dev
1 messages Β· Page 360 of 1
yes
Oh I am interested
i know i can do it by swapping the kernels out but want to have it all with the one kernel
so i was thinking having only magics to do python side things
then non magics for circuitpython
When #4378 is changed and merged, it will change from using bitbangio for 0, 1, or 2-byte writes to just 0-byte writes. I will try to test the equivalent of that change with some of the failing peripherals above.
Yes, I like the idea
at the moment the magics look at softreset and upload_delay. I was thinking just adding python or python3 to the list in kernel.py
interesting, if you need help let me know, as I said I want to use use CP with the Jupyter notebook.
is the nbviewer working in the web now?
i havent looked
My Feather RP2040 arrives next week and I have an nbdev notebook with CircuitPython code (running now on Blinka on a RPi3) ready to switch to a CP kernel. I'd be happy to test things for you.
Thank you!
Looks like a change committed after my last rebase changed the state machine construction. I'll have to fix that and the build is failing.
what i dont know at the moment is. How can we read a line of code in and run it as normal python
We catch the python code with the kernel, how do we just send it back to the standard python interpreter
The %magics, I do not think there is a way to parse the code within the cell.
Fixes #4372.
The clock stretch timeout for board.I2C() was given as zero, but the default is 255. This timeout is only used by bitbangio.I2C(), and didn't matter up to now for other ports. But the RP2040 port uses bitbangio for zero-byte writes, so it used the zero clock stretch timeout.
@dhalbert I see the clock stretch timeout fix going through already... that was fast! Thank you!
I reported the same issue in the adafruit forums ("Magtag - ConnectionError: Unknown failure 205") a few weeks ago.
In my case, when running the magtag wifi test program, or any other sample programs (from the adafruit learn circuitpython example), it can see several access points in my area. However when attempting to connect to my local wifi network, all I get is the 205 error after a 10-15 second delay. Contents of "secrets" file are correct. I have NEVER been able to connect to my netw...
It was much easier than I thought.
it was basically just a typo
@jerryneedell can you test this again? I think maybe this was #4379 but I didn't closely read this issue.
I think there may be a misunderstanding or an opportunity to clarify the documentation. rtc.RTC() is always the on-chip RTC, so using set_time_source() doesn't change it. However, it does change what time.time() and time.localtime() (with 0 args) use as their source of the time.
So it looks like in all your prints, what you saw was only rtc.RTC() misbehaving, and pos...
Easy is good! You guys have a lot on your plates, I am glad it wasn't too painful. Will this fix find its way into one of the bleeding edge CP releases on AWS, or will it be in the next beta release?
i'll be merging it in a few minutes when it finishes building, so it will be available shortly and in the next beta
Great, I will give it a shot later tonight then... have a good evening.
Merged ... look for 8d3217c builds a little later
If you haven't already, try connect in a loop with try/except. After connecting the first time, it's a little more resilient to re-establishing the connection if it fails.
Again, if you haven't already, try to connect to an alternate Access Point, and see if proximity to the AP makes a difference (a scan in CircuitPython will show RSSI for each AP; unfortunately a connection is probably needed to see the RSSI of the device from the AP perspective).
@still zephyr i got somewhere. I have got a inline magics running python code
however it must be inline and not cell. I will look further. But i was successfully able to import nbdev
@vague latch That is amazing, so now when could run CP and python in the same file? I would like to take a look at that code
yeah, it isnt actually all that hard. As the circuitpython kernel is still running python and just packaging up the messages i just needed a way to block and execute the message before sending it to the serial port
Thank you for your response guys.
The download pages of neither of those boards (chips) show the 'canio' module as enabled. Are you saying that I can add the bin file for the STM32F07 and run the module like normal?
Sorry I'm a bit of a noob and not too well versed with pull requests.
@Shubhankargo The module list will be update once a new release is published.
For now you can test the latest build by grabbing it from S3.
Does anyone know an alternative to exec() in python
I just realized that we are commenting on a review. I am marking this as resolved. Lets continue the conversation below. :)
Thanks! @dhalbert.
I tested all three provided examples on my microS2 and they work flawlessly. Just one question...
@dhalbert I think we can get the idf patch in v4.3 since its a pre-release at the moment.
Converting this to draft for now as SPI still crashes. Also, I2C will need a re-visit once #4387 is merged.
You want to have a look at the descriptors we use for https://github.com/keyboardio/KeyboardioHID
The idea is that you should offer up both a Boot Protocol descriptor and a bitmap descriptor.
On Thu, Mar 11, 2021, at 1:18 AM, akaenner wrote:
I also need a keyboard that works at boot time. I'm currently working on a software for a DIY split keyboard with each part having a Raspberry Pi Pico in it. All features I planned are now implemented and I will share the code on GitHub in the comm...
@jepler This si what I get now -- is it the expected result?
Adafruit CircuitPython 6.2.0-beta.4-78-g8d3217cbf on 2021-03-12; Raspberry Pi Pico with rp2040
>>> import gps_time_source
Set GPS as time source
No time data from GPS yet
Fix timestamp: 03/12/2021 10:39:18
RTC timestamp: 01/01/2020 00:04:20
Local time: 03/12/2021 10:39:18
Fix timestamp: 03/12/2021 10:39:19
RTC timestamp: 01/01/2020 00:04:21
Local time: 03/12/2021 10:39:19
Fix timestamp: 03/12/2021 10:39:20
RTC tim...
@still zephyr and others. I have the first alpha/beta version of python magics working. The code takes in %python and %%python magics and runs the code following. I have included a small example in the examples section, this will be further fleshed out. At the moment i have two issues that i need to work through. The magics dont print the result to the jupyter notebook and i have to figure out how to keep a scope from any %python or %%python command if it is necessary. Otherwise take a look at it https://github.com/qwertimer/circuitpython_jupyter_kernel
Finally i can say that with this functionality i can run nbdev and produce code.py files from the circuitpython script. I will add the example of this shortly
FYI -- I received a feather_rp2040 today and I am(so far) unable to reproduce this issue on a Raspberry Pi 400.
CP is the current tip of main - g8d3217cbf
example is added around using nbdev in the notebook.
That was a mistake; I think I was copying over some code from MicroPython to test. I'll put it back. Thanks for catching that.
@dhalbert I think we can get the idf patch in v4.3 since its a pre-release at the moment.
I agree, it would be good to PR upstream, but I am still somewhat bothered by the whole thing because I don't see why the IDF fix works. I did some more experiments yesterday and re-read a bunch of our code and their code. I came to no new conclusion. I haven't gotten feedback from igrr about it. Also I inquired with FreeRTOS: https://forums.freertos.org/t/vsemaphoredelete-immediately-after-xsemap...
The "RTC timestamp" line is now consistently advancing by about 1 second per second. I don't see where your program set the current time of the rtc.RTC() object by assigning its datetime property, so it's also expected that it starts counting from some arbitrary time in the past. So, yeah, it looks right to me. Is there something we can improve about the docs so that you think others would understand why this behavior is the anticipated behavior?
I'm fine with your explanation. If anything, the example in the gps library may need to be updated to set the RTC. Thanks.
Thanks! for making the changes.
I found that they use only Delete in the err routine of i2c_driver_install (here) for clean-up.
Getting someone from espressif to comment on why Take is required in case of i2c_driver_delete might clear things up.
I just tried this with the 2nd Feather RP2040 I ordered and it is not doing this. It behaves normally. Both Feathers are from the same work order. Neither have headers soldered. They are being used straight from bag.
Do you have an intuition about this?
No clue at the moment, I'll try to replicate this behavior in an IDF program.
Failed build was a network problem. Merging.
No clue at the moment, I'll try to replicate this behavior in an
IDFprogram.
When I look at the multiple threads running in a "crashed" program vs one running this fix, they look the same. In other words, it is not a hard crash, but some kind of loop or other problem. The clue with my simple tests above is that the REPL stops working, and eventually disconnects. So perhaps some program that does some USB serial activitiy would hang up. Perhaps also some wifi or I2C activity would fail...
This is the simplest example that reliably fails without the fix. It prints >>> after the import wifi but then the REPL hangs.
import board,busio
i2c = busio.I2C(board.SCL, board.SDA)
i2c.deinit()
import wifi
It prints >>> after the import wifi but then the REPL hangs.
Yes, I get the same behavior... it hangs and no backtrace. From the debug print I see that wifi starts initializing but stops abruptly.
This also happens on V4.3. I am going to replicate the sequence of code that is executed with these commands.
So the essence of the above is:
// From busio.I2C().
i2c_driver_delete(NULL); // does nothing
i2c_param_config();
i2c_driver_install();
// i2c.deinit().
i2c_driver_delete();
// Below from common_hal_wifi_init() and common_hal_wifi_radio_set_enabled().
esp_netif_init();
esp_event_loop_create_default();
xEventGroupCreateStatic();
esp_event_handler_instance_register();
esp_event_handler_instance_register();
esp_wifi_init();
esp_wifi_set_mode();
esp_wifi_s...
So the essence of the above is
Yup! that's it... you want to go ahead with the IDF program? If not I can run this sequence tomorrow.
I'll try to get the time; I'll let you know. I guess I can gut one of their examples and put that in.
Not got as much testing done as I'd like.
Using the raspberry_pi_pico port compiled with this change:
- [x] msa301_tap_example
- [x] msa301_simpletest
- [x] bme280_normal_mode
- [x] bme280_simpletest
PA1010D remains a mystery, it seems to perform a few writes and then lock up, attempting to init I2C again (even after a soft reset of the RP2) will fail with a pull-up error.
However, to add pure unadulterated mystery this problem...running i2c.scan() between reads will unlock...
Thanks for this testing. There are few devices that don't behave well, and we just have to document them for now. But your .scan() results are very interesting!
You're not going to like this, but I replaced the whole I2C read implementation with bitbangio and now reads from my PA1010D are rock solid. :grimacing:
@microDev1 Thank you for taking a look at this
You're not going to like this, but I replaced the whole I2C read implementation with
bitbangioand now reads from my PA1010D are rock solid.
That it works with bitbangio is expected, and that's the workaround for devices that don't work. Just use bitbangio.I2C() instead of busio.I2C() for such devices. We don't want to throw out the hardware I2C completely because it's more efficient, etc. It appears to be a hardware or SDK peculiarity, but I need to test the non-working devices...
Had to freeze outside to get the teeny GPS to fix, but with the above (albeit very nuclear) patch:
========================================
Fix timestamp: 3/12/2021 16:45:03
Latitude: 52.XXXXXX degrees
Longitude: 0.XXXXXX degrees
Fix quality: 1
# satellites: 5
Altitude: 15.3 meters
Speed: 0.46 knots
Track angle: 0.0 degrees
Horizontal dilution: 1.86
Height geo ID: 47.0 meters
========================================
Fix timestamp: 3/12/2021 16:45:04
Latitude: 52.XXXXXX de...
Thanks for this, I will take a look, could you submit in the Adafruit circuitpython_jupyter_kernel Repo after for people to comment and review. Thanks for the good work....
I would be interested in your testing the PA1010D with MicroPython or the Pico SDK if you have time.
I'm looking for CP wireless mesh technologies - too bad https://github.com/adafruit/circuitpython/issues/4032 is tagged long term. Any ideas on what hardware/software is available now or in a few months?
Limor has mentioned to me that the "serial" implementation via I2C for the PA1010D is pretty odd. As for TCS34725, it appears you resell our sensor boards, but I don't see a product of your own.
@Shubhankargo note that I did not add the F412, it's not a direct superset of the F405 like the F407 is and I don't have the cycles to test it right now.
Trying to create a socket on CPY for my feather S2, but I get an error when I try to try to issue either a "bind" or "listen" and the doc says they should be there, but when I do dir(socketpool.Socket) they are not there? What's up with that?
There are a lot of features in every port that will take the community's involvement to achieve.
If anyone feels like helping me understand this...how does the QTPY get away with powering the onboard NeoPixel directly from a GPIO pin https://cdn-learn.adafruit.com/assets/assets/000/095/390/original/adafruit_products_QTPy_sch.png?1602007604 I thought GPIO pins on SAMD21 were limited to ~7mA ... just curious. Or am I misreading the schematic? Or does that neopixel only need a few mA?
I think it just draws as much power as it can. It has a constant-current drive circuit internally, but the pin will only put out so much. It doesn't fry the pin because of the pin circuitry.
AH -- That makes sense -- thanks.
A question about it s power source came up in another channel #help-with-arduino and I wanted to make sure I gave the correct information.
It's long term and we don't have any plans. If you feel up to it, a PR is welcome π . It would be interesting to explore to see how much is in the ESP-IDF proper, how much is other C code, and/or could be done in Python.
Yeah PA1010D is an odd duck, I think I ended up referring to some Adafruit code to discover that it emits spurious /r or /n or something to that effect, totally breaking sentences if you don't treat only the combination of both as a valid line ending.
In a mostly SMBus world, these low-level i2c implementations always feel weird.
PA1010D results.
Hardware I2C fails miserably:
ret = i2c_read_blocking(i2c0, addr, rxdata, 10, false);
PIO "bitbang" works fine:
...
Hello, all! A reminder to please send any CircuitPython/Python on hardware related projects and news to cpnews@adafruit.com to be featured in the newsletter. We're always looking for more!
@jun2sak: Thanks! I have started testing the code. Timed light sleep works exactly as I expected, both real and simulated. In the case of timed deep sleep, I am losing the serial REPL connection when it goes to simulated deep sleep even for a couple of seconds. On the ESP32-S2, this does not happen, so it will need investigation.
I'm testing on a CLUE board with an integral display, so I have not tried power measurements yet, since the display will swamp everything else.
One thing about...
/ 6 leads to ~40mhz. 2M and 4M have a max 0x03 read speed of 60mhz.
If the divisor is / 4 then the speed is just over 60mhz.
Fixes #4377
Build for esp32s2 failed with following errors: Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
IDF_PATH=/home/jobla/circuitpython/ports/esp32s2/esp-idf cmake -S . -B build-unexpectedmaker_feathers2/esp-idf -DSDKCONFIG=build-unexpectedmaker_feathers2/esp-idf/sdkconfig -DSDKCONFIG_DEFAULTS="esp-idf-config/sdkconfig.defaults;esp-idf-config/sdkconfig-opt.defaults;esp-idf-config/sdkconfig-16MB.defaults;boards/unexpectedmaker_feathers2/sdkconfig" -DCMAKE_TOOLCHAIN_FILE=/home/jobla/circuitpython/ports/esp32s2/esp-idf/tools/cmake/toolchain-esp32s2.cmake -DIDF_TARGET=esp32s2 -GNinja
CMake Error: The source directory "/home/jobla/circuitpython/ports/esp32s2/build-unexpectedmaker_feathers2/esp-idf" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
Makefile:257: recipe for target 'build-unexpectedmaker_feathers2/esp-idf/config/sdkconfig.h' failed
make: *** [build-unexpectedmaker_feathers2/esp-idf/config/sdkconfig.h] Error 1
Sorry about previous post...I did follow directions and run the appropriate pre-req commands for esp-idf. CMakeLists.txt is indeed missing.
@rose cargo what version of cmake do you have?
Hi folks, please try this with builds after aec03a4. I found we were clocking the flash faster than it's rated for. I think this caused it to sometimes work if the clocks started up without overshooting their speed. If it did, it'd try to load code off the flash and it'd be corrupt. The corrupt code would cause a hard fault and things would stop. #4392 lowers the speed to 40mhz-ish which should be much more reliable even if the starting clocks overshoot.
I'm having an issue on main with CircuitPython and the ESP32S2 port. I'm using the ESP32S2 WROVER. If I build the firmware using make BOARD=<board> all and then copy the firmware.uf2 to the bootloader drive, it boots into CircuitPython, but if I make BOARD=<board> clean and build with make BOARD=<board> all DEBUG=1 to get some debugging output, it spits out this and boots back into the UF2 bootloader:
E (929) esp_image: Checksum failed. Calculated 0xb3 read 0xff
E (935) boot: OTA app partition slot 0 is not bootable
I did notice the DEBUG .uf2 is roughly ~2-300KB larger than the non-DEBUG one, but that may be a red herring.
Just for fun (if you've. not already) run make BOARD=unexpectedmaker_feathers2 clean and then try it again.
@echo jacinth I don't usually have an all in my command
Fair enough! What's the best command you'd recommend to build the .uf2?
I usually do make BOARD=<board> DEBUG=1
it's been a little while since I built S2 so it could be a different problem
@tannewt Thank you for reviewing this, and sorry for the delay reply.
2. You are right, I guess I never pushed the file changes including the TODO. the problem is in this line.
https://github.com/adafruit/circuitpython/blob/ed7cb6de7c0e31356739f2e824aeee2ba1769731/shared-bindings/i2cperipheral/I2CPeripheral.c#L63
The raised error is that this i2cperipheral_i2c_peripheral_type is unknown. I tried to change to the object but it did not work. To be honest I do not what to use here,
4. Agr...
Verified that this change fixes the problem on the two Feather 2040s I have.
Glad someone is also wondering why it works. I just got in and all my questions have been posed.
Large copies behaving as expected now. Fixed by #4377 closing.
Seems to have fixed it. Both of my boards are running normally now. Thanks!
Confirmed without using all that it still results in a bootloop. Anything else you think I should try?
it works without DEBUG though?
It does! Boots and everything, for the most part. I'm running into some bugs and want debug symbols, but DEBUG=1 simply doesn't boot at all. Checksum failed each time, and it kicks back to the UF2 bootloader.
Is the DEBUG= firmware too big and we're missing the firmware size check or checking against a wrong value?
That's my first guess, unless something is seriously wrong with the way debugging symbols are formed in the binary, but unfortunately I'm not familiar enough with the toolchain yet to make that kind of call.
I just built debug for the metros2 and it booted make BOARD=adafruit_metro_esp32s2 DEBUG=1 flash
Oh you're doing UF2...
Sorry... I always flash the bin file
I've never been able to get flash to work directly, unfortunately. It also loops into a bootloader being unable to enter the main program. Starting to wonder if these modules are cursed, but I did get them from Digikey. π
Current version uses the StateMachine.c interrupt setup and has simplified the SM program to the single IN instruction.
This looks incorrect, like a merge conflict was committed instead of resolved.
Yes, git got me (again). Correct files should be uploaded now.
On Fri, Mar 12, 2021 at 4:11 PM Jeff Epler @.***> wrote:
@.**** commented on this pull request.
In ports/raspberrypi/common-hal/pulseio/PulseIn.c
https://github.com/adafruit/circuitpython/pull/4262#discussion_r593479374
:+uint16_t pulsein_program[] = {
+<<<<<<< HEAD
- 0x4001, // 1: in pins, 1
+=======This looks incorrect, like a merge conflict was...
Okay, so bizarre. Doing a full esptool.py ... erase_flash before flashing CircuitPython directly using make BOARD=<board> flash works, so I can make it boot that way. That's the first time it's worked for me.
But doing make clean followed by DEBUG=1 results in a similar bootloop. This one provides perhaps a better error message, at least:
E (140) esp_image: image at 0x2d0000 has invalid magic byte
W (147) esp_image: image at 0x2d0000 has invalid SPI mode 255
W (153) esp_image: image at 0x2d0000 has invalid SPI size 15
E (159) boot: Factory app partition is not bootable
...
E (590) esp_image: Image length 1444768 doesn't fit in partition length 1441792
E (597) boot: OTA app partition slot 0 is not bootable
E (602) esp_image: image at 0x170000 has invalid magic byte
E (609) boot: OTA app partition slot 1 is not bootable
E (614) boot: No bootable app partitions in the partition table
I'm not sure if it's the toolchain or changes on main or what. For reference, these are the exact chips I bought: https://www.digikey.ca/en/products/detail/espressif-systems/ESP32-S2-WROVER-I/11613149
If you just load the .bin with esptool, does it work? I never use the uf2 bootloader, just out of habit.
alias flash-esp32s2='esptool.py --chip esp32s2 -p /dev/ttyACM0 -b 460800 --before=default_reset --after=no_reset write_flash 0x0000'
esptool.py is v3.0.
the older versions can be problematic or just not work
i am using the esptool.py in esp-idf/components/esptool_py/esptool/esptool.py
i have just been building the latest on main and flashing to a Metro ESP32-S2, so that's very similar to the setup you have. You might want to start with a fresh clone and do esp-idf/install.sh and then esp-idf/export.sh to make sure the toolchain is in fine shape
Yep, I'm using the one that ships with the repo, i.e: circuitpython/ports/esp32s2/esp-idf/components/esptool_py/esptool/esptool.py, so that seems right.
$ which esptool.py
> /Users/aliced/Code/circuitpython/ports/esp32s2/esp-idf/components/esptool_py/esptool/esptool.py
$ esptool.py --chip esp32s2 -p /dev/cu.usbmodem01 erase_flash
> Chip erase completed successfully in 17.7s
$ esptool.py --chip esp32s2 -p /dev/cu.usbmodem01 -b 460800 --before=default_reset --after=no_reset write_flash 0x0000 build-starwitch_wifi_imu/firmware.bin
> Wrote 1510304 bytes (907780 compressed) at 0x00000000 in 17.1 seconds (effective 704.7 kbit/s)...
Gets this in the UART, which I think might be the real issue here:
E (590) esp_image: Image length 1444768 doesn't fit in partition length 1441792
what is the board in your BOARD= ?
It's my own custom board, but the behaviour seems to be identical among adafruit_metro_esp32s2 and adafruit_feather_esp32s2_nopsram as well.
so if you try to load the adafruit_metro_esp32 .bin, it's too big? I'm rebuilding it now with debug and will get the numbers
esp32s2, specifically, but yep.
-rw-rw-r-- 1 halbert halbert 1493120 Mar 12 17:46 build-adafruit_metro_esp32s2/firmware.bin
One sec, I'm doing a fresh wipe of my entire toolchain to weed out any gremlins and it's taking a bit to do the git submodules.
Now that there are issue templates, the "file an issue link" should link to /issues/new/choose. The current link opens a blank issue, instead of the template list.
esptool.py --chip esp32s2 -p /dev/ttyACM0 -b 460800 --before=default_reset --after=no_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 4MB 0x0000 build-adafruit_metro_esp32s2/firmware.bin
esptool.py v3.0
Serial port /dev/ttyACM0
Connecting....
Chip is ESP32-S2
Features: WiFi, ADC and temperature sensor calibration in BLK2 of efuse
Crystal is 40MHz
MAC: 7c:df:a1:00:46:a3
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Compressed 1493120 bytes to 898075...
Wrote 1493120 bytes (898075 compressed) at 0x00000000 in 12.8 seconds (effective 932.8 kbit/s)...
Hash of data verified.
Leaving...
Staying in bootloader.
debug uart:
ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x1 (POWERON),boot:0x0 (DOWNLOAD(USB/UART0/1/SPI))
waiting for download
ESP-ROM:esp32s2-rc4-20191025
Build:Oct 25 2019
rst:0x3 (RTC_SW_SYS_RST),boot:0x0 (DOWNLOAD(USB/UART0/1/SPI))
Saved PC:0x400288c1
waiting for download
Yeah, it will upload just fine, but if I hit the reset pin to actually boot the program, it'll start looping.
Here's the transcript from my debug uart on boot (this is with DEBUG=1)
Now that there are issue templates, the "file an issue link" should link to
/issues/new/choose. The current link opens a blank issue, instead of the template list.
Fixed -thanks!
Yep... complete fresh toolchain, still get an error on reboot. Except now it's a new one:
E (611) psram: PSRAM ID read error: 0x00ffffff
E (616) cpu_start: Failed to init external RAM!
I saw this error before, but I'm also 100% certain these are WROVER chips with the PSRAM on them.
Do you figure it's a bad module at this point? I'm tempted to just assemble another board to see what the problem is.
There is a PSRAMCS pin exposed on the module. I don't know what it does, but we leave it unconnected. Did you ground it or anything like that? I was going to ask two things: 1. Does it say "WROVER" on the can π 2. check the "strapping pins" which control how it boots
Yep, it does say WROVER, and now I'm looking at the datasheet, which does say IO26 is reserved... and I've apparently hooked it up to something on this revision. Doh.
Cutting that trace did indeed fix the bootloader issue! Thank for very much for your time and help.
However, now I've got a new problem, and I think it might be related to your work with the I2C bus on the ESP32S2 port. The following script gets the proceeding error:
import busio
import board
# Initialize and lock the I2C bus.
i2c = busio.I2C(board.IO36, board.IO35)
while not i2c.try_lock():
pass
# Find the first I2C device available.
devices = i2c.scan()
while len(devices) < 1:
devices = i2c.scan()
device = devices[0]
print('Found device with address: {}'.format(hex(device)))
E (391478) i2c: ../../esp-idf/components/driver/i2c.c:362 (i2c_driver_delete):i2c driver install error
This is actually what I was trying to get to this whole time. π
I'm wondering if the current CPY build with DEBUG=1 exceeds the OTA partition on the 4MB ESP32S2 devices. I ran into this when i was attempting some tests and pushed if off to 'look at this later' file
@supple gale If it's not just me, then my bet is "yes." The PSRAM issue was unrelated, I think.
The goldilocks of flash speeds. / 2 is too fast and / 6 is slower than needed. It doesn't need to be divisible by 2.
@echo jacinth I tried your code and it worked (with some changes for pins being used) and it worked. I am using some code from the I2C/wifi PR artifacts for the UnexpectedMaker FeatherS2
Documentation includes:
socket.getaddrinfo(host: str, port: int) β Tuple[int, int, int, str, str]
Gets the address information for a hostname and port
Returns the appropriate family, socket type, socket protocol and address information to call socket.socket() and socket.connect() with, as a tuple.
But it has not been implemented on the esp32-s2 port. Just wanted to insert this as a reminder.
I (53) boot: ESP-IDF v4.3-beta1-24-g0bbc721a6-dirty 2nd stage bootloader
I (53) boot: compile time 16:13:59
I (54) boot: chip revision: 0
I (57) boot.esp32s2: SPI Speed : 40MHz
I (62) boot.esp32s2: SPI Mode : DIO
I (67) boot.esp32s2: SPI Flash Size : 4MB
I (71) boot: Enabling RNG early entropy source...
I (77) boot: Partition Table:
I (80) boot: ## Label Usage Type ST Offset Length
I (88) boot: 0 nvs WiFi data 01 02 00009000 00005000
I (95) boot: 1 otadata OTA data 01 00 0000e000 00002000
I (103) boot: 2 ota_0 OTA app 00 10 00010000 00160000
I (110) boot: 3 ota_1 OTA app 00 11 00170000 00160000
I (118) boot: 4 uf2 factory app 00 00 002d0000 00040000
I (125) boot: 5 user_fs Unknown data 01 81 00310000 000f0000
I (133) boot: End of partition table
I (137) boot: Defaulting to factory image
E (142) esp_image: image at 0x2d0000 has invalid magic byte
W (148) esp_image: image at 0x2d0000 has invalid SPI mode 255
W (154) esp_image: image at 0x2d0000 has invalid SPI size 15
E (161) boot: Factory app partition is not bootable
I (166) esp_image: segment 0: paddr=00010020 vaddr=3f000020 size=446e8h (280296) map
I (248) esp_image: segment 1: paddr=00054710 vaddr=3ffd1220 size=048a8h ( 18600) load
I (254) esp_image: segment 2: paddr=00058fc0 vaddr=40028000 size=00404h ( 1028) load
I (255) esp_image: segment 3: paddr=000593cc vaddr=40028404 size=06c4ch ( 27724) load
I (272) esp_image: segment 4: paddr=00060020 vaddr=40080020 size=fd314h (1037076) map
Hmm... My Metro is not happy with my debug build...
Seems like this is exactly what @echo jacinth was just talking about ...
That looks like what I was getting, yep.
My additional variable is I'm on the M1 Mac...
I'm going to erase and flash again
yep... same thing.
And I'm on the updated-idf branch
Partition table binary generated. Contents:
*********************************************
# ESP-IDF Partition Table
# Name, Type, SubType, Offset, Size, Flags
nvs,data,nvs,0x9000,20K,
otadata,data,ota,0xe000,8K,
ota_0,app,ota_0,0x10000,1408K,
ota_1,app,ota_1,0x170000,1408K,
uf2,app,factory,0x2d0000,256K,
user_fs,data,fat,0x310000,960K,
**********************************************
RETAIL Build
Compressed 1366480 bytes to 872394...
Wrote 1366480 bytes (872394 compressed) at 0x00000000 in 13.0 seconds (effective 837.9 kbit/s)...
ll build-adafruit_metro_esp32s2/*.bi
n
-rw-r--r-- 1 patrickwalters staff 1300944 Mar 12 16:24 build-adafruit_metro_esp32s2/circuitpython-firmware.bin
-rw-r--r-- 1 patrickwalters staff 1366480 Mar 12 16:24 build-adafruit_metro_esp32s2/firmware.bin
DEBUG Build
Compressed 1508704 bytes to 911808...
Wrote 1508704 bytes (911808 compressed) at 0x00000000 in 13.8 seconds (effective 872.2 kbit/s)...
ll build-adafruit_metro_esp32s2/*.bi
n
-rw-r--r-- 1 patrickwalters staff 1443168 Mar 12 16:28 build-adafruit_metro_esp32s2/circuitpython-firmware.bin
-rw-r--r-- 1 patrickwalters staff 1508704 Mar 12 16:28 build-adafruit_metro_esp32s2/firmware.bin
@supple gale I think you nailed it..
This error is unimportant: E (391478) i2c: ../../esp-idf/components/driver/i2c.c:362 (i2c_driver_delete):i2c driver install error. The code always tries to delete the driver in case there was one installed, but there may not be.
I think you do want the type. It should be externed in the header and defined at the bottom of the c file. https://github.com/adafruit/circuitpython/blob/main/shared-bindings/i2cperipheral/I2CPeripheral.c#L222
I'd recommend get the shared-bindings back to the checked in state and then adding c functions into the common-hal side.
it was unfortunate that it sent me down a wrong path when i was debugging something else. And DEBUG is my only method, unless i break out the JTAG stuff. Also unfortunate that the uf2 loader doesnt give any indication when the image wont fit.
@dhalbert Thank you for your testing. In my environment I don't see the USB-lost problem you mentioned. In my test of timed deep sleep with USB connection, when CY executes alarm.exit_and_deep_sleep_until_alarms(), it displays following lines and stops.
Code done running.
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Pretending to deep sleep until alarm, CTRL-C or file wr...
@supple gale and @echo jacinth This obviously is a hack, but I messed with the 4mb partitions and I can load debug now.
In ports/esp32s2/esp-idf-config/partitions-4MB.csv I edited the size of ota_0, the offset and size of ota_1
# ESP-IDF Partition Table
# Name, Type, SubType, Offset, Size, Flags
# bootloader.bin,, 0x1000, 32K
# partition table,, 0x8000, 4K
nvs, data, nvs, 0x9000, 20K,
otadata, data, ota, 0xe000, 8K,
ota_0, 0, ota_0, 0x10000, 1608K,
ota_1, 0, ota_1, 0x200000, 508K,
uf2, app, factory,0x2d0000, 256K,
user_fs, data, fat, 0x310000, 960K,
yep, more or less the same here. I'm using my UM FeatherS2 for now (w 16MB flash). Not really hacky as most arent using the ota_1 partition for anything.
@dhalbert On nRF REPL connection, I also have a similar problem. That is, when I connect my nRF board to a host PC, a serial console app (TeraTerm) cannot establish USB-serial connection for a while. After 30 seconds, the connection is established.
This problem had already been seen before I started modification for my sleep and wakeup.
After trying different releases of CY firmware, I found
adafruit-circuitpython-pca10059-en_US-6.0.0.uf2 OK
adafruit-circuitpython-pca10059-en_US-6....
See RTD:
>>> import wifi
>>> import socketpool
>>> from secrets import secrets
>>>
>>> wifi.radio.connect(secrets['ssid'], secrets['password'])
>>>
>>> pool = socketpool.SocketPool(wifi.radio)
>>> pool.getaddrinfo("adafruit.com", 443)
[(0, 0, 0, '', ('104.20.38.240', 443))]
>>>
What's weird with my I2C scanner script is that it works on the standard SCL and SDA pins, but if I move them to SCK (IO36, for SCL) and MOSI (IO35, for SDA), it actually freezes CircuitPython entirely, not responding to Ctrl+C over serial. The drive continues to be accessible, though. The "detect valid pins" script does say that those two pins are a valid pair, so I'm not sure why it can't continue.
@nitz Thank you for your comments. I also was surprised and a bit disappointed to find that nRF RTC is not a real-time clock and does not keep running while System OFF. There are some retained registers but their bytes are limited and shared with several purposes, so I think there should be kind of a guideline or protocol among them. I don't know if there are already some.
As for the state-transition diagram, I drew it with LibreOffice Draw.
I'm late to this so just reporting it works here also. I used b413535 FWIW. Both boards work as expected.
Thanks for the fix!
Again, no testing performed, but does what it says.
@tannewt
If this is still open and valid after two yeas I am willing to work on this for the long run. I made a list, and there are approx 680 occurrences of the macros.
list is here https://github.com/jposada202020/mp_func_macro/blob/master/test.txt
Develop the code to verify this automatically will be good, but at first sight I am not seeing as a trivial thing, maybe that will change along the way. The easiest way is to create check rules parsing the MP_ and then verifying the docs....
FYI -- I tried a DHT22 on a Raspberry Pi Pico now that pulseio has been added ... ```Adafruit CircuitPython 6.2.0-beta.4-121-g550eab2dd on 2021-03-13; Raspberry Pi Pico with rp2040
import dht_simpletest
Checksum did not validate. Try again.
Temp: 71.1 F / 21.7 C Humidity: 23.9%
Checksum did not validate. Try again.
Checksum did not validate. Try again.
Checksum did not validate. Try again.
Checksum did not validate. Try again.
Temp: 71.1 F / 21.7 C Humidity: 23.8%
Checksum did not validate. Try again.
Checksum did not validate. Try again.
Checksum did not validate. Try again.
Temp: 71.1 F / 21.7 C Humidity: 24.1%
Temp: 71.1 F / 21.7 C Humidity: 24.1%
Temp: 71.1 F / 21.7 C Humidity: 24.3%
Checksum did not validate. Try again.
Temp: 71.1 F / 21.7 C Humidity: 24.4%
I see in the PR adding pulseio that the DHT22 was tested early on. For my test I used GP22 and sampled every 2 seconds.
Hey I know that the digitizer is written into your HID devices but not enabled as it say here https://github.com/adafruit/circuitpython/blob/550eab2ddda780adb939693a51c8c07c4a540c36/tools/gen_usb_descriptor.py#L24.
I've been trying to build circuitpython with this feature enabled but can seem to get the rp2040 to build properly (with or without the changes). Whether its a uf.2 build or advice on how to get a digitizer working anything would be useful thanks!
Report failure instead of deadlocking the device
Looks like an HTTPS misconfiguration is blocking the CI
@caternuson Could you test this on the board you had trouble with? Thanks.
Hello @solar whale. I tested the initial PR at the beginning when pulseio PR. I was planning to redo the tests after it got merged, I saw your comments in the issue.
is there a place where all the built UF2 files from a PRs actions run are available to download?
I found the list of artifact links actually.
I had the issue from #4377 on both of my Feather RP2040 devices. I tried out the build from the artifact of this PRs actions and can confirm it does seem to resolve the issue for me.
This is my boot_out after loading this version:
Adafruit CircuitPython 6.2.0-beta.3-144-g737063c19 on 2021-03-13; Adafruit Feather RP2040 with rp2040
I tested on both devices and have successfully reset several times with the button, as well as unplug / replug. I have about a dozen trials between b...
Title
Or do I have to build one from the ground up, if so how is the report structed (buffer size and order of (x,y,ifPressed,etc))
The information you need is in https://github.com/adafruit/circuitpython/blob/550eab2ddda780adb939693a51c8c07c4a540c36/tools/hid_report_descriptors.py#L192. The report size can be derived from there but is also listed here: https://github.com/adafruit/circuitpython/blob/550eab2ddda780adb939693a51c8c07c4a540c36/tools/hid_report_descriptors.py#L28.
Any good documentation online on these reports? Because to me it looks like something crazy. Also thank you so much your so fast with these responses :)
https://eleccelerator.com/tutorial-about-usb-hid-report-descriptors/ is a good intro.
This is really more a support question, and would be better asked in https://forums.adafruit.com and/or our discord https://adafru.it/discord. So I'm closing this for now. Feel free to ask more about descriptors in either of those places.
@dhalbert Tested and works on the two Feather RP2040s I have.
I've spent some time experimenting with location & orientation of the magtag and have FINALLY got it to connect to my wifi router.
It looks like it could possibly be signal corruption due to parts layout on the magtag pcb causing interference to the wifi signal.
Results of my testing in the adafruit forums ("Magtag - ConnectionError: Unknown failure 205").
The changes look fine to me, but did not test directly.
Is it worth retrying X amount of times even? I know adafruit_bus_device had a routine to catch background tasks and keep trying for the lock, I'm not familiar enough to say for sure this needs it just a thought.
Based on nrf PWMAudioOut by @jepler and stm PulseOut by @hierophect
Tested on a Meowbit
@tyomitch Are you doing a by-hand code audit, or are you using a tool?
That was not intended as a code audit; just the few rough spots I came across while working on #4399
My OS Arch linux
Item ItsyBitsy M0 Express
What do I did ?
https://circuitpython.org/board/itsybitsy_m0_express/
- Update > adafruit-circuitpython-itsybitsy_m0_express-en_US-6.2.0-beta.3.uf2
- Update > update-bootloader-itsybitsy_m0-v3.13.0.uf2
β
Inside ItsyBitsy M0 Express
https://learn.adafruit.com/welcome-to-circuitpython/creating-and-editing-code
import board
import digitalio
import time
led = digitalio.DigitalInOut(board.D13)
led.direction = d...
Could it be that instead of the busy-wait in https://github.com/adafruit/Adafruit_CircuitPython_BusDevice/blob/master/adafruit_bus_device/spi_device.py#L73, it's better to throw an exception when the SPI is locked? Then the user would have control over how many times, if at all, to retry.
Thanks @caternuson. I will merge.
There should be an exception printed to the serial monitor. What is displayed?
https://learn.adafruit.com/welcome-to-circuitpython/kattni-connecting-to-the-serial-console
I was translating some strings from en to ger when i had an idea but i dont know where to put it, so maybe here is a good place:
I would love to see error codes added to cp!
When you have to google your error its quite hard if you have to translate the error to find something
Hello all.
I'm adding Franzininho WiFi boards to circuitpython.org. I added the two boards ( wrover and Wroom) in this PR.
Please let me know if the additions are correct or need some adjusts.
Thanks
Hardreset circuitpython
https://github.com/tuupola/circuitpython/blob/master/docs/wipy/tutorial/reset.rst
That link is from an out-of-date fork. https://circuitpython.readthedocs.io will always be the latest.
It is not clear why the fix in pr #4387 prevents i2c_driver_delete() from interfering with wifi. Rather than continue to discuss that in a closed PR, I'm opening a new issue about this for further discussion.
@dhalbert I think we can get the idf patch in v4.3 since its a pre-release at the moment.
I agree, it would be good to PR upstream, but I am still somewhat bothered by the whole thing because I don't see why the IDF fix works. I did some more experiments yesterday and re-read...
Do you have an intuition about this?
No clue at the moment, I'll try to replicate this behavior in an IDF program.
_Originally posted by @microDev1 in https://github.com/adafruit/circuitpython/issues/4387#issuecomment-797556117_
No clue at the moment, I'll try to replicate this behavior in an
IDFprogram.
When I look at the multiple threads running in a "crashed" program vs one running this fix, they look the same. In other words, it is not a hard crash, but some kind of loop or other problem. The clue with my simple tests above is that the REPL stops working, and eventually disconnects. So perhaps some program that does some USB serial activitiy would hang up. Perhaps also some wifi or I2C activity would fail...
This is the simplest example that reliably fails without the fix. It prints >>> after the import wifi but then the REPL hangs.
import board,busio
i2c = busio.I2C(board.SCL, board.SDA)
i2c.deinit()
import wifi
_Originally posted by @dhalbert in https://github.com/adafruit/circuitpython/issues/4387#issuecomment-797568174_
It prints >>> after the import wifi but then the REPL hangs.
Yes, I get the same behavior... it hangs and no backtrace. From the debug print I see that wifi starts initializing but stops abruptly.
This also happens on V4.3. I am going to replicate the sequence of code that is executed with these commands.
_Originally posted by @microDev1 in https://github.com/adafruit/circuitpython/issues/4387#issuecomment-797573191_
So the essence of the above is (you can double check this):
// From busio.I2C().
i2c_driver_delete(NULL); // does nothing
i2c_param_config();
i2c_driver_install();
// i2c.deinit().
i2c_driver_delete();
// Below from common_hal_wifi_init() and common_hal_wifi_radio_set_enabled().
esp_netif_init();
esp_event_loop_create_default();
xEventGroupCreateStatic();
esp_event_handler_instance_register();
esp_event_handler_instance_register();
esp_wifi_init();
esp_...
So the essence of the above is
Yup! that's it... you want to go ahead with the IDF program? If not I can run this sequence tomorrow.
_Originally posted by @microDev1 in https://github.com/adafruit/circuitpython/issues/4387#issuecomment-797576700_
I'll try to get the time; I'll let you know. I guess I can gut one of their examples and put that in.
_Originally posted by @dhalbert in https://github.com/adafruit/circuitpython/issues/4387#issuecomment-797577487_
Glad someone is also wondering why it works. I just got in and all my questions have been posed.
_Originally posted by @skieast in https://github.com/adafruit/circuitpython/issues/4387#issuecomment-797745897_
I worked some more on this today. I put some logging in before and after the call to esp_wifi_start() in Radio.c. What's interesting is that in the "fixed version", there is an extra logging entry after that call:
...
I (8988) wifi_init: tcp tx win: 2880
I (8998) wifi_init: tcp rx win: 2880
I (8998) wifi_init: tcp mss: 1440
I (11693178) wifi_init: WiFi IRAM OP enabled
I (11693178) wifi_init: WiFi RX IRAM OP enabled
I (11693188) common_hal_wifi_radio_set_enabled: > esp_wifi_sta...
Where might one find PIO examples for CP?
Moving this discussion to a new issue, #4401.
@solar basin This guide is quite recent: https://learn.adafruit.com/intro-to-rp2040-pio-with-circuitpython/overview I haven't read it myself since I took the example from the pioasm github repo but this is a similar example
Sweet! Thanks, I don't know why I didn't think to check learn!
@solar basin if you need more details check the appendix of the Get Started with MicroPython on Raspberry Pi Pico book for the pio syntax https://hackspace.raspberrypi.org/books/micropython-pico or chapter 3 of the official datasheet for the nitty gritty.
Raspberry Pi Pico is a new low-cost, high-performance microcontroller board with flexible digital interfaces. Microcontrollers are computers stripped back to their bare essentials. You donβt use monitors or keyboards, but program them to take their input from, and send their output to the input/output pins. Using these programmable connections, ...
Hi - are you saying that to translate the error you don't know where the string is used, or is it that when you see an error raised by your program, you're not sure which English error it corresponds to? In the first case I thought weblate would give you a pointer to the source file.
Hmm i think i need to rephrase: if i get an error i dont understand i like to google it, since nearly everything on the internet is in english it is quite hard to find someone with the same problem. But if the error had a code attatched to the text i could google "circuitpython error 1234" it would be simpler.
Sure it is possible to translate the german error to english and search for it, but it is hard to get the exact same wording to find relevant results
For me personaly it is no problem, i use the english version because of that reason. But i did a bit of translating for the german version and realised that it could be a problem
you can always search for the German error in the German translation file, and you will see the English error there then
I have encountered that kind of issue, not in CPY, but in general with error messages given by apps or operating systems. When trying to lookup info, or when trying to ask about it. "I'm getting an error, well it's in french but basically it says this"
@cedar lark thanks, I was already looking at the RPi Pico docs, I just wanted to compare examples. π
Does anyone know how rel is encoded into the irq instruction?
The compiler doesn't know which state machine the code will run on at compile time, right? So it's calculated at runtime, right? Because you could choose to run a program on all SMs
Is there a helper that will convert strings into hid keycodes nevermind I just made a switch for it
Corrections to the doc_strings in the analogio docs for readthedocs generation. Two changes:
- Erasing the [Optional] in the voltage reference
- Standarize both usage examples. Using CircuitPython
Verified Building docs using sphinx locally


Thats true, but not very beginner friendly - also when searching in the translation you would have to know the placeholder strings - i think its not an ideal solution - just adding a numeric code in the beginning or start of the error could help i think!
Totally confused myself by posting on this PR instead of the open one πΆ
But Iβve created a C++ POC for the problem with PA1010D (plus a comparison using the PIO that works) and raised an issue against the SDK here- https://github.com/raspberrypi/pico-sdk/issues/252
@hybrid scarab I am testing BME280 as I type this.
@modest hazel We saw the PlayPiper announcement and makezine video - congrats! It looks like most of the code is closed source, except for your CPy helper library. Is that the long-term plan?
Your successful use of Web Serial for the REPL connection is encouraging. Is that code available? Having a generic USB terminal available from the browser would be great for many purposes. I have tried the sample terminal that Google supplies, but it doesn't play well with the REPL: it seems to keep disconnecting and reconnecting.
@tulip sleet Thank you for the CircuitPython build guide and your pointers a few days ago. Turns out I had an outdated version of the gcc arm cross compiler in my path. Fixed, and builds are progressing just fine. (Context: cast boundary error on make.)
When reading uncompressed bitmap data directly, readinto can work much more quickly than a Python-coded loop.
On a Raspberry Pi Pico, I benchmarked a modified version of adafruit_bitmap_font's pcf reader which uses readinto instead of the existing code. My test font was a 72-point file created from Arial.
This decreased the time to load all the ASCII glyphs from 4.9 seconds to just 0.44 seconds.
While this attempts to support many pixel configurations (1/2/4/8/16/24/32 bpp; swapped w...
To customize the board i think a firmware configuration file could come handy.
The file should stay in the botsel part of the storage and should allow some basic configuration of the device.
The configuration should be applied on each firmware update so the configuration will always be the same even if the defaults in the firmware itself changes.
It could look like this
`
[GENERAL]
FileSystem="FS Label"
[USB]
USB_VID = 0x239A
USB_PID = 0x804C
USB_PRODUCT = "PyRuler"
USB_MANUFAC...
Although I cannot find it documented anywhere; looking at _pio_find_offset_for_program() in sdk/src/rp2_common/hardware_pio/pio.c, it is checking if the program origin is >= 0 and, if so, using that origin to look for space. As a result, with the default origin of 0 then pio_can_add_program() will fail on the second attempt to add a program. This limits CP to only adding one program per PIO. This was the cause of issue #4237, where the third call to rp2pio.StateMachine() would fail. The fix...
Maybe it would be best to keep this information in the bootloader? https://github.com/Microsoft/uf2/blob/master/cf2.md
I get this error when I attempt to make the uf2 for PyPortal with this branch:
β― make BOARD=pyportal
Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
QSTR updated
../../shared-module/bitmaptools/__init__.c: In function 'common_hal_bitmaptools_readinto':
../../shared-module/bitmaptools/__init__.c:365:35: error: comparison of integer expressions of different signedness: 'int' and 'size_t' {aka 'unsigned int'} [-Werror=sign-compare]...
Thanks @FoamyGuy , the CI saw it too. I've attempted to correct it.
Really nice speedup! I tested this successfully on Feather RP2040 and a PyPortal. I saw a 4x speedup loading the yasahsi-ascii-200.pcf font with the bitmap_font library that utilizes this.
@kevinjwalters please test/review!
Hi! Thanks! It's Piper's call ultimately, but I and Shree are both advocating for it. It's not currently because when we started a year ago, we started with a different internal project and just kept it closed while we developed it. And we've been so busy trying to get it finished an polished that we haven't had a chance to even have those conversations! At a minimum we need to go through the whole repo and add in all of the appropriate licenses! I'd really like to publish the web REPL we developed. It's actually pretty simple, and it's mostly a matter of carefully tracking states and using the paste-mode. There are a couple of weird things with a couple of characters that need to be compensated for, but nothing serious.
I have a repo for a in-browser terminal that I wrote when I was at Parallax that I adapted for web-serial use here: https://matzelectronics.github.io/uTerm/web-serial.html
It's a little rough and doesn't do any of the state management that the Piper Make project does, but it does work π
Also, we realized the FileSystem Access API in Chrome is really good for writing files/firmware to a device, too - so that lets us provide a way to install CircuitPython right from the site.
are circuitpython dicts still unordered?
Did some searching in PRs, issues, and docs but have missed a mention about it if there is one. if not where should one PR a change to reflect that?
from testing on 6.1.0-rc it seems like they are but it's hard to test as if they aren't the ordered-ness could be coincidental...
I think the orderednes would be coincidental?
at least last time I checked but that was before 6.1
how would you suggest testing? I've been trying **kwargs and manually writing literal dicts and thee always mirror the entry order but as you said...
ah. nm, took fiddling but found a case that is out of entry order.
it was on my first try heh, I got lucky I guess.
This PR includes two changes in documentation in the C files to display in the readthedocs. Adding to examples of usage::
- RTC: add usage of the calibration setting
- Touchin: add usage example of the threshold setting
This changes were tested doing a local built of the documentation. See pictures


Thanks! CI failure seems unrelated. Decided to install every version of awscli that ever existed, then announced they all conflicted. Haven't seen that before.
thanks! CI failure is unrelated.
@microDev1 ping -- did the above comment enable you to move forward or are you still stuck with the same problem when reverting py/qstrdefs.h?
API doc is here: https://docs.python.org/3/library/collections.html#collections.OrderedDict.move_to_end
Code would be added to: https://github.com/adafruit/circuitpython/blob/main/py/objdict.c#L563 It'll need a separate locals so that move_to_end isn't added for regular dictionaries.
This will fix https://github.com/adafruit/Adafruit_CircuitPython_BLE_BroadcastNet/issues/18
This looks like a cool addition. I havenβt tried yet but have a few questions since I couldnβt follow all the code with all the bit operations.
- Does this require that the dimensions of the destination bitmap and the file bitmap are the same?
- If the color palettes are different bit sizes or number of colors, how does it handle this?
- Also how do I get the palette colors from the file into a new pixel_shader palette object?
If Iβm missing something important about the main goal of ...
I would love to see some kind of powersaving / sleep functions for the RP2040 / Raspberry Pi Pico.
I think that is one of the key features missing for CircuitPython on the new Pi Pico board are some Sleep funktions!
For me the reason choosing a Pi Pico over a ESP32 is the lower powerconsumption for projects needing no WiFi!
?serverinfo
Woah, 28k!
Woah
Does this require that the dimensions of the destination bitmap and the file bitmap are the same?
Yes, it always reads all widthΓheight pixels. (oh, and rows of pixels always go from top to bottom, which is different from at least some BMP files)
If the color palettes are different bit sizes or number of colors, how does it handle this?
Whatever displayio_bitmap_write_pixel does.
Also how do I get the palette colors from the file into a new pixel_shader pale...
Is there a way to check the formatting in the CI via pre-commit?
@tannewt I have added formatting check to pre-commit along with translations check.
did the above comment enable you to move forward...
@jepler Thanks! for digging into this. :)
The qstrdefs issue is resolved. I disabled the formatting on it.
// *FORMAT-ON/OFF* for C and # fmt: off/on for Python can be used to limit formatting.
Seems like CI is still failing at Test all but the tests are different this time... any ideas?
I notice that the docs state
When the TouchIn object is created, an initial raw_value is read from the pin, and then threshold is set to be 100 + that value.
I doubt that all ports do exactly this, so the docs may need to be updated, but basically I think that for other platforms we've found that adding a constant to a value that is assumed to be the 'background value' was an effective but simple way to set the initial threshold.
@dhalbert didn't you add this checking to all platforms when you added the 2nd CDC? If so, please close.
See also #1015 about making USB descriptors configurable. I think we favored the idea of doing it in Python code from boot.py over having a "configuration file" in another language.
Note that the filesystem label is set just once when the storage is initially formatted (or re-formatted via storage.erase_filesystem()) rather than each time the device is plugged in.
This could also have been related to #4377 and fixed for good by #4392
I notice that the docs state
When the TouchIn object is created, an initial raw_value is read from the pin, and then threshold is set to be 100 + that value.
I doubt that all ports do exactly this, so the docs may need to be updated, but basically I think that for other platforms we've found that adding a constant to a value that is assumed to be the 'background value' was an effective but simple way to set the initial threshold.
The threshold is in shared-bindings,...
Added board configuration files for the Sparkfun ThingPlus RP2040
Builtin NeoPixel, LED, QWIIC port and build-in micro-SD slot all tested and working with the updated pin definitions.
I didn't even know there was an issue :). FIxed by #4215.
The problem is due to the added line in cmd_showbc.py. As far as I can tell, when the expected file has something like
########
bc=\\d\+ line=155
it searches for a line that matches this regular expression, and then checks all the subsequent lines until the next ######## for also matching as regular expressions. However, line 155 has become line 166 due to the added line, and so forth
https://gist.github.com/8293402cffa2d8dfc3bbc80786988151 fixes this test by updatin...
After a soft restart, the pins change to gpio mode. After re-initialization, change the pin mode to spi or i2c.
Empty rx uart fifo to remove characters that were received during initialization.
Looks good to me. Thanks
@jwcooper are you still the correct person to review this?
Thanks
Thanks for your detailed answer!
hey can someone pluck me with the circuitpythonistas role? I figure tuned in enough notifications should be helpful for me to pay attention π
Got you added to it. Thanks for joining. There is a meeting in a few hours today if you are interested in participating.
Thank you! That was the big reason, I typically always miss them and just listen on YT afterwards, but it's quiet at the office today so I figured I'd give it a shot listening live :]
@opaque abyss Welcome! Looking forward to possibly seeing you in today's meeting!
btw, I just tried https://matzelectronics.github.io/uTerm/web-serial.html and it can connect, but when I see Press any key to enter the REPL. Use CTRL-D to reload. and then type anything, it disconnects. I did get it to stay connected at one point, but I'm not sure why. This is the same behavior I saw with the Google example. It may be some odd DTR thing?? I imagine you have solved this in PlayPiper.
Ty! Y'all are all so friendly π
Me trying to enter hug reports while @slender iron updates the notes doc. type type type type ......... where did everything go...? oh right. scroll scroll scroll
sorry about that! I figured now was better than the hour before the meeting
No worries π It caught me off guard the first time, but the subsequent four times simply made me laugh.
It was like my ADHD was somehow made tangible... I would look away, and then everything I was typing was gone....
I really should have expected it. I wouldn't be too concerned about warning folx.
It happens to all of us at some point π
Scroll scroll scroll certainly beats a "This file was modified, would you like to reload it? Clicking 'Yes' will lose all your changes"
@slender iron @onyx hinge FYI I can't take notes next week because there is a scheduled power outage and I will likely be tethered and working from my laptop only. So Jeff is apparently hosting, Scott if you could take notes or arrange for Melissa to do it, that would be appreciated.
Ya, I can do it
Cheers.
Not happy about this at all. They're repairing or installing something that requires the entire building to be offline. Including elevators.
Yuk. I hope it's not too cold, or that heating isn't fully dependent on electricity
Oh, it does require electricity. However, this stupid place heats up like an oven all the time. We literally never turned on the heat all winter. And kept the window open about 98% of the time. It's so bad. We really need to move but circumstances are preventing that for now.
I guess that's good on the hydro bill if the source of the "natural" heat isn't related to yours, but ouch. Too hot is, for me anyway, worse than too cold.
Same for me. It's so awful here. And they don't turn on the AC until like June or some such nonsense. We had to get a "portable" unit last year, that we're technically not even supposed to have, but they made it kind of a necessity.
Looping over common_hal_busio_spi_try_lock() in C will not succeed if it doesn't work the first time: If foreground Python code has locked the bus, it has to be able to proceed in order to unlock the bus. I don't think we ever un/lock the bus from an interrupt context.
"We'll turn on the A/C when we hit 35C+ for 7 days in a row. If you don't like the heat, why do you live so far south?"
oh wait Kattni said next week.
Yeah. I actually remembered something ahead of time for once.
Sorry for the fright π
No worries, I miss review requests from time to time as well.
@tulip sleet Are there any CircuitPython boards that wouldn't have board.LED except for QT Py (and anything without a tiny LED)? Or is that pretty much standard?
i think there are some that are just board.D13, or maybe board.L. We haven't been as consistent as we should be about the names. Also sometimes there's board.RED_LED and board.BLUE_LED or something like that, because there's more than one and we wanted to distinguish them. Maybe Feather nRF52840.
i'd have to look
@tulip sleet Hmm ok. That's what I was worried about. D13 doesn't work for all of them, but if they all had LED, that would work. So I figured I would ask.
yea, feather 840 is
{ MP_ROM_QSTR(MP_QSTR_L), MP_ROM_PTR(&pin_P1_15) },
{ MP_ROM_QSTR(MP_QSTR_RED_LED), MP_ROM_PTR(&pin_P1_15) },
{ MP_ROM_QSTR(MP_QSTR_D3), MP_ROM_PTR(&pin_P1_15) },
{ MP_ROM_QSTR(MP_QSTR_BLUE_LED), MP_ROM_PTR(&pin_P1_10) },
hmph.
so L or RED_LED
π Bleh.
it doesn't mean we shouldn't clean these up, but right now the consistency is not good
Trying to deal with the templating stuff, and realising it's still limited because of that inconsistency.
How hard would it be to fix, do you think?
I guess I don't even know how many boards we have anymore π
we have to make a pass over all the board pin.c's to add LED or L, and we have to decide
we have like 188 boards
or something ridiculous like that
Oi fair enough.
Did you sleep one hour more or one hour less? This is the week where I will be two hours too early or two hours too late... Hopefully my notes are ready.
Is the meetin in 1H20 from now?
spring forward, lost an hour, but I went to bed early
Yes, meeting is at 2pm New York time, so you can ask google what time it is in NY
Yes.
Less. π
Relative time is the best...
@tulip sleet I think L is carryover from Arduino, isn't it?
LED is at least descriptive.
yeah, I think so, at some point someone said "name it L", but I don't remember the circumstance; this might be a brief mtg topic
Ok.
for internal mtg
Right. Will do.
The PIO module can support a conditional jump based on a GPIO pin. However, the pin to use can't be specified in CircuitPython. Let's add it!
I hope we solved it, too! π That tool was one of the earliest proof-of-concepts and is not much more than Google's implementation. The one we are using for Piper Make is a bit more robust. I am curious, though - if you go to https://make.playpiper.com/?python=true&verbose=true and click New Project, then you can use the PYTHON tab at the bottom just like an IDE, and the CONSOLE tab is there too. The add-on to the URL is for debugging, so it won't save anything (changing the block code in any way will wipe out whatever python you type in). I'd be curious to know if you have the same sorts of connection issues there.
@modest hazel invalid ssl cert
might want to make sure that it's properly signed
a lot of browsers don't like self signed SSL
There is a free service called "Let's Encrypt" that lets you get signed SSL certificates issued. https://letsencrypt.org/
Huh - I'll let our server person know, thanks!
okay - it's too early in the morning for me. Try this one: https://make.playpiper.com/?python=true&verbose=true. Ugh, You'd think I'd know the site I helped build!!!
Let's Encrypt is cool if you automate the renewal of certificate... or be ready for a problem every 3 months.
ah yes, that's better
Sorry about that!
but the web page keeps crashing in safari
Particularly with azure hosted servers - unless they've finally managed to get an automated webjob working simply for it
much better in chrome
Yeah - only the Chorme-based browsers support the APIs we need for it. I'm still working on the Safari specific problem.
can we get #4362 merged in first thing today to avoid conflicts
the conflicts shouldn't be that big of a deal but I would like to keep the pr clean due to the scale of changes
@slender iron @onyx hinge ^^^
Thanks! @jepler. That solved the issue.
@analog bridge yup, that seems like a good idea to me
I did a preliminary review of some of the docs vs code:
I take a look at these libraries. order dictated by commit and oswalk function in python
- touchio
- rtc
- alarm
- display
- pulseio
- bitmaptools
I found that MP_DEFINE_CONST_FUN_OBJ_KW is used differently in depending on the library
bitmaptools: https://github.com/adafruit/circuitpython/blob/3cbff45f9aac5ea2855bbc888083d356a91c80fe/shared-bindings/bitmaptools/__init__.c#L243
bitmap: https://github.com/adafruit/c...
brb.
<@&356864093652516868> Meeting is about to begin
Good afternoon all you wonderful folks π
lurking text only
Make sure you mark it in the doc @still zephyr
the time's changed?
Greetings, good sir Mr. of Certainly!
@fossil gorge @still zephyr You don't need to mark lurking anymore in the notes doc π
@analog bridge ya, the US changed timezones this weekend
Oh, DST already?
Daylight savings time change in the US moved it.
Only if you have something to say, you can then add it to the notes.
I will be lurking anyway. π
just lurking
Meeting times are also available in iCal format using the following link: https://raw.githubusercontent.com/adafruit/adafruit-circuitpython-weekly-meeting/master/meeting.ical for use with standard calendar applications or in your browser: https://open-web-calendar.herokuapp.com/calendar.html?url=https://raw.githubusercontent.com/adafruit/adafruit-circuitpython-weekly-meeting/master/meeting.ical
On Pi Day 2021, Piper is releasing a new product, Piper Make, a browser-based coding platform based on the Raspberry PI Pico and a block-programming interface based on Google Blockly. Shree Bose is a co-founder of Piper, who is passionate about how encouraging children to create, build and make. She tells Make: Magazine about Piper Make and giv...
To contribute your own news or project, edit next week's draft on GitHub and submit a pull request with the changes. You may also tag a tweet with #circuitpython-dev on Twitter, or email cpnews@adafruit.com.
Self-promotion is totally legitimate too! Your project, or your friend's project!
π¬ π₯¨ π₯§
breaking the glassmalloc ceiling
lurking
candied pretzel pie?
looks comfy
the official chair of circuitpython?
if you say so
@ornate breach That actually sounds like a fun science experiment π
i love science π
Culinary challenge
I'm thinking a crust made from/similar to the Butter Waffle Cookies from Trader Joes.
@jepler doesn't the same apply to adafruit_bus_device? Or may run_background_tasks() lock SPI in one tick, and unlock it in another?
I made a cheesecase with a pretzel crust that was fabulous.
@veryalien @pimoroni @adafruit @CircuitPython @Gadgetoid @sandyjmacdonald Issues with the IS31FL3731 library are solved and I made @recantha happy with his 7x11 breakout.
I don't have the 5x5 hardware either, could you test this demo:
https://t.co/5ldkyQHd7o
with:
https://t.co/9DzDWx4BtU
Of course if @Pimoroni send me a free one... (hint).
Using #CircuitPython on the MagTag display C02 information from an SCD30 sensor.
While it is sleeping for 10 minutes in between reading, I need to find a way to power off the sensor or I2C when not needed.
Source code: https://t.co/8g04V2OHXm
@geomarster @pimoroni When I saw your tweet, I was working in #CircuitPython on the library for the Scroll pHAT HD on a Raspberry Pico.
There is an example that display an arrow, so I adapted it a bit. If you use Blinka on your Raspberry Pi Zero you could adapt this code:
https://t.co/6UfpG3JLFW https://t.co/9oEhEB6Vz6
One more board in my repo where I test pHAT/HAT with the Pico (in a Pi Zero form factor): Zeroseg by @Average_Maker for @ThePiHut
Lookup on @PiPinout + quick search for the #CircuitPython library for MAX7219, recover simpletest, adapt pinout and Tada!
π
@onyx hinge want to finish reviewing the formatting PR for @analog bridge ?
Sorry, I am a bit late.
@lapis hemlock No worries. Welcome!
I think I rambled a bit π
I totally missed the daylight savings.
An engineer is never late, nor are they early. They arrive precisely when they mean to.
nope, you are doing lots of cool things
@lapis hemlock We all wish we could miss it. In that it would be great if it didn't exist. π
oh yes belated hug report to @still zephyr for the doc improvements. Each small change makes it better
@onyx hinge Here's the approach I took to deal with US DST. Created detect_dst and adjust_dst helpers that work with structured time values. https://github.com/CedarGroveStudios/Unit_Converter/blob/master/docs/pseudo_readthedocs_chronos.pdf
@solar whale if you are using Linux for BLE, the bluez library used underneath bleak and adafruit-blinka-bleio treats the battery service specially (big π¦ ), or at least it used to. This is fortunately not true for CircuitPython native or AirLift BLE.
@errant grail thanks! Part of the WWVB signal are 2 bits of information about DST: 0 = DST not in effect, 3 = DST in effect, 2 = DST begins this UTC day, 1 = DST ends this UTC day. (I think, from memory). So in principle you don't need DST rules (aside from an "is DST observed at all" flag, and of course your standard time offset) .. HOWEVER, the bug was: when the UTC day changes (by counting up using the local RTC), but you don't have a new successful WWVB signal reception yet to get the DST flag value of 3, you still calculate whether DST is in effect while assuming "DST begins this UTC day", i.e., you revert to non-Daylight time..
so I WANT to keep using the bits from WWVB, and the fix is to change the DST flags from 2->3 or 1->0 when the UTC day changes..
@tulip sleet Thanks -- First attempt is with an nrf52840 -- I'm sure I'll have questions...
(oh and of course you assume which local hour DST begins or ends)
@tulip sleet Is there even remotely a way to automate updating the board defs, or is that going to need to be manual across the board....(no pun intended, but I'll let it stand)
Ah. Nice that they provide the logic but the success latency is concerning. The helpers I referenced were designed to work with local time and could be used to update the local structured time value when you're in the transmission dead zone.
Basically I don't mind if manual is the answer, but I want to make sure I'm not wasting time doing it manually.
It would be manual, but it would be possible to find all the relevant pins.c easily. This is the kind of thing I would do in emacs in 20 minutes after preselecting the files to edit
I wonder if something could be added to adabot to check the pins file and modify it if it doesn't contain the correct pin name?
and of course we'll work through it with you here on Discord if you run into trouble with the new formatting checks!
Heh fair enough.
having pre-commit is highly recommended
There's too many differences in boards I think for Adabot to do it. Plus I don't think Adabot is designed to affect the core.
we'll have to figure out how our mac and windows devs can set up the new stuff, there may be complications too
@idle owl i would look for all pins.c with MP_QSTR_*LED*, MP_QSTR_L, and MP_QSTR_D13, and then edit those files.
Yeah sounds good.
colorsys from Cpython would be great...
And adapting example and learn guide to use that (or fancy LED)
Yes we are talking hee about styling, not the conversion functions
If you take rainbow example from Pimoroni for Pi, they use colorsys.
So having it work the same way would mean reuse of those example directly.
CPython way.
Learn how to install and get started with your Blinkt!
cool thanks
@idle owl I semi-automated made some lists of files based on L / LED / D13 ... https://gist.github.com/jepler/03e26d9e1df6f17982d1062c69522429
Nice!
Sorry, I don't have mike at the moment.
np, I can read off your idea
Which other objects could benefit from adding the buffer protocol?
I can help with that.
We have ulab.array.tobytes, which is a buffer.
Right, I do.
@onyx hinge Yeah, the latter lists are what I need. Ones that don't have LED. Thanks! Part of the issue is that some use a pin other than D13, but we'll stumble on them eventually. This is a perfect start.
I would call out to kmatch98 π
I am also open to adding tools on my side,
@thorny jay could you ping me in the issue?
Listening to this maybe Iβve got to go past my current forest of weeds and into new weeds to learn about dealing with the bit packing into bitmaps.
clone and use grep ....
Well, if there is a constraint, we have to find a workaround.
@onyx hinge Do you mean this: https://pypi.org/project/git-grab/?
"git grep"
Seach was also important for German error message... π
it is a built-in sub-command of git
@onyx hinge OK, thanks!
Searching locally hinders over-the-web collaboration.
I can't just send a link to someone else.
@slender iron is this the one: https://github.com/ggreer/the_silver_searcher
Thanks!
Permalinks is what I meant.
@thorny jay one minor speed up for array functions is to replace the tuple indexing into a calculated direct index.
image_bitmap[h, w] = inta[index]
Would be something like:
image_bitmap[h * image_bitmap.width + w] = inta[index]
But please double check my math calculates the right index before using! For some reason accessing by tuple is slower than direct.
@mental nexus But that still iterates on inta, and that is slow.
Thanks! π
Forks are only indexed for code search when they have more stars than the parent repository https://docs.github.com/en/github/searching-for-information-on-github/searching-in-forks
hmmm that's not quite what I remembered
By default, forks are not shown in search results. You can choose to include them in repository searches, and in code searches if they meet certain criteria.
Playing with ulab, I found it was costly to copy from an array to a display.bitmap.
ulab can build a buffer: ulab.array.tobytes
Here is the current fastest way I was able to copy:
image_bitmap = displayio.Bitmap(24, 32, number_of_colors)
inta=ulab.array((npframe-min_t)*factor,dtype=ulab.int8)
index = 0
for h in range(24):
for w in range(32):
image_bitmap[h, w] = inta[index]
index+=1
so maybe the answer is find us 10,000 more stars on github
Thanks everyone!
Thanks
Thanks
Thanks all!
Thanks.
@modern wing Thanks for playing the court jester!
@lapis hemlock ?
@modern wing What is exactly the question?
Sourcegraph is a web-based code search and navigation tool for dev teams. Search, navigate, and review code. Find answers.
Dropping off. Thanks folx!
@lapis hemlock Court jester?
for i in range(768)
image_bitmap[i] = inta[i]
That fail for me. Because the bitmap is two dimension.
@slender iron Please ping me when you put in the PR for the newsletter updates today.
π
Sourcegraph is a web-based code search and navigation tool for dev teams. Search, navigate, and review code. Find answers.
@ionic elk also the request for you to review that pwmio came via the internal meeting
signing off, thanks all!
SourceGraph is nice, not gonna lie. I don't know what their licensing/pricing is like though. There's some free "up to a point"
Basically, what would be needed is a way of passing the bytes of an ndarray directly into the bitmap. One option would be the tobytes array method, if displayio could accept a buffer. https://micropython-ulab.readthedocs.io/en/latest/ulab-ndarray.html?highlight=tobytes#tobytes
lol
I do enjoy the deep dive.
Have a good week. Dog is demanding a walk.... π
@onyx hinge Does git ls-files -z "ports/*/boards/*/pins.c" | xargs -0 grep -l MP_QSTR_.*LED | sort > has-led.txt catch .RED_LED and .LED properly?
I mean this is a perfect start and we can catch the oddities as they come up, but I wanted to make sure.
Because there is at least one board with RED_LED and BLUE_LED.
It looks free to me for public repos
@idle owl yes I think it should
Right on.
While the other two were exact word searches
Right
I'll start with your lists. Better than I would have done, I'm sure. (I would had had help though.)
@onyx hinge Even if there's work on the core, as long as no one is editing pins.c, there won't be conflicts, right? I think that's right.
Should only get conflicts when two people work in the same file
Ok that's what I thought.
Rebasing still messes me up every time, so I try to avoid it.
I hear you
Ok, so here is my git status: ```1800 kattni@robocrepe:circuitpython [67m main *= 05ed179e1]$ git status
On branch main
Your branch is up to date with 'adafruit/main'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
(commit or discard the untracked or modified content in submodules)
modified: extmod/ulab (new commits)
modified: frozen/Adafruit_CircuitPython_CircuitPlayground (modified content)
modified: frozen/Adafruit_CircuitPython_FocalTouch (new commits)
modified: frozen/Adafruit_CircuitPython_NeoPixel (modified content)
modified: frozen/Adafruit_CircuitPython_Register (new commits)
modified: frozen/pew-pewpew-standalone-10.x (new commits)
modified: lib/mp3 (new commits)
modified: lib/protomatter (new commits)
modified: lib/tinyusb (new commits)
modified: ports/esp32s2/esp-idf (new commits)
modified: ports/raspberrypi/sdk (new commits)
modified: tools/usb_descriptor (new commits)
no changes added to commit (use "git add" and/or "git commit -a")```
I did not make those changes (except maybe to CircuitPlayground) and would like to not have to deal with them. Do I have to discard them individually? Or is the git restore listed above what I need to get rid of them?
I did a git pull adafruit main before this.
That's strange. Here is a gist with the example of a "rotozoom" function written in python. It uses the calculated "direct" indexing into a bitmap: https://gist.github.com/kmatch98/27bc30076e015e8acd0ec7bae1af9c7a
Here it is at line 145:
if c != skip_index: # ignore any pixels with skip_index
# place the pixel color (c) into the destination bitmap at (x,y)
destination[
x + y * destination.width
] = c # direct index into bitmap is faster than tuple
# destination[x,y] = c
@mental nexus Adding the buffer keyword to the bitmap constructor would have the added benefit that you could "display" various things, e.g., the data in an ADC buffer.
@onyx hinge Is there an easier way to discard changes in submodules? Or should I be doing something else with those changes? stash says I have nothing to stash. I think the changes are all in submodules.
@idle owl If you don't have any intentional changes to submodules, then first fix to try is "git submodule update" in the top directory
Looks like they've updated since I last checked into it. Good to know!
@mental nexus Here is David's issue: https://github.com/adafruit/circuitpython/issues/4414
@onyx hinge oh, of course. sigh. π€¦
This whole thing? git submodule sync --quiet --recursive && git submodule update --init
first try with the pre-commit code formatting check was unsatisfactory. It is not running on the right set of files.
entry: sh -c "git diff --staged --name-only | xargs python3 tools/codeformat.py"
if the git diff names no files, then tools/codeformat is invoked without any files, and it does a recursive operation including submodules and ignored files
@slender iron Thanks!
@onyx hinge That worked. It's only the two that I think I manually changed that are showing changes now. Thank you.
Here is the notes document for Mondayβs CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youβll be attending the meeting - itβs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weβll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/11uksHbpF2KT8sBC9Bov9XLtSgM62HXAHUKVxKhjr5cE/edit?usp=sharing
CircuitPython Weekly for March 22nd, 2021 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 participate...
I think pre-commit has its own ways of knowing what files to work on, unfortunately this rule doesn't pay attention to it. Or maybe it's only for determining whether to run the check or not? In any case, I think the way it's written doesn't work with pre-commit run --all
--all or --all-files, the thing is that this uses git to say 'what files are "staged for commit"' and run on just those files: entry: sh -c "git diff --staged --name-only | xargs python3 tools/codeformat.py"
so it won't run on main.c unless main.c is "staged", which is git parlance for "has a change and you've requested it to be commited with git add or other means"
Oh I see
@analog bridge what version of uncrustify is required? I get a whole lot of messages which imply that maybe I have something wrong. ```$ python3 tools/codeformat.py main.c
/home/jepler/src/circuitpython/tools/uncrustify.cfg:41: unknown symbol 'disable_processing_nl_cont'
/home/jepler/src/circuitpython/tools/uncrustify.cfg:70: unknown symbol 'sp_do_brace_open'
/home/jepler/src/circuitpython/tools/uncrustify.cfg:73: unknown symbol 'sp_brace_close_while'
/home/jepler/src/circuitpython/tools/uncrustify.cfg:76: unknown symbol 'sp_while_paren_open'
Have you tried the formatting for the shell commands from the cookie-cutter repo? I had an odd time trying to get shell commands to work correctly
Uncrustify-0.68_f
``` this is the version in Debian stable (buster)
Basically, this for the hook (with name, etc)
entry: /usr/bin/env bash -c
args: ['([[ ! -d "examples" ]] || for example in $(find . -path "./examples/*.py"); do pylint --disable=missing-docstring,invalid-name $example; done)']
language: system
So you put the call to the shell in the "entry" field, and the script/commands/etc in the 'args' array
I don't think it's a quoting problem or anything like that, the command is simply .. not doing what is desired.
This adds the "no-run-if-empty" flag to the xargs invocation. Otherwise, if git diff names no files, the command is run once with no agument specified which leads to running on a default list of files that appears to include ignored files and files in submodules.
I am uneasy about how this works (it means that pre-commit run --all doesn't actually check all files) but that's a separate issue.
This isn't right either, because during CI we appear to depend on exactly this behavior to run the formatting at all.
OK, so to answer my own question you must have a SPECIFIC version of uncrustify, which is NOT IN DEBIAN OR UBUNTU, but only in a "ppa".
Get:6 http://ppa.launchpad.net/pybricks/ppa/ubuntu focal/main amd64 uncrustify amd64 0.71.0-0pybricks1 [547 kB]
Ok it is working and faster, I was missing the ":" at the end of the for loop. But the error message was for the next line.
0.72 (debian testing) doesn't format the same either
@ionic elk you could do sleep on the rp2040
@thorny jay Thank you for posting an example to that colorsys issue.
OK I remain SUPER puzzled, because code format is reformatting a bunch of files for me, but it's "clean" on github in actions. So either it's not running during CI as expected OR I still have not replicated the setup
I wish I had looked more closely before accepting the PR.
Uncrustify-0.71.0_f
@onyx hinge I think this inevitable with such a large change. It's worth biting the bullet and working through it IMO
@slender iron I am willing to give the auto-code-formatting a try, but I need to be able to replicate the setup where it doesn't introduce 18,000 changes if I can expect others to do it as well
if you're available that would be great.
I'm on Debian but I installed the specific (intended for ubuntu focal) version of uncrustify that the CI is using
I'm in the valentina woice
ok give me 2 minutes to get to my computer w/mic!
kk
ps uww | grep uncrust
static void reset_devices(void) {
-#if CIRCUITPY_BLEIO_HCI
+ #if CIRCUITPY_BLEIO_HCI
bleio_reset();
-#endif
+ #endif
}```
The build failed at "pre-commit: Have pre-commit pass the list of files to codeformat.py" ( cc1dd73 ) so I added all the changes that the formatter made locally.
pre-commit run --all && git commit -a -m"run pre-commit"
- files = list_files(args.files)
+ files = list_files(args.files, EXCLUSIONS)
@mintakka Shouldn't the flash size be 16 as they're 25Q128 flash chips?
IE: #define TOTAL_FLASH_SIZE 8 * 1024 * 1024
Should be:
#define TOTAL_FLASH_SIZE 16 * 1024 * 1024 ?
Yes it should be, I missed that!
On Mon, Mar 15, 2021 at 6:26 PM falkenad @.***> wrote:
@mintakka https://github.com/mintakka Shouldn't the flash size be 16 as
they're 25Q128 flash chips?
IE: #define TOTAL_FLASH_SIZE 8 * 1024 * 1024
Should be:
#define TOTAL_FLASH_SIZE 16 * 1024 * 1024 ?β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython/pull/4411#issuecomment-799795954,
...
I'm interested in helping out on this and stretching my skills a bit to try to understand better how the bitmap structure is formed and modified. Sorry I didn't chime in during today's CircuitPython call, but I'm not very well versed in the terminology y'all use, so I have to do some digging to be partially intelligible when discussing this. Here goes:
As best I understand, to save memory the bitmap structure uses the minimum number of bits necessary to hold the maximum palette indices (...
args.files= ['shared-bindings/neopixel_write/__init__.c', 'drivers/wiznet5k/ethernet/socket.c', 'tests/cmdline/repl_basic.py']
files= ['/home/jepler/src/circuitpython/shared-bindings/neopixel_write/__init__.c']
<!-- Thanks! for testing out CircuitPython. Now that you have got a problem...
you can file a bug report for it. Feel free to modify the below format to better
suit your issue. :) --
Lastest firmware (git clone https://github.com/adafruit/circuitpython.git)
Error when building
Code/REPL
adding the line: CIRCUITPY_USB_MSC = 0
to /ports/raspberrypi/boards/pimoroni_tiny2040/mpconfigboard.mk results in a build error
Behavior

['a/c.h', 'a/b/c.h']
To erase the CircuitPython filesystem, use these commands at the REPL:
>>> import storage
>>> storage.erase_filesystem()
@slender iron if the problem comes back ... it was also because of the running-in-parallel that the first time we put check-translate in pre-commit, some people got empty files sometimes.
.. I bet
I've not used the C SDK. The documentation does not state what -1 would do: https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__pio.html#ga3571e3c7c6e645e92b8d438203a911b9 & https://raspberrypi.github.io/pico-sdk-doxygen/structpio__program.html (this is the matching data structure even though it's missing the _t suffix, the quantity is signed making -1 a legal value).
The actual source code can be viewed, I don't know if this matches the SDK in use but it does appear to d...
FYI, I think code sharing kicks in based on the assembed code object, sm1 and sm2 would need to refer to same assembled code to do this.
Unrelated, elite users with 32 bytes of pio code may get a disappointment: https://github.com/raspberrypi/pico-sdk/issues/261
probably having it configured with pass_filenames: False means it only gets one invocation, not parallel.
OK, I got rid of sed in codeformat.py
Here is the article based on the questions above: https://www.tomshardware.com/news/circuitpython-bootable-os-raspberry-pi
@ArielWolle wanna try submitting a PR where the line is behind an #ifdef or #ifnef (the url isnt working)
Thanks for the definition! Please rename the folder to sparkfun_thingplus_rp2040 because thingplus is a name used for the form factor. You'll also need to add the board to .github/workflows/build.yml
// Flash chip is GD25Q128 connected over QSPI
USB_VID = 0x1B4F
USB_PID = 0x0025
Why do you want this? boot.py is meant to store settings too.
@FoamyGuy and @kmatch98 (just invited you) please do the review.
Thank you, I will make these changes and re-submit
On Mon, Mar 15, 2021 at 8:43 PM Scott Shawcroft @.***>
wrote:
@.**** requested changes on this pull request.
Thanks for the definition! Please rename the folder to
sparkfun_thingplus_rp2040 because thingplus is a name used for the form
factor. You'll also need to add the board to .github/workflows/build.ymlIn ports/raspberrypi/boards/sparkfun_thingplus/mpconfigboard.h
<https://gi...
I believe this still may be an issue but I'm not sure with what scope. Its been a long time since I was thinking about it. I think a simple way to test could be to try and pass extra positional or keyword arguments to the APIs to see if they fail.
It hasn't come up recently, so the simplest thing may be to close it.
I would go further and think this should be disabled by default. This behaviour is unexpected and a small display like the 128x32 shows only two and a half lines. Of course with no useful information.
If someone really needs this output it should be explicitly enabled.
Maybe like this:
display = adafruit_displayio_ssd1306.SSD1306(display_bus, width=WIDTH, height=HEIGHT, rotation=180, console=True)
I strongly disagree. It's useful to know things are running and for most boards ...
@slender iron do you think it's worth defining a minimum number of WxH characters for a display to show the console? Right now you get the console on a 32x32 rgbmatrix and I think you can see an entire 2x2 character region of the console in all...
I'm open to it but it's still nice to see its working
we shift to showing the blinka logo if we can't show a single character, I think
idk, it's not a big deal to me either
We thought this was fixed by #4283, which was merged, so it should be in the latest source base. Could you paste the source URL again?
I've now added arrayblit.
You can blit the whole bitmap:
>>> b = displayio.Bitmap(8, 8, 256)
>>> a = array.array('H', range(64))
>>> bitmaptools.arrayblit(b, a)
>>> print([b[i] for i in range(64)])
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63]
You can blit just part ...
Spooky CI errors will have to be fixed first...
revised pull request with requested changes
I propose this:
- I will review the shared bindings in order to verify, the class definitions, a python "lexer" house-made could help here to compare with the documentation and the enum, and mp_check..
- Review the docs at the same time to see if we need add usage examples or correct return types.
whether the work is completed or not we close this in the summer 2021. I will do commits with the progress.
Adds appropriate board definition files for the Pro Micro RP2040 and adds it to the build.yml file.
So, the
ndarraywill somehow need to know thebits-per-valueof the bitmap, thewidth,height, andstride.
No, that should definitely be done on the bitmap's side.
In looking at the
ulab documentation, it looks like ndarrays can be decoded as 8, 16 or 32 bits. (I'm uncertain if < 8 bits can be handled directly in ndarray.)
Bits can't be stored even in `nu...
Can confirm this now working in latest nightly builds (cannot build myself due to M1 silicon config error). Might be that assignation of encoder pins A & B is flipped. I have :
encoder = rotaryio.IncrementalEncoder(board.GP3, board.GP4)
working in correct orientation (clockwise increment, counter-clockwise decrement), however,
GP3 is connected to B and GP is connected to A.
Switch the wires, the encoder goes the wrong way, or code as
`encoder = rotaryio.IncrementalEncoder(b...
If it is possible to edit those settings within boot.py i'm fine with it. I thought, the configuration needs to be available at the time circuit python is installed/updated.
The idea behind the bot-sel storge was that this configuration cannot be accidentally deleted and it would be easier to deploy because you just need to copy the configuration an the firmwarefile to the same directory.
Morning folks.... a new Mu (beta) has just arrived. We'd love feedback and any bug reports..! π We hope to have some new CircuitPython related features in upcoming releases, so watch this space..! Thank you..! π€ https://madewith.mu/mu/users/2021/03/15/beta2.html
Couple nitpicks otherwise the changes look good. Thanks!
I think we should point users to only 0.71.0.
I had a go with adafruit-circuitpython-raspberry_pi_pico-en_US-20210315-05ed179.uf2 and CIRCUITPY vanished again. I tried a device cleanse of just my two Pi Picos and that didn't seem to help but I was tired so might have missed something.
@jepler I don't think we have exclusions for submodules.
Arch and Debian only provide easy access to 0.72. We want to support Arch and Debian users, if it is feasible, rather than forcing use of Ubuntu.
During my work to fix the pre-commit process, I repeatedly had trouble because invoking codeformat.py directly did things that were undesirable. Do you see it as important to your workflow to invoke codeformat.py directly? (anyway, it's just advice, we don't stop you)
interesting, but not circuitpython: networking over USB for pico https://github.com/luigifcruz/pico-stuff/tree/main/lib/usb_network_stack
I think the uncrustify configuration while is version specific.
I fear running different versions might introduce conflicting changes.
Are you running 0.72?
Not important to my workflow but I didn't encounter any issues running codeformat.py directly.
If the pre-commit check fails on a PR the PR should fail to build right? I think mine last night still ran the build after. Just don't want to slow down other builds accidentally
The Build CI could still indicate code or docs specific issues but ya it takes a lot of time for it to complete and you will be pushing again anyway which makes it a compelling reason to cancel it. I gave this a thought earlier but wasn't able to come-up with any ideas as to how to achieve this.
Thanks, oh I think I see where i can cancel my own builds now too
I think a lot of CI time can be saved if we can somehow cancel previously running checks on a pr when new commits are pushed.
Yup, I can imagine (especially for people like me who this is still somewhat new to)
So I may need help from someone here, my PR has been around a while (due to my lack of time) and pre-commit formatting is now failing on formatting some files that aren't even part of the change.
My guess is with the new formatting checks these were fixed already but I don't have them? Not sure my best course of action at this point
Yes, both @tannewt and I used 0.72 locally. I used 0.72 locally when preparing this PR, and upon upload the CI ran 0.71 and didn't detect introduce any formatting changes during pre-commit.
Since I saw pre-commit with 0.72 introduce some changes compared to what you had committed (d3bf1fe15dd3720d6566e061a0d315add550b248) I verified that the same changes are introduced by 0.71. I do not know why these changes were not previously introduced, except possibly due to problems running on the right sets of files before the changes in this PR.
Okay, thanks for clarifying that. :)
Firmware
With 6.2.0-beta.2 and 6.2.0-beta.3 on a MagTag
Code/REPL
import sys
import ipaddress
import time
import wifi
import socketpool
import adafruit_requests
import ssl
import board
import busio
import json
MYSERVER = "HTTP/1.1 200 OK\nServer: WebSocket Server\nContent-Type: text/html\n"
MYHTML_LEN = "Content-Length: {}\n\n"
MYHTML = """
title {
text-align: left;
}
body {
background-co...
My Feather RP2040 does not behave very well. If it is unplug for 10-30 minutes, I can plug it, boot into Firmware upload mode, upload CircuitPython UF2. But I don't the CircuitPython drive, at best I see Windows complaining about "Unrecognised USB device". I sometime get a green LED and previously I was able to push code in the Feather. Is there a know problem? If I try to use it without that gap of time, then I don't even get light and I cannot go to UF2 mode. Is there a factory UF2 I could upload, or a known good one?
@thorny jay assuming you are using the "hold bootsel and plug in USB" steps to access the bootloader, then the problem cannot be CircuitPython, because the previously-uploaded UF2 data is not accessed in that case. Note that when you enter the bootloader, NO LEDS WILL LIGHT due to limitations of the RP2040 microcontroller. The only way to tell is that an "RPI-RP2" mass storage device becomes available on your computer. Also, if you have a battery plugged in to the feather, these steps won't work because the RP2040 microcontroller is looking at the BOOTSEL button when it is first powered on, and with a charged battery connected it would already be powered on.
https://learn.adafruit.com/adafruit-feather-rp2040-pico/circuitpython The reset+bootsel technique described here would work regardless of whether a battery is plugged in, however.
Yes the hold bootsel and plug. However, I do get the green LED at first connection, so that must be CircuitPython active (but not showing as a drive nor as a serial).
It must be hardware issue, I can get to the RPI-RP2. Sometime I can upload UF2 there. If I wait, Windows will lose the drive and complain about the USB device.
I would go ahead and document the problem here https://forums.adafruit.com/viewforum.php?f=57 as it's the official place for technical support and if it's damaged hardware they'll be able to get you a replacement.
Of course it can be all sorts of things like a dodgy USB cable or hub, etc.
Adds the following for adabot/lib/circuitpython_library_validators.py (used to update circuitpython.org/contributing):
- Additional ignored files for
validate_release_state - Validator to check the result of the last GitHub Actions run
The rest of the updates are ancillary to circuitpython-org...
I spent some time on the readinto function and it's working great. It shows a big speedup when loading PCF fonts, and a similar speedup for loading other BMP files. As @jepler mentioned above, some bitmap files are loaded in different row direction. I submitted a PR to give the option to reverse the row loading and an associated PR in the adafruit_imageload library to use this new .readinto function.
It looks good to me! I'll spend some time on the .arrayblit function later t...
Huzzah! Thank you for your work!
Hello. Is PULL working properly now in PIO on RP2040 boards?
@tannewt Seems like this functionality is still missing.
I plan to employ tud_ready() for this... it checks for usb mounted and not suspended.
@tough flax For the Feather RP2040 pinout image, I think it's good to go. My one question about the location of the CP pins I decided was fine, the board is labeled with the proper pins already, so it really doesn't matter where they fall in the diagram. I'll get it added to the guide. Thanks again!
sorry for pinging you. there is a "bug" where parts of the behavior you see will happen if you write a file to the rp2040 in the circuitpython. specifically, the "unrecognized device" you see. does your code.py (or anything you have) uses the io.FileIO library?
No I did not write a file from CP, only from Windows when it was possible. I was definitively capable of copying code on it at least once, and use Mu and see the console, and upload CircuitPython at least twice too. But to give this a it a try, I need to keep it without power for let's say 30 minutes. It is as if after being powered, some capacity(?) charge and then the behaviour change, and not using it make it "usable" for a few minutes.
it does indeed sound like an hardware issue
could it be some weird USB cache on the windows side ?
Did reboot Windows, tried on another windows, multiple cable...
have you tried micropython? just to see if the behaviour changes?
But yes, the "not recognised USB device" is not consistent, you do not always get it, as if Windows was like: "I already told you that device was bad."
Like, the micropython for the Pico? on the Feather RP2040? I could try... but not sure I know what to expect, I should practice micropython on a Pico first. π
i meant for you to try to put micropython instead of circuitpython in your device that's giving you problems
just to see if anything changes
@thorny jay what version of circuitpython are you using?
(I tried adafruit-circuitpython-adafruit_feather_rp2040-en_US-20210315-3cbff45.uf2 and adafruit-circuitpython-adafruit_feather_rp2040-en_US-20210316-921bf6d.uf2)
hrm, that should have my speed fix
Those are the two I have downloaded, so I believe yesterday I did a try and today the latest.
I suspected flash and I was not sure when it was added. That is why I was searching for a "factory.UF2" or a "test.UF2".
Great! You might stick your logo and a link to the product on there. Iβll be happy to help but you can probably just do it in the bitmap if you arenβt comfortable with Inkscape
yes, it should be
@tough flax That would be brilliant. I use Illustrator but I'm absolutely not comfortable with it. I'd greatly appreciate the assistance.
Sure. Send me any logos or Iβll just grab them from other files.
I'll get you something. Give me a moment.
@tannewt - I've addressed the required changes and I think it is ready for re-review
@tough flax SVG?
Yep! If you have them!
@tough flax Hopefully this will work for what you need.
Yep! BTW if anyone else sees any flaws in this pinout (or things I missed) nows a great time to let me know π
It looked right to me, but I'm going crosseyed from going through that table in the datasheet so many times.
@tough flax sorry for the ping, but, the pin on the bottom left side is labeled as D4, but the purple legend says 4
@idle owl do you have a feather logo or the rp2040 logo?
is that intentional?
That I'm not sure of. Let me look quickly. I definitely don't think I have the RP2040 logo. That would be something to locate from RPi I think.
@tough flax No I don't know where to find those logos. If you can grab them from elsewhere, great, If not, that's ok too.
Ok.
So all of the digital pins are just the numbers. I think thatβs been standard since Arduino doesnβt use the D. However in the past we had split (A0/27) style chevrons to show the digital names. I donβt think the rp2040 has that.
Part of the challenge is there isnβt an Arduino port yet
But I donβt think adding a βDβ would be consistent https://learn.adafruit.com/assets/78438
oh, i was just asking because of the "D" there on the board, while the others don't have it
@tulip sleet I've started adding LED to board defs. The list is long and so I think I'll do a little every day I have time instead of trying to do them all at once. The PR I'm about to put in is required for a guide to work that still isn't ready to be published, but ideally would be merged reasonably soon.
but googling it seems to show the board has the "D" on it
In CircuitPython, all the numbered pins are D##. But there's not room on the silk to include the D on every pin. So it's only included on one in this case.
It's implied, I guess.
Sounds good - if you need help due to time let me know
Feather M4 is the same, only D4 has D on the board
yes, and that makes sense
this link has information about the battery (lipo). you think it is a good idea to add that info to the image too? (and sorry for pinging again)
Thinking about it @idle owl I have the schedule for that final feather pinout. Would you like me to add the onboard components section and the logos from that?
In this case, I'll ping you on the PR. That's the only time sensitive thing at the moment. She'll have me working backwards in time to update the board guides, so each time I find one without LED in it, I'll do another PR with a bunch.
Sure, if you'd like to. The more information the better. I don't entirely know how much of that is on the RP2040. Might all be the same, but it's worth checking.
I mean I wrote the guide, but I didn't memorise the components π
I think I can put the same columns (uart, spi, etc) on the pins for the QSPI and neopixel. I need to check if thereβs a battery monitor pin
And I can stick the little battery connector in
@idle owl Since I saw you were active working on the bno08x library, I thought I' point out that the guide refers to an adafruit_bno08x.mpy file, but there is none -- it is an adafruit_bno08x folder with .mpys in it -- came up on the forum https://forums.adafruit.com/viewtopic.php?f=60&t=176831
sorry about that
Oh! Can you send me an email? Easier for me to track. kattni(at)adafruit.com
No worries π
@lone axle You've dealt with the new licensing stuff on the libs right?
I'm trying to tell someone what they need to add to their example to make it pass CI. Will the following be sufficient? ```# SPDX-FileCopyrightText: 2021 KC YUGESH
SPDX-License-Identifier: Unlicense```
I think so. I've dealt with the reuse check that is now in pre-commit and adding the files that satisfy it.
Yep, I believe so.
Ok thank you. They're a first time contributor so I'm trying to help as much as I can.
gnerally speaking I think it also needs a matching file in the LICENSES dir. but Unlicense is a commonly used one It's most likely already in there.
ok Good to know thank you
@tough flax the PWM pins are marked with a sine wave instead of a square wave
So, all this that I wrote below might end up being an exercise in futility, since it can't keep ticking while off, but for retaining
I went and checked, and yes the bootloader does use NRF_POWER->GPREGRET (but not GPREGRET2) , however it only clears it if it's going into DFU mode! (Usage in bootloader source)
So that's something, as long as it didn't use the [magic values](https://github.c...
@solar whale Does that mean all the example code in the guide is wrong too?
No. It should be fine. I have never used it
Ok. It has import adafruit_bno08x. Does that work with packages? I'm second guessing now.
It imports from adafruit_bno8x.something
hmmm -- not sure why the import adafruit_bno08x is even there....
Fair enough.
just a sec -- I'll try it
Cheers
ok then I'm leaving it. I don't have one to update the screenshots anyway
Thanks!
I updated the guide to reference a folder instead of a file
If you want to let the forum poster know, that would be great
or maybe it has to be there -- I'm really not sure ....
if it works, I'm ok with it regardless.
I'lll add a note to the forum -- thanks!
I've updated this on top of main, let's see if it allows CI to pass now.
Thatβs a long standing style on all of the pinouts
@shy rain are you around?
@slender iron Hey yes I am
just looking at the naming of the rp2040
the samd51 board is sparkfun_samd51_thing_plus
looks like the sfe product listing has the chip last though
I did see that. Youβd prefer to align for consistency?
That makes sense I can change it
I'm torn between consistency in circuitpython vs consistency with the product name on the sparkfun site
Yes I named per the product page initially
ok, that's ok with me
the nice thing about having thing plus earlier is that it'll list them all together then
Haha sometimes happenstance works out nice
No in their documentation they are two words. I think itβs one word in the pico-sdk which is where I actually took the naming from initially
The sparkfun_thingplus.h file in the sdk i mean
I can check the history to see who added it
looks like it was pi folks
I think itβs your executive decision, whatever you want is how Iβll name it and update if needed
#define MICROPY_HW_BOARD_NAME "SparkFun Thing Plus - RP2040"
A few minor things. Sorry I didn't see them in the first round of reviewing.
kk, thanks @shy rain. sorry I didn't post this yesterday
No problem! This is my first PR so Iβm just pumped to be helping
thanks!
#define MICROPY_HW_BOARD_NAME "SparkFun Pro Micro RP2040"
Two minor capitalization changes. Good otherwise. Thank you!
USB_MANUFACTURER = "SparkFun"
The UF2 file is copied to a fake drive so no other files can be copied with it. boot.py runs before USB starts, so it can change what the USB device is configured as.
All change requests incorporated
It's worth trying a latest build. I believe there have been changes since beta.3 that may have improved things.
Those are great catches, thanks!
@jepler want to support descending pins too?
This code works much better now.
magtagserver.zip
Closing the sockets after use did the trick.
This seemed not to be a problem so much in MicroPython.
@jposada202020 Ok, take a bit of time to start looking into it. If you don't find any issues in 3 modules then I'd suggest assuming the rest are ok. I don't want you to spend too much time on this.
@tannewt Suggested changes committed, thanks.
@onyx hinge thanks again for getting the formatting polished up
@slender iron you're welcome! I do enjoy working on tooling, even if I might cuss at it in the moment π Thanks @analog bridge for setting the stage
π
Thanks @onyx hinge and @slender iron for taking out time to test the pre-commit changes
@onyx hinge since you mentioned your enthusiasm for tooling work, I have got another thing coming up..
I am working on port specific tests to save CI time, I can do a crude implementation and if need arises you can do the final polishing π
as we don't have any tests that we run except on the unix port, I'm interested to see what you're up to..
its something like if the changes are only in ports/*/ directory then only run tests for the boards in ports/*/boards/
i a git cloned staright from the main branch url yesterday i will try again right now
Just tried rebuilding again using "git clone https://github.com/adafruit/circuitpython.git" and same issue works as soon as I take that line out
@analog bridge oh I think we have decided not to have the CI "take shortcuts" based on what kinds of paths are modified in a PR, if that's what you mean. I'd check with @slender iron before trying to change the CI like that, to verify my recollection.
ya I have this question too that whether a change in a port sub-directory will impact other ports
This is awesome! Iβm working on a project that sends rgb565 values from Max/MSP over tcp to the MatrixPortal and would love to use this.
It's possible it worked with my test board because I had CIRCUITPY_STORAGE disabled.
@ArielWolle which line exactly? Your link point to nowhere.
@slender iron should i merge the ParallelBus support? I saw you approved it but didn't merge it so just making sure there wasn't a reason for that
This sounds like a good idea to me! I would not expect changes in a ports directory to impact other ports
Google has a whole complex system that determines which tests to run on any given change :)
@gilded cradle Does the blinka displayio PR need testing or can I approve it w/o?
github user @wildestpixel notes that the rp2040's quadrature decoder doesn't allow the pins to be swapped in order. If feasible, allow the pins to be specified in either order, and if they are in the swapped order then switch the counting direction.
@idle owl it should probably be tested first.
@gilded cradle Ok I won't merge it. Rerequest a review from cplibians because I approved it. I don't have anything to test it with.
Ok @idle owl, you know what, I'll just test it really quick and if it works, I'll merge.
Right on. That works.
I added the line
CIRCUITPY_USB_MSC = 0
to the bottom of:
https://github.com/adafruit/circuitpython/blob/1be5ca7881a8aa8d32a783bc6a94994886463c30/ports/raspberrypi/boards/pimoroni_tiny2040/mpconfigboard.mk
From what I see in the datasheet, the QSPI pins on the RP2040 CAN be used for GPIO (including Analog input), however, they are not in the GPIO "Functions" table, so I'm assuming that they have no I2C, SPI, UART, or PIO functions... so, I don't think it makes sense to pull them out in the diagram as they inherently "can't" conflict with the pulled out pins. Thoughts? I do think it makes sense to pull out the Neopixel and voltage divider pins and even to add the "digital pin numbers" when they're known for the Arduino port.
Don't pull out the QSPI in that case. And it's fine to include the others. And update it once Arduino is available.
There is no way exposed in CP to directly use the QSPI pins as GPIO. They're dedicated to their purpose.
Do we have any idea what those digital pin #s will be? Making them the same as the underlying GPIO pins would make sense (that'd be 26-29) but that's just me (and isn't what the M4 did)
@onyx hinge I get that, but we pulled them out in the M4 because they DO have other functions defined on them so could cause conflicts
And I know that's unlikely in CP, but the diagram kind of needs to support Arduino as well (eventually)
No clue.
Ok, then they stay blank!
I see no voltage divider on VBAT to check battery level. Is this intentional due to power consumption? Or am I missing it?
Bill is this the answer? "Note that unlike other Feathers, we do not have an ADC connected to a battery monitor. Reason being there's only 4 ADCs and we didn't want to use one precious ADC for a battery monitor. You can create a resistor divider from BAT to GND with two 10K resistors and connect the middle to one of the ADC pins on a breadboard."
I knew I had seen it somewhere. π
@tulip sleet would you happen to be familiar with the port_enable_tick system? It is causing problems during sleep for me that appear correlated with file writes, and I'd like to know what I can tweak without breaking filesystem/MSC stuff.
Following on from a comment by @kmatch98 on adafruit/Adafruit_CircuitPython_Display_Text#116 about the difficulty subclassing/overriding Group, I've been trying to subclass Label with the example class GridLabel below.
# test polymorphism
import board
import displayio
import terminalio
import time
from adafruit_display_text import label
class GridLabel(label.Label):
def __init__(self, font, **kwargs):
super().__init__(font, **kwargs)
@property
def...
Transferring to CircuitPython as this sounds like a change is required in CircuitPython and not on the Pi.
I think this should also be y1 <= y < y2
Testing of the readinto function worked well. Just one minor type in the docstrings.
I briefly tested the arrayblit, function and it operated as described.
Any functions that use this will want to watch out for if the array values exceed the bitmap color depth. In this case the value copied is array_value % color_depth. If used with the skip_index value and the color depth is too large, you can still get the skip_index value copied into your bitmap (since it is the result ...
Currently there is no available methods for querying the color depth or number of bits used to represent each color in a bitmap.
This would be useful to check before performing certain bitmap manipulations, or if an automated palette is required.
Ok, @idle owl - here's everything ready to go (PNG, SVG, PDF, etc.)
@tulip sleet helped with some final details π
Beautiful!
A quick screenshot
I'll get it added to the guide. @tough flax How would you like me to attribute you? Is your name ok, or do you have something else you'd rather have?
Do the pinout diagrams normally show the stemma pins? I donβt remember seeing that on a board diagram before.
"Bill Binko of ATMakers" would be ideal, but Bill Binko is fine
First pinout diagram of a board with a STEMMA connector, as far as I know.
That's perfect, that's why I asked.
Very nice diagram @tough flax! Crikey!
That would explain it
The diagram looks really nice though
Glad you like it!
I made a video about how to make them a while ago ... will get link
@tannewt sounds like a plan. I will report my findings. And put the results here, so far I have not seen anything wrong, besides a "," missing here and there or an space, but I consider this more styling. Thanks.
Bill Binko from ATMakers.org has taken on the noble task of making accurate color pinout diagrams for some Adafruit microcontroller boards. He walks in the footsteps of pighxxx and others who firstβ¦
SWEET!
@tannewt yes, I would probably redo a lot of things, now that I understand better all things, and finally.... realizing the meaning of the word "shared-bindings". I will work on this during the weekend. Thanks For the time that you are taking with this, I am putting time myself too!
I created class PPController(busio.I2C) and encountered two problems, 1) it cannot get a lock via try_lock(), e.g. to run scan(), and 2) when an object instance is destroyed, it seems that it does not deinit() as any other uses of busio.I2C fail with ValueError: SCL in use. I've tried all sorts of debugging & digging through CircuitPython source files, and I'm kinda stumped, I can't see what I'm missing. π
Do you have some code to share?
Just learned that the STM32 Feather has a second USB OTG peripheral and that @meager fog was awesome enough to pull out the pins! https://tenor.com/view/wow-omg-surprised-scared-kid-gif-10714204
https://github.com/durapensa/CircuitPython_pico_pi_controller/blob/main/CircuitPython_pico_pi_controller/core.py
I'm transitioning some working but hacky code into the module here.
How do you initiating I2CDevice in the super().init... meaning what is i2c?
I see it know the first one got me confused
PPController should be passing thu all initialization to https://circuitpython.readthedocs.io/en/latest/shared-bindings/busio/#busio.I2C
I've been beating my head against this for a while now. Does anyone know if it is possible to set the current date/time to a running board with Micropython? I know how to get set/get the current datetime with an rtc (like the Adafruit Adalogger Featherwing,) but I'd like to set it to the current time in a program, so that time.time() shows the correct value. Does anyone know if this is possible?
oh right, PPDevice class is defined first. The naming is a bit confusing, as I2CDevice refers to the I2C interface on a board. perhaps PPDevice is better renamed to PPPeripheral.
is this in blinka?
lets changd channel and go to hep with circuit python
I'm unsure that there's a concept of 'board time'. https://docs.micropython.org/en/latest/library/machine.RTC.html might be what your'e looking for. https://circuitpython.readthedocs.io/en/latest/shared-bindings/rtc/index.html says that it "backs the time.time() and time.localtime() functions using the onboard RTC if present" but I"m unsure if the MP version does so.
Both Blinka & MCU CP. okay, moving to #help-with-circuitpython
Thanks - I was hoping to have it saved the other way around though, so that time.time() would return the real-world value, because I have another module that makes use of time.time() assuming it's right (it was written for cpython.) Since time: https://github.com/adafruit/circuitpython/blob/main/shared-bindings/time/__init__.c will return a value for time() I feel like it should be able to have an offset or something so that a realistic value can be set. Not seeing anything in there though. Maybe a pull request would be accepted?
do you mean the difference between time.time() and time.localtime(), or are you looking to set the hardware RTC's time, which can only be done through the RTC module afaik.
I'm trying to set the time.time() itself - if I just turn on my board and run time.time() it thinks it's 1/1/2000. I'd like to get the value back from the RTC and set it correctly, so that time.time() returns a realistic value
I can already set the RTC, but it doesn't work with the time module itself - so rtc.datetime is returning the right value, but time.time() doesn't
So when I turn it on, I'd like to set. time.setcurrenttime(rtc.datetime) -- or something like that
I think you need to use rtc = machine.RTC() first, and it should populate time.time() with values from the hardware RTC. Not sure though, I haven't gotten to this step in my own project where a Pico will receive time from a Pi vi I2C to set its hardware RTC, where the Pi is using an add-on battery-backed hardware RTC.
Unfortunately it doesn't look that way. When I do: "rtc = adafruit_pcf8523.PCF8523(myI2C) then rtc.datetime" returns the correct value,but still time.time() doesn't
it may be that MP rtc module doesn't populate the values in the time module; I guess you'd need to do your own time.setcurrenttime(rtc.datetime) in boot.py?
Sorry, I meant that I made that up - I mean that I can't find a method that does that, looking through the C code it doesn't look like it does that (though there is some micropython code in there that looks like it can use an on-board RTC but that doesn't look relevant)
At the risk of really shaving the yak, if you guys accept pull requests I'll take my hand at adding it?
is this what you are trying to do ?
>>> import time
>>> import rtc
>>> time.time()
1577836819
>>> rtc.RTC().datetime = time.localtime(1615939292)
>>> time.time()
1615939298
(I'm not clear if you are talking about Micropython or Circuitpython)
(and yes CPY accepts pull requests a plenty)
There is currently no way to public method to query the opacity/transparency status of the elements in a palette.
For replicating or expanding palettes it will be useful to have an opacity getter for a palette index. That would allow both the color and opacity/transparency to be replicated too.
Wow, that is exactly what I'm trying to do! Works perfect, thanks
That should be in the docs for adafruit-adalogger-featherwing probably π https://learn.adafruit.com/adafruit-adalogger-featherwing/rtc-with-circuitpython
I pulled that from the PortalBase library, which has a network.get_local_time() feature that I knew of
That's great, thanks @jaunty juniper
(it's conditional to the rtc module being implemented on the board)
and yeah that would be a good idea to document that there
actually I don't think so, as long as I set it every time in code.py - I just did something like this:```python
myrtc = adafruit_pcf8523.PCF8523(myI2C)
myrtc.datetimertc.RTC().datetime=myrtc.datetime
time.time()
1615918633```
(sorry one of these days I'll figure out how to format code)
(you can put ```python on a line to open a block of code and close with ```)
Thanks again. Setting it in code.py looks like it will work even if the board doesn't support the RTC module using that method it looks like.
no I mean on some boards import rtc will just not work because it's not implemented, like small M0 boards to make space, and the stm32 port
Ah, got you. Right now I'm only testing on the S2 and a Pico, might be an ok limitation though
Overall I'm working on a module for the Contrib library, a circuitpython version of the "schedule" library. Just released it on pypi, but doing some testing with RTC etc to make sure everything works right before doing the PR for the contrib
ooo that's very useful!
Thanks - I'm actually working on a plant monitor/watering system, but didn't want to have to implement my own scheduling system on those longer times (turn on/off lights twice a day, check and water once a day, etc). Much easier to have a library for it. Testing it out now, but now that I have the RTC figured out I can do things like: ```python
schedule.every(1).tuesday.at("20:00:00").do(telltime)
I went looking for exactly this a few days ago. Not finding it, was going to hack together something that just compared time.monotonic() in the while True: loop.
Awesome, hope it helps! I'm still testing, but for all the basic stuff it's working, I just needed RTC to finish longer term tests etc.
aligned board name in boards.yml with the folder name for the board in ports/raspberrypi/boards
This adds an is_transparent getter to determine the transparency of an item in a palette.
seems fine, didn't test. thanks!
Docs pass. Yay! Looks good to me.
hey @steep finch sorry to bother you. had a question about your circuitpython fork. I'm updating the adafruit_hid library to work with your modification and I see you recently changed the report size from 22 to 19, but I'm still counting 22 reports. am I misinterpreting something?
@kmatch98 thanks, can you leave an approving review?
Looks great. Thanks for the addition.
Sorry I was holding up the show. Didnβt realize the procedure for getting this released. All looks good to me.
@mental nexus thanks for being my reviewer on this one.
The recent addition of the bitmaptools.readinto function helps speed loading of bitmap files. This provides an additional input variable reverse_rows to flip the row order to accommodate the format of some bitmap files.
This is required for speedups to the Adafruit_CircuitPython_Imageloadlibrary: https://github.com/adafruit/Adafruit_CircuitPython_ImageLoad/pull/45
(Note: There were some doc string changes that appeared due to my manual merging. I tried to match the formatting ...
@lone axle I have a favor to ask.
it could give some data too

