#circuitpython-dev
1 messages Β· Page 34 of 1
I need to pass the Bitmap and Palette object to the Draw function. Thinking about it now I could just pass the whole gifio_ondiskgif_t struct and make it easier to read.
That abs on radius should definitely be removed. Thanks for noticing!
x&y math should have abs(). Circles are placed by their center point, so the math only needs to be concerned with the 1st quadrant. The other 3 are symmetrically mirrored with positive math. You could factor out the abs by doing signed math up to the end, but I think you might have to store 1 more variable if you did so. Dubious that it would read any better :-)
I'll make this change and submit a PR for it later on this evening.
@kvco I don't understand the point of the (int32_t)x * x, then. It does not recover the sign. What is the purpose of the (int32_t) casting?
oh no ! All the cookiecutter libraries are impacted by the jQuery issue !!!
this fix works https://github.com/adafruit/circuitpython/pull/7799/files
I'm having some issues around circuitpython hanging when using displayio. My current circuit uses an external SH1106 display, which is powered on and off using a separate controllable voltage regulator. I need to do this to limit power drain in deep sleep. The I2C rails are also connected to this switched power supply. My problem arises when the program ends - the power supply is turned off, but then I think circuitpython tries to display blinka (or an error message if there is a crash). This causes circuitpython to hang, and I am unable to connect via USB. I can see my laptop recognises that the USB device has stopped responding and eventually disconnects it. Access to the flash drive also stops working at this point
If I leave the display powered on then everything works fine. I've tried CIRCUITPYTHON_TERMINALIO=0 in the makefile - but still get the same problem
This is referenced in this issue: https://github.com/adafruit/circuitpython/issues/2791
@mystic flume call release_displays() before sleeping
I think it would be really useful to have an option to stop any terminal (and blinka) output to the display, either as an option in boot.py or when creating the displat
It's more of an issue during development, my device keeps freezing during testing if I get an exception
you could use atexit to release the display ?
@jaunty juniper I was just thinking that!
(as a workaround)
generally freezes are loops that should be checking for interrupted state π
a debugger can help find them
though most of those loops will keep usb alive
I'm still getting an error on soft reboot saying pin D8 is in use after release_displays is called
which is what ? The SCL pin ?
Sorry yes
looks like I2CDisplay doesn't clear the never_reset properly
I've found that deiniting the i2c bus in an atexit call fixes this bug
which will prevent it from being reset automatically
π that'll work
explicit deinit overrides never_reset
Yep - that works well enough for me now
Thank you all for your help - I can get back to my nerding now!
I2CDisplay needs to clear the never_reset state of the I2C bus when the bus isn't inline. This can happen if release_displays() is called before exiting the user code. This causes the I2C pins to be stuck in use the next time the user code is called.
I think I was using CORS to call from HTML and JS hosted by the local httpserver to a circuitpython device. That way I could iterate on the html and js without rebuilding and loading CP each time.
CircuitPython version
Adafruit CircuitPython 8.0.5 on 2023-03-31; Raspberry Pi Pico with rp2040
Code/REPL
import displayio
import board
import busio
import terminalio
from adafruit_st7735r import ST7735R
displayio.release_displays()
tft_spi = busio.SPI(clock=board.GP18, MOSI=board.GP19)
tft_cs = board.GP17
tft_dc = board.GP16
tft_reset = board.GP20
displayio.release_displays()
tft_bus = displayio.FourWire(tft_spi, command=tft_dc, chip_sel...
Is this right?
//| palette: Optional[displayio.Palette]
That covers that it can return None? if so yes that is right and I can commit that suggestion. It will always return something - even if it is None.
I'm able to do it this way:
import sys
import board
import displayio
import terminalio
display = board.DISPLAY # or equivalent external display library
splash = displayio.Group()
fontx, fonty = terminalio.FONT.get_bounding_box()
term_palette = displayio.Palette(2)
term_palette[0] = 0x000000
term_palette[1] = 0xffffff
logbox = displayio.TileGrid(terminalio.FONT.bitmap,
x=0,
y=0,
widt...
Terminal should verify that the tilegrid is more than 1x1 and raise an exception if not.
@dhalbert widening. So that circles at 256 < x or 256 < y can still be handled. I have some Adafruit displays with more pixels than that ;-)
If you multiply 257 * 257 int16's what do you get? :-) On the other hand, if you widen to int32, you can support nearly every positive position of int16 x and y. Ideally we'd widen to uint32 instead though because (2^15)^2 * 2 is 2^31, and that's 1 greater than 2^31 - 1! But it fits no sweat in 2^32. Int16.minval x and y will position at 0 I think. So v...
@slender iron I think I got the jquery issue wrong, though I'm not sure that I understand what is going on. There was something about the version of the theme being invisibly forced on older libraries or something ? I believe @lone axle would know about that.
The issue is that right now, none of the Adafruit libraries that I looked at have a working bottom left panel.
I haven't been following it so I'm not sure what the right thing to do is
Being explicit may be helpful but it's also the case (as far as I know) that the arithmetic will actually happen according to C promotion rules in "int" type, which is always 32 bits for us. On an 8bit micro it could be different but we're on 32 bits only.
Yea, another esp32 board.
I still need to go find CIRCUITPY_CREATOR_ID & CIRCUITPY_CREATION_ID.
Other than that the port is good.
I should maybe configure a VBUS_SENSE pin alias, but not sure.
Creating as draft, till I get these things sorted.
Uhh. Why are we returning 3.3 on rp2 when on esp we return None?
Isn't it a horrible idea presenting a fake value?
are you using it?
Not really..
its probably a mistake
Shall I None it in my ttgo pr?
sure, that's fine
(background: https://github.com/adafruit/circuitpython/pull/2213)
[Regarding](#circuitpython-dev message) rp2 voltage reporting being set to None.
tl;dr it was fake all along, and did not comply with docs which say it should be reported None.
@slender iron Question for the DVI PR, Testing now, would adding elements to a displayio.group would have any effect in the display dimensions?
it shouldn't
So I personally prefer to be explicit when bit width matters... I always forget what the rules are for implicit widening within a math expression :-( and whether I'm on an 8, 16, 32 or 64 bit pointer machine :-(, so it helps me read it. Maybe it's helpful to other people reading it to be explicit also? It's otherwise implicitly dependent on the size of int (or ptr, again I'm not sure, and being explicit makes me sure).
Also, I notice that below even after abs() we're using int16_t. On ar...
mmmm, will investigate some more then... Having different behaviour that I normally do in a pyportal in some of my libraries. Will try to see what is hapenning. Thanks for the info π
kk, sounds good. definitely could be a bug
kk will try to reduce it to simple code if so, and comment in the PR is so (y)
thanks!
I am discovering Feather DVI. I took the latest image but is it know issue that the first character is missing in the REPL?
I haven't seen that
It does not seems to be my screen, but I will try another one.
It is my screen (actually an LG beamer) and I have other doing that.
On my big LG OLED there is a similar issue, that look like "overscan".
(overscan will typically eat the screen boarder for a full HD source, I have never seen that acting on low res signal)
However, there is a "Analyse Signal" mode that when enabled will display everything correctly.
Maybe one thing "special" about most TV/Screen at home is that over here in Belgium we are 50Hz (also PAL). But our TVs, expecially with DVI input should be able to display a 60Hz signal without problem.
So I am curious about other positive or negative report and from where they are coming.
my real interest is experimenting with the lsm6dsox imu Machine learning capability. I'd love to find a Board supported by circuit python with that sensor.
no need to have it on the board https://www.adafruit.com/product/4438
this made my jaw drop
after getting poor search results
That's a perfect solutionThank you
As I am doing the t-energy port, I discovered that as the battery discharges the serial chip spams KeyboardInterrupt's to the serial console.
It wouldn't be an issue since I could just configure the usb_cdc console to disable serial.
But that is impossible on esp32 since there is no usb_cdc.
This board hates me.
This could alternatively be solved by #7857, as non-interrupting data can be ignored.
Older TV and a monitor took the signal without problem and I see the "H" of Hello World.
Do we have a 16:9 resolution available???
That would help have circle be circle on the big screen.
Currently on boards without usb_cdc it's impossible to get a Serial object for the main uart/serial peripheral interface.
It's needed to read in_waiting, reset_input_buffer, reset_output_buffer and have access to raw read/write.
you can do 800x480
it's closer to 16x9
@tulip sleet for the warnings about vectorio Circle. Did you have to do anything specific in the make command to get those to be shown? I'm trying out builds of a few different ports, but not seeing that warning when I build from current main.
I only saw it in the new silabs builds. It must be due to a different (newer?) compiler.
Thank you, I'll try it out on that new port.
The Wio Terminal includes a RealTek RTL8720D as a companion to the main chip to provide WiFi and Bluetooth capabilities via eRPC over a UART connection. The WIO Terminal schematic labels some pins as the RXD/TXD for the UART, and that was captured in the board definition for CircuitPython. However, these pins may be used for logging in another mode, but they are not the main pins used to communicate with the RTL chip. The correct configuration is RX on PC24/pad 2 and TX on PB24/pad 0 of SERCO...
Attempt to resolve #7883
This removes the unnecessary absolute value call from radius variable.
Honestly I don't quite follow the rest of the conversation about x and y calculations and casting. If there are other proposed changes that need to be tested out I'm happy to try those if someone can point me more specifically to what the code would look like.
Add address_little_endian for epaper displays with little endian
(low byte first) addresses.
Also clears allocated display and display bus memory so it has a
known state. The acep member wasn't always set so it varied
accidentally.
Fixes https://github.com/adafruit/circuitpython/issues/7560. May fix https://github.com/adafruit/circuitpython/issues/7778. Fixes https://github.com/adafruit/circuitpython/issues/5119.
As discussed in Discord.. I think I reduced the code as much as I can... hopefully
Tested in
Adafruit CircuitPython 8.1.0-beta.1-36-g7d02bff6b on 2023-04-20; Adafruit Feather RP2040 DVI with rp2040
Problem
import board
import displayio
from bitmaptools import draw_line
display = board.DISPLAY
group = displayio.Group()
palette = displayio.Palette(1)
palette[0] = 0xFFFFFF
a2 = displayio.Group(x=0, y=0, scale=1)
a2bitmap = displayio.Bitmap(300, 300, 2)
tile...
@slender iron ^^
Got a ValueError: width must be 1-32767 loading a bitmap_font in the DVI too, but I need to reduce the code to a minimum. and verify that is not the library.
This is the only thing I'd currently advocate for changing in here. This change looks great to me, thanks π
You could use the value as-is instead of the typecast it's doing to a signed integer but no big deal either way imo:
uint16_t radius = self->radius;
@still zephyr please file a new issue. They are easier to keep track of
the default display will be 320x240 when in color mode
I would say the device/server side is fixed if CORS support is desired (What problem is it solving??? Example, please).
Here is how I understand this:
The first implementations of tools using the web workflow were code.circuitpython.org trying to load API endpoints from the circuitpython.local web workflow. This would cause the browser to send a CORS preflight request to the board, so that request had to be allowed to go through, but not from any address for security reasons. I was my...
Attempts to resolve #7885
This PR adds minimum size validation that enforces the TileGrid being no smaller than 2x2, which is arguably still too small to be practically useful. Perhaps a higher limit would be appropriate?
If there is a desire to allow 1xN sized TileGrids the logic in this will have to get reworked.
Also something for consideration would be adding an example to the docs of terminalio module that illustrate how to use it. As noted in the issue there isn't currently any...
Don't idle from main if we scheduled an interrupt for 0 ticks in the future.
Have RP2040 detect wakes that happen between setting the timer and the idle call.
Fixes #7361
Running 5 days straight without a single error using try/except.
try:
vbat_label.text = f"{battery_monitor.cell_voltage:.2f}"
except OSError as e:
print("OSError:", e)
That's all that is required now as far as I can tell.
CircuitPython version
Adafruit CircuitPython 8.1.0-beta.1-36-g7d02bff6b on 2023-04-20; Adafruit Feather RP2040 DVI with rp2040
Code/REPL
import board
import displayio
from bitmaptools import draw_line
display = board.DISPLAY
group = displayio.Group()
palette = displayio.Palette(1)
palette[0] = 0xFFFFFF
a2 = displayio.Group(x=0, y=0, scale=1)
a2bitmap = displayio.Bitmap(300, 300, 2)
tile2 = displayio.TileGrid(a2bitmap, pixel_shader=palette, x=0,...
Just sharing what this code give on my SONY Bravia TV. What was your question?

First thank you for your piece of code, I could not have progress without reading your code.
I changed a few things to let you check your screen rendering.
First I make the bitmap exactly the size of the DISPLAY.
a2bitmap = displayio.Bitmap(display.width, display.height, 2)
Then I draw a boarder one pixel inside.
Finally I use a sleep loop to stay in the program and not exit in the REPL.
`import time
import board
import displayio
from bitmaptools import draw_line
display =...
I know your mistake, you expect 640x480... and that the output resolution after pixel doubling, you only have 320x240 in the frame buffer.
I know it from listening to "Ask an Engineer" or "Show and Tell", I am not sure where this is documented in writing.
Just checking about the Feather RP2040 DVI.
If I take the FeatherWing AirLift, do I have almost automatically most of the PyPortal project ready to be put on the big screen?
What is missing:
- Light sensor
- Touch screen
- M0+ rather M4
- Less colour(?)
Is anybody planning to create a glue library that will make porting PyPortal code to such a setup?
Thank you. Thats explain a lot. Happily will close this π. Will test later. Thank you for the info @dglaude . I guess I will need to learn more about this. π₯³
Similar to #7799 most Adafruit libraries have a jquery error that makes the bottom left panel non-working in the RTD docs. It seems that new libraries from the past weeks are not affected (I added a library to RTD last week without the issue).
As mentioned in that PR: it seems that jquery gets "loaded/injected" into the page after the page finishes loading, so it doesn't work when it's used the first time in the page. The fix forces jquery to be included earlier in the page. I looked at ad...
Using localhost web-editor debugging on non-standard port throws CORS error violation.
This fix allows use of localhost origin independent of port designation.
os.getenv('WIFI_SSID') & os.getenv('WIFI_PASSWORD') seems to be a de facto standard for connecting to native wifi without assuming that Web Workflow auto-connect is enabled (via CIRUITPY_WIFI_SSID & CIRCUITPY_WIFI_PASSWORD). Is this documented somewhere? Do we intend for all example code to migrate from secrets.py to this?
The above message from @jposada202020 is discussed in #7894 (and is now a closed issue).
As discussed in Discord.. I think I reduced the code as much as I can... hopefully
Is the documentation on doc.circuitpython.org generated directly from the "//|" lines in the code? i.e. If I find a documentation error, is a PR changing the matching text in the module all that's needed?
yep
CircuitPython version
8.1.0-beta.1-39-gd078bc3ae
Code/REPL
#Trying to draw in the framebuffer using adafruit_framebuf
import displayio
displayio.release_displays()
import time
import board
import picodvi
import framebufferio
w=640
h=480
fb = picodvi.Framebuffer(
width=w, height=h, color_depth=1,
clk_dp=board.CKP, clk_dn=board.CKN,
red_dp=board.D0P, red_dn=board.D0N,
green_dp=board.D1P, green_dn=board.D1N,
blue_dp=bo...
Hi, the issue above is a bit convoluted... I have been trying to change resolution of the DVI output, and found no example code. I was successful in that.
Then I have been trying hard to draw directly in the framebuffer and try to figure out the proper way to do that... and that is where I failed so far. So it is more like a call for help.
I don't know what I am doing... but it is really fun.
Now is time to sleep. π€
Meanwhile me here porting circuitpython back to esp8266 as support was dropped all the way back in 3.x.
I want to see what happens.
I think the biggest pain with ESP8266 was crypto and certificates to support modern TLS world. And of course the lack of USB support, but wifi and BLE workflows reduce that aspect.
Well, I'm just playing around. This stuff isn't goin in main anyways, so why not.
I don't care if it doesnt do ssl. I want to see it do web workflow for the memes.
Also isn't esp8266ex a newer chip? Mine's produced in '21.
I could be wrong but eh.
My remote temp sensors still are esp8266/micropython/webrepl.
And modern micropython can still be wedged in an 8266 and its probably no worse than a SAMD21 in terms of capability.
Unless I'm missing something, I believe setting root_group=None causes the display to go black and not be updated with any output. I've tested this to be the case on both a fourwire and framebuffer display.
There might be another way or other place where the documentation does not match the code. But this is the most obvious, that's why I found it.
yea that. I will prolly be copying micropy's homework on 8266
ugh git/github can't auto merge adding a submodule if another module was added in the mean time π€¦
I have noticed this and I hate it
maybe I can a cheat by manually placing the new module somewhere else than at the end in the .gitmodule file π€
oh yeah that worked
@ember iris I figured out the sphinx problem, it was a problem further down in the file (relative to the line 11 that the error kept citing) with a stray :!
This is updated! Now an envelope can be used similar to this, from my testing code:
envelope = synthio.Envelope(
attack_time=0.1, decay_time=0.05, release_time=0.2, attack_level=1, sustain_level=0.8
)
melody = synthio.MidiTrack(
b"\0\x90H\0*\x80H\0\6\x90J\0*\x80J\0\6\x90L\0*\x80L\0\6\x90J\0"
+ b"*\x80J\0\6\x90H\0*\x80H\0\6\x90J\0*\x80J\0\6\x90L\0T\x80L\0"
+ b"\x0c\x90H\0T\x80H\0\x0c\x90H\0T\x80H\0",
tempo=240,
sample_rate=48000,
waveform=sine,
...
I wouldn't ever think to look down for an error like that, that's a nightmare. Nice job hunting it down!
Have you some CircuitPython/MicroPython/Python news?? Please send links to cpnews-at-adafruit-dot-com for newsletter consideration. Thanks!!
CircuitPython version
Adafruit CircuitPython 8.0.5; 04/23/2032 ItsyBitsy M4 Express
Code/REPL
import gc
import board
import adafruit_ssd1306
import adafruit_tca9548a
import alarm
import time
import digitalio
gc.collect() # Garbage Collector to free up residual space
# Create the TCA9548A object and give it the I2C bus
tca = adafruit_tca9548a.TCA9548A(board.I2C())
led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direction.O...
Sorry: 4/23/2023, not the future! :-). Also, I have tried just about every other pin with the sane results
CircuitPython version
Adafruit CircuitPython 8.0.5; 4/23/2023 using IstyBitsy M4 Express
Code/REPL
import gc
import board
import adafruit_ssd1306
import adafruit_tca9548a
import alarm
import time
import digitalio
gc.collect() # Garbage Collector to free up residual space
# Create the TCA9548A object and give it the I2C bus
tca = adafruit_tca9548a.TCA9548A(board.I2C())
led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direct...
CircuitPython version
Adafruit CircuitPython 8.1.0-beta.0-80-g22636e056 on 2023-03-29; Adafruit Feather ESP32-S2 TFT with ESP32S2
Code/REPL
Code and initial testing commentary here (also some on Discord):
https://gist.github.com/anecdata/f46a1d07add5fc60cfbcf42dc7be6528
Behavior
The most limiting issue right now I think is that if peer channel is set to anything except 0 (default; becomes channel 1) or 1, send will result in `espidf.IDFError...
@lone axle Do you feel up to updating https://learn.adafruit.com/pico-w-http-server-with-circuitpython/code-the-pico-w-http-server (https://github.com/adafruit/Adafruit_Learning_System_Guides/tree/main/PicoW_CircuitPython_HTTP_Server) or would you like the author to do it?
that is the only Learn Guide that uses the library.
Ooh, good thought. I will update that. Didn't think to check for usages outside the repo for some reason π€¦
PR for that is open here: https://github.com/adafruit/Adafruit_Learning_System_Guides/pull/2484 I noted in the message there as well, but wanted to mention it might be worth waiting for tomorrow to merge the change. Currently the bundle is in a bit of a limbo until adabot packages up the new one automatically tonight.
I will add a calendar event for me to merge it tomorrow.
The PoM Newsletter is ready to crib for the Discord Notes
@tannewt Can we wait for @jepler to also re-review, or do we need this in a build for Pico DVI?
Thanks!
It can wait. It isn't needed for DVI.
That is correct. Thanks for fixing the docstrings @RetiredWizard. I must have missed updating these at the time that the new API was settled upon and merged.
Thanks - just made a few formatting changes, which I will add to the PR and then check for CI building issues.
//| If the root group is set to `displayio.CIRCUITPYTHON_TERMINAL`, the default CircuitPython terminal will be shown.
//| If the root group is set to `displayio.CIRCUITPYTHON_TERMINAL`, the default CircuitPython terminal will be shown.
//| If the root group is set to `displayio.CIRCUITPYTHON_TERMINAL`, the default CircuitPython terminal will be shown.
Just running into this where my custom local domain on my local network doesn't work properly, the OPTIONS request is 403'd. I assume it's the CORS restrictions. Would putting additional allowed CORS domains in the settings.toml be something that could be implemented at some point?
That is correct. Thanks for fixing the docstrings @RetiredWizard. I must have missed updating these at the time that the new API was settled upon and merged.
The instance is of picodvi.Framebuffer, so making that clearer.
//| `picodvi.Framebuffer` instance. After deinitialization, no further operations
I'm not sure what happened in the failed actions build. It seems to have failed on something related to submodules, but I'm not sure what specific action it was taking at the time. I did test a build of openbook_m4 locally and was able to get successful build though.
I'm not sure what happened in the failed actions build. It seems to have failed on something related to submodules, but I'm not sure what specific action it was taking at the time. I did test a build of
openbook_m4locally and was able to get successful build though.
This looks like a transient CI failure. I will start a re-run of just the failed job.
- I don't think this is an issue because lower case
bis consistent with existing native frame buffers. - Definitely a bug. It shouldn't crash.
- I think it makes sense that you would be able to write directly to the FB. This is a longer term thing though because we'll want to apply it to other native frame buffers.
Thank you @wtuemura, @bergdahl, @andibing and @jposada202020.
This looks good to me. The main purpose is to prevent misunderstandings of what terminal needs.
For the ESP32 I think a board.SOMETHING for the UART object should be sufficient.
On C3 we will need to make an object for the USB to Serial/JTAG interface.
usb_cdc is irrelevant here because ESP32 doesn't have native USB.
Seems to me that the USB to serial converter chip isn't working well when the battery dips. I'm not sure CP really needs to handle this.
I suppose we could disable serial workflow and only allow wifi. That's definitely advanced though.
Thanks for noticing this!
Thanks for figuring this out!
Have you tested with the absolute newest ?
#7876 fixes the code limiting all access to the internally known names.
The OPTIONS request here is likely to be the one made by the web workflow page to get the list of allowed actions, to know if the drive is writeable (it tests the presence of DELETE in Access-Control-Allow-Methods).
Note ...
Thanks for the explications. We can leave the reste as is.
<@&356864093652516868> We'll have our weekly meeting in about 5 minutes from now in this text channel and in the circuitpython voice channel. Please take the time to add your notes in advance to the document: https://docs.google.com/document/d/1O1R88xjW7HiJjJ1zOHpSwMhXNh-jX7-BOy8P8jLgLyA/edit#
turtle logo runs nicely on the Feather DVI with CircuitPython
we rummaged through CircuitPython project-lead tannewt's github branches to find this build of CircuitPython with DVI output support. now you can treat any HDMI monitor as a display for CircuitPython - for exampleβ¦
It is done.
Thanks for the great reference tutorial @johnedgarpark !
#adafruit #diy #gaming
That thing looks awesome!! The LED animations when touched are a really nice touch.
i can read libraries and/or blinka
I can take the other.
20 authors, is that a new record? that's a lot of new contributors.
Hi all! sorry for typing out of turn .. we are at circuitpython sprints day 1 and the number of people here is amazing. all of us here are working to get everybody going, whether that's extending the open spaces and letting them learn on circuitplayground expresses, or starting to work on issues in the libraries. Group hug from us here at pycon!
we had planned to come by at least in an audio capacity but it's just a bit crazy π
i will paste this in -- thanks!
π
That might be JohnG?
[From Boston Python slack events channel]
@Scott Gustafson
will give us an introduction to running Python on microcontrollers using CircuitPython. He showed us a sneak peek of some of the content in the discussion at after the last meeting of the #study-group and a good time was had by all, hope you can make it!
https://www.meetup.com/bostonpython/events/293092896
frequency for overclocking?
I think underclocking was the use-case they mentioned in the PR. To save power.
iMX + synthio will be amazing.
I don't even understand asyncio, Neradoc got that working I have no clue how it works π
my mic is working on windows, role change?
yup, discord reset the input device messing with the fpv camera stuff
Custom 3D printed RC tank turret replacement with FPV camera mount. This is testing piping the FPV video feed through an AV to USB2.0 video converter into the PC (OBS capture). Hopefully a future sewer inspection bot in the making.
Anecdata in Adafruit Discord said I always have some new whizz-bang creation every day. In honor of all of his am...
OnDiskGif palette is that new?
Yes, prior to the PR OnDiskGif had to use ColorConverter. The new PR adds support for using Palette instead.
I wanted to have the second step of the blinking to be an asynchronous activity so as to not affect the inter-key delay. That would be "spawning a task" to turn off the LED a little bit latter.
Making random change to Neradoc code is not the optimal solution, understanding asyncio might help in the long run.
That's all beyond my understanding. It worked so that's how it shipped.
@thorny jay the example in Dan's guide is really good, that structure goes a long way
Seems like a question for Kattni?
The guide that defines SPDX has a link to all valid codes
If my memory is correct we added one license for display_text, Ill take a look
I think the problem is with all the non GPL licence. π
πΈ
πΎ lemme outside
Foamyguay we added OFL to the licenses directory for in display_text.. so we could add the BSD one too
ty all.
Thanks
thank you
@slender iron I was trying to draw circle or turn on pixel on the DVI. The piece of code I had was creating a bitmap, using bitmaptools to draw, then display the bitmap with displayio. Adafruit_framebuf did seems like the way to go to avoid consuming twice the memory. But I have no clue how to make that work, maybe some typing secret that I don't master in python.
I am maybe also interested in some ulab magic where the framebuffer would be an array and you could do math to compute the next frame... but this is way above my head anyway.
Here is the notes document for next Mondayβs CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youβll be attending the meeting - itβs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weβll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1JbwTjyVDqmIo2do9EDXZkUYYMgTv97QTfM2nBxRK3HM/edit?usp=sharing
Ya, I think that's an interesting use. The trick is that the picodvi uses different framebuffer structures depending on color depth
I bet we could reuse the bitmap code to write to the framebuffer bitmap
We had the same issue with bitmap, with different number of colors, but still I think we did it by assuming the user of such ulab trickery would know what he was doing.
A FB really is just a bitmap. That's pretty much how I'm using it go OnDiskGif
One of the other thing I did not try yet... with picodvi.
Right but we don't expose it like one.
hi all, I'm at the pycon2023 sprints working on this issue: https://github.com/adafruit/Adafruit_CircuitPython_GPS/issues/82. Is there someone with GPS domain knowledge who can 1) answer some questions, and 2) review the PR for accuracy?
I'm happy to try and answer questions
oh great, thank you! draft PR is here for reference: https://github.com/adafruit/Adafruit_CircuitPython_GPS/pull/96
ok I have ~4 questions. 1. the GPS class has two competing(?) attributes, self.horizontal_dilution and self.hdop. As far as I can tell, they come from different parts of the message or different protocols. Is what I've done enough to disambiguate them?
I think the GSA vs GGA annotation makes sense
cool, ok. q2: attributes true_track and mag_track are unused. do you know what they are?
hmm ok. is it worth defining them do you think? If the relevant code is gone, I'm tempted to take them out
otoh, might be nice to have if someone comes back to reimplement the missing stuff
I'd remove them if not set but its worth figuring out when they were removed and why
ok, I'll do some research
thanks!
q3: after a bit of googling, I'm sort of sure that sat_prns is "Satellite pseudorandom noise code". is that right?
that I don't know
ok, I think that's it, the two unused vars are in the same boat
can I tag you on this PR when it's ready for review?
sure though I think you understand it better than I do now
haha ok. well much appreciated!
I'm ok documenting them as something and having folks correct if needed
I'm only around another hour or two but can look tomorrow if needed
sure, no real deadline on this
CircuitPython version
Adafruit CircuitPython 8.1.0-beta.0-62-g4986ad6d6-dirty on 2023-03-30; Adafruit PyPortal Titano with samd51j20
and
Adafruit CircuitPython 8.1.0-beta.1-36-g7d02bff6b on 2023-04-20; Adafruit Feather RP2040 DVI with rp2040
Code/REPL
import board
import displayio
from adafruit_bitmap_font import bitmap_font
from adafruit_display_text import label, bitmap_label
display = board.DISPLAY
main_group = displayio.Group()
MEDIUM_FONT...
I did not see any code issues, but I smoke-tested this on a PyPorlta, CLUE, MONSTER M4SK, and a Macropad (I2C display). All but the Macropad were fine. On the Macropad, there is some kind of rolling/flickering effect. The first time I loaded it, the screen was unreadable. The second time, I could see the REPL, but there was a rolling effect down from the top.
Just tried with version 8.1.0-beta.1-48-gabb0d5e62 and it does work with a custom domain. Thanks for the tip!
CircuitPython version
Adafruit CircuitPython 8.1.0-beta.1, board ESP32-S3-DevKitC-1-N8R2.
If I do microcontroller.reset() on safemode.py, as soon the configured wifi network is available, the, main.py will then run.
NOTE: this issue did not happen to me on CircuitPython 7.xx.
Code/REPL
import board
import time
import supervisor
import simpleio
import asyncio
import ebike_data
import vesc
import m365_dashboard
import simpleio
import supervis...
CircuitPython version
Adafruit CircuitPython 8.1.0-beta.1-46-gb5a26c7f9 on 2023-04-24; Raspberry Pi Pico W with rp2040
Code/REPL
import os
import traceback
import microcontroller
import supervisor
time.sleep(3)
while True:
try:
print(f"starting station...", end=" ")
wifi.radio.start_station()
while not wifi.radio.connected:
wifi.radio.connect(os.getenv("WIFI_SSID"), os.getenv("WIFI_PASSWORD"))
...
I think this may have been fixed by #7867 which was merged on 4/20. I tested using the Feather RP2040 DVI using a build from 6/21 and didn't see the issue. Can you try the latest build and retest?
Thanks. @RetiredWizard ill try tomorrow. Day pystack ran out π
Following up on the meeting I must have the incorrect Scott for the Boston meetup π€£
Ah, I do
Well, still exciting!
@bill88t I would like to change it to use qio, after change from dio to qio, the board fails booting, do you have any expierence?
diff --git a/ports/espressif/boards/yd_esp32_s3_n16r8/mpconfigboard.mk b/ports/espressif/boards/yd_esp32_s3_n16r8/mpconfigboard.mk
index 2120ba97c..d2c477951 100644
--- a/ports/espressif/boards/yd_esp32_s3_n16r8/mpconfigboard.mk
+++ b/ports/espressif/boards/yd_esp32_s3_n16r8/mpconfigboard.mk
@@ -5,9 +5,11 @@ USB_MANUFACTURER = "VCC-GND"
IDF_T...
For me, it works as is. Though I flash it manually.
I flash it with esptool.py --after no_reset --chip esp32s3 --port /dev/ttyACM0 --baud 115200 write_flash 0x0 build-yd_esp32_s3_n16r8/firmware.bin)"
I will test with make flash. If it needs to be changed to qio I will make a new PR.
Does anybody know how make flash is supposed to work?
I've used it on a couple boards but all I know is that you add the port and flash parameters and make executes the flashing comand (nrfutil, esptool, etc...) I never actually got it to work on the nRF board I was using.
No you don't need to add the address/reset/etc parameters, just the port
Oh, ok then.
Bcz there is this.
And I really have never used automatic flashing.
I only used my aliases which did it with auto settings.
@jedgarpark @todbot I think this is ready for another round of testing.
Flashing with:
esptool.py --chip esp32s3 -b 2000000 -p /dev/ttyACM0 write_flash --verify -fm dio -ff 80m 0x0 build-yd_esp32_s3_n16r8/firmware.bin works.
Flashing with: esptool.py --chip esp32s3 -b 2000000 -p /dev/ttyACM0 write_flash --verify -fm qio -ff 80m 0x0 build-yd_esp32_s3_n16r8/firmware.bin does not work. It doesn't boot.
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x7 (TG0WDT_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x400454d5
SPIWP:0xee
mode:QIO, clock d...
CircuitPython version
Adafruit CircuitPython 7.2.0 on 2022-02-24; FeatherS2 with ESP32S2
Board ID:unexpectedmaker_feathers2
Code/REPL
[13:52:08.944] Disconnected
[13:52:09.951] Warning: Could not open tty device (No such file or directory)
[13:52:09.951] Waiting for tty device..
[13:52:11.976] Connected
You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Crash into the HardFault_Handler.
Please file an issue with the contents...
Just realised I'm running an older version of CircuitPython... would it make sense to start by upgrading the version and libraries to latest?
I would appreciate it if you could send the output of your flash_id @JiapengLi.
Oh wait, your's can't boot either.
I would like to change it to use qio, after change from dio to qio, the board fails booting.
I initially though yours did.
I have no idea honestly. But it certainly seems like our flash modules won't work with qio or qout.
For further discussion please open a new issue and ping me at it.
Some additional info I found while researching this issue:
https://docs.espressif.com/projects/esptool/en/latest/esp32s3/advanced-topics/spi-flash-modes.html...
The status LED is assigned to the NEOPIXEL0 pin (16), instead of the board's neopixel pin (4).
I note that board.NEOPIXEL is broken out on the side of the board as D4, meaning that pin has to be used carefully if the status LED is enabled, but I feel that disabling the status LED altogether would be weird.
I am in that group and signed up for the meeting. I gave an in-person CPy intro to the Boston Python group in 2018, along with someone else who did a Python intro on RPi.
Just realised I'm running an older version of CircuitPython... would it make sense to start by upgrading the version and libraries to latest?
Yes, please do.
That was honestly funny. Scott, "Apparently I'm going to Boston". π
CircuitPython and Libraries all updated to the latest version. New copy of my CIRCUITPY drive attached. I will monitor for a couple of days and see how it goes.
CIRCUITPY.zip
Thanks for the testing! I didn't fully Display over to the core attributes. Fixed now.
@ladyada
Proto board tested completely:
- Tested all pins are mapped correctly, checking that they can drive an LED.
- Tested external neopixel capability.
- Tested external power switching on/off.
- Tested I2S amp by playing an MP3.
- Tested
EXTERNAL_BUTTONas an input. - Tested STEMMA I2C with a BNO055
- Tested accelerometer, including tap detection via interrupt pin, and tested state of interrupt pin
- Tested battery power capability
I2S_MOD is called out in the schematic,...
Plenty of Scotts, there can be only 1 Tannewt
The LIVE editing from Danh that found the right family name (I was in the google doc) and Scott noticing the edit that the real Scott was found. Everything was funny.
See you there then! And neat - I met some organizers at PyCon. Everyone seems just great.
Glad my totally intended joke and not at all reading comprehension error was funny!
Helping beta test this one on the UM FeatherS2 with AndyWrburton.
Adafruit CircuitPython 8.0.5 on 2023-03-31; FeatherS2 with ESP32S2
Board ID:unexpectedmaker_feathers2
Closest I can come is AdafruitIO with a DPS310 temp sensor. Your motor driver, other specific sensors, and home assistant broker I can't replicate on my setup.
I can say I had this same issue with the UM FeatherS3, it wasn't specific to the S2 or UM boards as I had the same issue with the Adafruit S3 in 7.3 a...
I'll take a stab at this!
That's why I picked tannewt. It's weird enough to be unique
almost was icantwait which would have been cool too
but I think someone had it on twitter already
Bump the shallow-since date & also move the command into a Makefile target
During PyCon sprints, a participant raised the issue of needing to type an argument as 'any kind of displayio display'. It would be nice if the core (or maybe circuitpython-typing?) had a Union type that included all these types, for libraries to refer to.
A hard fault after a couple of days would be nearly impossible to track down for me. I thought this was a couple of hours thing when I first read it. Someone would have to put a debugger on it and hope it crashes. So far I'm about 6 hours running perfectly fine.
Not a single error let alone a hard fault. Looking good so far.
CircuitPython version
Adafruit CircuitPython 8.1.0-beta.1-48-gabb0d5e62 on 2023-04-24; Adafruit Feather RP2040 DVI with rp2040
Code/REPL
import board
display = board.DISPLAY
print("display width, height:", display.width, display.height)
Behavior
Prints out:
code.py output:
display width, height: 320 240
Description
I am not sure that 640x480 is actually possible. Most all the PicoDVI examples I've seen have been 320x240.
###...
Randomly decided to take a look into first good issues. I was like hey maybe I'll give type annotations a shot again. Almost every issue I looked at already has a PR submitted from hours ago. Almost feels like Hacktober Fest with all the random contributors. The PyCon sprints are obviously having a good impact and I hope everyone is having fun! People are knocking out type annotations over 570 days old. Reviewers, you've got your work cut out for you this week for sure. Can't wait to hear all about it in next weeks meeting.
Speaking from the sprints, we're having a blast. There were probably 20 people in the room today and the hosts are taking great care of us π
Retested on macropad; all fine now. Also thanks for redoing the validations.
@DJDevon3 for me the Hard Fault was happening at around the 24-48 hour mark. My setup has now been running for about 12 hours without a problem but I'm hoping it'll just keep running "forever"
I will check in again probably on Friday (tomorrow is a national holiday here in The Netherlands and I'll be out and about).
My attempt failed at the 13 hour mark because it doesn't have a graceful failure try/except if the broker doesn't respond apparently. This is my first time ever using mqtt so I don't have a snippet for that part. It's mostly using the default AdafruitIO example. Circuit Python really needs to include try/except error handling with all examples for anything MQTT or Requests related. Looks like mine failed inside io.loop() and I think that's something the library itself handles.
Trac...
Hi,
I suggest you look at the code in this issue for a way to get a 640x480x2 display:
https://github.com/adafruit/circuitpython/issues/7898
(just ignore the afb and the circle, but the rest of the code should work)
I confirm most resolution and number of colours do fail on the Memory side.
But I manadged to go in "High Res" mode and that was my only goal.
And is why I wanted to write to the framebuffer to avoid alocating any extra bit of memory.
I also confirm that having width ...
I have put together a demo or high-resolution DVI output.
It create a bitmap as big as the frame buffer, so it is very inefficient.
This works for 640x480 black and white.
It seems ok in 800x480 too.
But it fail if you want to go grey scale with 2 bits per pixel.
Also, most "turtle" attempt will fail as turtle reserve a frame buffer (I guess).
So either we get an addressable frame buffer from picodvi and can reuse that.
Or you have to draw with object in displayio, but don't ex...
Hi, build artifacts from merged PRs are uploaded to Amazon S3 with the board ID, which is the name of the board directory in the Circuitpython repository, and the path in the URL used on circuitpython.org. That is the S3 link you mention.
The board list on circuitpython.org is only updated when there's a release, unless a board is added manually in which case it will be listed at the end, with no release but a link to "Absolute newest" (which might not work if there is no finished build yet).
CircuitPython version
Adafruit CircuitPython 8.3.3 on MatrixPortal M4
Code/REPL
# SPDX-FileCopyrightText: 2020 Jeff Epler for Adafruit Industries
#
# SPDX-License-Identifier: MIT
# This example implements a simple two line scroller using
# Adafruit_CircuitPython_Display_Text. Each line has its own color
# and it is possible to modify the example to use other fonts and non-standard
# characters.
import adafruit_display_text.label
import board
im...
Welcome to the community π
Thanks very much. I've sorta tinkered on my own and lurked a bit here before but it's nice to participate βΊοΈ
Closing since e have pystack controls now, and WIZnet library has changed significantly. If this crops up again, we can re-open in the library.
Why on Pico [W] can I set supervisor.runtime.next_stack_limit to something over 100KB, but ESP32-S2 N4R2 (QT Py) gets AttributeError: can't set attribute 'next_stack_limit'?
Pico [W] default stack limit is 24576, but ESP32-S2 QT Py (much more RAM) default is 16896.
esp stack is fixed always, even with CIRCUITPY_RESERVED_PSRAM=?
ya. reserved psram adds psram to the idf heap
idf must manage b/c C stack always comes from on-chip memory that has to get shared / traded-off with esp-idf memory?
thanks adds deep dive into esp memory onto bucket list π
I don't know much about it
the idf starts a main task for CP
and the IDF sets the size of the main task stack
and that's probably before we start to mess with PSRAM
a couple of people have been asking about pystack and recursion limits, so I was trying to understand the constraints better
ya, its weird
they'll give different error. pystack exhausted vs recursion depth
pystack prevents large function frame allocations to the heap
hey folks, just for giggles I decided to see if I could build CP for the Feather ESP32-S2 Reverse w/ TFT I ordered. I've been following the instructions at https://learn.adafruit.com/building-circuitpython (I'm on Ubuntu 22.04) and it's been going smoothly up until the actual C compilation step. It looks like it's complaining at not finding ninja - is that a build system requirement now or something I just forgot to config to not use?
the idf uses cmake and ninja
so you will need it
Thanks, I somehow missed that link!
np
Sorry if I wasn't clear. What I mean to say is that the framebuffer setup code and docs are mistaken. The [Feather RP2040 DVI board.c code] thinks it's making a 640x480x8 display but is actually making a 320x240x8 display. See: board.c#36:
void board_init(void) {
picodvi_framebuffer_obj_t *fb = &allocate_display_bus()->picodvi;
fb->base.type = &picodvi_f...
#7490 is open for better crash data capture and would help here it seems.
Trying to create a duplicate of
board.DISPLAYusingpicodvi.Framebufferyields "invalid height" when trying to do 320x240x8 or "MemoryError: memory allocation failed" when trying to do 640x480x2 or 640x480x4.
Please post this code. x4 isn't supported.
These are the supported arguments and the resulting framebuffer. The larger versions will be hard to allocate from within CP but may be possible from board_init().
Grayscale:
- 640x480x1 -> 640x480x1
- 800x480x1 -> 800x480x1...
now to watch as the build completely destroys this poor little Pentium Silver
lap warmer
Wrote 2614784 bytes to build-adafruit_feather_esp32s2_reverse_tft/firmware.uf2 π
added missing string translation
Question: Is Chinese character not supported? Only US-ASCII encoding strings?
The strings are UTF-8 encoded. We could have a chinese character translation if you like. We would disable the terminal on displays because of the many characters needed in the font.
I don't yet care much about making my own Framebuffer, I am content using board.DISPLAY, but board.DISPLAY is 320x240x8 when the board.c code thinks it's 640x480x8. And if I try to make a 320x240x8 display, it's an invalid resolution.
Why do you say it "thinks" that?
This 3-color issue is with adafruit_il0373. The 2-color adafruit_ssd1675 was for comparison. But maybe the fix is the same?
@tannewt could you approve my pr?
Ah, I didn't look close enough. I don't think the IL0373 is little endian. It is worth testing again though.
Did you make it directly? Usually we get translation updates through weblate.
From the original code at the top:
import board
display = board.DISPLAY
print("display width, height:", display.width, display.height)
and from looking at it on a monitor
@devout jolt I'm not sure why you are confused
the object's height and width don't match the given parameters
The board.c code for Feather RP2040 DVI is attempting to make a 640x480x8 display https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/boards/adafruit_feather_rp2040_dvi/board.c#L36 The resulting display is actually 320x240x8
it is outputting 640x480
but that's not the framebuffer size
color framebuffers are halved
why does display.width print out 320? the code clearly says 640
The display looks like a 320x240 display
it looks like that because color pixels are doubled horizontally and vertically when transmitted to the display
grayscale isn't
Agreeing with the comment above. According to my test for the picture in https://github.com/adafruit/circuitpython/issues/7894 is done assuming 320x240 resolution, and you can see the screen is "full"
okay so logically (to CircuitPython users), color display is 320x240, even though they pass in 640x480 to picodvi.FrameBuffer but physically the output is 640x480
yeah I made the changes directly
Ok, I'll merge when the CI is done. Weblate is preferred I think because it keeps a newer copy of translations potentially.
Okay, after conversation with @tannewt in Discord, I see the problem. While you must construct picodvi.Framebuffer() with a 640x480 argument or using board.DISPLAY, the resulting display is reported as 320x240 to CircuitPython code, the actual monitor is driven at 640x480 with pixels doubled in both dimensions
I would still classify this as a bug. Shouldn't display.width and picodvi.Framebuffer(width=) have the same value?
As an explicit example using the Feather RP2400 DVI...
is the contextlib stdlib pkg supported in CircuitPython? so I can do
from contextlib import suppress
with suppress(ImportError):
from typing import List, Tuple
We don't have this library. There is a MicroPython implementation (probably partial) here: https://github.com/micropython/micropython-lib/tree/master/python-stdlib/contextlib. It might be portable to CircuitPython.
π thx
Thanks, so I just have to wait for the next release and it will appear.
//| **Limitations**: Stack size is fixed at startup on the ``espressif`` port; setting this will have no effect.
MP 1.20 is out: https://github.com/micropython/micropython/releases/tag/v1.20.0
Dan, I get confused in cases like this... you made the commit with wording change, but GitHub still says changes requested... do I need to take some action?
No, I am going to approve and merge it once the build looks OK. It is a way for maintainers to sneak in changes π . Please comment if you would prefer something else.
it's good to go π thanks
@crimson ferry thanks for the very quick PR
@analog bridge I had to mess with the circuitpython branch protection rule temporarily when I was undoing the older silabs PR. I may not have put everything back. Should this be checked?
The question comes up because a PR was made via the GitHub web UI, and I noticed that additional pushed commits are not stopping the older GItHub Actions CI runs for the obsoleted commits. But maybe this is unrelated.
If we can get the UM FeatherS2 running for about 72 hours total I think we can close this and hand everything over to #7490. @tannewt tagging this issue means it's already referenced as additional data for their uses over in #7490.
I wasn't sure if the IDF issue was still a thing so I didn't bring it up. Best scenario for this one is to hit 72 hours (fingers crossed), close it, and hand our findings over to #7490.
7.3.3 in part...
Consider adding the esp32-c3 label?
btw ALARM sure would be nice (for deep sleep support), but I do understand features don't just magically appear out of thin air.
I'm submitting this as a Draft because WiFi on the Pico W version doesn't work. When the board boots, Web Workflow hasn't started and the board will crash into safe mode if you attempt the following:
import wifi
wifi.radio.connect(ssid,passwd)
The standard Pico version of the Demo Base I've tested and the built in SD card slot, I2S DAC and DVI out all seem to work great.
I've contacted Pimoroni and they've been very helpful with naming recommendations and obtaining the V...
Lady Ada demo'd a very similar build using a PIco Bell and the Pico W today, so I'm confident I just did something stupid and the Pico W version should work fine.
Automated website update for release 8.1.0-beta.2 by Blinka.
New boards:
- adafruit_feather_rp2040_can
- adafruit_feather_rp2040_prop_maker
- adafruit_feather_rp2040_usb_host
- devkit_xg24_brd2601b
- explorerkit_xg24_brd2703a
- m5stack_core2
- sparkfun_thingplus_matter_mgm240p_brd2704a
- waveshare_rp2040_lcd_0_96
- yd_esp32_s3_n16r8
- yd_esp32_s3_n8r8
Code still works on PyPortal (when fixed up for built-in display and no time_to_refresh), but I can't get any images to display on the 2-color EPD FeatherWing for some reason, not imageload and not OnDiskBitmap. With or without the little endian library change. I'll keep poking at it. Maybe some API changed that I didn't keep up with.
import wifi
dir(wifi.radio)
Also causes a crash to safe mode.
I took the board_init function and the associated includes out of pimoroni_pico_dv_base_w/board.c and the crashes went away. I then ran the following script:
import displayio
displayio.release_displays()
import time
import board
import picodvi
import framebufferio
from bitmaptools import draw_line
w=640
h=480
cd=1
fb = picodvi.Framebuffer(
width=w, height=h, color_depth=cd,
clk_dp=board.CKP, clk_dn=board.CKN,
red_dp=board.D0P, red_dn=board.D0...
I'm trying to add CIRCUITPY_ROTARYIO to a circuitpython build by editing the mpconfigboard.mk file. I can successfully build and flash but no module named 'rotaryio' and I don't see rotaryio when I run help('modules'). The board I build for is lolin_c3_mini. I also have seeed_xiao_esp32c3. I'm wondering if the esp32-c3 is able to support rotaryio
I found that the C3 lacks a PCNT to count rising/falling edges. https://github.com/jjsch-dev/rotary-encoder
This going to change (see Scott on Show&Tell): https://www.youtube.com/watch?v=Gcw8rOYaO8U&t=411s
This PR adds support for Pimoroni's Badger2040W. Once merged Pimoroni will add a PR for circuitpython.org
CircuitPython version
boot_out:
Adafruit CircuitPython 8.0.5 on 2023-03-31; Adafruit Feather M0 RFM9x with samd21g18
Board ID:feather_m0_rfm9x
UID:09BDE3414E37505120202050052009FF
Code/REPL
import time
import board
import adafruit_character_lcd.character_lcd_i2c as clcd
i2c = board.I2C() # uses board.SCL and board.SDA
lcd = clcd(i2c, 40, 4)
lcd.message = "Hello, world!"
time.sleep(5)
lcd.clear()
Behavior
get the whoops response in ...
The common backpacks use a PCF8574, which is not supported by the Adafruit library. However, it should not normally crash for software reasons.
Are you powering the display and backpack with 5V? If so there may be 5V on the I2C pins from the pull-up resistors. This may cause a hardware issue with the Feather M0.
Do you have a link for the display and backpack, or if not, photos? How is it wired? How was it wired with the RPi, and do you have a link to that software?
yes, its powered off 5v, e same USB power that runs the feather
I hear you saying that the backpack needs to talk to the feather at 3.3v on the I2C
makes sense, so If I unplug the I2C at the feather end it should no longer crash
will not work, but no crash. but thats not what happens, same result
BTW fantastically fast response, I was expecting tmw morning earliest
if I just get a new adafruit backpack will that run at 3.3v?
This is the latest version of our backpack: https://www.adafruit.com/product/292. The LCD needs 5v for proper contrast, but this new backpack upconverts the 3.3V to 5V. It will probably work with your display, but it's possible it wouldn't. We'd to know more about the display to check on that.
If you disconnect the I2C, you will get an error that there is no I2C connected (it will mention missing pullups).
This appears to be more of a support issue than a CircuitPython bug. I'm going to...
Thank you. I will keep an eye on that issue.
@JaggerJo + @hdo
would you mind sharing some details on how to implement your solution?
I'm having a hard time; tried all sort of solutions via Arduino to get absolute position without success on a Qt Py ESP32-S2 nor Nano 33 iot.
Does this work with CuircuitPython 8.x too?
If not; does it support 7.3?
It would help me a lot if you could just point out the procedure roughly.
Thank you very much
is there some sort of "TODO list" to take a look at? i have a little experience with embedded C and been coding in Python for a few years (no idea about the layer connecting both things tho), i would like to contribute on something if i feel like im capable of doing so:
- rather basic stuff, given my lack of knowledge/familiarity with the ecosystem
- cross-platform code, as the only hardware i can test with is RP2040
the repository issues have milestones and labels that you can navigate
CircuitPython.org collates the github issues into a nice format for browsing and picking one out to tackle.
Check the open PR's for an issue first to make sure someone hasn't already committed a fix waiting for review.
that's definitely easier to go through π
took a look at one or two of them which were recently solved (PyCon), seems like the page updates every once in a while and last changes aren't there, completely understandable...
however i was taking a look at this as i have some of those registers... it was solved by the issue's author with a PR, but isn't closed https://github.com/adafruit/Adafruit_CircuitPython_74HC595/issues/21, perhaps some admin can do it ;)
Closed with ref to the fixing PR -thanks!
sometimes PR's aren't closed for a variety of reasons including requiring some 3rd party sub-module to be updated first. all PR's are reviewed first so it does take time for a reviewer to manually go through and confirm the fix. for events like Hacktober Fest and PyCon there's usually a team of reviewers at the ready to review PR's for special events.
yeah, im aware of that, i've already contributed on a couple projects (both by PRing and help reviewing). also, page not being 100% updated is to be expected
however, i can easily keep looking through the list to see if some stuff needs to be updated and/or if i can PR myself, will spend some time of it after dinner
(couldn't help translating as spanish is 100% done already)
yeah have to click through, look at the issue in Github, and see. I think the CircuitPython list is updated once per day.
which is usually plenty, but for sprints I can see how wanting it updated every 10 minutes or so would be more helpful.
The page is supposed to update once per day
Thanks for your help!
If the page is seriously out of date then somebody will need to take a look
Hope everyone is having fun out there @onyx hinge Some really good feedback about the sprints so far. β€οΈ
@midnight ember I had a blast however today is my travel day, getting home this evening
So many folks interested in learning or improving circuitpython
the ones i've seen were closed at most some hours ago, and some others are being worked on (PRs openned) during PyCon, so not something i would say needs to be checked/improved in any way (having a completely up to date page will take a hit on performance and outisde events its not needed)
however i will try and find other stuff that is solved but the issue isn't updated accordingly, and perhaps find something i can PR myself
Apparently try/except around the io.loop() doesn't help it fail gracefully.
try:
io.loop()
except (ValueError, RuntimeError) as e:
print("MQTTException: \n", e)
time.sleep(60)
continue
Monotonic: 173387.0
Monotonic Hours: 48.1629
Publishing 86.0045 to DemoFeed.
Traceback (most recent call last):
File "code.py", line 119, in <module>
File "adafruit_io/adafruit_io.py", line 239, in loop
File "adafruit_minimqtt/adafruit_...
Issues that could be closed
https://github.com/adafruit/Adafruit_CircuitPython_BLE_File_Transfer/issues/15 (PR mentioned the issue, shows at the bottom) CLOSED
https://github.com/adafruit/Adafruit_CircuitPython_MacroPad/issues/30 be fixed by https://github.com/adafruit/Adafruit_CircuitPython_MacroPad/pull/36
https://github.com/adafruit/Adafruit_CircuitPython_PN532/issues/48 fixed byhttps://github.com/adafruit/Adafruit_CircuitPython_PN532/pull/64 CLOSED
https://github.com/adafruit/Adafruit_CircuitPython_RSA/pull/19 fixed by https://github.com/adafruit/Adafruit_CircuitPython_RSA/pull/27 CLOSED
https://github.com/adafruit/Adafruit_CircuitPython_TCS34725/pull/37 fixed by https://github.com/adafruit/Adafruit_CircuitPython_TCS34725/pull/16 ? got confused jumping through a couple of issues/PRs tbh CLOSED
===
Would this one only need a PR copy-pasting the file linked on a comment? https://github.com/adafruit/Adafruit_CircuitPython_MAX7219/issues/36
Will be updating if i find something else (or if im told any of those gets closed)
Note: Perhaps the PR's left some func un-annotated, im not checking that π
Update: Went through the full list already, more stuff tomorrow (maybe)
hiya, do you have a different github name or is the same?
same (https://github.com/elpekenin)
I think MMQTTException is just not a subclass of ValueError or RuntimeError. So you want to catch more classes of exceptions than what you have now, or we should make MMQTTException be a subclass of RuntimeError.
Yeah I copy pasted that from my weather station script that uses adafruit_requests. oops. Updated with:
try:
io.loop()
except (MMQTTException) as e:
print("MMQTTException: \n", e)
time.sleep(300)
continue
@spare jacinth for the TCS library, We did some test and validation for the raw color, at the end we kind of agree that the PR from FR where not longer required as we included better explanations in the simple_test and in the library. Ill take a look after dinner to the MAX7219. Thanks again for your help
Oops. linked 2 PRs instead of issue+PR for the TCS34725 one... https://github.com/adafruit/Adafruit_CircuitPython_TCS34725/issues/18
@spare jacinth regarding MAX7219, I think the FlantasticDan's idea is good, not sure why they did not make a PR, but we could make one and link the issue. And then, the solution could be discussed in the PR.
Not many of us left today but there's at least two of us still here holding down the fort for the last day π
As the nrf52840 is quite an attractive platform for CircuitPython development with BLE, I would like to request PIN-based encryption feature to be supported on this platform. Thank you.
Don't think I need to continue with the UM FeatherS2 wifi/mqtt stability test. 53 hours in, feed update every 10 seconds, approximately 19,000 transactions to AdafruitIO over 2 1/2 days... not a single error let alone a hard fault.
Monotonic: 193109.0
Monotonic Hours: 53.6413
```I'm satisfied with the board uptime at this point but I did say 72 hours so will just let it ride. Hope that helps you devs somehow. I'm sure UM will be very happy to hear about the stability.
I will be doing the same test to the UM FeatherS3 next.
The only possibly useful observation I've made from todays poking at this is that when Web Workflow attempts to connect to the AP using common_hal_wifi_radio_connect it fails with a timeout (WIFI_RADIO_ERROR_UNSPECIFIED) after calling cyw43_arch_wifi_connect_async. However, attempting to execute wifi.radio.connect('ssid','password') from the REPL immediately crashes apparently without entering the common_hal_wifi_radio_connect module.
The merge queue thing should be un-checked.
Can you point me to the PR/Commits/CI run.
Some feature I find missing from keypad library:
- There's no way to use normally closed seitches without external pullups.
Inkeypad.Keysifpull=True, the pin is always pulled to the opposite ofvalue_when_pressedwhich prevents the use on normally closed switches without external pullups.
Allow the use of normally open switches here and in thekeypad.KeyMatrix; - Add support for SPI bus to be used for
keypad.ShiftRegisterKeys; - Add support for more con...
is unchecked, that's good
https://github.com/adafruit/circuitpython/pull/7914; see the anecdata-patch-1 actions in https://github.com/adafruit/circuitpython/actions (right now bottom of page 1 and top of page 2. I cancelled several by hand.
thanks!
This PR adds support for Pimoroni's Plasma2040W board. Once this is accepted Pimoroni will create a PR for circuitpython.org
Good news, we're at four days now and all seems to be going well. The device rebooted a couple of times due to lost connections to the internet or home assistant (my fault for installing updates) but I haven't had a single HardFault since updating to 8.05
Early hug report to all the PyCon sprinters again, y'all have been awesome and these PRs are wonderful π₯Ή
circuitpython_typing could add a typing.Protocol for displays (or multiple kinds) if we want to duck type it. Can you link to an example of where it would be used to know what methods/attributes are required?
Half of the CI runs were due to push events as the anecdata-patch-1 branch was created on adafruit/circuitpython.
Unlike the runs triggered by pull_request event, the runs triggered by push event aren't configured to auto-cancel.
You can see this when filtering the runs like so:
push - https://github.com/adafruit/circuitpython/actions/workflows/build.yml?query=branch%3Aanecdata-patch-1+event%3Apush
pull_request - https://github.com/adafruit/circuitpython/actions/workflows/build.yml?query=branch%3Aanecdata-patch-1+event%3Apull_request
I didn't take note of which repo the author was working on. However, adafruit_bitmapsaver looks like one such:
def save_pixels(
file_or_filename: Union[str, BufferedWriter],
pixel_source: Union[Display, Bitmap] = None,
palette: Optional[Palette] = None,
) -> None: ...
Assigning to myself so I don't forget about this!
Got it. Do you know of a way to get the push's to auto-cancel, or is that somethig we don't want? Currently, any updates to PR's made directly to the repo won't cancel. I see this in build.yml:
on:
push:
pull_request:
release:
types: [published]
concurrency:
group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
cancel-in-progress: true
Testing with Adafruit CircuitPython 8.1.0-beta.2 on 2023-04-26; Raspberry Pi Pico W with rp2040
If I remove the pin_alarm the time_alarm works consistently.
With the pin_alarm enabled I see wildly inconsistent results (even though nothing was connected to the pin);
sometimes with the alarm getting called constantly, and sometimes including a hard crash:
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Waking up
Auto-reload is off....
This adds a script to generate the peripherals files (except clock).
It adds support for the 1015, 1020, 1040, and 1050 EVKs.
Some work was started on 1176 but it isn't working. So, the board def is in a separate branch.
Fixes #3521. Fixes #2477.
Glad you got these working. A few minor things.
I think it would be better to call these boards nxp_mimx... instead of just mimx.... I know the first one was not named that. I would really like to see the manufacturer included in the board name. I know we haven't been consistent, and it's going to be a job to rename them all. So if you don't want to do it now and we do it in a big bang later, that's OK.
I called this I2S on the Prop-Maker, and chose these pin names, to match the arg names to I2SOut(),
specifically:
{ MP_ROM_QSTR(MP_QSTR_I2S_DATA), MP_ROM_PTR(&pin_GPIO16) },
{ MP_ROM_QSTR(MP_QSTR_I2S_BIT_CLOCK), MP_ROM_PTR(&pin_GPIO17) },
{ MP_ROM_QSTR(MP_QSTR_I2S_WORD_SELECT), MP_ROM_PTR(&pin_GPIO18) },
(I didn't need all the pins above.)
Assign a new PID. This is the 1060 EVK PID.
same comment on I2S pins as above
Thanks -- I have some questions though.
is this change intentional? (bringing in 11xx support?)
is it feasible to run this script at build time and remove the committed files? if the file is auto-generated and never intended to be hand-edited it would be nice to have a comment that says so, too.
what does this change mean? It's nice, if it enables the flash to be clocked higher.
It is because it brings in 1040 support. (It names its USB weird.)
I don't think so because it depends on files from their configurator tool that I don't think can be redistributed. I'll add a comment. I was going for minimal diff.
It means we can use/reset the DQS pad. (Otherwise flash stops working when you reset DQS even when not connected externally.)
so the sck vs dqs change is unrelated to the bump in flash speed @slender iron ?
I agree but do we handle board renames well now?
@onyx hinge ya, though I think we do need a loopback from a pad to be faster
instead of looping back internal to the peripheral
No, we don't -- it would affect circuitpython.org, and there at least we could have alias or redirect mechanism. For the S3 buckets, it's a problem, and we'd probably have to write a rename script. I have yet to find a good aws S3 CLI that lets you do bulk renames easily, etc.
maybe we do it with 9.0 and do all ports then too
yah, that's what I was thinking, so a few more boards named in old style now doesn't make much difference, and we may as well keep all the mimxrt evk's the same for now
https://github.com/jamesmcm/s3rename is not recently updated, and is probably too powerful for the task
$ ./s3rename 's/data_(?P<year>[0-9]{4})-(?P<month>[0-9]{2})-(?P<day>[0-9]{2}).txt/year=$year\/month=$month\/day=$day\/data_$year-$month-$day.txt/g' s3://s3rename-test-bucket/datatest
and it probably causes a very large number of API calls too
UM FeatherS2 Wifi is finally stable and good to go. #7907 can be closed. @andywarburton
Monotonic Hours: 71.5934
Tests: Wifi, AdafruitIO, MQTT, I2C
Great, thanks @andywarburton and @DJDevon3 for re-testing.
Onto the UM FeatherS3
@tulip sleet It does seem like the MMQTTException was never being caught properly by my try/except attempt. I was catching OSError and RuntimeError's np. I have no idea if rolling it into RuntimeError is a good idea or not, that's way above my level of understanding, that's up to you devs. I only know how to use them to get around scripts from crashing which is important for online retrying stuff. Using MMQTTException did not work as I expected it to like OSError and RuntimeError exception handling.
It's a minor issue but one that did stop my online script in its tracks multiple times instead of automatically retrying its way around it. Probably my fault for using it incorrectly around the entire io.loop() instead of the individual def functions.
Tested on a plain Pico (no W) running CP 8.1 beta and both alarms worked correctly. Re-tested the PICO W without wifi on and still saw the issues with the pin_alarm.
I mean, as a worst case scenario, could you not place a except: below all others if you want to always catch it?
Or if you wanna know what it was except Exception as err: print(str(err))
I don't know why, but MMQTTException is just a subclass of Exception. If you were expecting a more interesting superclass, it would be fine to open an issue about this: https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/issues/new/choose
Will probably do that, it didn't behave as I expected it would the same as OSError or RuntimeError would. I'm used to those with the requests library. Would be good to have error handling act the same for anything online/wifi related.
or maybe I'm just doing it wrong. will have to add a catch all at the bottom, thanks bill88t and danh. π
I don't know what the best exception hierarchy is, but I would say you want to catch a MQTTException when using the MQTT library ?
yeah after thinking about it if it fails inside the io.loop() I don't think it'll get to the bottom.
try:
io.loop()
except (OSError, RuntimeError, MMQTTException) as e:
print("MQTTException: \n", e)
time.sleep(300)
continue
if (time.monotonic() - last) >= polling_rate:
value = temperature * 1.8 + 32
print("")
print("Monotonic: ", time.monotonic())
print("Monotonic Hours: ", time.monotonic()/60/60)
print("Publishing {0} to DemoFeed.".format(value))
io.publish("DemoFeed", value)
last = time.monotonic()
vs
try:
io.loop()
if (time.monotonic() - last) >= polling_rate:
value = temperature * 1.8 + 32
print("")
print("Monotonic: ", time.monotonic())
print("Monotonic Hours: ", time.monotonic()/60/60)
print("Publishing {0} to DemoFeed.".format(value))
io.publish("DemoFeed", value)
last = time.monotonic()
except (OSError, RuntimeError, Exception) as e:
print("------------------------------Error: \n", e)
time.sleep(300)
continue
Most of the issues I have with it fail inside the io.loop() with an MMQTTException. Tried adding that to the except but it doesn't seem to be recognized as a valid error handler. Double checked the spelling, seems right.
It does recognize Exception in the bottom example but pretty sure it'll never get there if it fails inside io.loop()
Created issue 163 https://github.com/adafruit/Adafruit_CircuitPython_MiniMQTT/issues/163 will let the devs figure it out.
If things from the library are being imported with from ... import, you'll need to add MMQTTException to that import, since it's defined in the library
ah
I was using my weather station script as an example. https://github.com/DJDevon3/My_Circuit_Python_Projects/blob/main/Boards/espressif/Adafruit Feather ESP32-S2/3.5 TFT Featherwing/Online OpenWeatherMaps Weatherstation/code.py
which only uses OSError and RuntimeError which are not imported because they're built-in?
right, they are built in
π€¦ββοΈ should i close that issue?
I don't understand -- the weather station script doesn't use MQTT at all, is that right?
correct, uses adafruit_requests
I was expecting the error handling for mmqtt to be like adafruit_requests
seems like MMQTT has it's own built in error handling. i didn't realize error handling could be built into a library like that.
the API of MiniMQTT is based (somewhat?) on some other libraries, but I don't know them at all, and don't know if they have unique exceptions. ... But your issue says you can't continue after the exception. That is a separate issue, unrelated to the class of the exception. In other words, is the exception recoverable or not? That's what you're asking for, is that right?
that isn't related to what the superclass is
just whether it's easy to catch
yes but I was using it wrong as you pointed out without the correct import
will likely work as intended now
oh, you mean you got a compile error?
i think this is user error
I just updated a couple of boards. FunHouse is having frequent safe modes, but same code on QT Py ESP32-S2 does not. Probably some onboard I2C thing? There should be no other material differences... an S2 is an S2.
you might try erasing the whole board and reinstalling the uf2 bootloader, just in case
thanks, I'll try that
ah yes, you will not get an error until it gets to the exeept
i don't know if it is the same module, might be difference related to differences in PSRAM and flash size
is it a hard fault or something else?
HARD_FAULT, yes
did you update from beta.1 to beta.2? Some stack stuff was changed
you might try a manual bisect with the non-labeled builds
i have to go chop onions
some random random 8.1.0-alpha to 8.1.0-beta.2, I'll bisect if flash-from-scratch doesn't work
a FunHouse freshly erased with a 4-days old build running a httpserver that does nothing (as in, I don't connect to it) hard faults into safe mode after a certain amount of time, I have not had time to dig into that, it used to happen months ago and I don't know if it ever stopped
@deshipu can revisit and retest this one on UM FeatherS2 on 8.0.5 stable (most recent). I'm not seeing this issue anymore on my UM FeatherS2.
time to revisit this one on the FeatherS2 with 8.0.5 stable?
after bootloader update and storage.erase_filesystem(), it's still hardfaulting. so on to next steps
Eligible for a retest with 8.0.5 stable. I'm at 2 hours stable on the UM FeatherS3 currently.
@PaulskPt Time to revisit for 8.0.5 stable? At least with my Mu it no longer behaves in this manner on any of my Circuit Python devices. I'm currently testing the UM FeatherS2 & S3 in Mu serial. I'm not testing with web workflow though.
I think I want to leave these as-is. We can add standard names later when we test this. The extra pins are used for I2S input and I don't want to use the names above because they don't include direction info. (The 1040 and 1050 have separate bit clock and word select lines per direction too.) The peripheral can do other protocols besides I2S so I think the primary name should be generic.
The shared-bindings are documented that they return None when not available. They convert NAN to None so NAN matches the docs.
took it around 2 hours to crash π€
Mine crashed just once so far, 20 minutes in, but not again in the past hour. It was crashing several times an hour before the cleanse. More data needed.
(on the 8.1.0-alpha, it went into safemode last a month ago, but for WATCHDOG - probably some network hang)
Worth noting that I tried this NOT in REPL but in my script. Took about 2 hours to get out of it. You'd think that using python esptool to erase_flash would defeat it but it didn't. Only way out was to quickly load the QT Py S3 Factory Reset (even though I'm on a UM FeatherS3 because it's just too big to go through fast enough). Surprisingly the UM FeatherS3 is happy to live as a QT Py S3. Once the QT Py boot showed up I was able to reflash everything back as the UM FeatherS3.
impo...
The peripheral can do other protocols besides I2S so I think the primary name should be generic.
I did not know, sounds good.
Glad you got these working. A few minor things.
I think it would be better to call these boards nxp_mimx... instead of just mimx.... I know the first one was not named that. I would really like to see the manufacturer included in the board name. I know we haven't been consistent, and it's going to be a job to rename them all. So if you don't want to do it now and we do it in a big bang later, that's OK.
I ran this on the Adafruit Feather RP2040 dvi and it seemed to work fine. I displayed a gif from desktop and an example turtle script without issue.
I was hoping I might stumble on a clue as to why the DVI+PicoW build is giving me trouble but other than learning that a color depth of 1 requires a widthxheight of 640x480 and a color depth of 8 requires 320x240 when creating a picodvi.framebuffer (either in C or python) I don't think I'm any closer.
CircuitPython version
Adafruit CircuitPython 8.1.0-beta.2 on 2023-04-26; Adafruit Feather ESP32-S3 TFT with ESP32S3
Code/REPL
import time
import board
import adafruit_htu31d
i2c = board.I2C() # uses board.SCL and board.SDA
htu = adafruit_htu31d.HTU31D(i2c)
while True:
temperature, relative_humidity = htu.measurements
print("Temperature: %0.1f C" % temperature)
print("Humidity: %0.1f %%" % relative_humidity)
print("")
t...
I did eventually get back to testing the UM FeatherS3 running 24 hours without a single error let alone a hard fault. This issue is now 100% confirmed closed on 8.0.5 stable release.
I don't have a matrix portal. I have 2 panels, RGB Matrix Featherwing, and M4 Express. Would that be close enough to help beta test this issue?
It would depend on the device. One option is to have the pins hardcoded. To have a pin displayed and entered your devices should be able to support that.
I don't have a matrix portal. I have 2 panels, RGB Matrix Featherwing, and M4 Express. Would that be close enough to help beta test this issue?
@DJDevon3 , is the code block that I posted unable on your setup? I'm not sure if the hardware is similar enough. That being said, Adafruit is sending me a replacement MatrixPortal so once it arrives, I'll post an update as to whether this issue was due to hardware.
I have this set-up with matrixportal in the basement, I just need to get it out and update to the latest to find out if I can reproduce a problem:

with some older circuitpython it did work fine for an extended period of time.
@jepler , that's good to know. Would you mind sharing the code and version of CircuitPython that you're using to run that example? I would be interested to try that on mine too.
I tested all the combo I had in mind with the artifact for the Feather RP2040 DVI from this PR, and I get the result in the code comment.
I am not super fan of the error "# ValueError: Invalid width" but at least those 3 give the same value:
print("input: ", w, h, cd)
print("board: ", board.DISPLAY.width, board.DISPLAY.height)
print("disp: ", display.width, display.height)
Regards
import displayio
displayio.release_displays()
import time
import board
import picodvi
im...
Hi all, we are running into an issue where all USB comms on our 2040 suddenly die: the removable disk unmounts and both cdc interfaces disconnect. It appears the uC may still be running, although it is hard to confirm without serial comms.
The issue seems to be somewhat sporadic and difficult to reproduce.
In order to reconnect, we have to power cycle the uC.
Hardware: 2040 on a custom PCB, running 8.0.5
Is there any debugging tool you could recommend to trace the cause of this issue? Thanks!
CircuitPython version
adafruit CircuitPython 8.0.3 on 2023-02-23; FeatherS2 with ESP32S2
Code/REPL
#
# Motor
#
# connects to WIFI and MQTT broker as specified in the screts file
# main loop gets sensor data from MQTT
#
# imports for the board
import gc
import board
import adafruit_dotstar
import time
# imports for WIFI and MQTT
import ssl
import socketpool
import wifi
import adafruit_minimqtt.adafruit_minimqtt as MQTT
# impport th...
Well, you could always have it hooked via swd for debugging.
That interface will never crash.
Load up a DEBUG=1 firmware and you are off to the races.
odd new behavior... PicoW (8.1.0-beta.2) running adafruit_httpserver starts repeatedly getting
[CYW43] STALL(0;233-233): timeout
[CYW43] do_ioctl(0, 262, 9): timeout
[CYW43] STALL(0;233-233): timeout
[CYW43] do_ioctl(2, 263, 16): timeout
(I don't know which is the chicken and which is the egg)
then, even control-C to the REPL continues to repeatedly get:
[CYW43] send_ethernet failed: -1
[CYW43] STALL(0;233-233): timeout
[CYW43] send_ethernet failed: -1
[CYW43] STALL(0;233-233): timeout
reset fixes it, if there was a way to test for it code could auto-recover
lib/cyw43-driver/src/cyw43_ll.c
661: CYW43_DEBUG("[CYW43;%u] STALL(%u;%u-%u)\n", (int)cyw43_hal_ticks_ms(), self->wlan_flow_control, self->wwd_sdpcm_packet_transmit_sequence_number, self->wwd_sdpcm_last_bus_data_credit);
```here's where the STALL message comes from, in one of the submodules. dunno anything beyond that, but I haven't done much wifi and no httpserver lately
@crimson ferry are you reading the voltage on GP29? our protection around that may not be adequate. https://forums.raspberrypi.com/viewtopic.php?t=339994 https://github.com/raspberrypi/pico-sdk/issues/1222
we may need to add cyw_thread_enter/exit calls down in our function common_hal_analogio_analogin_get_value:
You only need to wrap calls to the shared pins between cyw43_thread_enter() and cyw43_thread_exit() and make sure there is no other wifi activity ongoing like an HTTP call.
Thanks will give that a go!
@onyx hinge Not checking temp, just very simple web server. Iβm guessing something random got things into a bad state. Iβll double-check the code when i get back later.
adafruit CircuitPython 8.0.3 on 2023-02-23; FeatherS2 with ESP32S2
Please update the Feather to Circuit Python 8.0.5 stable or newer release and try again. Most of the hard fault issues dealing with Wifi & MQTT have been addressed in 8.0.5
jepler... yeah, simple web server, occasionally does a request to an external site, occasionally serves up an integer to an HTTP client, no ADC or special CYW pins accessed. Thanks for looking at it. Never seen it before, wouldn't be surprised if I don't see it again.
Also if you can do serial logging output to a UART port (as opposed to USB serial), that should stay up and perhaps you can get more information about where it is failing.
@analog bridge This may be of interest to you, about using ESPNow and wifi simultaneously (they have to be on the same channel): https://forums.adafruit.com/viewtopic.php?t=201055
Question - I am making a CircuitPython compatible board that I plan on selling.
I am currently creating the port for it. I see that there is a USB_VID and a USB_PID
I am not sure what I would put for those. Doing a vendor lookup, I see that Adafruit has their own VID, so I don't want to use that one.
Do I just omit/comment out? Do I put a random one?
I see that online, it costs several thousands to get a USB Vendor ID. This is just something I plan on selling a few of, so I really don't want to buy a Vendor ID
You will need a legitimate USB VID and PID. If you do not own your own VID there is https://pid.codes/ that is aimed for hobbyists and startups. If you start producing a large number of boards and items that need a PID it would be best to get your own but this is a way to start
Thanks!
It is aimed at open source hardware though just FYI
Yes, you will not receive a PID from pid.codes unless the board design is open source.
hi, I am looking similar to this(https://github.com/brainelectronics/micropython-winbond) in Circuitpython. Actually I want to interface an external W25 4MB external flash with Raspberry Pi Pico board and use this an expended storage. I am ok if this additional 4 MB will not ahowup in my windows drive, but still i want to store some CSV file and read it.
@open wren it should be possible. CircuitPython also can 'mount' a filesystem from a block device implemented in Python code. You can look at adafruit_sdcard from https://github.com/adafruit/Adafruit_CircuitPython_SD to see how that looks. I think the critical methods are readblocks, writeblocks and capacity. You'd substitute an implementation of these methods suitable for the W25 chip, probably using adafruit_bus_device as the abstraction for talking to an SPI bus.
Further discussion may be more appropriate #help-with-circuitpython
thanks @onyx hinge . I will try it once
<@&356864093652516868> hey y'all! It's my pleasure to invite you to our weekly CircuitPython meeting today at the usual time of 2PM ET / 11AM ET, or a bit over 2 hours from now. If you have notes, please add them to the notes document https://docs.google.com/document/d/1JbwTjyVDqmIo2do9EDXZkUYYMgTv97QTfM2nBxRK3HM/edit?usp=sharing and if you need me to read them please note that too, by writing a note like "(no mic)", "(missing meeting)" etc after your name. If you just feel like listening in, that's great too, and we're happy to have you. The meeting is recorded, and the recording will be released on YouTube and other streaming & podcast services under a Creative Commons license which allows re-use.
If you want reminders like this, or you want to speak in the meeting, ask any admin or community moderator to add you to the "circuitpythonistas" role. It's free an entails no obligation!
CircuitPython Weekly Meeting for 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, add y...
The newsletter is ready in GitHub to crib from for the meeting
thank you very much!
Skipping the meeting without notes. Group hug and the only thing I did is playing with Feather RP2040 DVI (in CP) and USB-Host (Intelikey).
I noticed the contributing page on circuitpython.org has got days that are off by 2-3 days from realtime. Investigating a bit I made a build of circuitpython-org locally from main and in the local version the days are 2 days "newer" i.e. a line showing Open 2 Days on circuitpython.org live site shows Open 4 Days on the local one.
It looks like the final action to build the site after fetching data failed to run fully the most recent attempt that it made: https://github.com/adafruit/circuitpython-org/actions/runs/4850291876/jobs/8643070977
Is this one of the actions that we can just use the re-run functionality with? Or does it need something different, or to just wait a day and see if it suceeds tomorrow.
I can just try re-running it.
it worked!
Actions has been a bit more flaky than usual the past few days. I've often had to re-run 2-4 failed jobs after a circuitpython PR merge
@jposada202020 Do you have a similar ESP32-S2 you could test it with? It might be an I2C clock-stretching or similar issue, which the S3 can have trouble with. Thanks.
I'm going to close this as "works (badly) as designed", if that's OK. I'm not sure what we can do about the pull-up that's present there. But if it's not mentioned in the guides, it should be.
@dhalbert works fine with the S2 :)
Adafruit CircuitPython 8.1.0-beta.2 on 2023-04-26; Adafruit Feather ESP32-S2 TFT with ESP32S2
>>> import t2
Temperature: 21.0 C
Humidity: 54.7 %
Temperature: 20.9 C
Humidity: 54.7 %
Temperature: 20.9 C
Humidity: 54.7 %
Temperature: 21.0 C
Humidity: 54.8 %
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "t2.py", line 15, in <module>
KeyboardInterrupt:
@dglaude Would Invalid color_depth make more sense?
Certainly should be documented. Since the issue makes the pin unusable as an analog output. Shouldnβt the output capability be disabled within CircuitPython?
shouldnβt the output capability be disabled within CircuitPython?
if you added a pull-down of the same value, is the current drive enough to override the balanced pull-up/pull-down?
Certainly should be documented.
I'll check on the guides, and we can add it to a **Limitations:** section in RTD.
The datasheet says that the DAC output is buffered, apparently not enough to negate the effect of the pull-up resistance. Thatβs if the assumption of the pull-up being the cause is true β donβt know how to verify it without more design details. Thatβs a long-winded way of agreeing that βitβs just the way it is.β
shouldnβt the output capability be disabled within CircuitPython?
if you added a pull-down of the same value, is the current drive enough to override the balanced pull-up/pull-down?
Certainly should be documented.
I'll check on the guides, and we can add it to a
**Limitations:**section in RTD.
Thatβs an interesting idea. Adding an offsetting pull-down could reveal more about the buffer but would defeat the purpose of having the pull-up. Iβm inclined to chalk i...
You could have a switchable pull-down by using a pin: external resistor you ground or not, or attach another input. But that's getting into the weeds.
I have no idea why they decided to add a pull-up on that pin and sacrifice the analog functionality -- it's weird.
We're wrapping up our internal meeting and then I need to take a few moments to get ready for the discord meeting, so things will get going a bit late
thanks for your patience!
@onyx hinge your mic volume was pretty high during the meeting, so let's check it here too
Heya!
Hello
it's fine
I'm text only today
You could have a switchable pull-down by using a pin: external resistor you ground or not, or attach another input. But that's getting into the weeds.
I have no idea why they decided to add a pull-up on that pin and sacrifice the analog functionality -- it's weird.
If we assume that the pull-up resistor is impacting the DAC, adding an external resistance or source current to the pin would introduce other non-linearity effects and temperature issues. Designers take the DAC accuracy...
A wizard is never late, nor early, they arrive precisely when they mean to.
I'm text only today, so please read.
Still unpacking and can't find my microphone cord.
No worries! I've got it. π
Thanks
@gilded cradle I do have a request, can you type out your quick explanation involving "is our CP compatibility layer"? I think I remember the whole thing, but I'd prefer to get it right. Everything else I don't need any assistance with.
Add it to the notes doc next to the title please π
Sure, will do.
Thank you so much!
Time stamps
You're welcome and thank you as well.
My pleasure (and blood, sweat, & tears)
Visualization of the MicroPython source code over its 10 years of development, created using Gource.
The first line of code was written on 29th April 2013. There have been 573 contributors since then.
A teeny tiny traffic signal simulator using the @pimoroni Cosmic Unicorn LED display.
Adafruit's CircuitPython Newsletter is π₯ Thanks @turbid radish
wow, that's gotta be a record 
will no timestamps be an issue for the host?
nvm
There are so many new contributors there's no way to thank them individually like they normally do.
Ok, this should be ready for review. Thanks for the testing! It'll raise Invalid color_depth if the resolution is correct but the color_depth doesn't match.
PyCon sounds like a great time.
I have so many improper animated gifs in mind for all the synthio envelope talk... just awesomeness.
Attached: 1 image
I just scored an apparently-working Z80 CP/M system (Xerox 820) at an estate sale. The computer lives inside the monitor, plus there's a keyboard & HUGE two 8" disk drives. One of the floppies will boot it to an "A>" CP/M command prompt. What in the world will I do with it? #retroComputing #z80 #cpm
An actual Xerox PC? Can't wait to read about that.
Didn't know it was blocking, looking forward to seeing you work on that.
Still going through notifications. Currently still have >1000 to go through.
Awww β€οΈ
i am gonna show my age, but i actually did some programming on one of those when they were new
I assume they got engaged.
Congrats @proven garnet !
Congratulations @proven garnet
Thanks!
Thank you for hosting @onyx hinge
@proven garnet Congrats!!! That's delightful news!
Thanks everyone and thanks @onyx hinge for reading my notes.
@proven garnet congrats!
ok
thanks all, have a great week!
Congrats @proven garnet
Thanks for hosting Jeff!
Thank you everyone! Thanks @onyx hinge for reading my notes!
Thanks, everyone!
Thank you Jepler & Kattni for sharing your experience at Pycon. It was interesting on this end too seeing so many type annotations come out of nowhere.
You're entirely welcome!
Wanted to ask why didn't we have a coordinated sprint like we did for Hacktoberfest?
It was coordinated on our end π
lol
you know what i mean, here on discord.
fear of overwhelming reviewers?
because that would definitely be a valid reason from the action i saw happening.
A lot goes into an in-person sprint. We had the folks doing reviews and helping out coordinated here, but involving the remote community would have added quite a lot more to the situation. That said! I'll add this to my notes for next year. Perhaps someone like you π could help coordinate the Discord end of things to help out!
haha umm I am definitely not the right person for that one.
No worries. There's no obligation here. It's a good idea, but I would definitely want help with it. There are plenty of folks who offered to help remotely that I had no tasks for this year, so, next year I'll have one for one or more of them!
Let me know if you need help. π
Adding you to my list!
@onyx hinge I had an idea about qstr https://github.com/micropython/micropython/pull/10758#issuecomment-1522418051
I briefly looked into making objects identical across boards
that is an interesting idea @slender iron
the tricky part is knowing later which ones you need
It's probably all tricky parts π
Here is the notes document for next Mondayβs CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youβll be attending the meeting - itβs super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weβll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1y5tGjTm1zDpbaSjTIQLytXE_Eg4mmfI4kf95AclnJ2Q/edit?usp=sharing
CircuitPython Weekly Meeting for 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, add y...
I also wondered if we could just switch to C strings
@slender iron just confirming, are you running the next meeting? it's what our internal calendar says but also I thought I saw that you ran last week's
I can do it again. That's fine
appreciate it
I'm not keeping score though it sure is nice now that you're back in the rotation!
π
I'd love to figure out this qstr thing at some point
it'd be nice to share compiles across boards better
Hi @jepler!
I finally got around to trying this out. Very cool! Much easier to change envelope rates based on incoming note playing, and we can now make some pretty expressive synths.
A few observations:
- The
synthio.Envelopeis "global" to the synth, so the amplitude envelope of currently playing notes gets replaced by notes with a different envelope (e.g. play gentle, then play hard, hard notes' env replace gentle notes' env). It would be nice to have per-note envelope state, but ...
I tested with more or less @dglaude's code above, and got what I expected
It's a bit weird to me that 320x240 with a color depth of 1 or 2 doesn't work, but I guess that's the way it is.
We could implement it but PicoDVI doesn't by default.
I also tested with the above code and it worked as expected. I did notice one peculiarity, If you set the framebuffer to any of the sizes greater than 320x240, pressing ctrl-D and then attempting to run the code with another framebuffer size greater than 320x240 but different than the one you just used caused a memory error. Pressing ctrl-D again, after getting the memory error and pasting in the same code that just gave you the error then succeeds.
I saw the memory errors too, but I thought it was because the buffer was deliberately persistent across VM's.
There did seem to be some correlation with the persistence of the DVI output across Ctrl-D restarts but I didn't do it enough times to figure out the relationship. I was changing framebuffer sizes most times and it didn't seem like the DVI output survived most ctrl-D restarts but it did sometimes.....
I've recently run into this as well. Thought I would get my act together and use deepsleep, and it would give me a nice battery life boost in some ItsyBitsy nRF52840 Express based projects. Then I saw this report and ran some experiments. I get 1.5x to 2x the battery life just using time.sleep+supervisor.reload vs alarm.exit_and_deep_sleep_until_alarms.
I poked around a little looking at https://github.com/adafruit/circuitpython/tree/main/ports/nrf but have no idea where to start. A real b...
- The
synthio.Envelopeis "global" to the synth, so the amplitude envelope of currently playing notes gets replaced by notes with a different envelope (e.g. play gentle, then play hard, hard notes' env replace gentle notes' env). It would be nice to have per-note envelope state, but that may be asking too much. :)
I want to tackle that in the next round of improvements, so that a note can be associate with an envelope rather than having just one envelope for the whole Synthesizer obje...
@onyx hinge have you looked at pico-8 for synth inspiration?
I wish I had done more of a 'survey' up front. this started out as looking for a quick win improving the audio synthesis, then I got more free reign (time) than I expected to improve on it. but it means it's a big pile of NIH and I don't know much about what is out there.
π understandable. I was just looking at it for the edit/run cycle it has. (escape toggles between editor and console)
I'll review that PR you asked me about tomorrow, but ping me if I fail
kk, np
I am fine with "Invalid color_depth" or anything, really.
I had the same memory issue (I guess)... this is why I have that count-down.
For each test I started from power on, that is the time I needed to get to the console in time to see the message.
I did not try to understand the random memory allocation issue... could it be that the REPL use the DVI output and block reuse? I don't know much how ^D interact with memory management.
I was thinking the allocation error were due to som...
Letβs say I go into production with a circuitpython compatible board. How do I batch program hundreds of boards?
Some of the Desk of LadyAda videos talked about Adafruit's testing rigs that also do the board programming. So they put the produced board in the tester, it flashes the image and then runs a series of tests and flashes "ok" (assuming everything went ok)
Interesting. Iβll have to look into that. Thanks!
I usually just give the firmware to my fab and let them flash it as a part of their testing procedure
there are some guides on testers and recently ladyada has been switching from teensy to pico for that (using pio USB host for USB test and programming)
Unexpected Maker has a discord and youtube channel where he talks about his production process (he ships his boards with CP installed)
I have not investigated what LadyAda share on her testing board. And I guess it is Arduino code.
But one great use case would be to help educator flash a classroom of Circuit Playground Express all with the same UF2 (and maybe the same filesystem content).
I could see a Feather RP2040 USB-Host doing that work (maybe it need an SD card reader to store the image?).
In fact, I would not even know how to do that from a Linux machine, I guess it would involve discotool.
yeah I was thinking of that too. For a classroom I would think a computer is enough, kattni has code to do that, I have an example in the discotool repo that's geared towards that. But I could see using a handful of USB feathers, you plug the device, wait for the LED to turn green, go to the next one, do 5 in parallel...
thanks for addressing my concern!
@jimmo you may want to check this in micropython. In particular @gneverov has researched and found that tcp_new will LWIP_ASSERT_CORE_LOCKED but lacks an ENTER/EXIT pair. I didn't get into detail on the other sites where the guard was newly added.
Thanks for the changes, & for your patience.
Makes sense. I removed the duplicate. However, let's merge this for 9 instead of 8.1; I'll set a milestone.
CircuitPython version
When running this simple code that creates several async/await tasks that run in parallel, CircuitPython will HARD_FAULT randomly roughly every several hours.
I have tested this on CircuitPython 8.0.5 and 8.1.0 and they both act similarly.
Code/REPL
# main_test_why_circuitpython_hardfaults.py
# This file will just run a simple asyncio infinite loop to see if that causes
# a hard fault after 24 hours.
import asyncio
import time...
Adding the USB Host and ThinkInk Feathers to _boards
Images automagically compressed by Calibre's image-actions β¨
Compression reduced images by <strong>65.3%</strong>, saving <strong>127.27 MB</strong>.
| Filename | Before | After | Improvement | Visual comparison |
|---|---|---|---|---|
| <code>assets/images/boards/large/0xcb_helios.jpg</code> | 35.54 KB | 33.85 KB | -4.8% | [View diff](/adafruit/circuitpython-org/pull/... |
Looks good! Not sure why so many images needed to be compressed but that's fine
Yes.
On Tue, May 2, 2023 at 10:20β―AM anecdata @.***> wrote:
Wemos S2 Mini?
β
Reply to this email directly, view it on GitHub
https://github.com/adafruit/circuitpython/issues/7926#issuecomment-1531666182,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB4J23IG7DGU33NNYXHT5NTXEEQ5FANCNFSM6AAAAAAXTAC3WM
.
You are receiving this because you authored the thread.Message ID:
@.***>
@jepler i think the image compression action happens when a pr is not from a fork. The action won't run on forks, so they get queued up. (I think)
I think the memory issue does have to do with the buffer outside the VM heap vs inside. I don't know of a good way to fix it.
This is what implements deep sleep:
https://github.com/adafruit/circuitpython/blob/488dca565f700f40358eb3a6e50f1eb561f541c2/ports/nrf/common-hal/alarm/__init__.c#L263-L284
That file also includes light sleep.
@deshipu Do you use synthio?
A few minor things. Very cool that you have tests for this and can run it from the Unix port.
Should these be forced to be kwargs? Should they default to 0?
//| envelope: Optional[Envelope] = None,
OK I've gotten my project out of storage.
I'm using two of the 64x32 LED displays, a matrixportal, and a 4V 2A power supply
The power supply reads 5.18V no load and 5.10V while running the code with display on.
I have previously installed a 220Β΅F capacitor on the power input, but I do not know if this is important.
The display looks right with the following versions: 7.3.1 (was previously loaded), 8.0.5, 8.1.0-beta.2
The display initiali...
anyone tried (and failed) to load the most recent builds onto rp2040?
@gilded cradle Re: web-editor: with the latest build system, should it have triggered a deploy via gh-pages branch? I don't see a new push on https://github.com/circuitpython/web-editor/commits/gh-pages - or did you create these manually?
wild guess:
https://github.com/adafruit/circuitpython/blob/488dca565f700f40358eb3a6e50f1eb561f541c2/ports/nrf/supervisor/port.c#L356-L397 appears to skip sleeping if there are any background callbacks, and I don't see anything in the loop here https://github.com/adafruit/circuitpython/blob/488dca565f700f40358eb3a6e50f1eb561f541c2/ports/nrf/common-hal/alarm/__init__.c#L182 that immediately looks like it is processing background callbacks.
So maybe there is a background callback (dunno anyth...
I just loaded the latest build on a rp2040 Feather without any issues
OK, I'm trying to use wifi.radio.ping. And I've tried every format that makes any sense for the IP to ping, and nothing is working. How is this supposed to work? There are no details in the documentation.
there's a ping in the wifi test
https://learn.adafruit.com/pico-w-wifi-with-circuitpython/pico-w-basic-wifi-test#code-the-basic-wifi-test-3128858
ipv4 = ipaddress.ip_address("8.8.4.4")
print("Ping google.com: %f ms" % (wifi.radio.ping(ipv4)*1000))
bytes or a string formatted address.
Oh, hmm ok.
Thanks @jaunty juniper.
Ok, that worked. Now I understand why the docs are what they are for ping. Learned two things here. Appreciate it.
to ping a domain name you have to go through getaddrinfo:
https://github.com/anecdata/Socket/blob/4fc073927c8dce0d2d4b1c388917062994ddba44/examples/udp_client_CircuitPython_NATIVE.py#L22C36-L23
server_ipv4 = ipaddress.ip_address(pool.getaddrinfo(HOST, PORT)[0][4][0])
print("Server ping", server_ipv4, wifi.radio.ping(server_ipv4), "ms")
Ohhhhhhhhhh. Interesting. I assumed it simply wasn't supported.
Thanks!
I found a domain that would work though.
hihi - updating board name from EPD to ThinkInk and adding pin def for board.BUTTON
Oooof. When using settings.toml, wifi.radio.connect throws completely useless errors. I modified the SSID to be wrong for the purpose of throwing an error, and I get Unknown failure 15 and, once, Unknown failure 4. Is this by design, or some limitation? I would think, at least for SSID or password mismatches specifically, it could provide a clearer error.
I don't know if this is the right method but it seems to work :).

I just added a PR #1192 to explain how to do it.
Testing envelope now -- this is working really nicely, sounds great! I think the envelope parameters make a lot of sense now (to people familiar with typical synth methods at least).
I don't think connect knows why it fails
Hmm.
you can blame me for adding those cryptic numbers to "Unknown failure" :p
I wonder if there's a way to specifically tell you if your SSID or password are wrong, a least.
tannewt is right, the error you actually get back could be one of a few, depending on where in the wifi connect / disconnect process it fails
not always indicative of what really happened (sometimes there are a series of error codes, and the one of the moment gets reported)
it's a good problem to try to solve
I'm not sure how I found my way there but I used the "In-System Programming" section on this site: https://www.silabs.com/developers/mcu-programming-options to download "Simplicity Commander" which recognized and programmed the board with the .bin file.
You can get there after a few clicks from the "MGM240P Wireless Module" link but should there be a direct link to the "Simplicity Commander" download as well?
I don't know what sensible defaults these would have, so I did not provide defaults
An exception cannot be raised at this point, because the context is the background task that updates. Are you suggesting to add an error_offset property to the MidiTrack object, to let the information be retrieved programmatically? I can do that. Is it in lieu of printing this message?
I think one of your demos had some pretty good defaults: attack_time=0.1, decay_time=0.05, release_time=0.2, attack_level=1, sustain_level=0.8
without further re-work I'm not sure default values or kw-only values are possible, because I'm re-using the namedtuple constructor. I could change this at the cost of larger code size.
no, several of the files here are copied verbatim from cpython's stdlib.
https://github.com/adafruit/circuitpython/actions/runs/4867023896/jobs/8679184392?pr=7862 not sure what this is or what to do about it.
"get the latest commit with checks" failed with "IndexError: list index out of range" so nothing else ran...
I'll try 're-run jobs'
@microdev1 this is failing in a weird way:
Run python3 -u ci_changes_per_commit.py
Traceback (most recent call last):
File "/home/runner/work/circuitpython/circuitpython/tools/ci_changes_per_commit.py", line 239, in <module>
main()
File "/home/runner/work/circuitpython/circuitpython/tools/ci_changes_per_commit.py", line 228, in main
check_runs = get_bad_check_runs(query_check_runs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/circuit...
I increased the number of asyncio tasks to 30 and started your test program on a UM Feather S2 and an Adafruit Feather ESP32-S2 about 13 hours ago. They haven't crashed yet but I'll let them run over night. I'm assuming that adding the extra tasks didn't mess the test up. Unfortunately, I don't have a Wemos S2 Mini to test on, hopefully it's not hardware or port specific.
I did notice that the Lolin S2 boards are among the relatively few S2 boards that have CIRCUITPY_ESP_FLASH_FREQ set to...
I was actually using a Lolin S2 Mini, not a Wemos S2 Mini, but aren't they basically the same thing?
I've been running this even further since I posted and I did get a HARD_FAULT again a couple hours ago. Here's my log below. I also seem to sometimes get the WATCHDOG as well as a reason for a reboot. So my period between HARD_FAULTs is about 22 hours.
I'm building a Marble Run for the local school's STEM lab to inspire the kids and this thing needs to run 24x7 so the kids can hit the bu...
Yea, I think they are the same board. Hopefully I'll see a crash by morning, If not, maybe I'll try loading the Lolin firmware on one of them and see if I can reproduce the crash that way.
Here's my bout_out.txt, but keep in mind I saw the same thing on 8.0.5.
Adafruit CircuitPython 8.1.0-beta.1 on 2023-03-30; S2Mini with ESP32S2-S2FN4R2
Board ID:lolin_s2_mini
UID:487F307D7D25
Hello @RetiredWizard:
- Can I have confirmation of the addresses to use to flash the binary?
- I propose to add some notes to help users:
Method 2 - Simplicity Commander
You can use Simplicity Commander: A tool that contains a scriptable command line, allows the user to flash their application.
- Download Simplicity Commander
- Extract Simplicity Commander directory from the zip file.
- Go to Simplicity Commande...
Thanks DJDevon.
I upgraded to 8.0.5 but the same hard crash
CircuitPython core code crashed hard. Whoops!
Crash into the HardFault_Handler.
The UM FeatherS2 had been running for 2.5 hours, at the time of the crash the MQTT topic was static so no changes being made to the GPIOs. Just monitoring in the MQTT loop.
Could you also try with "Absolute Newest", linked from the board download page on CircuitPython.org?
CircuitPython version
main
Code/REPL
make html
Behavior
/home/jepler/.local/lib/python3.9/site-packages/setuptools/__init__.py:84: _DeprecatedInstaller: setuptools.installer and fetch_build_eggs are deprecated.
!!
********************************************************************************
Requirements should be satisfied by a PEP 517 installer.
If you are using pip, you can try `pip install --use-pep517`.
...
@candid sun @split ocean @devout jolt I'm working on the next thing after ADSR. I would like feedback on this API. ```py
class Note:
def init(
self,
frequency: float,
amplitude: float = 1.0,
waveform: Optional[ReadableBuffer] = None,
envelope: Optional[Envelope] = None,
tremolo_depth: float = 0.0,
tremolo_rate: float = 0.0,
vibrato_depth: float = 0.0,
vibrato_rate: float = 0.0,
) -> None:
"""Construct a Note object, with a frequency in Hz, and optional amplitude (volume), waveform, envelope, tremolo (volume change) and vibrato (frequency change).
If waveform or envelope are `None` the synthesizer object's default waveform or envelope are used.
If the same Note object is played on multiple Synthesizer objects, the result is undefined.
"""
frequency: float
"""The base frequency of the note, in Hz."""
amplitude: float
"""The base amplitude of the note, from 0 to 1"""
tremolo_depth: float
"""The tremolo depth of the note, from 0 to 1"""
tremolo_rate: float
"""The tremolo rate of the note, in Hz."""
vibrato_depth: float
"""The vibrato depth of the note, from 0 to 1"""
vibrato_rate: float
"""The vibrato rate of the note, in Hz."""
waveform: Optional[ReadableBuffer]
"""The waveform of this note. Setting the waveform to a buffer of a different size resets the note's phase."""
envelope: Envelope
"""The envelope of this note"""
NoteSequence = Sequence[Union[int, Note]]
"""A sequence of notes, which can each be integer MIDI notes or Note objects"""
Each place a `Synthesizer` could take an integer MIDI note number, it will also accept a `Note` object. The `Note` object can also be dynamically changed while playing, such as by changing the base `Note.frequency` to do a sweep. Notes can have different waveforms and envelopes, so each note can have its own distinct sound.
It's largely coded, but not yet tested on hardware. Also it'll require some re-work after I make the changes requested on the ADSR PR. But this is what's next, and I welcome your feedback (and anyone else who's interested)
CircuitPython version
Adafruit CircuitPyhton 8.1.0-beta.2, ESP32-S3-DevKitC-1-N8R2 board.
Code/REPL
pass
Behavior
http://cpy-2b4f34.local/code/ don't load the code editor. Some weeks ago it was working perfectly for me.
Description
I tested to change the CIRCUITPY_WEB_API_PORT.
I tested in two different ESP32-S3 as also in one ESP32-S2, that always worked well for me.
I also tested on a different wifi network, with only my PC and the ...
That looks correct, however I'm running the Windows install which would probably be launched from an icon rather than the command line.
Here are a couple other approaches that I thought might work, but really as long as the link and reference to Simplicity Commander is included I think they're all good:
Method 2 - Simplicity Commander
You can use Simplicity Commander, A tool that contains a scriptable command line, allo...
super cool @onyx hinge ! i really like being able to dynamically change the attributes. i'm envisioning tying the values to sensors
I actually have a pan/tilt servo kit. Can help test this on latest beta release sometime this week on the UM Feather S2 with motor featherwing.
The UM FeatherS2 has a special featherS2.py that is created upon initial install with many pre-defined functions. I'm not sure if they're required or just helpers but in all of my uses I've always included it in my code.py
def enable_LDO2(state):
"""Set the power for the second on-board LDO to allow no current draw when not needed."...
OK, I'll use those as defaults. It's not as bad as I was worried it would be to allow default values. After the next update, it'll work like this:
>>> synthio.Envelope()
Envelope(attack_time=0.1, decay_time=0.05, release_time=0.2, attack_level=1.0, sustain_level=0.8)
>>> synthio.Envelope(decay_time=7)
Envelope(attack_time=0.1, decay_time=7, release_time=0.2, attack_level=1.0, sustain_level=0.8)
>>> synthio.Envelope(7)
Traceback (most recent call last):
File "<stdin>", line 1, ...
If you're still having a problem with this, I recommend trying to play the MidiTrack through an AudioMixer.
The reason is that the MidiTrack produces audio buffers of varying sizes, including very small sizes for short notes. (in older versions it also produced extremely large buffers for long-held notes, but now it has a certain upper limit buffer size)
Some of our audio out implementations handle this small audio buffers poorly and get confused because with a small buffer the next aud...
I added reuse-style license notices to the copied files.
OK, I added an error_offset property and removed the message.
The new synthio.Synthesizer is very unlikely to fit here, but I could shuffle things around so that the new features are optional: synthio.Synthesizer Envelope and Note all raise NotImplemented, OR put them in a fresh module (but you have to tell me the module's name)
@microdev1 the CI problem seems to have healed so that's good I guess
I'm almost certain this was all due to a major online editor update. I updated the original issue (https://github.com/circuitpython/web-editor/issues/90) with the information from here, though I am still referencing this issue, and am closing this issue.
I believe this issue may be occurring when the status of the pin is already in the triggered state when the alarm is being created. . @adriangalilea ; could you test your script adding in "edge=True" to the pin_alarm parameter list?
Just ran into this today, took me awhile to realize it's not supported in CircuitPython. This feature would be much appreciated!
RUN_BACKGROUND_TASKS; should process the background callbacks.
This is fine for now. I'll leave it up to @deshipu how they want to get it back. (The new features sound so good!)
One nitpick that you can do in your next PR if you like.
This no longer prints. Maybe set, record or report?
@gilded cradle https://forums.adafruit.com/viewtopic.php?p=971173#p971173
Great, many Thanks to You. Just started to rebuild my esp32-s2 wifi connection function.
Confirmed that it was due to changes introduced through the editor update.
Apologies but I might not be able to test it for now, will add a reminder, sorry π
yeah, missed that scanning for stuff followed by parens.
I wonder if it is softdevice related (which I guess is the radio?), if the softdevice is enabled it looks like it doesn't go into deepsleep, but instead waits for events from the sd
@devout jolt can you remind me what website(?) you were using for all those single-cycle waveforms? I'm after a windchime-style waveform for this demo.
I've been playing with the Seeed XIAO nrf52840; this device will need to be turned off for long periods without draining the battery. I'd been hoping to get micro-amp current draw as per the Seeed website - but instead I seem to be getting about 2.5mA. Looks like CP doesn't actually use the deep sleep function of the processor, but just does a light sleep and then a reset. Is there a reason for this? I've got uctypes working on my build of CP so I can poke the various registers and enable deep sleep myself - anything I need to be careful of with this?
@mystic flume our deep sleep implementation seems to need some work on that platform. If you use github and have any more information you can add it to https://github.com/adafruit/circuitpython/issues/5318
CircuitPython version
Adafruit CircuitPython 8.1.0-beta.1-50-ge928554a9 on 2023-04-25; Metro MIMXRT1011 with IMXRT1011DAE5A
Board ID:metro_m7_1011
Code/REPL
import time
import board, analogio
import busio
import audiobusio, audiomixer
import synthio
import ulab.numpy as np
import usb_midi
import adafruit_midi
from adafruit_midi.note_on import NoteOn
from adafruit_midi.note_off import NoteOff
from adafruit_midi.control_change import ControlChange
...
Yep, verified that usb_midi worked in 8.0.5 but does not work in 8.1.0-beta.2 and up
The simpler test code I was using was:
import usb_midi
import adafruit_midi
from adafruit_midi.note_on import NoteOn
from adafruit_midi.note_off import NoteOff
midi = adafruit_midi.MIDI(midi_in=usb_midi.ports[0] )
while True:
msg = midi.receive()
if isinstance(msg, NoteOn) and msg.velocity != 0:
print("note on", msg.note, msg.velocity)
elif isinstance(msg,NoteOff) o...
The search term is "AKWF". The WAVs are here: https://www.adventurekid.se/akrt/waveforms/adventure-kid-waveforms/ And there's a viewer here: https://www.adventurekid.se/AKRTfiles/AKWF/view/waveforms_index.html
Thanks @devout jolt -- do you know one that sounds like a bell?
hmmm. not by visual inspection, but I did put the "granular" set up as a ready-to-go list of 200-element long np.array()s here: https://gist.github.com/todbot/7b750c84d0bec4801baf570008253124
The granular ones are probably most bell-like
ooh cool! I ported desktop python's wave file reader to CP so I can just put the wav files directly
oh nice
I'm removing the pico w version of this code and will submit that as a separate PR once I figure out my issue. I know Adafruit is working on a DVI PiCowbell that should work with the pico w so if I haven't figured it out by then, I suspect that release will point me to the solution.
This PR should be ready for review....
https://github.com/adafruit/circuitpython/tree/main/tests/circuitpython-manual/synthio/wave audoop + chunk + wave + ```py
def read_waveform(filename):
with wave.open(filename) as w:
if w.getsampwidth() != 2 or w.getnchannels() != 1 or w.getcomptype() != 'NONE':
raise ValueError("unsupported format")
return memoryview(w.readframes(w.getnframes())).cast('h')
waveform = read_waveform('/AKWF_cello_0007.wav')
nice. thanks!
I hope to find time to package it maybe as a community bundle item
bbl
btw as I try to put together this demo I see more what you are saying about the loudness of 1 voice vs multiple voices but I still don't know what to do about it π if someone wants 1 voice at a time they don't want it 1/12 of total possible loudness.
since I think bells are mostly multiple sines at disharmonious frequencies, maybe "AKWF_granular" 0041 or 0031? And maybe anything in the "AKWF_overtone" group
this was a big problem with "Virtual Analog" synths in the early 2000s. I'll see if I can read up on what their strategies were
oh hey I'm caught up to 2000? rad
ahahah it's very impressive. "wavetable synthesis" was the holy grail back then and we get it sort of for free
I've had a play and tried turning off the softdevice - _bleio.adapter.enabled = False. This doesn't have any effect
I think that one part of it is the RMS level of a sum of a bunch of sine waves of different frequencies is less than the sum of their amplitudes, because half the time they cancel each other out; so that's why 12 notes sounds a lot lower volume than 1
when either one is "allowed" to get to +-32768 as the sum of all the waveforms
can you do a random phase for each oscillator? that will reduce constructive summing blowing out your headroom budget. Also I know in Mozzi & DSP libs, the summing buffer is often twice as big as "native" signal path (i.e. 32-bit if 16-bit signal values) and then shifted down to the native width
i.e. (sig1 + sig2 + sig3 +sig4)/4 and not thinking much harder than that about it
I can confirm that I get about 0.9 mA when just doing a simple timed sleep -
I'm guessing the reason why true deep sleep isn't used is due to needing a possible timed wake up. And SYSTEM OFF doesn't have any timers. Is there any reason why we couldn't use SYSTEM OFF if there were no timers?
Oh fun, when I do bleio.adapter.enabled = False in the repl running on the device, nothing happens. if I ctrl-d to exit the repl the device does a hard reset (serial port device disappears, lights blink, serial port device reappears). If I do the enabled=False in code.py without the repl, instant hard reset, and sometimes the device ends up in safe mode.
@hiredman I don't suppose you are connecting to the REPL via bluetooth?
I've tried using uctypes to "manually" set up a pin alarm and deep sleep - and that seems to work really nicely, current consumption drops down to about 20uA as per my (fairly cheap) multimeter.
pin_no = get_pin_no(hardware.BUTTON_A)
if pin_no >= 32:
gpio_base_addr = 0x50000300
pin_no %= 32
else:
gpio_base_addr = 0x50000000
pin_cnf_addr = gpio_base_addr + 0x700 + pin_no * 4
...
Obviously this doesn't help if you are wanting it to wake after a specific time
nope, repl over serial over usb.
Has anyone had success getting code.circuitpython.org to connect via BLE? I've been trying to an nRF52840 and my own nRF board and after selecting the device I never get the option to Bond to it and while a subsequent connect shows it is paired, no functionality works
Thank you for looking at it. I received a replacement MatrixPortal so will
try using that one to run the same code and will post an update.
On Tue, May 2, 2023 at 12:57 PM Jeff Epler @.***> wrote:
OK I've gotten my project out of storage.
I'm using two of the 64x32 LED displays, a matrixportal, and a 4V 2A
power supply https://www.adafruit.com/product/1466The power supply reads 5.18V no load and 5.10V while running the code with
display on.I have previously insta...
How do I use MP_QSTRs? Where are they defined?
I want to create a custom pin name for one of the features on my board and I want to know where I can add the strings. I assume they are constants defined in another file somewhere?
no they are auto defined just by being there (by a script in the build process)
note that you have to make BOARD=... clean of you change them
I had a bit of a glitch overnight last night which killed my terminal sessions, so from yesterday's test runs all I know is that neither board crashed after about 13 hours.
I started the tests up again this morning but this time, I loaded the Lolin S2 mini firmware up on one of the boards first. The test program has been running again for about 13 hours. I'll check them again in the morning and hopefully at least one of them will have hard faulted.
Sounds good. Yeah, I left mine running today again too, but I actually had
accidentally left it in the REPL, so missed out on my test today as well.
On Wed, May 3, 2023 at 9:51β―PM RetiredWizard @.***>
wrote:
I had a bit of a glitch overnight last night which killed my terminal
sessions, so from yesterday's test runs all I know is that neither board
crashed after about 13 hours.I started the tests up again this morning but this time, I loaded the
Lolin S2 mini firmware up ...
Because it's almost 3 am I'm not going to ping you in a reply. Has anyone had success getting code.circuitpython.org to connect via BLE? I've been trying to an nRF52840 and my own nRF board and after selecting the device I never get the option to Bond to it and while a subsequent connect shows it is paired, no functionality works
Yes I've had this happen ever since the web flasher and web serial in chrome became a thing with every type of board. It's more likely to fail when it says paired next to it than when it doesn't. I have no idea what paired means (serial communication i think). It's not just the NRF, this definitely affects ESP boards as well.
You can use esptool in python to get around the issue of it locking down the serial bus quite easily with ESP32's using erase_flash then reflash with a bin. It's not as easy if you run into it with the NRF52840.
3AM? π
Thanks, I will add the LD02 code and have a look at your example.
I will test over the weekend and update here.
When starting a wifi access-point with this code:
import wifi
wifi.radio.start_ap(ssid=ssid, password=pw, channel=chn)
It will always use same local IP for the network it creates: 192.168.4.X
This prevents us from generating several networks with several boards.
Can you please allow setting the third part of the IP for a custom value?
This was also raised here: https://forums.adafruit.com/viewtopic.php?t=201121
Had a HARD_FAULT again last night.
The timestamp is odd. Safemode got hit at 3:33AM. Then it rebooted into normal mode which should be about 10 seconds later, but the clock says 3:27AM. I do the RTC lookup when booting in normal mode, so it just makes me think the clock runs fast on the ESP32. Is it possible a fast clock throws stuff off over time and that's what causes a hard fault?
From safemode.py. Kill switch off. 2023-05-04 03:33:58, supervisor.RunReason.STARTUP, microcontrol...
@slender iron [up early?] quick gut check question -- I have ported the cpython library for reading wave files to CP (nearly trivial). it seems useful for reading single-cycle waveforms for synthio. should i package it as an adafruit circuitpython library, or put it in the community bundle? I anticipate it'd be used in a synthio guide which tends to make me think adafruit.
Oh, MidiTrack was completely broken on samd and rp2040 until 04f4092e110b50fc03dd55e8a5f1c2151c5d0035 -- closing because I think we did fix the underlying cause. Feel free to open a fresh bug report if this persists in 8.1.0 and later.
CircuitPython version
Broken:
CircuitPython 8.0.5, CircuitPython 8.1.0-beta.2 for ESP-C3-32S (2M)
Working:
Adafruit CircuitPython 7.3.3 on 2022-08-29; AITHinker ESP32-C3S_Kit_2M with ESP32-C3
Code/REPL
ESP-ROM:esp32c3-api1-20210207
Build:Feb 7 2021
rst:0x1 (POWERON),boot:0xd (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x3fcd5810,len:0x24
load:0x403cc710,len:0x668
load:0x403ce710,len:0x2218
entry 0x403cc710
Serial console setup
...
Here's the doc for the new class, which can be used where integer note numbers were used before:
class Note:
def __init__(
self,
frequency: float,
amplitude: float = 1.0,
waveform: Optional[ReadableBuffer] = None,
envelope: Optional[Envelope] = None,
tremolo_depth: float = 0.0,
tremolo_rate: float = 0.0,
vibrato_depth: float = 0.0,
vibrato_rate: float = 0.0,
) -> None:
"""Construct a No...
Probably the separate Note.amplitude property should be removed, the envelope is ample to give a per-note amplitude.
It should be possible, similar to Station but with the AP NETIF:
https://github.com/adafruit/circuitpython/blob/bd9aca2526b568eeacd8b8e02fe1a8d9baae3843/ports/espressif/common-hal/wifi/Radio.c#L477
per-note envelope, which I didn't test before pushing, :rofl: doesn't work :sweat:
No luck for me, 25 hours, 2 boards, 30 asyncio loops and no faults yet. I'll keep them running but I'm wondering if it's something with the specific board. Do you have just one of the Lolin boards?
I've gone ahead and ordered one which should be here in about 10 days but I also seem to remember that there was an issue with different manufacturers of these boards using different parts that behaved differently. Hopefully I've just been lucky and I'll be able to reproduce this on one of these...
I have tested this on 2 different Lolin S2 Mini's and same issue, but I
could try this on other ESP32's now that you mention it could be specific
to the version of the chip they used.
On Thu, May 4, 2023 at 10:16β―AM RetiredWizard @.***>
wrote:
No luck for me, 25 hours, 2 boards, 30 asyncio loops and no faults yet.
I'll keep them running but I'm wondering if it's something with the
specific board. Do you have just one of the Lolin boards?I've gone ahead and ordered one which...
Do you think it has anything to do with me activating the display?
On Thu, May 4, 2023 at 10:17β―AM John Lauer @.***> wrote:
I have tested this on 2 different Lolin S2 Mini's and same issue, but I
could try this on other ESP32's now that you mention it could be specific
to the version of the chip they used.On Thu, May 4, 2023 at 10:16β―AM RetiredWizard @.***>
wrote:No luck for me, 25 hours, 2 boards, 30 asyncio loops and no faults yet.
I'll keep them running ...
Well I'm not doing anything with the display, I'd suggest you run the same test you have posted above. I don't think just having the display physically attached should be an issue if the software doesn't address it.
Another thought, how are you powering the board?
and the rp2040 squawk-at-reload came back :(
I do have the display regurgitating the standard output, so code would be
executing in those display classes. I just commented out that part of the
code so I'm ONLY testing the async tasks. If this doesn't crash on me then
it would have to be the display causing this. If it does crash, one other
idea is that I am using the Web Workflow to see the serial output. Perhaps
it's the Wifi classes causing it.
As for powering the board, I'm just using a normal USB-C wall wart for a
Raspberry Pi that...
Thanks. Donβt worry I mute my phone at night so not worried about pings.
Is there someplace to file issues with code.CircuitPython.org? Or to report issues too? I lack a ton of web knowledge so not sure how much help I can be looking into it but could try.
I've switched my monitoring to the web workflow serial terminal as well....
My board looks a bit different from the one on the images.
adafruit makes sense to me
https://github.com/circuitpython/web-editor You may need to bond through your OS. Its been a little while since I've done it.
Is there any reason why we couldn't use SYSTEM OFF if there were no timers?
How would you wake it from system off?
The adafruit_wiznet5k_wsgiserver.py module in the adafruit_wiznet5k Ethernet driver implements a WSGIServer class. This class relies on a mixture of calls to deprecated, non-standard socket.socket methods and direct calls to the hardware via WIZNET5K methods. It is difficult to maintain. Rather than expend a lot of effort on refactoring this module to use only standard socket.socket calls, does the adafruit_httpserver provide the same functionality as adafruit_wiznet5k_wsgiserver.py, could it be used instead?
I don't own a wiznet thingamabob, but there's a similar question with ESP32SPI, where the API needs to be reworked to make it closer to CP's native wifi. In the mean time, I made a class that bridges the socket implementations and makes it possible to use adafruit_httpserver with ESP32SPI, but that's experimental I would say
https://github.com/Neradoc/Circuitpython_Universal_Sockets
That's really helpful. Ironically, you've implemented a socket.readline() method that is deprecated in the WIZNET5K implementation because it's not a CPython socket method π . But my basic premise stands, adafruit_httpserver does provide the same functionality as a WSGI server?
yeah I implemented readline() because the point was to make it work the other way too, so that native wifi sockets could be used with libraries that were written for ESP32SPI (originally it was written for my uwebsockets port, which assumes native wifi)
and yeah I would say it provides more functionalities at this point
I now believe per-note envelope, including dynamically modifying a per-note envelope, works.
not sure how it compares in memory use though, as it's getting bigger
Ah, I see. OK, so I think my time would be better spent making the WIZNET5K module compatible with the adafruit_HTTPServer . Your point about memory usage is well taken, I'll keep sticking bandaids on the WGSI server module for now.
Okay, someone save me...
I get an error when I log some debug data:
This is the code:
print(type(result))
print(str(result))
log.debug("I2cConnection received raw: {}".format(self._data_to_log_string(result)))
and the data_to_log_string is:
if type(data) is bytes:
return "[{}]".format(", ".join(
["0x%.2X" % i for i in bytearray(data)]))
else:
return str(data)
and the console output with print statements and error:
<class 'bytearray'>
bytearray(b'\x04\x07\x95\x04}\xb6\x04\xb6\x1b\x04\xd0\x06\x12\xcb\x9b\x13~%\x04LB\x7f\xff\x8f')
Traceback (most recent call last):
File "code.py", line 336, in <module>
File "/lib/sensirion_i2c_sen5x/device.py", line 242, in read_measured_values
File "/lib/sensirion_i2c_driver/device.py", line 61, in execute
File "/lib/sensirion_i2c_driver/connection.py", line 116, in execute
File "/lib/sensirion_i2c_driver/connection.py", line 153, in _transceive
File "/lib/adafruit_logging.py", line 380, in debug
File "/lib/adafruit_logging.py", line 327, in _log
TypeError: not enough arguments for format string
and adafruit log function:
def _log(self, level: int, msg: str, *args) -> None:
record = _logRecordFactory(self.name, level, msg % args, args)
self.handle(record)
Since GitHub mentioned it today, reminder that Node 12 will be depreciated in two weeks on GitHub CI!
I believe almost of the CircuitPython infrastructure is safe (not too sure about the core though), but please feel free to ping me if something doesn't work starting on the 18th if that is a problem anywhere!
it doesn't
the problem is that the priority of operators is not intuitive there, he needs parens
brilliant, thank you. I was trying to avoid changing more of the main i2c driver logging code, i.e. I can get it to work changing "{}".format to "%s" which allows the code to work, but changes one log method in connection.py and I was curious why it was necessary for adafruit logging but not python logging.
[("0x%.2X" % i) for i in bytearray(data)]))
interesting. Basically i'm modifying as little as possible the sensirion repo python-i2c-driver and python-i2c-sen5x, which involved using platform detect and swap logging library, add a bus_device i2cdevice implementation, but wanted to avoid changing the main bits like sensirions data_log_to_string function
works on right, crashes on left
checking if any_embedded_linux to use the sensirion linuxi2ctranceiver.py and a circuitpython version if not, plus logging swap
@willow totem it can sometimes be useful to split lines like those up to make them easier to read, too. i.e.
if type(data) is bytes:
bytestrings = ["0x%.2X" % i for i in bytearray(data)]
return "[{}]".format(", ".join(bytestrings))
else:
return str(data)
Fixes a small bug I noticed
this is the python i2c driver (base driver), and the sen5x driver on top, both forked from sensirion and then modded for ciruitpython
https://github.com/tyeth/python-i2c-driver/tree/circuitpython-busio-i2cdevice
https://github.com/tyeth/circuitpython-i2c-sen5x/tree/circuitpython-fix
yeah what is happening is that _transceive is calling logging.debug() without additional arguments
ah, apologies, you were talking about adafruit_logging specifically, not the % operator in general
and that is not supported by the adafruit library
but python logging is okay with it?
(im not great at python, c# guy but dnagerous in all languages)
I'm not sure honnestly
it's curious, and I really don't get why the %s version works but the other doesnt
it says TypeError: not enough arguments for format string
and that would mean something like:
>>> "%d" % ()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: not enough arguments for format string
but you don't pass a format string with % in it I don't think
