#circuitpython-dev
1 messages · Page 53 of 1
Howdy folks and particularly <@&356864093652516868> -- we'll be having the meeting in about 65 minutes from now! Please take this time to add any notes to the notes doc: https://docs.google.com/document/d/1S1W7c3Rq2PIV4TVrRahtz3Em5cfJpEEPi6sSyW_mk5U/edit?usp=sharing
CircuitPython Weekly Meeting for December 4, 2023 Welcome to the CircuitPython Weekly meeting notes! Feel free to add your Hug Reports and Status Updates before the meeting, alphabetically by your username. During the meeting, we go through them in order. If you can’t make the meeting and woul...
@lone axle all these "unpin sphnix" PR's -- it's tested, is that right, so you are just looking for approvals?
for a non-controversial change, you could merge without approval
I was just starting to approve and merge them
assuming you have the privs
That is correct, they're tested. It's the same change that I pushed with Adabot patch, it's just that these repos had different configuration and couldn't push automatically like the others.
I don't have privilage for it on these ones. Merge button is disabled saying it needs an Approval, and the approv button is disabled for me saying PR author cannot approve.
I am saving a list of the repos that were like this though. In the long run I think it would be great to have their permission configuration changed to match the rest of the others so that the patches can apply to all of them without the manual PR ones.
There are 6 more that I'll finish up after the meeting, I set it down for lunch before the meeting.
NanoPy
Please tell folks about the newsletter - it's free top subscribe, no ads or spam
to
a lot of new PR authors, very nice to see. 🙌
👋
Let's do this for all ports or none. There's no reason to limit it to one port.
You're welcome
The HEIF encoder is a bit complex, but it would be a nice alternative format. Jpeg is a bit old :p
(but it's kinda like vfat, it will never die...)
could be a beta too
I definitely think a release this week would be good
I think the idf update and the web workflow changes are unreleased
i certainly can do one sooner rather than later.
thank you!
I will merge from 8.2.x and maybe update frozen
ability to update WIFI credentials via on-display controls would be awesome!
That's a neat project DGlaude! Would like to see a demo of that.
I am willing to accept help. There aren't many touchscreen related projects to pull inspiration from. Most of them are for the Pyportal but I don't have a Pyportal.
@mortal kernel do you still have a Ventura machine you could make comparison traces on? I saw delayed writes of some kind when using the initial cluster-number-only traces, but it was not clear if the "delays" were unrelated to the original write transaction or not. Thanks.
Been seeing a lot of Mac related questions in discord lately, seems like a big problem. Good luck to the Devs!
I've got a pre-Ventura machine available. The issue has a pointer to my trace code. I can refine it into a pull. How would like that to look?
it's on my short list to look at your fork, hope to do that today or tonight
@gilded cradle All your efforts with the Qualia library is greatly appreciated. There are a lot of new displays and they keep coming out with new ones.
Please sidetrack :p
ESP BLE 🙌
Thanks @midnight ember
Cool. The MacOS version I have available is Big Sur, 11.7.8. Hope that's OK.
Take care of your mom. ❤️ Been praying for you and your family.
Welcome @short tendon ! First meeting. 
i could run your same tests on a Ventura machine. I have an Intel Macbook Air that can't go to Sonoma anyway. (It's actually rolled back further at the moment due to us trying to figure out when FTDI and CP21xx drivers were added.)
could you put your exact tests in the issue? or could be in the PR, though I'm not sure where, maybe tests/circuitpython-manual
Not sure what you mean. The test is just a one-liner in terminal that writes a one block file of random data.
It's in the issue.
ah ok, I saw that line. I thought you were maybe copying files of various sizes
i had some multi-file copies that generated cp errors
Multi-file copies are good for hitting secondary effects, but tend to muddy diagnosis.
I am going to blog the issue in the Adafruit blog and also point to the current "best" workaround (czei's remount script). Will also post on Mastodon. This is all to increase exposure, and also make more people aware and maybe report it.
iOS results so far are a relief. The >8MB results are disappointing because my fake FAT16 won't be a viable workaround.
do iOS internals track macOS closely or vice versa? Do you think this might might be an external "flush" process that has been turned off or adjusted?
There is a private _free_socket https://github.com/adafruit/circuitpython/issues/6502
I used that and it did work
sockets also have finalizers
Thanks for hosting Jeff
but moving the session outside the while true loop made the biggest difference and _free_socket became unneeded at that point.
Although they are separate development "trains" they do merge selectively. I'm leaning toward a bug in auto-mounting on Sonoma.
Thanks for running the meeting Jeff. Hope everyone has a nice week!
Thank you for hosting Jepler 🤗
👋
do good work everybody
I think the other part of "make gc 'do the work' of collecting unused sockets" would be that a failed socket() call that returns the equivalent of an EMFILE error would gc.collect() and try a second time before failing for real
oh i had them spread all over the place 😅 because of the early 8.0beta with leaked sockets issue which was eventually fixed. so i thought by 8.2.8 that would have been cleaned up, so i removed them all, and it appears it wasn't... at least not with the way I was attempting to iterate through sessions.
@short tendon fyi that multi API script hasn't worked in a while. last time i updated it was before Twitter removed API access. most of those API's likely no longer work. part of updating the API examples to be 9.0 ready is going back through them all to ensure they work. Like the Twitch API example I found was broken so I'm sure there will be more.
Here is the notes document for next Monday’s CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1jtCjgV5NExzjBZxgPpE8dY_D42g4DAJv6w24TaARTRw/edit?usp=sharing
Briefly tested on nrf and rp2. I can't test the others, since I don't have any.
I wanted to circle back on a question I posted recently regarding USB VID:PID
(I would link it but as mentioned, it’s very difficult to find ‘human’ content in this channel)
I am designing an education board which will ship with CircuitPython and which uses the RP2040. The Adafruit guide indicates people in my situation need to contact the appropriate manufacturer for getting an assigned PID.
I reached out to Raspberry Pi (via their online form) on Thursday and was granted a PID today.
… so the process works 👍🏼🤩
That's okay. I know tons of API endpoints. Any that fail I'll just update to use something random
I ran a couple quick tests on the SAMD51 and mimxrt10xx. I didn't do run any benchmarks and didn't notice any speed differences but the build seemed to work fine.
@anecdata, thank you for suggesting safemode.py. I have created the following safemode.py script and the devices I am testing have now been up for nearly 3 days. In those three days I have detected at least 4 crashes into safe mode, but the device has reset itself and continued on with the task.
import microcontroller
microcontroller.reset()
I would love for the wifi tools to be more stable, but this workaround at least keeps us up and on the network. Thank you!
CircuitPython version
Adafruit CircuitPython 9.0.0-alpha.5 on 2023-11-15; Adafruit-Qualia-S3-RGB666 with ESP32S3
Code/REPL
https://github.com/adafruit/Adafruit_CircuitPython_Qualia/blob/main/examples/qualia_paint.py
Behavior
After about every 10 reads or so from the capacitive touch screen, there is a noticeable delay. You can really tell by running the paint program:
 This will happen earlier with split heap than it did with the one big heap. The pauses should be shorter though.
Raising the starting heap size may give you enough buffer to capture a full finger drag before triggering the GC. You could also try running gc.collect() when a finger isn't active.
Ok, I'll try those to see if it helps...
Raising starting heap size did help. Garbage collection didn't help.
anyone worried about me requiring a directory exist and be empty for a mount point?
that way it'll be listed when listing the parent directory
that's how posix does it, except for being empty
if it isn't empty then the files aren't listed when something else is mounted right?
Usually a mount will hide any files in the mount point directory.
👍
Linux has a "union" mount that can be used with pseudo filesystems with a notion of upper and lower directories, but I've never used it.
I haven't either
Currently to toggle the usb filesystem, usb hid and midi, we need to have to edit boot.py.
However, if you want to toggle it frequently it becomes quite annoying.
And it's hard for applications to just set it for the next boot in a clean manner, since there is no such ready-made api.
For ljinux, from 6.x I had implemented a config.json which stored stuff for boot.py and the os to read/write.
But during 8.x I switched to using settings.toml and the os just set the values with m...
Oh this issue has always been there.
I can't upload (reliably, it fails around 70%) my 300 file root filesystem over it.
The code hang is just that the run_backround_tasks takes over and doesn't let go as far as my understanding goes.
I just didn't know how to report the upload hang and gave up. (and made ftp for that, but now that's broken too)
CircuitPython version
8.x / 9.0
Code/REPL
N/A
Behavior
When dragging something into the web-workflow upload button, it works fine the first time, but if the upload fails / you reload the page / anything unsuccessful happens, the selection is not cleared, even if you reload the page.
If you try to use the same upload box, the drag and drop fails and you get the thing you dragged to open in another tab.
If you try to use the other upload box (the...
A lot of the configuration is either complicated (HID report descriptors), or you want it to be conditional, such as hiding the CIRCUITPY drive, but only if a button is not pressed, etc. So, yes, you could conditionalize the boolean things, or set their default values, but it would be a subset of what you can do in boot.py.
(The title of this issue says "only", but it seems like that's not what you said in your post.)
@tulip sleet it's possible that the USB descriptor configuration stuff can be made somewhat less complicated now that we have host_malloc...
the core C code that is
Scott already simplified (removed) the hoisting onto the stack and back after boot.py. But yes, it could use dynamic allocation. It can be revisited in the longer term. Too many other things to work on right now.
CircuitPython version
Adafruit CircuitPython 8.2.6 on 2023-09-12; Raspberry Pi Pico with rp2040
Code/REPL
import rotaryio
import board
last_encoder_position = None
encoder = rotaryio.IncrementalEncoder(board.GP7, board.GP8, 1)
while True:
position = encoder.position
if last_encoder_position is None or position != last_encoder_position:
print("Encoder pos: " + str(position))
last_encoder_position = position
Behavior
H...
I should have given a tl;dr:
CIRCUITPY_USB_FS = bool
CIRCUITPY_USB_HID = bool
CIRCUITPY_USB_MIDI = bool
I don't think we should move all the options into settings.toml.
I just think we should have a default state setter in it, for ease of use.
Yep the title is wrong.
I believe you want to change the last argument you have to rotaryio.IncrementalEncoder() from a 1 to a 4 (the default). e.g. do this:
encoder = rotaryio.IncrementalEncoder(board.GP7, board.GP8, 4)
or
encoder = rotaryio.IncrementalEncoder(board.GP7, board.GP8)
Thanks, i tried that but setting it to 4 makes the value only change on every 4th increment
@onyx hinge I have some questions regarding the 3.7" 240x960 bar display. Is that one you got working?
@gilded cradle I don't remember. I can go look at what I have. I think one of them was 240x960, that sounds familiar.
Ok thanks, I can't get the overscan_left + width to be > 320, but timing says it should be 360.
So last 40 pixels are cut off
I have a screen marked "HWTL31601G02-04" but it's about 3.3" and I have a screen marked "BL-HD458002" but it's about 4.8" -- so I may not have that one
The 4.8" one is actually 4.58", hence the hd458 and I got that working. The one I have that is causing trouble is marked HD371001C40.
So it doesn't sound like you have it.
what i have
Have you tried setting it to 2? It really depends on the encoder what that value should be.
Ok, I think the TL032 one is already done as well.
I'll check with limor and see if she has some arduino code or something I can go off of. Thanks @onyx hinge.
Could you link to the encoder you are using? How are you wiring it? There should be two signal terminals, and a common terminal connected to ground.
@gilded cradle this product? https://www.adafruit.com/product/5799
yeah
pretty sure I don't have one. should I order one?
If you want, but I'm pretty sure I'll figure it out before it gets to you.
I hope so too
🙂
does busio.I2C/SPI/UART.unlock() ever throw an exception?
it only would if the object were deinited
also there is no lock/unlock or UART, since it's not a shared bus
oops. yah. was just naming all the busio things.
and that's a generic behavior, right? (attempting to use a deinitd object)
right, those classes check all over the place for deinited objets
for more context, asking in relation to this issue:
https://github.com/adafruit/Adafruit_Blinka/issues/748
but Blinka should try to match
yes
I think we wanted to make unlock() be idempotent. So, yes, Blinka should not complain.
I had a rotary encoder project handy, QT Py RP2040 and CNC rotary encoder
This project is running Adafruit CircuitPython 8.2.8 on 2023-11-16; Adafruit QT Py RP2040 with rp2040
# SPDX-FileCopyrightText: 2018 Kattni Rembor for Adafruit Industries
#
# SPDX-License-Identifier: MIT
import board
#import rotaryio
from rotaryio import IncrementalEncoder
import usb_hid
from adafruit_hid.mouse ...
let me check Espressif, because it uses a semaphore
cool. thanks. so fix for Blinka should be trivial.
i think so
thanks for the merges dan
Jpeg decoding is not quite right
but it's clearly something!
Ship it! 😄
Now it's perfect
Something's wrong with the doc build; I'll get that sorted soon.
Testing file:
Testing code:
import jpegio
import displayio
import adafruit_pycamera
import numpy
cam = adafruit_pycamera.PyCamera()
j = jpegio.JpegDecoder()
with open("test.jpg", "rb") as f: b = f.read()
w, h = j.decode(b, None)
print(w, h)
bm = displayio.Bitmap(w, h, 65535)
j.decode(b, bm)
arr = ulab.nu...
This ends up NOT using the ROM jpeg decooder, becaues it's an older version, is not header-compatible, and uses RGB888 instead of RGB565 as desired.
it would be nice to eliminate the need to byte-swap the image before merging this, as that'd be an incompatible change.
jpegio sounds like arpeggio
Tested with macOS Sonoma 14.2 beta RC (build 23C63), hot off the CDN on Dec 5 and unsurprisingly it still exhibits this problem.
@onyx hinge I have a Q about background tasks when you have a chance. On reset, the whole callback structure is cleared to zero. The webworkflow only sets it function once so if it is queued during a reset, then it stops working
Should I change it to only clear next?
or have web workflow set func again?
seems to me that any CB off the python heap should be untouched
@slender iron trying to piece together my train of thought. is this background_callback_reset?
and changing it for heap vs non-heap objects was at 64460107531ee110c809edec7823a557e1455b49
yup
jepler@bert:~/src/circuitpython$ git grep '^static background_callback_t'
ports/cxd56/supervisor/port.c:static background_callback_t callback;
supervisor/shared/status_bar.c:static background_callback_t status_bar_background_cb;
supervisor/shared/tick.c:static background_callback_t tick_callback;
supervisor/shared/usb/usb.c:static background_callback_t usb_callback;
supervisor/shared/workflow.c:static background_callback_t workflow_background_cb = {NULL, NULL};
```Here are the non-heap background_callback objects I can spot easily
so this could be affecting a number of things
haha, I was just going to look at that
So background_callback_reset should .. reset all GC-based ones but leave all non-GC based ones?
ya, I think so
is the memset just in the wrong spot?
I assume a non-heap one will use a non-heap function and data
diff --git a/supervisor/shared/background_callback.c b/supervisor/shared/background_callback.c
index cceda7d413..68a174e806 100644
--- a/supervisor/shared/background_callback.c
+++ b/supervisor/shared/background_callback.c
@@ -130,7 +130,5 @@ void background_callback_reset() {
*previous_next = cb;
previous_next = &cb->next;
- cb->next = NULL;
new_tail = cb;
- } else {
memset(cb, 0, sizeof(*cb));
}
why would we need the memset at all?
I'm not sure; it was part of the original design is all.
it helps make things GC'able but this is only called when zapping the heap
(right?)
well test with -memset too and see how it goes? audio and keypad would be good to check, one or the other
could check if the callback's data is heap and clear that too
diff --git a/supervisor/shared/background_callback.c b/supervisor/shared/background_callback.c
index cceda7d413..99170d6015 100644
--- a/supervisor/shared/background_callback.c
+++ b/supervisor/shared/background_callback.c
@@ -118,5 +118,5 @@ void background_callback_end_critical_section() {
-// Filter out queued callbacks if they are allocated on the heap.
+// Filter out queued callbacks before tearing down the heap
void background_callback_reset() {
background_callback_t *new_head = NULL;
@@ -127,11 +127,9 @@ void background_callback_reset() {
while (cb) {
background_callback_t *next = cb->next;
- if (gc_ptr_on_heap((void *)cb)) {
+ // unlink any callback that is either on the heap itself, or refers to heap data
+ if (gc_ptr_on_heap((void *)cb) || gc_ptr_on_heap((void*)cb->data)) {
*previous_next = cb;
previous_next = &cb->next;
- cb->next = NULL;
new_tail = cb;
- } else {
- memset(cb, 0, sizeof(*cb));
}
cb = next;
Yup, that's what I'm thinking
oh but in case you unlink a callback that is off-heap, but its data is on heap you DO need to clear .. something
you need to clear prev? ```c
void PLACE_IN_ITCM(background_callback_add_core)(background_callback_t * cb) {
CALLBACK_CRITICAL_BEGIN;
if (cb->prev || callback_head == cb) {
I'd assume the owner of it would reset the data
diff --git a/supervisor/shared/background_callback.c b/supervisor/shared/background_callback.c
index cceda7d413..07d4461a7c 100644
--- a/supervisor/shared/background_callback.c
+++ b/supervisor/shared/background_callback.c
@@ -118,5 +118,5 @@ void background_callback_end_critical_section() {
-// Filter out queued callbacks if they are allocated on the heap.
+// Filter out queued callbacks before tearing down the heap
void background_callback_reset() {
background_callback_t *new_head = NULL;
@@ -127,11 +127,10 @@ void background_callback_reset() {
while (cb) {
background_callback_t *next = cb->next;
- if (gc_ptr_on_heap((void *)cb)) {
+ // unlink any callback that is either on the heap itself, or refers to heap data
+ if (gc_ptr_on_heap((void *)cb) || gc_ptr_on_heap((void*)cb->data)) {
*previous_next = cb;
previous_next = &cb->next;
- cb->next = NULL;
+ cb->prev = NULL; // invariant for un-queued callbacks
new_tail = cb;
- } else {
- memset(cb, 0, sizeof(*cb));
}
cb = next;
are you going to test with it? if that doesn't work we should probably go to video and see what we can figure out together. I'll be around for a couple hours.
ya, I'll test this. I think it'll work
now I'm looing at previous_next = &cb->next next to cb->next = NULL and I'm not sure this is a correct 'remove from linked list' operation.
I need pictures or something
ya, I think the old code completely cleared it
well, maybe not. new_head is set via previous_next
I'm right there with you
// Unlink any callbacks that are allocated on the python heap or if they
// reference data on the python heap. The python heap will be disappear
// soon after this.
if (gc_ptr_on_heap((void *)cb) || gc_ptr_on_heap(cb->data)) {
cb->next = NULL;
cb->prev = NULL; // Used to indicate a callback isn't queued.
} else {
*previous_next = cb;
previous_next = &cb->next;
new_tail = cb;
}
// Filter out queued callbacks that refer to GC heap before tearing down the heap
void background_callback_reset() {
CALLBACK_CRITICAL_BEGIN;
background_callback_t *cb = (background_callback_t *)callback_head;
callback_head = NULL;
callback_tail = NULL;
while (cb) {
background_callback_t *next = cb->next;
// Set 'not on queue' invariant
cb->next = cb->prev = NULL;
if (!gc_ptr_on_heap((void *)cb) && gc_ptr_on_heap((void*)cb->data)) {
// This background task was queued and not on the GC heap,
// so re-enqueue it
background_callback_add_core(cb);
}
cb = next;
}
// Flag shouldn't be set here, but clear it anyway
in_background_callback = false;
CALLBACK_CRITICAL_END;
}
no that's not so good because background_callback_add_core also sets/clears CALLBACK_CRITICAL_END and has the side effect of calling port_wake_main_task
callback_add_core2? 🤣
*previous_next = cb;
previous_next = &cb->next;
cb->prev = new_tail;
new_tail = cb;
- set next of the previous cb 2. set our next to be set 3. set our prev to the old tail 4. now we're the tail
Thanks to @onyx hinge for reading my notes, I felt I made it long and complicate but he did read that great.
DJDevon3: As already hinted here, I don't plan to go on Show and Tell with my doorbell project, because it end at 2AM (my time)... and pressing the doorbell button will wake up everybody (also I have 4 Pavlov's dogs that go check the entrance door when they hear the old doorbell).
Picture 1: This is my bodge wire job (the blob is some UV nail gel to secure the cable).
Picture 2: This is the central relay that open/close 4 separated circuit at the press of the main doorbell button, that way I can work various solutions with the peace of mind that some sound will be produced even if my code crash.
background_callback_add_core wants to add at the end of the list, so that a callback that pathologically re-adds itself still progresses. I don't know that the order is important during reset.
@thorny jay UV nail gel has many uses indeed
https://circuitpython--8696.org.readthedocs.build/en/8696/shared-bindings/jpegio/index.html TIL that for pull request builds, readthedocs uses an entire temporary domain name!
@onyx hinge after looking into the settings for that display, I think there is a bug somewhere, so maybe you should pick one up after all.
@gilded cradle OK, I will. can you put what you know so far into an issue please?
Sure. In CircuitPython?
yes
Ok, will do.
@gilded cradle any data you'd like in the directory listing json? I'm changing it to include whether it is writable and free space
CircuitPython version
Adafruit CircuitPython 9.0.0-alpha.5 on 2023-11-15; Adafruit-Qualia-S3-RGB666 with ESP32S3
Code/REPL
from displayio import release_displays
release_displays()
import time
import random
import displayio
import busio
import board
import dotclockframebuffer
from framebufferio import FramebufferDisplay
tft_pins = dict(board.TFT_PINS)
tft_timings = {
"frequency": 16000000,
"width": 240,
"height": 960,
"over...
I presume you mean web workflow. Maybe something like number of files and folders. Perhaps total size.
hrm, total number of files may be hard. total size is easy
@gilded cradle let's eliminate overscan_left. what if you simply specify a framebuffer of 360 pixels wide?
I tried that. Same result.
what if you ask for 368 pixels?
and if that doesn't work, what about 384. I am wondering if there's a required "pixels are a multiple of N", where N might be 16 or 32.
does that get you a stable display?
cool. displayio will still think the width is too much, so I'll have to do .. something.
I can't find where in the esp-idf source code this "multiple of 16" error is actually being raised.
I don't know the exact model of the encoder anymore unfortunately and i tried all the settings, like i said a divisor of 1 leads to the correct total counted clicks, just the way its counted is wrong (2 position changes every two clicks).
I think the problem is that the library counts every falling edge twice while not counting rising edges at all, which probably makes no difference if the encoder has more than 1 count per detent. Maybe this graphic will help:
? The internal implementation is different for those processor families. If you get different results, then that says something is different about the RP2040 implementation. We have done testing of this and it didn't seem off (for instance the rotary encoder on the MacroPad, which uses an RP2040).
Like mentioned i don't know the exact model but measuring the output seems to match this diagram in the datasheet, so basically half a cycle per detent. I do have some ESP32s laying around which i could give a try if that helps
<img width="923" alt="image" src="https://github.com/adafruit/circuitpython/assets/9402008/aef583ce-8b34-4c1d-a4e2-98b94013c7cd">
These details apply to RP2040; other microcontroller families may use other methods for quadrature counting
The IncrementalEncoder on the RP2040 uses all quadrature edges (different than either of the images you showed).
Each transition 00 -> 01 -> 11 -> 10 -> 00 increases an internal counter by 1, and any transition in the reverse direction decreases it by 1. (invalid glitches like 00 -> 11 or 01 -> 10 do not change the count; non-changes like 00 -> 00 do not change the count)
W...
Thanks for the detailed response, will do some debugging and then come back to you, if it is counted like you described there must be an error in my setup 🤔
Please show us how you have wired the project. I think that would be more helpful in figuring out what is going on, vs substituting a different microcontroller.
Repeating Dan's earlier message:
There should be two signal terminals, and a common terminal connected to ground.
example of wiring an encoder with circuitpython (this one also wires the "press in to click" function available on some encoders)
if one of the signal terminals is interchanged with ground, that might cause what you are seeing
It looks like something internal to IDF is leading to a "multiple of 16 pixels width" requirement, though I didn't find the specific line of code that does it. This may be related to the DMA unit size.
Can we add an overscan_right or perhaps have it automatically round up?
Here's the underlying error:
E (3410) cache: esp_cache_msync(35): size isn't aligned with the data cache line size (32)B
E (3410) lcd_panel.rgb: rgb_panel_draw_bitmap(742): flush cache buffer failed
This confirms there's a 32 bytes / 16 pixels requirement for line lengths.
I'll just round up the (width + overscan_left) to a multiple of 16. PR tomorrow.
I think we're defaulting new ESP file systems to extended
and not preventing their use with dual bank afterwards
I'm actually done with changes this time :)
For a (width + left_overscan) of 360, e.g., debug info shows the following:
E (3410) cache: esp_cache_msync(35): size isn't aligned with the data cache line size (32)B
E (3410) lcd_panel.rgb: rgb_panel_draw_bitmap(742): flush cache buffer failed
Internally add extra pixels as needed at the end of a pixel row, like an automatic overscan_right.
This may not be compatible with all panels, but there's not really another alternative with this peripheral. So let's try this!
Clo...
@gilded cradle adafruit_qualia_s3_rgb666/firmware.uf2 locally built from the code in https://github.com/adafruit/circuitpython/pull/8698 if you want to try it .. but I'll be AFK for the rest of the evening
We are checking for extended with dualbank
its in shared-bindings
(I expected common-hal)
Thanks @onyx hinge
cfg->timings.h_res = int((width + overscan_left + 15) / 16) * 16; // round up to multiple of 16
It's still giving the same error. I think without the int(), it just re-multiplies.
I'll actually try it tomorrow and get it fixed for real @gilded cradle
Thanks @onyx hinge
This changes storage.mount() to require that a mount point exist on the parent file system.
A bug in background tasks is also fixed where the function parameter is cleared on pending callbacks during "reset".
Disk usage is shown on the directory listing and changes based on the mounted file system. Writable is also loaded per-directory.
Fixes #8108. Fixes #8690. Fixes #8107.
The server side USB check isn't quite right. Will need to look at that when I have a chance next. Out of time for today.
I ran the test code.py from #8690 and didn't see any delays/hangs in the timer printouts and was able to copy multiple files via web workflow without the webpage crashing. Thanks!!! :grin:
I successfully copied a 4Mb file which did hang the code.py file while the transfer was happening but once the transfer finished everything behaved normally.
I was able to hang the code.py running on the serial terminal by doing a page refresh on the web workflow directory listing, at which point the...
Check whether 7 pixels works fine or not. Also multiples of 8.
Also whether AudioMixer is necessary to cause the problem.
Fails from 4-11 pixels. Never mind about audio: @todbot says it's needed.
- Fixes #8489.
As suggested in https://github.com/adafruit/circuitpython/issues/8489#issuecomment-1836574464, use DMA when the PIO transfer size exceeds the FIFO depth. Since the FIFOs might or might not be joined, figure out the FIFO depth in the constructor and remember it. (It's hard to retrieve the JOIN info from the config, so just use an extra byte to remember it.)
Tested using the test program in #8489 from 1-12 pixels. No jumping seen.
This is close to my first foray into PIO...
@gilded cradle I still don't have that display 'in hand' but I double-checked that I don't get an exception when setting up a display with ```
"width": 240,
"overscan_left": 120,
"height": 960,
I actually did grab the artifact when I tested, but I'll try again in case I did something wrong.
OK.
FWIW if a is an int, then a / 16 in C is a lot like a // 16 in Python: it doesn't result in a float like a / 16 does in Python or Javascript.
Ah ok. Well, tried again and it's working this time, so I'm not sure what happened the first time.
@onyx hinge ^
Tried from the start and it worked this time, so I must have uploaded the wrong firmware.
woohoo thank you for re-testing!
yw
@gilded cradle so the bars show correctly and the displayio width of the panel is what it should be?
Let me verify...
(it prints a width of 240 here)
yes
thank you! your notes and testing were helpful
Awesome. Thanks for fixing so quickly.
I checked my circuit again and I indeed had the ground wire switched with one of the signal wires (didn't have a pinout or a datasheet unfortunately 😑). Feeling quite stupid now, thanks for your all your help and sorry for the caused effort!
You're welcome. it could happen to anybody :)
The cause of this was incorrect code in background task reset. This happens after code.py is run. Background tasks are a linked list of callback objects with function and data to call when running background tasks. The web workflow has a callback object it reuses to queue its work and sets the function to call once at the start. The background task reset code was completely zeroing the whole callback object including the function pointer and breaking it forever more. #8699 preserves callbacks...
@slender iron @onyx hinge I am making an 8.2.9 release. Anything to backport from main? I don't think so.
not that I can think of
nothing on my mind
web workflow issues are improved on 9
if you're doing a 9 release I wouldn't mind getitng the jpeg decoder in 🙂 I just marked it ready for review.
I will do a 9 release soon. I was just going to ask about those pending PR's.
I'm closing this since we took one of the alternative solutions in #8663 -- please feel free to continue the conversation if this is still not resolved for you.
Automated website update for release 8.2.9 by Blinka.
New boards:
- wisdpi_ardu2040m
- wisdpi_tiny_rp2040
We updated the documentation to reflect that monotonic time is not guaranteed to persist after the interpreter exits, whether it's for reload, deep sleep, etc.
Looks like this is the IDF default PID: https://github.com/espressif/idf-extra-components/blob/master/usb/esp_tinyusb/usb_descriptors.c#L11-L21
I wouldn't use it though because CircuitPython presents different interfaces than what 0x4001 is for. Please request a custom PID from Espressif: https://github.com/espressif/usb-pids
This is unchanged in current idf. If the current state of affairs is unsatisfactory, we should probably write our own ping out of lwip socket calls.
@onyx hinge I just replied on the flipper zero board def
0x400x is IDF defaults and are probably wrong for circuitpython
oh dang, I thought it was OK to go in. I'm sorry.
I know, we overlapped
@maewolfsky Please request a new PID from espressif and make a new PR. I think using the same PID will confuse the host computer because the USB descriptor is different from the default firmware.
We can put it in as is and ask that they change it. Not sure it's worth reverting.
I ran the test code.py from #8690 and didn't see any delays/hangs in the timer printouts and was able to copy multiple files via web workflow without the webpage crashing. Thanks!!! 😁
Yay! Thanks for testing!
I successfully copied a 4Mb file which did hang the code.py file while the transfer was happening but once the transfer finished everything behaved normally.
This is expected. The web workflow code waits for the whole file before returning to python code. I don't think this ...
does CP 9 now have everything from CP 8?
no, i have to merge up
I had to do this by hand because the automerge got very confused and was considering random similar files in merge conflicts. This is happening more often lately, not sure why.
BLE workflow hasn't been updated so the CI failed. I have ideas on doing clearer per-mount locking so I'm going to run with that. I'm thinking about the S3 future where we have both web and ble workflows going concurrently.
Could you explain this in more detail please? I'm not sure if you mean the REPL or not.
I have a tio terminal session connected to the micro controller, doesn't matter if it's in the REPL or running a python program.
I also have the web workflow file browser open in a web browser window (http://10.0.0.218/fs/#/) .
If I hit the refresh page button on the web browser the web workflow web page refreshes but the tio serial terminal hangs and will not respond to any input including Ctrl...
@lone axle not sure who I should ask, but my addition of the pycamera library to the bundle seems to have gone wrong. My library got moved to the end of its list and with no description; the files in it don't seem to be in the bundle. https://github.com/adafruit/Adafruit_CircuitPython_Bundle/commit/f0a9f54ebbaf2d79b2d66f48155bbc6a01f01089
Updating https://github.com/adafruit/Adafruit_CircuitPython_Bundle/circuitpython_library_list.md to NA from NA:
> Added the following libraries:
Updating https://github.com/adafruit/Adafr...
and something happened to another module but that's my fault and I know why ..
is it because I was missing ".git" on the URL?
very odd, I don't think I've ever seen the automatic adabot update do anything like that before
Ahhh, yeah I think that is a good theory. The rest of them all do end in .git. Something could be receving an HTML page as a response when it's expcting some kind of git data.
@lone axle I took the liberty of requesting your review
The full code isn't updated for the new directory listing yet. The developer tools in your browser may have more info.
I'm not sure what to look for but the developer tools console simply displayed a couple status messages:
Load different workflow index.js:37
Initializing File Transfer Client... index.js:37
exceptions know the line numbers where they're generated, but in general... is the runtime self-aware about what line number is executing? it would be super-handy for safemode to document where it went bad
Something that might be useful would be a "trace-back buffer". This would be a modestly-sized array that is treated as a ring buffer by the runtime, recording each line number as it is executed.
The line number info is stored at least some of the time. It's suppressed by mpy-cross -O3.
is it worth an issue for enhancement? are there other non-exception circumstances besides safemode when execution stops and the runtime would still be intact?
it's possible, yes. Related issue: https://github.com/adafruit/circuitpython/issues/1054. But reset_into_safe_mode() really needs to retrieve the info and then stash it somewhere it so we can recover it after a hard reset. Feel free to open an issue!
Thanks @deepserket and @hexthat!
It would be very helpful to know which line number was executing when a safemode occurred, perhaps with a supervisor attribute.
It's a reasonably-involved process (not beginner-friendly) to make a debug build, collect a backtrace, and decode it. And sometimes the backtrace is corrupted, or otherwise incorrect due to different build parameters with DEBUG=1, or perhaps other reasons.
Related to #1054
Brief Discord discussion [here](https://discord.com/channels/32725470853411635...
@gilded cradle can you help @crude blaze with some questions on the tinydrm/fbtft overlay
Sure
hey @gilded cradle
Limor mentioned you had already created an overlay using the tinydrm ili9341 driver?
ok nvm actually looks like its already working 🙂
ah nope it was a lie, its actually loading the fb driver
with the tinydrm drivers available it seems to give me a white screen/does not init the controller for some reason
Hi @crude blaze. I had not created a tinyDRM overlay. I had previously worked on an installer script that installed a MIPI driver that somebody else had made here https://github.com/adafruit/Raspberry-Pi-Installer-Scripts/blob/main/adafruit-pitft-mipi.py and there was talk of somebody having already created tinyDRM drivers here https://github.com/raspberrypi/bookworm-feedback/issues/130
Contribute to adafruit/Raspberry-Pi-Installer-Scripts development by creating an account on GitHub.
ah I see! thanks for the links, will take a look
you're welcome
Destroy display[0] or Not?
I see several CircuitPython boards with an integrated display. They create their display in board_init() and it’s available as board.DISPLAY within CircuitPython.
Some firmware also has board_deinit() which will release the display if the user code calls displayio.release_displays().
Most CircuitPython tutorials (and troubleshooting suggestions) recommend calling displayio.release_displays() early in their code.
The problem is there appears to be no way to re-initialize the integrated display without power cycling the board.
- Is there a way for a board to re-initialize the integrated display?
- Should boards with integrated displays ignore
board_deinit()?
you can re-initialize it by using the python libraries for the given displays
the only reason you would call release_displays on a board with a built-in display is if you wanted to initialize it with your own code
The problem I see (and have encountered) is that tutorials often say to release_displays and then the user has no clue why their code stops working with the integrated display.
A search of this discord amplifies this issue. It has been confusing and troublesome for both board developers and end-user CircuitPython coders.
you call release_displays as part of initializing a display in python
for boards with built-in displays you don't do it
because you never initialize the display in your code
I understand the logic.
I’m saying, the situation causes problems for both board developers and end-users.
Unless there is a valid reason, it would seem - at initial blush - that the board should not deinit the integrated display.
how would you reinitialize the display then?
if the integrated display is not de-initialized then it would always be available as board.DISPLAY
I will give you an example. I have a tile-and-sprite engine called Stage that I use for games. It's much simpler than displayio (and faster thanks to that), and it doesn't have software rotation of displays. For the MeowBit, the board_init initializes the display up-side-down, and uses displayio's software rotation to make it look right. In the mewobit port of Stage, the initialization file releases the displays, and initializes the display with correct orientation, so that Stage works correctly. If your change was added, this would no longer work.
There may be other reasons why people might need to use a python library for a built-in display.
besides, having a command that does nothing would only be more confusing in the long run
Rotation is an interesting point as it is “usage” specific. This would also be true for any other parameters which are only available during initialization. (BTW: some initialization parameters would benefit form being available after initialization but that becomes a whole other topic).
it's not just rotation
there are framebuffer-based display drivers that don't use displayio
The only current path may be to have a re-init capability of the integrated display.
you might want to use gifio directly, skipping displayio
there is a lot of reasons why you might want to disable displayio
Yes. Which is why there should be an intuitive documented way for a user to get back board.DISPLAY
currently, there is not user-friendly message and no codeable solution
the board_init is not just for displays
I understand. I’m saying, if the end user has a well documented coding method which can make board.DISPLAY stop working, it seems intuitive there should be a coding method for getting it back.
The problem is rooted in the prolific advice to use displayio.remove_displays() as a catchall troubleshooting step.
prolific?
you only ever use release_displays when you are initializing a display, and then you have a method of gettingit back right there
literally on the next line
If you search in this discord and on the web, there are many many posts advising end users to call release_displays() as a step.
and I bet chatgpt is also giving all sort of stupid advice
It may be be bad advice but it’s broadly mentioned
The advice is in many adafruit learning guides … and without guidance on “when not to do it”.
can't control that
do you have an example of a learn guide that advises to call release_displays without initializing the display?
we should probably fix those
That is not what I said. I was saying there are guides that give examples and it’s easy to mix when the guide is talking about an integrated display vs an external one.
any advice taken out of context is always going to be bad
Again, the issue is not calling release_display and then initializing explicitly. It’s calling release_display and having no intuitive way to get board.DISLAY back.
okay, let's consider a hypothetical scenario
We need to decide the persona of the majority of CircuitPython developers.
_ I’ll pick this up shortly. I need to walk the dog_
A user of a board with a built in display has some kind of problem, and to solve it, they randomly try to copy-paste pieces of code they find in different guides. Eventually they find the mention of release_displays and add it to their code. Their display stops working, so they try to find a way to get it working again. Now, there are two possibilities: right now, there is no such way, so they just remove the release_displays call and try other things to fix their problem. With your proposed change, they find the function to call to get the display back, and add it to their code somewhere after release_displays. Their code is now even worse than it was.
I believe the differences of our viewpoint comes down to the persona of the target end-user. Novice users find the current behavior of release_displays() on an integrated display to be confusing while more advanced users find it adds flexibility.
@empty salmon I agree there is probably room for improvement here. This is something that core devs are looking at and may change for version 9: https://github.com/adafruit/circuitpython/issues/8675
Part of what we're looking at doing is something like
Instead, we can add an explicit supervisor.runtime.display = that allows for setting a single display to preserve outside the VM and use for the terminal
based on the discussion I was a part of, it's not clear to me whether that'd complement or replace board.DISPLAY.
If you wanted to organize your thoughts and add them to that issue it would be totally appropriate. Thanks!
A note about (2): the pycamera has to release and reinitialize the display multiple times during a single application run. would it change to doing a deinit call on the specific display object instead of calling release_displays()?
Thanks @onyx hinge - I read that issue and will set aside some time to assemble a coherent comment.
should 8.2.8 have this implemented? deinit() doesn't seem to work in my hands. Or is it only in the 9.x alphas?
should 8.2.8 have this implemented? deinit() doesn't seem to work in my hands. Or is it only in the 9.x alphas?
It was merged to main, so it's only in the 9.x.x releases.
I wasn't thinking we'd do it for 9. But I would like to do it to get rid of release_displays.
@slender iron oh oops, sorry for putting words in your mouth about that. The milestone info is correct and I just .. ignored it.
np
Yes, you'd deinit the specific display. supervisor.runtime.display would give you access to a display created by a previous run and kept alive by CP. (It doesn't need to be board.DISPLAY.)
Line number of the main file or would we try and keep the filename too? And if we store a string, why not the full traceback? Similar to #7490
The full code isn't updated for the new directory listing yet. The developer tools in your browser may have more info.
I'm not sure what to look for but the developer tools console simply displayed a couple status messages:
The network tab can be helpful because it shows the calls being done to the device and if they failed.
I don't see any failed calls... The 9 second delay was me entering the CircuitPython password
@slender iron what is left to merge that you would like in alpha.6 (or beta.0)? @onyx hinge jpegdecoder is still in process, right?
not necessarily going to do this now, but I could do it by tomw
I thought the output was still a bit buggy, as noted internally?
maybe alpha because I'm changing how storage.mount works in my wip SD card pr
the PR is marked as ready
yes, I'm thinking there are still some evolving and not-yet-added things
Neat! We may want to enable it on more boards in the future so we can display jpegs right off the web.
Please comment what this is doing and how it works. It isn't super clear from the code.
It was weird to me that this doesn't do anything. However I see that the object has buffers on it. I'd note that in the doc.
The shared-bindings make_new code should call the common_hal construct. I think you missed it because it doesn't do anything (which is ok.)
I worry a little bit that we could be forgetting #CircuitPython2024 (not that I have any clue what I could write there) ... or is it a blogpost that @slender iron does on the first of January?
I intend on doing it.
We did just get the email setup
good to have a reminder though
No that was quickly fixed
I think it's ready but the api needs review
which I see scott was kind enough to provide, thanks!
If we're planning to try incorporating the esp32 jpeg decoder, we may want to hold off on this specific API; the esp32 simd decoder may not support the /2 /4 /8 downsampling; I'm not sure yet.
/8 downsampling is very useful (for thumbnailing photos taken on a camera, it makes the highest resolution downsample to 320x240 or something)! (and downsampling after decoding isn't viable, as the simd decoder only decodes full images, so it would need 10MB+ RAM for the full image).
Setting back ...
and it needs bitmaps to be 16-aligned which MAY be guaranteed (aren't gc blocks 16-aligned?)
word is to just go with tjpg decoder for now. I'll try enabling jpegio more widely, then turn it back off where it doesn't fit, and finally set the PR as ready for review again. so, maybe not for this release dan is planning to do.
I wonder if it would make sense, once this lands, to add jpg support to image_load using jpegio, if it exists
I know you can use jpegio directly, but having a simple wrapper in image_load would give a consistent interface
plus, image_load can autodetect file type
that sounds very possible to me, not that I am super familiar with image_load
Retested with Adafruit CircuitPython 9.0.0-alpha.5 on 2023-11-15; Adafruit QT Py ESP32-S3 4MB Flash 2MB PSRAM with ESP32S3. Well-behaved on espresso and raspberry. Closing.
This refactor changes all board_urls to a list so that multiple links can be used.
This may be how the unsupported version is handled. @makermelissa would know.
I did not look at every single one :)
No worries. I've been running a script to check them automatically.
I can't really remember because it's been about a year, but I would have thought it would at least attempt to contact it.
and it needs bitmaps to be 16-aligned which MAY be guaranteed (aren't gc blocks 16-aligned?)
Ya, python heap is 16 byte aligned on everything but imx. On imx it is 32 byte aligned to match the cache structure.
/8 downsampling is very useful
I'd leave it since it is useful. You can always raise an error on other implementations if you really need to. Or fall back to the shared implementation.
Looks good to me. Won't merge since still a draft.
It looks like there are some boards to disable it on for size reasons. After that I think this'll be ready to go.
Looks good to me. Won't merge since still a draft.
Fixes #1299. Also, fixed one of the hidden boards' board_url format.
Hi guys,
I try to "port" circuitpython to a cheap, bit older board:
Heltec WifiKit 32, featuring esp32 + Oled.
Pinout, Schematics and Specs here: https://resource.heltec.cn/download/WiFi_Kit_32/
So far I got the circuitpython build framework incl. esp-idf up and running and succesfully built and flashed resulting firmware.
However, I don't get a Repl or human readable Console output after the bootloader init.
This is what I get in CuteCom:
![Bildschirmfoto vom 2023-12-0...
esp_restart();
If you put this in board_init(), it's going to cause a reset each time the board starts up, so you'll end up with a boot loop.
We'd have to see the rest of your code to see what else is wrong.
Your board seems close to this, which has already been added: https://circuitpython.org/board/heltec_esp32s3_wifi_lora_v3/
Hi and thank you so much for answering that quickly.
The esp_restart() is only for testing purpose.
I expected at least seeing the printf() output, but instead I just get garbage.
Thus I suspect having some esp-idf uart stuff not configured right.
The mentioned Heltec Lora 32 V3 board is a ESP32-S3 and has some other relevant GPIO pinout.
Okay, I try to do the github stuff with forking and so on.
I hope that will help.
I see - there are multiple "WiFi" boards, and the original ESP32 one (yours) seems to be discontinued
There seem to be several versions of the original WiFi, with different-sized flash chips. Which one do you have? You will need to set CIRCUITPY_ESP_FLASH_SIZE and the other values properly
I am trying to recompile circuit python so I can see when circuit python allocate memory and when trying to compile i get this error
│ /mnt/e/circuitpython/ports/atmel-samd/../../tools/gen_nvm_devices.py:9 in main │
│ │
│ 6 │
│ 7 │
│ 8 def main(input_template: pathlib.Path, output_path: pathlib.Path): │
│ ❱ 9 │ flashes = cascadetoml.filter_toml(pathlib.Path("../../data/nvm.toml"), []) │
│ 10 │ │
│ 11 │ template = Template(input_template.read_text()) │
│ 12 │
│ │
│ ╭─────────────────────────────────────── locals ───────────────────────────────────────╮ │
│ │ input_template = PosixPath('../../supervisor/shared/external_flash/devices.h.jinja') │ │
│ │ output_path = PosixPath('build-matrixportal_m4/genhdr/devices.h') │ │
│ ╰──────────────────────────────────────────────────────────────────────────────────────╯ │
│ │
│ /home/carson/.local/lib/python3.10/site-packages/cascadetoml.py:163 in filter_toml │
│ │
│ 160 │ acceptable values for the given keys.""" │
│ 161 │ root_toml = root / ".cascade.toml" │
│ 162 │ if not root_toml.exists(): │
│ ❱ 163 │ │ raise ValueError("Missing root .cascade.toml") │
│ 164 │ │
│ 165 │ template = list(root.glob("*.template.toml")) │
│ 166 │ if not template or len(template) > 1: │
│ │
│ ╭────────────────────────── locals ──────────────────────────╮ │
│ │ filters = [] │ │
│ │ root = PosixPath('../../data/nvm.toml') │ │
│ │ root_toml = PosixPath('../../data/nvm.toml/.cascade.toml') │ │
│ ╰────────────────────────────────────────────────────────────╯ │
╰──────────────────────────────────────────────────────────────────────────────────────────────────╯```
The command I am running is `circuitpython/ports/atmel-samd$ make BOARD=matrixportal_m4`
which version of gcc are you using?
11.4.0
and did you run make fetch-port-submodules?
no I forgot
Hi Dan,
I got the github fork, and commit workflow managed.
Also tried the best I can to introduce the board and descriptions.
Highly appreciate if you took a look on it.
Can I compile circuit python in wsl or should I switch to linux (i dual boot)
I use WSL so it works, though a bit trickier to map ports to WSL then in native linux
Ok. I was wondering because I tried to compile and it took forever but I restarted the command and its working
is this normal
The errors are not normal
internal screaming intensifies
what is boot2.elf
I am running with verbose mode (make -j BOARD=adafruit_kb2040 V="steps commands rules")
I've been able to make builds with WSL but the python pathing can be tricky to setup.
Best practice for WSL: treat it like it's own OS. if you try to share entire projects across it doesn't really work. But if you just want to copy the build/final files across, it works like a champ.
probably should have asked this before I downloaded the circuit python source but is there a debug build I can just download. I know there is a flag that can be set to log allocations
no, we have too many builds already to offer debug builds.
How do I enable build flags. I found a flag called MICROPY_DEBUG_VERBOSE and setting it in py/mpconfig.h does nothing and setting it in ports/raspberrypi/boards/adafruit_kb2040/mpconfigboard.h causes errors (I wrote it to try to set the flag even if its set so these errors show that I would already be set and my config wouldn't matter)
I think I figured it out. There is a file called py/circuitpy_mpconfig.h that I had to configure
You can pass DEBUG=1 into make like so: make BOARD=my_board DEBUG=1 -j8
Also, it's often handy to have REPL plus messages on a UART port, so add these lines (adjusting the pins as necessary) to your board's mpconfigboard.h:
#define CIRCUITPY_CONSOLE_UART_RX (&pin_GPIO1)
#define CIRCUITPY_CONSOLE_UART_TX (&pin_GPIO0)
Finally, you can tweak your optimization flags in your ports Makefile like this (RP2 example):
#Debugging/Optimization
ifeq ($(DEBUG), 1)
CFLAGS += -ggdb3 -Og
# No LTO because we may place some functions in RAM instead of flash.
Giving you a friendlier debug build for use with GDB.
thank you
so this is would make a build that prints debug messages and when something allocates memory make -j BOARD=adafruit_kb2040 DEBUG=1
Nope. You'll have to add code for that yourself.
Ok. I am asking about compile flag things because here https://github.com/adafruit/circuitpython/blob/7715ff09cc663b80403f8907fe90c00fd89c9706/py/malloc.c#L85 it looks like m_alloc will print messages when something allocates memory but I want to know where I enable the flag thing. I tried to set it in py/circuitpy_mpconfig.h and I set MICROPY_MALLOC_USES_ALLOCATED_SIZE to 1 because it is needed but but then I am getting errors.
Here is the log
Try modifying py/malloc.c adding a line like (for extra points you can make it conditional on DEBUG):
#define DEBUG_printf(...) mp_printf(&mp_plat_print, __VA_ARGS__)
Not all of the debug stuff you'll find in the source is current or working, so you'll have to roll your own.
it looks like DEBUG_printf gets define when a flag is set. How could I check is DEBUG is set in the make command
do I do something like #if DEBUG
See my previous message. Just stuff that into py/malloc.c after line 40 and you may get what you want. As far as chasing down macros and flags, you'll need to use something like VS Code with its powerful search facilities.
I tried to compile circuit python for the matrix portal m4 but I get a error saying that build-matrixportal_m4/firmware.elf section '.text' will not fit in region 'FLASH_FIRMWARE'
sounds like: you dont have enough flash for all the code 😅
the only changes I made is
-#define DEBUG_printf DEBUG_printf
+#if MICROPY_DEBUG_VERBOSE || defined(DEBUG) // print debugging info
+#define DEBUG_printf(...) mp_printf(&mp_plat_print, __VA_ARGS__)``` in py/malloc.c
and
```- CFLAGS += -ggdb3 -Og -Os
+ CFLAGS += -ggdb3 -Og -Os -D DEBUG``` in ports/atmel-samd/Makefile
That port already takes up all available flash, so adding just a few debug strings pushes it over the edge. Upgrading your toolchain to GCC 13.2 can claw you back a few bytes. See here: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads. You can also try narrowing the scope of your debug messaging. Finally, you can also see if there are any features you don't use that you can throw over the side. Each has its own flag like CIRCUITPY_PIXELBUF that you can set to 0 in the port or board mpconfigboard.mk.
Download the Arm GNU Toolchain, an open-source suite of tools for C, C++, and Assembly programming for the Arm architecture.
Ok thank
One more thing to try, if you're not using GDB then drop the -ggdb3 and -Og flags.
It should, that's what gets shipped.
I get the same errors when removing it so
What version of CP have you checked out? What version of GCC are you using?
gcc (Debian 12.2.0-14) 12.2.0```
And I downloaded the latesd version of cp so I think 9.0.0
If you cloned the repo and didn't do a git checkout then you have main which is 9.0.0. You'll need the updated toolchain (gcc 13.2) I noted earlier to do a build that fits.
how do I install gcc 13.2
@pulsar sleet I do not think you are going to find out as much as you want by turning on debugging and allocation logging. There are many allocations that will be mysterious. I would suggest instead that you start with a minimal version of the Python program, and then add features one at a time.
(this is from some previous discussion in #help-with-circuitpython )
I know. I need a way to see how big a object is in memory but I don't know how and I don't want to mess around with circuit python's code that much
Dan's likely right. But, it is informative to learn the ins and outs of CP building. The toolchain instructions are available where you find the download.
there are allocations that are made for compiled code and for internal use that are not part of any Python object
I agree we could add sys.getsizeof()
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads and then add the bin directory of that to your path, before other things
note that there are two parts of "getsizeof": enabling the built-in but also implementing MP_UNARY_OP_SIZEOF for relevant types. For instance, getsizeof(a bitmap object) will fail because this is not implemented; this is true for probably ANY type we have added to micropython: ```>>> import displayio
b = displayio.Bitmap(320,200,65535)
import sys
sys.getsizeof(b)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported type for sizeof: 'Bitmap'
uheap.info() might be easier
what if you wrap it in memoryview?
TypeError: unsupported type for __sizeof__: 'memoryview'
boo
if implemented the sizeof a memoryview would be small, behavior on standard python is to not count the referred-to memory: ```>>> b = b"x" * 1024
sys.getsizeof(b)
1057
sys.getsizeof(memoryview(b))
184
(python 3.11)
I install gcc13 and now I get this error
@pulsar sleet here is build of CIrcuitPython 8.2.x for the MatrixPortal M4 with uheap enabled. I had to do a bit of fiddling to get it to compile. However, I repeat that this is not going to tell you as much as you want to know, because native objects have internal allocations that don't necessarily show up here, as jepler mentioned.
Adafruit CircuitPython 8.2.8-7-gc5c7d110df-dirty on 2023-12-10; Adafruit Matrix Portal M4 with samd51j19
>>>
>>>
>>> b = bytearray(100)
>>> import uheap
>>> uheap.info(b)
Array of size: 112
128
>>>
Thank you soo much
you need to do a clean build if you switch compilers
I am getting space issue again. I disabled some stuff but then trying to build with DEBUG disabled should be smaller than a standered build but its not
All I did was disable
MICROPY_PY_BUILTINS_HELP
MICROPY_PY_BUILTINS_HELP_MODULES
MICROPY_PY_BUILTINS_INPUT
MICROPY_PY_BUILTINS_MEMORYVIEW
MICROPY_REPL_AUTO_INDENT
MICROPY_REPL_AUTO_INDENT ``` and I disabled SPI and I2C by commenting out the lines that those pins are defined
building without DEBUG worked after clearing the build foulder
You're getting off into the weeds. Let's go back to the beginning. What is it that you are trying to figure out?
Printing when allocations happen. My issue is that adding a print function that would print the text takes up too much space
I'll be back later if you're still stuck. The dinner bell just rang.
Ok
I am trying to compile Circuit python but I am getting this error
../../py/objarray.c:70:17: error: 'array_decode' declared 'static' but never defined [-Werror=unused-function]
70 | STATIC mp_obj_t array_decode(size_t n_args, const mp_obj_t *args);
|``` Is `STATIC` equal to the C `static`
Figured it out. I needed to reenable bytearrays
Question (on my path to write out some changes to requests and sockets):
Would it make sense to rename adafruit_esp32spi/adafruit_esp32spi_socket.py to adafruit_esp32spi/adafruit_esp32spi_socketpool.py and then import the latter in the former? Since it's really a fake pool?
for some reason when I downloaded the github for circuit python this file had asf_assert instead of assert on line 98 and 75
define ASSERT_IMPL(condition, file, line) **asf_assert**((condition), file, line)
void **asf_assert**(const bool condition, const char *const file, const int line);
```
should I replace asf_assert with just assert. It only happens in the utils_assert.h files
When testing stuff, running experimental builds or other weird stuff, safemode is great.
Now that safemode.py exists, it can do so much more.
But on production (for those few that want to ship CP), it may be desirable to not permit the user to enter safe mode through the boot button.
CIRCUITPY_DISABLE_SAFEMODE_TRIGGER
This would disable the ability to press the boot button to enter safe mode.
This would not stop the code from entering safe mode.
What do you about it?
I can prob...
Trying to use NeoKey1x4 with QTPY_M0 but not enough memory. Maybe I can use a custom build if I remove unused features.
safemode.py is new to me, but one option would be to put some self destruction code in safemode.py or just restart if someone tries to enter safemode... so I am not sure you need CIRCUITPY_DISABLE_SAFEMODE_TRIGGER if those work around are OK.
What would it be, a compilation option so that if you create custom CircuitPython firmware (that you rename another name) you can enable that flag?
Or is it something in boot.py or settings.toml.
There are a few things that people that wan...
safemode.py does not work when safe mode is triggered by the boot button.
Having a fork / downstream build is exactly what I'm trying to avoid.
Having a "fast boot" of sorts would require build parameters (since we can't read fs that early) and is not something I am willing to do.
I've compiled together the list of everything that shook out from the Adabot patch and subsequent release sweep that I don't think I have access to solve. 1 with a pypi token issue, 1 with a GH token issue perhaps the same thing as a different one that Jeff found the settings fix for. And then the list of repos that had additional branch protections which prevented the adabot patch from comitting directly.
There were a few other failures sprinkled in that I have loaded up to look into further today but upon first glance they all looked unrelated to repo settings so I'm hopeful that I'll have the means to get the sorted out.
Does anyone know of a way to force pre-commit to wipe and re-install it's dependencies? Or show me what version it's using for it's tests (version of pylint specifically) I've run into a situation where running pre-commit locally is having a different result then what happens when it runs in the github actions. I noticed the pre-commit config file specifies pylint rev: v2.17.4 so I manually installed that and confirmed if I run it directly on the files I do get the same error messages as the actions container with it.
But if I just run pre-commit run -a locally it's still passing and not having that same error. Which leads me to conclude it's using a different version than the one now installed in the venv all this is running in, and also seems to be a different version from the one specified by the pre commit config file since it has different results when run directly on the same files. Unless there is some other thing that could account for that difference?
pre-commit clean turned out to the be answer to wipe and re-install everything and that has worked to get me in sync with behavior from actions 🎉
There is something wrong with your build. This should not be necessary. If you are trying to do a build, just follow the instructions in the Building CircuitPython guide to the letter, first.
The program you are trying to make fit is just not going to fit in its present form. That is why we wrote it only for the Matrix Portal S3. I do not think the information you are trying to print out is going to be that helpful in shrinking that program.
@lone axle requests.get() should not require the timeout argument. What is the pylint error you are getting? Let's not change the code, let's change the check
I happen to have this link handy which is the same error in a different library: https://github.com/adafruit/Adafruit_CircuitPython_BLE_BroadcastNet/actions/runs/7152642898/job/19478188549#step:2:842
This is the pylint reference for it: https://pylint.pycqa.org/en/latest/user_guide/messages/warning/missing-timeout.html. I'll get the link for the original failing check in adabot.
that's a rather opinionated diagnostic.
Here are the failures from the adabot repo that prompted me to add timeout: https://github.com/adafruit/adabot/actions/runs/7169513926/job/19520092586#step:7:37
I'm not sure if this is a new pylint check or what changed but I don't think it used to flag the same way?
I think it is new. It makes sense that a timeout is a good idea. I'd suggest making a constant maybe instead of using using 30
Error: examples/ble_broadcastnet_blinka_bridge.py:18:11: W3101: Missing timeout argument for method 'requests.post' can cause your program to hang indefinitely (missing-timeout)
It's not incorrect in the sense that calling a function without a required keyword arg is .. pylint just thinks it's bad practice not to specify this optional keyword arg.
it was added in pylint 2.15.x
In the adabot repo example would that be 1 constant in each file that makes requests? or just a single one inside __init__ or somewhere that it can be imported from the different files?
maybe it would be easier to create a helper function that calls requests.get() with a fixed timeout (or make it an optional arg). Basically make the default value of timeout be something else besides None
that would be a lot less verbose
I can do that, although it feels a bit akward to add that to adabot specifically though, would we create the same wrapper in other libraries that use requests?
i am surprised requests.get() has no default timeout
this seems like a larger thing. lemme look at issues in the requests library
This is has been an issue in requests for a long time. main issue is https://github.com/psf/requests/issues/5789. Ideally one would want to set a default timeout, but it seems to be not so simple.
I think it would be fine for now to provide something like from adabot import REQUEST_TIMEOUT and do timeout=REQUEST_TIMEOUT everywhere, so that you can change it if 30 seems too long or to short
maybe REQUESTS_TIMEOUT with an S
Sounds good. I'll add that change to the adabot PR and take a similar approach with other libraries I run accross with the same error raised by pylint.
I have run into a seperate question around actions / infrastructure now as well. In our workflow file (gh release) we have something this:
upload-url: ${{ github.event.release.upload_url }}
What is github.event.release.upload_url or how does it get populated? I have a case where it seems that is being empty or null and then the thing it's passed to fails because it's a required argument. I'll do some digging in the actions docs.
I got some further success:
After compiling the esp-idf system/console example and having similar behaviour (garbage on the console) I suspected indeed UART misconfiguration and found out, that the CP2102 of this board is connected to Custom UART 1, so using the default led to the issues described.
Now I have console output, yayyy!
Let's fight the next issues...
'''
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv...
Thank you!
i use other things from this API to find out stuff about the PR, etc.
Next focus: After disabling DEBUG in mpconfigboard.mk the now relevant part seems to be:
Serial console setup (hanging)
My comment is specific to the board.DISPLAY capability and related CircuitPython behavior; and more specific to boards with integrated ePaper displays. (I realize this is a very small segment but they pose an interesting set of scenarios.)
For a novice user - which CircuitPython has as a core persona - the behavior of displayio.release_displays() is confusing when the user did not initially use displayio to create the display.
With respect to ePaper displays, treating them as ...
Latest Github master source:
While porting to a board:
https://github.com/szsoftware/circuitpython/tree/heltec-wifikit-32-v2
After appearing of this message and studying the source (supervisor/shared/serial.c), I found out that the above message should better be: "Serial console setup done."
Otherwise, developers like me could think something with console setup is wrong, but it's a success message.
Does anyone recall any history on https://github.com/adafruit/Adafruit_CircuitPython_Register_SPI ? It's readme contains instructions for installing with circup install register_spi but it appears it was never added to the library bundle so that doesn't work ATM. Should it get added to the bundle or perhaps have it's readme adjusted?
I don't know what the development status of that is. I see you did the 1.0.0 release -- did you consider it complete and ready to use, just forget to add it to the bundle?
Good question, I do not recall to be honest what I was thinking when it I released it. Forgot that I had done that. My best guess is that I just saw it in the list on the contributing page under library infrastructure and released to get it out of that. But it does appear I may have jumped the gun on it. There is an issue on that repo that was discussing anything further needed to be ready but it didn't get much traction. https://github.com/adafruit/Adafruit_CircuitPython_Register_SPI/issues/1
I don't know if "un-release" is a thing that can happen but if so perhaps that would be appropriate for this library.
since it is not in the bundle I would say don't worry about it. It is possible to delete releases and their associated tags, if you would like to do that.
<@&356864093652516868> The weekly meeting will take place here on discord 1 hour from now at 2pm Eastern / 11am Pacific US. The notes doc is here: https://docs.google.com/document/d/1jtCjgV5NExzjBZxgPpE8dY_D42g4DAJv6w24TaARTRw/edit?usp=sharing for anyone that would like to fill in Hug reports and Status updates. We look forward to hearing from folks during the meeting!
On the WisdPi boards, the description says "Introducing our...", which might be confused as something from Adafruit? Or do we have plenty of text like that? Could be made third-person instead of first-person?
I wonder if these descriptions might link to the originals. Then we could have a link at the top "From ".
@lone axle discord is taking steps to make links to uploaded files expire, so I replaced your link with a copy of the file I uploaded as a github gist.
Thank you, I initially tried attaching it directly to the doc but it turns out that isn't possible.
Current code is:
...
// Do an initial print so that we can confirm the serial output is working.
console_uart_printf("Serial console setup\r\n");
#endif
port_serial_early_init();
}
Easy to change the message, but I think the print should also be done after port_serial_early_init().
I generally try and change text like that, so I just updated it.
To be clear, you want this to be settable in settings.toml?
This is handled in supervisor/shared/safe_mode.py, wait_for_safe_mode_reset().
safemode.pydoes not work when safe mode is triggered by the boot button.
More precisely, safemode.py is deliberately not run in that circumstance.
@lone axle I could grab the library section if you want a break during state of circuitpython
Got it more than basically working. Current status: REPL works, WebREPL works. Thus, wifi works.
Currently testing display init code.
OV5640 Register Datasheet https://cdn-learn.adafruit.com/assets/assets/000/118/994/original/OV5640_datasheet.pdf?1677598686
wisdpi_tiny_rp2040.md needs a little copyediting to remove first-person references. It's also quite redundant: for instance the additional WS2812 RGB LED is mentioned three times (!).
it is segmented eink which is weird
oh very interesting!
@tannewt I believe that the VREF solder jumper noted above resolves this issue.
To be clear, you want this to be settable in settings.toml?
I mean, is there a better way to permenantly set a flag?
nvm would be nice here, as we could make an efuse of sorts.
A module could set a specific bit, and early boot could read it.
But since we don't have a region (to my knowledge) specifically for internal flags, it's not something I wanna do.
This is handled in supervisor/shared/safe_mode.py, wait_for_safe_mode_reset().
I was thinking of just blocking off repl and ...
1.9inch Segment E-Paper Module, 91 Segments, I2C Bus, Ideal for Temperature and humidity meter, Humidifier, Digital Meter
oh yah. huge hug to @danh for dealing with this macos stuff.
I hope it wasn't at 2AM
Sorry I was editing while you were reading.
No worries
I replicated the displayio issue on my own esp32s3 rev tft feather and confirmed the bug on 8.2.9 with the latest 8.x bundle.
Jepler and Melissa doing wizardry this week
Closing this due to the apparent fix. Please reopen if this does not solve the problem.
I had it late (22H00) and early (8H00) but since it is only the music, it may have run during the night without anybody noticing. 🙂
It could be the wind, or "electricity in the air"... I need to measure the minimum time a human close the circuit when pressing the doorbell button, and use that timer for debouncing so that a 1 is only a 1 if it is a 1 for at least x milliseconds.
Neradoc's keyboard layouts for different languages has been an invaluable asset to point people at.
If I understand right that'd make those fonts installable via circup which would be very convenient as well!
Fontz: I usually cherry pick in the Learn Guide repo for font to use in my projects. 🙂
The amount of detail with resin surpasses FDM 3D printing but the chemicals...
The 8x5.bin frequently missing is a pain.
@onyx hinge In the summer, you have to deal with direct sunlight prematurely curing the resin
amazing update Jepler!
Appeciate all your work Melissa doing great things!
Thanks
❤️ Sending you good vibes Scott. God bless you and your family.
No that code was after the book.
Maybe next book will contain CP stuff, that would be great. 🙂
thanks for hosting!
CircuitPython version
Adafruit CircuitPython 8.2.9 on 2023-12-06; Adafruit Feather ESP32-S3 Reverse TFT with ESP32S3
Board ID:adafruit_feather_esp32s3_reverse_tft
adafruit-circuitpython-bundle-8.x-mpy-20231210
Code/REPL
# SPDX-FileCopyrightText: 2021 Tim C for Adafruit Industries
# SPDX-License-Identifier: MIT
"""
CircuitPython simple text display demo
"""
import board
import terminalio
from adafruit_display_text import bitmap_label
import displ...
@tulip sleet did someone do a merge of 8.x to main recently? I think we talked about that being a good idea to do
I did do that: https://github.com/adafruit/circuitpython/pull/8702
aha great
This is deliberate. When you displayio.release_displays(), board.DISPLAY is set to None, because you gave up the display.
Adafruit CircuitPython 8.2.9 on 2023-12-06; Adafruit Feather ESP32-S2 TFT with ESP32S2
>>>
>>> import board
>>> board.DISPLAY
<Display>
>>> import displayio
>>> displayio.release_displays()
>>> board.DISPLAY
None
This is not new. The same thing happens on 7.3.3.
Same error occurs without displayio.release_displays()
nvm you're right just needed a hard reset
import board
import terminalio
from adafruit_display_text import bitmap_label
import displayio
display = board.DISPLAY
print(display)
# Update this to change the text displayed.
text = "Hello, World!"
# Update this to change the size of the text displayed. Must be a whole number.
scale = 1
text_area = bitmap_label.Label(terminalio.FONT, text=text, scale=scale)
text_area.x = 10
text_area.y = 10
text_group = displayio.Group(...
Yes, releasing the display is persistent.
Here is the notes document for next Monday’s CircuitPython Weekly Meeting. It is at the normal time of 11am Pacific / 2pm US Eastern here on Discord. Add your hug reports and status updates to the document before the meeting. If you are unable to attend but would still like to contribute, feel free to add your notes and we’ll read them off during the meeting. Hope to see you there! <@&356864093652516868> https://docs.google.com/document/d/1Jzrzv6IAmRjEdOTQcFm_VghdlLhwG3r-AJlZBHTid68/edit?usp=sharing
Yeah, I had copied and pasted from their website. I just revised most of it and updated.
Thanks for cleanining up the copy.
The multiple links for boards is working out great! Thanks for adding that.
Thank you @tulip sleet for MacOS USB serial chip testing Playground page! It always feels like a roulette "will this board show up?"
You're welcome! I never found this written down in any Apple documentation, but maybe I was looking in the wrong place.
But the doc is pretty terrible about describing things like this.
No, you found what's there. I've been dealing with MacOS X USB for 15 years and nothing is publicly documented
btw, if you don't have a copy of the great "USB Prober" for MacOS, I've a copy of it stashed here: https://github.com/todbot/hidapitester/releases/tag/0.1
👍 i have used that, but not on mac OS. I have the repo bookmarked!
"USB Prober" is one of the only USB diagnostic tools Apple ever made. And stopped supporting it in 2014 I think. But it still works!
I finally got circuit python to compile with allocations printing. The bulk of the size being used was from just the DEBUG flag. Compiling with the debug stuff on without needing the DEBUG flag worked
@lone axle @onyx hinge I fixed everything here: <https://gist.github.com/jepler/64b302125bce317ad93e108aa796984f28
Thank you!
Got oled display initializing.
Have succesfully running Circuitpython on this board.
Hi - great progress. I noted several things.
Check some existing ESP32 boards to see what they do, especially for mpconfigboard.mk.
Take out the commented-out pins.
Also only include pins that are accessible. If some are not connected at all to any accessible pads, take them away also.
This board does not have an onboard RFM, does it?
Why freeze the display libraries?
macOS Sonoma 14.2 actual release is out today, confirmed it still has the same issues with small FAT drives
The release version of 14.2 is out today and as expected still has the problem.
Since there's a new version out we should all report this again using the Feedback Assistant and reference feedback IDs FB13269327 FB13428357 FB13416096 FB13226668 FB13306896 - no particular order, sorry if I missed any.
For a novice user - which CircuitPython has as a core persona - the behavior of
displayio.release_displays()is confusing when the user did not initially usedisplayioto create the display.
I agree. That's why I think it should be removed.
With respect to ePaper displays, treating them as general purpose for console output is potentially damaging. Every time the user has an error in their code or hits
CTRL-Cthe ePaper display is called upon and refreshes. This adds wear an...
Version checked: 8.2.8 and 9.0.0.5a I think the title says it all. This might go as a bug report but there's no code to show.
Cheers, Beat
This changes makes the board able to be powered on, tested on prototype hardware
It has no influence to flashing process nor what debug output at startup reports: It's always mentioned "dio".
I set it to dio for now. Done.
Honestly, I have no clue. This is what the flashing tool reports and I don't know where else to get the info from:
esptool.py v4.7.dev3
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 26MHz
MAC: 24:0a:c4:5c:11:d8
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Flash will be erased from ...
Exactly as you said. I removed it.
in preparation for 9.0.0-alpha.6.
RFM was a leftover from the (only) other Heltec Board files I took for reference.
Removed it.
I just learn about the circuitpython framework and building process and after studying the freeze terms and ideas I wonder myself why one put this into default firmware.
However also this is a leftover from the other heltec board available in Circuitpython and there it passed the pull request/implementation process.
I remove it for now.
@unexpectedmaker please review.
@UnexpectedMaker please review.
Yup, this is good, Michael is working on the CP stuff for TinyWATCH.
Thanks for checking Scott.
I probably made something wrong in the PullRequest procedure.
CI checks fail. I accidentally merged main branch into my fork/feature branch after I commited the last changes.
Can that be the source of "Some checks were not successful" in Build CI?
Any help thankful appreciated!
thank you @tulip sleet
Heads up @v923z - the "ulab" label was applied to this issue.
Automated website update for release 9.0.0-alpha.6 by Blinka.
New boards:
- breadstick_raspberry
- cytron_maker_uno_rp2040
- firebeetle2_esp32s3
- flipperzero_wifi_dev
- p1am_200
- pctel_wsc_1450
- unexpectedmaker_tinyc6
Notable since alpha.5: jpegio, synthio enhancements, update to Espress ESP-IDF v5.1.2
CircuitPython version
Adafruit CircuitPython 9.0.0-alpha.6 on 2023-12-12; Raspberry Pi Pico W with rp2040
Code/REPL
import time
import os
import wifi
import traceback
AP_SSID = "Bob"
AP_PASSWORD = "YourUncle"
DELAY = 5
time.sleep(3) # wait for serial
print("="*25)
# start clean
if wifi.radio.connected or wifi.radio.ipv4_address:
wifi.radio.stop_station()
if (wifi.radio.ap_active) or (wifi.radio.ipv4_address_ap):
wifi.radio.stop_a...
When (web workflow) auto-connect is enabled, is it expected for "auto-connect " to be printed to the console when attempting to manually connect? It will do that endlessly (no exception) and need a restart to connect again.
The meeting calendar has been updated with the 2024 meeting dates, including January 2, 2024. The 2022 events have been removed.
We do treat eink specially internally. Specifically we respect the refresh time spacing that manufacturers suggest be 180 seconds. Showing errors is very valuable.
The refresh time is a problem. The user can set this when creating an epaper display using one of the libraries such as adafruit_ssd1681.mpy but for an integrated display, this is hard coded. Because of this, mot boards with an integrated display choose to use as short a value as possible.
Note, with the proposed super...
@gilded cradle so far it looks like support for jpeg images was limited to the pyportal library, not the portalbase library. is there a reason for that, or is it just how things ended up? I am asking because I wondered if the existing code could be made to transparently switch to using jpegio to decode a jpeg image locally.
@onyx hinge I'll take a look. Not sure the reason. Perhaps it was added by a user.
@gilded cradle OK, let me know -- if it makes sense to do, I can probably take on the work since I want to change it anyway.
Do you know where it's added in the lib?
Do you mean the general image handling?
Ok, I kinda remember that now. I think it handled png, gif, and jpg
the goal would be to have something similar to https://learn.adafruit.com/pyportal-nasa-image-of-the-day-viewer/code-pyportal-nasa-image-viewer work on a qualia, and use jpegio locally to decode the image if it's possible..
Yeah, I think just making sure it's a jpeg and not another kind of image and that should be fine. Go ahead and work on it if you'd like.
thank you. can I tag you on an eventual pull request?
sure
I'm baffled.
#8326 - merged 2 commits into adafruit:main from bill88t:picow-stop-ap on Aug 25
#8590 - merged 1 commit into adafruit:8.2.x from eightycc:8138 on Nov 13
Release 9.0.0-alpha.6 release notes show
Port and board-specific changes
RP2040
...
Looks like 8326 isn't stopping the AP. That's what the call to cyw43_wifi_set_up(..., false, 0) in 8590 does.
@anecdata You're right. We need elements of both for this to work correctly. I'll submit a pull after lunch, will you be willing to test it?
no, that sounds like a bug
Hmmm. Problem is deeper than I thought. The call to cyw43_arch_disable_ap_mode() in #8326 is calling cyw43_wifi_set_up(..., false, ...) so that's not the error. There's a recurring bit of code in #8326:
while (port_get_raw_ticks(NULL) < deadline && (cyw43_tcpip_link_status(&cyw43_state, CYW43_ITF_STA) != CYW43_LINK_xxxx)) {
RUN_BACKGROUND_TASKS;
if (mp_hal_is_interrupted()) {
break;
}
}
that looks like it delays but never actua...
Prior to #8326 common_hal_wifi_radio_start_ap() was not testing cyw43_tcpip_link_status() after calling cyw43_arch_enable_ap_mode() so with #8590 applied it appeared that the AP could be started, stopped, and then started again successfully. #8326 adds testing of cyw43_tcpip_link_status() which returns CYW43_LINK_DOWN for the second start attempt, resulting in the RuntimeError: AP could not be started exception.
The CYW43_LINK_DOWN status is returned because the CYW43 driver'...
Tracing asynchronous events from the CYW43439 shows that it is reporting that the AP is up on the second start attempt. So, there's a status reporting problem in the CYW43 driver.
Starting AP...
[ 6409] ASYNC(0001,LINK,0,0,1) // CYW43_EV_LINK, link is up
[ 6411] ASYNC(0001,LINK,0,0,1) // CYW43_EV_LINK, link is up
AP tcpip status: 3 // CYW43_LINK_UP
AP wifi status: 0
...wifi.radio.ipv4_address_ap=192.168.4.1
Stopping AP...
[ 11573] ASYNC(0000,LINK,0,4,1) //...
@crude blaze I just wanted to check in and see if you ran into anything you had questions about with the Raspberry Pi stuff.
@tulip sleet @lone axle yesterday I made a release of pycamera https://github.com/adafruit/Adafruit_CircuitPython_PyCamera/releases/tag/0.0.2 but last night adabot didn't release the a bundle https://github.com/adafruit/adabot/actions/runs/7190944054/job/19584889856 -- do either of you know what I missed that might have prevented it from being picked up? Wed, 13 Dec 2023 05:06:18 GMT Adafruit_CircuitPython_Bundle Wed, 13 Dec 2023 05:06:19 GMT Everything is already released.
I'm not exactly sure how it normally gets triggered but it looks like the release action hasn't triggered since 12/10 https://github.com/adafruit/Adafruit_CircuitPython_Bundle/actions/workflows/release.yml
my vague understanding was that the adabot action I linked to 2nd is supposed to cause the release to be made but I don't know.
it looks like there could be logic in adabot.circuitpython_bundle
The 0.0.1 and 0.0.2 pycamera releases have the same commit SHA!
oh!
I wonder how the release note got generated saying there was a bunch of stuff in it then
it still needs to see the bundle re-released, because it needs changes from circuitpyhton-build-tools. so many interconnected pieces.
really weird because the Asset files are quite different sizes
I've gotten pretty far!
Managed to get the tinydrm driver working 🙂
Currently working on a kernel patch for the TSC2007 to give that support for the usual touchscreen properties (missing stuff like swap and invert atm)
turns out all that was missing was to invert the reset GPIO, the default behaviour is just the opposite to how it worked in fbtft
Not a status reporting error in the CYW43 driver. The interface flags are getting clobbered due to the AP interface being initialized (possibly in error) after the CYW43439 has brought the link up. Here's what happens on the second AP start:
common_hal_wifi_radio_start_ap()invokescyw43_arch_enable_ap_mode()cyw43_arch_enable_ap_mode()invokescyw43_wifi_setup()cyw43_wifi_setup()invokescyw43_wifi_ap_init()andcyw43_wifi_ap_set_up(). This is where the CYW43439 is ...
Out of curiousity what order does boot.py and the web workflow initialization occur in? If boot.py contained code that added or removed the web workflow configurations from settings.toml would the modified configuration be used when webworkflow is initialized? Or web workflow init happen prior so it won't know about the changes?
Issue arose in HTTPServer library in the context of websockets:
https://github.com/adafruit/Adafruit_CircuitPython_HTTPServer/issues/73
The library can be improved with a flexible import that looks for either the native hashlib module or the adafruit_hashlib library (web sockets could be run on a board without hashlib (for example, with an ethernet featherwing), but the native module is faster.
Awaiting testing.
There is a race condition in the CYW43 driver that is the root cause of this error. I cannot find a workaround, so I'll report it to the CYW43 driver project and we'll have to wait for them to issue a fix.
On the first start of the AP, the CYW43439 takes longer to bring the link up and signal asynchronously than it does on subsequent attempts. For the first AP start cyw43_wifi_setup() is able to complete CYW43_cb_tcpip_init() before the CYW43439 signals that the link is up, so `NETIF_F...
@danh Am I handling #8718 correctly? I could patch the CYW43 driver, but I don't think we want to maintain a CP fork.
It looks like right now the inclusion of "mbedtls" header & library is conditional on CIRCUITPY_SSL only. This will have to be fixed in ports/raspberrypi/Makefile, selecting a different mbedtls subset when SSL is off but HASHLIB is enabled. I don't know exactly what that will end up looking like.
I'm not sure I understand. There is no TLS right now on Ethernet boards or Ethernet SPI configs.
we have a fork of the driver already: https://github.com/adafruit/cyw43-driver. It hasn't been kept up to date because we switched back to the georgerobotics one. It could be sync'd up and then a branch for these fixes could be made.
Ideally I think a PR to the georgerobotics upstream version is the right thing. The q is how fast it would be acted on.
I've opened issue https://github.com/georgerobotics/cyw43-driver/issues/106 against the driver. I've not been seeing any response to an earlier issue I opened several weeks ago.
I'll test on micropython if I get some time. 8.2.9 with #8590 allows turning AP on and off repeatedly. AP shows up and devices can connect to it on subsequent re-start_ap()s.
I'm thinking that if we get close to 9.0.0 release and it's still not resolved we should consider the fork.
It's not really fixed in 8.2.9, we just were not testing its status. Internally the CYW43 driver thinks the link is down due to internally clobbered state, so the AP won't actually work.
Please do. I'm basing what I'm saying on my reading of the code not on actual testing.
I'm bad at reading code, so I have to test to know what's happening 😉
I'm bad at both.
This function in standard Python is a building block for custom REPLs:
from codeop import compile_command
print("Repl in (Circuit-)Python")
ns = {}
PS1="< import myrepl
Repl in Python
<<< for i in range(10):
,,, print(i, i*i)
,,,
0 0
1 1
2 4
3 9
4 16
5 25
6 36
7 49
8 64
9 81
<<< 3+3
6
<<< [
,,, 1
,,, ,
,,, 2,
,,, 3]
[1, 2, 3]
<<<
@stuck elbow - getting a little closer.
setting #define CIRCUITPY_REPL_LOGO 0 in pmconfigboard.h and setting CIRCUITPY_TERMINALIO = 0 in mpconfigboard.mk` will prevent the REPL text and the log from appearing on the ePaper but the display still is "refreshed" when REPL is activated (as in the case of an error, using CTRL-C, or when code.py ends).
I need to figure out how to prevent the "refresh to blank" in those cases.
I think the refresh is built into the epaperdisplay code
on deinit
but I thought dinit only gets called with release_displays() ?
but if I had used the display (eg I actaull created group(s) and tile(s) and did a display refresh), then 'end fo program' does not refresh the epaper.
maybe it's some kind of a special case in there
look at the reset_displays function maybe
... reading code now
@mortal kernel CP 8.2.9 on Pico W ...started and stopped AP 5 times to get things rolling, then started it a 6th time and started a UDP server ...an ESP32-S3 station can connect and they can send and receive UDP packets to each other
Thanks for giving it a try. I'll take a closer look at the code and see if I can find anything that won't work. If the code checks out, I'll submit a pull that ignores the link down indication from the driver as a workaround.
My change caused the bundle to fail building. I will fix it asap. We may want to remove the latest release from GitHub as I think it is broken and won't let circup work
Sorry
ok, let's remove the bundle. it is today's date?
I think it is also on S3. I will remove it there.
If you have a good PR to submit to george-robotics, that will probably get attention faster. Would it be upward compatible?
This one. I'm mobile so I don't want to rush to do something
I need to update and release circuitpthon build tools for it to work to release. I'm not sure why the ci of c-b-t succeeded.
Could you try IP data packets? It looks like those might get dropped.
circup was unable to download the bundle, and complained, but my recent fixes make it proceed with an older bundle. I'll go ahead and remove it, since it's clearly not functionala
Thank you!
like TCP? ping works (or at least gets a result of 0.0 ms)
Can do. After some testing, of course.
the bundle json was never uploaded to https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bundles/adafruit/ so nothing to delete there
thanks!
Specifically, the soft spot I'm seeing is the data in the packet gets dropped by cyw43_cb_process_ethernet when the flag NETIF_FLAG_LINK_UP is off. The zero ms result could be a symptom of that.
Also, the bad flag affects ARP/IGMP/MLD/RS reports.
ok, i need to think about how to test that (don't know much about that level and need a computer I can take off the network without disrupting other things)
I'm going to need to make a similar setup here, too. I'll be using a spare RP4 with WireShark. But first, my walk!
hardware: raspberrypi RP2040 board with integrated ePaper display
situation: unable to prevent low level refresh of display whenever REPL is reached (error, CTRL-C, or end of code.py)
version: building with 8.2.x branch
I am using the build flag CIRCUITPY_TERMINALIO = 0 and the compiler definition CIRCUITPY_REPL_LOGO 0 to prevent REPL content from appearing on an ePaper display. Howerver, the display still refreshes (to a blank screen with a border) by something in the ...
@mortal kernel I can connect to the AP from a mac laptop, but oddly, I don't get an IP address like I do on the ESP32-S3, so can't do anything with it, weird that the DHCP server would work for one but not the other nope, strike that, it must have disconnected --> I get ping times from the Mac, arp -a finds the PicoW
Here's the code that I'm most concerned about:
void cyw43_cb_process_ethernet(void *cb_data, int itf, size_t len, const uint8_t *buf) {
cyw43_t *self = cb_data;
struct netif *netif = &self->netif[itf];
#if CYW43_NETUTILS
if (self->trace_flags) {
cyw43_ethernet_trace(self, netif, len, buf, NETUTILS_TRACE_NEWLINE);
}
#endif
if (netif->flags & NETIF_FLAG_LINK_UP) {
struct pbuf *p = pbuf_alloc(PBUF_RAW, len, PBUF_POOL);
if (p != NULL) {
pbuf_take(p, buf, len);
if (netif->input(p, netif) != ERR_OK) {
pbuf_free(p);
}
CYW43_STAT_INC(PACKET_IN_COUNT);
}
}
}
It looks like it will not run pbuf_take so the buffer passed in as buf will get nothing.
And no error indication.
note for posterity ...
Using board.DISPLAY.root_group.hidden = true does not prevent a board level ePaper from refreshing on REPL.
I'll try explaining again, sorry for being unclear. I was trying to offer you advice about how to fix the build errors.
I looked at the failing build. It appeared to me that this was the salient portion of the build error:
./common-hal/hashlib/Hash.h:29:10: fatal error: mbedtls/sha1.h: No such file or directory
29 | #include "mbedtls/sha1.h"
| ^~~~~~~~~~~~~~~~
I believe this occurs because the Makefile only decides to include mbedtls when ssl is enabled....
Awesome. I'm excited to see it. Soon we can get the installer scripts updated.
@crimson ferry I have a 9.0.0 alpha build that fixes the race condition in cyw43-driver. It passes your test (repeatedly starting and stopping the AP) and I was hoping you would give it a more thorough testing. I'm not sure of the best way to get you the build artifact.
I loaded this up on the LilyGo T-deck (esp32-S3) and the python REPL code seems to work fine.
My intent is for boot.py to run before workflows are started.
Nice, Thank you!
I'm thinking about a mechanism that uses a physical switch or button to enable / disable the webworkflow, kind of how the examples for mounting storage as writeable encourage users to set it up.
and writinng stuff in boot.py is easy, because you can remount the drive ro afterwards
@mortal kernel if it’s in your personal repo, I think you can just drop the UF2 here
I’m tied up for a few hours, but would be happy to test it when I’m done
Thank you! Here's the patched UF2.
I noticed that the following docstring was lacking type hints:
//| @overload
//| def open(self, /, bytesio: io.BytesIO) -> Tuple[int, int]:
//| """Use the specified object as the JPEG data source.
//|
//| The source may be a filename, a binary buffer in memory, or an opened binary stream.
//|
//| Returns the image size as the tuple ``(width, height)``."""
When I removed the /, positional-only marker, the type hints appeared.
I'll format ...
- Separate open() [set data source and read metadata] and decode() [actually fill bitmap with pixels] steps
- add support for any binary stream type. this should include socketpool sockets, allowing jpeg decode direct from net (if it doesn't, it's a problem with socketpool sockets; esp32spi sockets probably will not work)
- testing only on io.BytesIO though
- fix type checking of stream types, this was lost in a micropython merge and not hit by testing
- (any object with some pro...
@tulip sleet can I have a moment of your time to review https://github.com/adafruit/circuitpython-build-tools/pull/104 ?
sure
thank you
New feedback submitted from macOS 14.2: FB13468526. References previous feedback and this issue. Sigh.
this BMP was generated via the AIO image-formatter service
but for some reason can not set the white to transparent
opening and resaving the BMP in gimp creates this BMP
which works as expected
wondering why its not working, why the BMPs are different, etc.
test code:
import displayio
from adafruit_pyportal import PyPortal
pp = PyPortal()
odb = displayio.OnDiskBitmap("/radar_orig.bmp")
odb.pixel_shader.make_transparent(0xFFFFFF)
tg = displayio.TileGrid(odb, pixel_shader=odb.pixel_shader)
pp.splash.append(tg)
I was hesitant to do this change during the initial port, since the datasheet states that for cross-page boundaries the maximum speed is 84mhz, but as other boards with the same chip do 120mhz just fine, and it's stable capturing massive images (QSXGA) reliably for my sample, I think it's safe to increase it for this one too.
@mortal kernel UF2 tests out with the same test as earlier with successful results like 8.2.8:
• esp32-s3 can connect to PicoW AP, receive DHCP address, and exchange UDP packets
• macOS can connect to PicoW AP, receive DHCP address, ping, arp-a
I'll try a more aggressive test of station + AP and report back
Thanks a million! I've been testing here too with no failures. Looks like it might be a keeper.
@mortal kernel ran loops of every combination and sequence of start/stop_station/ap ...everything looks good 🙂
I'll submit a pull to cyw43-driver. Make that two pulls, there's a second bug I hit earlier that keeps its latest release from building in 9.0.0 alpha. Thanks again for the testing.
thanks for getting it ship-shape!
NP. I love a good bug.
did it become clear why 8590 worked on 8.2.x despite the bugs, and 8326 worked initially on main then broke?
8590 worked because it did not test the state of the link as reported by cyw43-driver and cyw43-driver doesn't check its internal state consistently so we lucked out.
The places where it does check we don't seem to hit in CP.
Did 8326 ever work for the AP restart case?
no, you're right, it was an independent fix for simultaneous station + ap, and stopping AP (once)
Good, I think we've got all the cases explained then.
Does having to wait for cyw43-driver cause you any problems?
Thanks for the detailed explanation. I know approximately zero about makefiles (and mbedtls for that matter), so I'm not too inclined to go messing with them. I had interpreted the errors as the builds being too big in some languages.
nope, I can keep using 8.2.x for restart AP, and stick with main for other alpha stuff
Submitted pulls georgerobotics/cyw43-driver#107 and georgerobotics/cyw43-driver#108 to resolve this issue and allow the latest cyw43-driver to build in CircuitPython, respectively.
@dhalbert Please tag this 3rd party. We will need to create a pull to update cyw43-driver once the above pulls are accepted.
macOS Sonoma 14.3 beta 1 - same problem. Feedback FB13469123, referenced FB13468526 FB13269327 FB13428357 FB13416096 FB13226668 FB13306896
I don't think you should prevent errors from showing on the display. It's helpful.
Is the real issue that you are getting refreshes more often than you should? It shouldn't refresh if code is reloading.
Looks good to me! What are you using it for?
Does anybody has an hint on how to flash the C6 I acquired from Adafruit in January 2023 ( https://www.adafruit.com/product/5672 ) with this https://circuitpython.org/board/espressif_esp32c6_devkitc_1_n8/ ?
First I need to figure out if I should use the UART port or the USB port (UART seems to work). Then https://adafruit.github.io/Adafruit_WebSerial_ESPTool/ complain that it does not know the chip: Error: Unknown Chip: Hex: 0x2ce0806f Number: 752910447 (it is the build in CP2102N USB to UART bridge).
Then I need to figure out if I should flash from 0x000 or from 0x1000 like with this tool: https://espressif.github.io/esptool-js/
I am a bit lost, I am not sure if it already work and what to expect from each port... REPL? Mass storage (is it supported)? Should I use BLE workflow?
I keep reading "you shouldn't prevent errors from showing on the display". It's on several similar issues.
There are several cases where the display is of little use for error messages, including very low resolution "displays" like pixel matrices, tiny OLED displays, and small very slow ePaper displays.
In my use case, the board has a small very slow ePaper display which is designed for vary infrequent use to display a static image.
Using the two build-time settings do prevent errors fro...
have you tried using a recent version of esptool.py instead of the web serial tool? I think the "Unknown Chip" error is the chip ID for the C6. The WebSerial tool probably needs to be updated to know about the C6 chip ID.
hmm, well, it appears there is a chip ID for C6 in the current WebSerial code.
The C6 has a limited USB port. I think you should try the USB port, not the UART port. But you may need to get the board into boto mode.
i found my C6 in the back of a shelf and will take a look
Thanks, I will try again... at one time I had the RGB LED flashing green, that could be Circuit Python telling me that the "Hello World" program ended successfully, but I did not find a REPL to confirm, not a mass storage.
I used the UART port, because that was the only place I could get a stable Serial... I was able to format and flash with some web tool.
I went using the boot button as I do on other ESP32.
I am able to get it talking on either port. However, the board I have seems to be a dev sample. I bought it in Jan 2023:
$ esptool.py -p /dev/ttyACM0 chip_id
esptool.py v4.6.2
Serial port /dev/ttyACM0
Connecting...
Detecting chip type... ESP32-C6
Chip is ESP32-C6 (QFN40) (revision v0.0)
Features: WiFi 6, BT 5, IEEE802.15.4
Crystal is 40MHz
MAC: 60:55:f9:00:00:f6:98:a4
BASE MAC: 60:55:f9:f6:98:a4
MAC_EXT: 00:00
Uploading stub...
Running stub...
Stub running...
Warning: ESP32-C6 has no Chip ID. Reading MAC instead.
MAC: 60:55:f9:00:00:f6:98:a4
BASE MAC: 60:55:f9:f6:98:a4
MAC_EXT: 00:00
Hard resetting via RTS pin...
if you use esptools.py, do you also see (revision v0.0). and Warning: ESP32-C6 has no Chip ID. Reading MAC instead.?
Same board acquired on 25 Jan 2023. 🙂
So I think the webserial tool is for a more recent version that maybe reports a proper chip id. So try uploading with esptool.py instead
Will try that, it seems that I need to boot my Linux because I did not install that on my Windows Desktop. I'll report in a few hours. 😦
you should be able to pip install esptool on Windows
assuming you have Python isntall
Here is a simple test:
import time
print("delay 10 seconds ...")
time.sleep(10.0) # allow some time for user to start serial terminal
print("start test")
time.sleep(1.0) # just a simple delay to separate the print statements
print("end test")
# end of program
The first time this code runs (after the board is powered up), the display refreshes at the end of the code execution.
If the code has a while True: loop at the end, then the board will refresh when the c...
Do you agree that, given the test example and video results, this as a "bug" and not as an "enhancement" request ?
My understanding is that you've added the display as board.DISPLAY on this board. Our assumption was that board.DISPLAY was usable for status information. It is made available continuously, across Python VM instantiations. If you removed board.DISPLAY, and treated this like any other external display, initializing it with Python code, would you see the refreshes you are reporting?
We can track down the extra refreshes by examining the code, and maybe you can too.
Maybe this should...
Yes, I have an integrated ePaper display on the board. I have explicitly compiled CircuitPython to not use it for terminal output.
That is what CIRCUITPY_TERMINALIO = 0 is meant to do - not use the display for console output.
While it is no longer getting console output, it is still being refreshed on the first REPL (or code completion).
I attempted to track down the extra refresh. I think it has to do with
epaperdisplay_epaperdisplay_reset()which changes tehroot_grouptocircuitpython_splash.
So if you just guard that with #if TERMINAL_IO, does that solve the problem? We would take a PR.
It sounds like you want board.DISPLAY to be available, but you want no writing to be done to it ever, except by the user's CircuitPython code. Is that correct?
I will give that a try.
I am already working in a fork and branch and I'm not the most talented GIT user so please understand if I fail miserably on the PR.
It sounds like you want board.DISPLAY to be available, but you want no writing to be done to it ever, except by the user's CircuitPython code. Is that correct?
yes.
Our current image compression doesn't run well due to the workflow of limiting to forked pull requests.
This proposed change modifies the image action to run once a month on the first of the month.
It will create a PR with compressed/optimized images that we can review and merge.
This is a suggested workflow from the image-action:
https://github.com/marketplace/actions/image-actions#compress-on-demand-or-on-schedule
I also submitted a report as well.
This is primarily for boards without native usb.
Some serial chips (even good ones) spam garbage characters during connection.
With this, lines are cleared before being printed at during boot.
It's not spammed everywhere, just where it makes sense to have it.
Tested on m5x, I can see it do the line clear.
CircuitPython version
Adafruit CircuitPython 8.2.7 on 2023-10-19; Adafruit Metro M4 Express with samd51j19
Code/REPL
import pulseio
import time
import board
pulses = pulseio.PulseIn(board.D2)
while (1):
print(time.monotonic())
Behavior
I have a wire connected to D2, but its not connected to anything else.
If I save this file to the board a few times (causing soft resets), or wave my hand near the wire, or just wait for a while, I ...
esptool.py v4.3
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP32-C6
Chip is ESP32-C6 (revision v0.0)
Features: WiFi 6, BT 5
Crystal is 40MHz
MAC: 60:55:f9:f6:94:d8
Uploading stub...
Running stub...
Stub running...
WARNING: Failed to communicate with the flash chip, read/write operations will fail. Try checking the chip connections or removing any other hardware connected to IOs.
Warning: ESP32-C6 has no Chip ID. Reading MAC instead.
MAC: 60:55:f9:f6:94:d8
Hard resetting via RTS pin...```
I don't have a specific use case for it right now. I like the general idea of being able to build a custom Python REPL. If you don't want to include this when nobody's planning on a specific use for it, please feel free to close it up. Someone can revive it later.
So I have CP working on my C6... my C6 is not saying EEE802.15.4 and has trouble communicating with the flash. But I can erase the flash, and push CP to it with esptool.py. I did the flashing on UART on /dev/ttyUSB0 but to get the REPL I need to use the USB port that is /dev/ttyACM0 . The thing is that I don't see the mass storage, and I did not succeed with PyLeap to get the BLE workflow working. So right now it is a bit like working on an ESP32 or with MicroPython. But I am fine and happy to have it running CP. Thank you very much. 🙂 ```$ tio /dev/ttyACM0
[tio 17:28:19] tio v1.32
[tio 17:28:19] Press ctrl-t q to quit
[tio 17:28:19] Connected
Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 9.0.0-alpha.6 on 2023-12-12; ESP32-C6-DevKitC-1-N8 with ESP32C6```
you cannot see the mass storage: the USB port is only serial -- it is a limited hardware implementation. This is not a great board for general CPy dev. It is like the ESP32 or C3
I don't see the flash chip problem on mine. That is strange
it may simply be defective. Did you buy it from us?
That explain a lot, that and plugging on the USB where there is no REPL. I got it from Adafruit, but never touched it because I did not read the warning saying: Please note: There is minimal support for this dev board. For example, as of the time of this writing, there is no Arduino or CircuitPython support - only ESP IDF! Please purchase if you're doing development with the C6, and OK with stuff not working 100% out of the box.
It is only a few days ago that I saw the board on circuitpython.org/download and I said to myself: "Hey, don't you have that in a box taking dust?" 😉
Actually, the product page could be updated since CP support is coming...
there have been revisions to this dev board since we started selling it, but I don't know if we are still selling the original stock
Also https://espressif.github.io/esptool-js/ is working with it, but not the version by Melissa on https://adafruit.github.io/Adafruit_WebSerial_ESPTool/ so maybe just matter of whitelisting something. But since there is esptool.py, that's fine.
(my real crazy dreams also require an async input() or something)
your esptool is v4.3, update via pip and see if it does better about seeing the flash chip
I checked stock and it is still the original version
I currently use a python REPL on the LilyGo T-Deck and it's apparently been used by a few folks based on the github activity. It's useful when using the device as a standalone CP device.
As Jeff has shown above, this PR makes upgrading that REPL to support multiple line statments (For, If, etc) relatively easy, although I had already started thinking about what was needed without this addition. There has also been mentions of possibly support...
Sorry, I had to fight with pip and esptool.py (remove it and re-install it). So now my C6 is in perfect condition and as good as yours. I just need to work around the chip limitation and find a use for it. At least I will be able to test CP release from time to time and report issues. : $ esptool.py -p /dev/ttyACM0 chip_id esptool.py v4.7.0 Serial port /dev/ttyACM0 Connecting... Detecting chip type... ESP32-C6 Chip is ESP32-C6 (QFN40) (revision v0.0) Features: WiFi 6, BT 5, IEEE802.15.4 Crystal is 40MHz MAC: 60:55:f9:00:00:f6:94:d8 BASE MAC: 60:55:f9:f6:94:d8 MAC_EXT: 00:00 Uploading stub... Running stub... Stub running... Warning: ESP32-C6 has no Chip ID. Reading MAC instead. MAC: 60:55:f9:00:00:f6:94:d8 BASE MAC: 60:55:f9:f6:94:d8 MAC_EXT: 00:00 Hard resetting via RTS pin...
excellent
This implements what I wanted on #8693.
I tried to implement a bool getter for getenv, but it was ugly and broken.
So for now it reads an int and makes it a bool.
PR in draft, stuff checklist:
- [X] USB_MSC,
CIRCUITPY_USB_MSC_DEFAULT - [ ] USB_HID,
CIRCUITPY_USB_HID_DEFAULT - [ ] USB_MIDI,
CIRCUITPY_USB_MIDI_DEFAULT
@thorny jay BLE workflow isn't on ESP chips yet. Web workflow should work on c6 though. Only the h2 doesn't have wifi.
How about doing this for the serial connection only? Its here: https://github.com/adafruit/circuitpython/blob/main/supervisor/shared/serial.c#L148
If you think it should be done for everything, then please factor out the sent string into a variable so it is only in the file once.
Thanks!
I don't have a specific use case for it right now. I like the general idea of being able to build a custom Python REPL. If you don't want to include this when nobody's planning on a specific use for it, please feel free to close it up. Someone can revive it later.
I'm fine for it to be merged in. I was just curious. Merging will prevent it from getting stale.
Thanks, I have the web workflow working.
Maybe we need a workflow matrix (and a way to maintain that):
- Serial (no mass storage)
- Keyboard (USB Host)
- CIRCUITPY (traditional)
- Web workflow
- BLE workflow
Do you agree that, given the test example and video results, this as a "bug" and not as an "enhancement" request ?
I don't think you should diverge from standard CircuitPython behavior of showing status on epaper after code finishes. Even if it finishes cleanly, it is important to know that user code is no longer running. It will also include the status bar. We've done this since the MagTag release in November 2020 and no one has complained about it.
The refresh is coming from here: h...
When I add the traditional while True: loop to the end and the user performs CTRL-C to get to REPL, there is no reason for the display to refresh but it does.
ePaper "displays" are very different from other displays. They are used for persistent information. Having they cleared outside the users code is the issue I am attempting to address..
For it to work (on m5x at least) the line-clear has to be sent after the user has opened the serial terminal.
I don't know why.
So we can't just do it once during serial init.
I made it a variable.
Usually you want code for the MagTag to go to sleep once the display content has been rendered. You then wake up on a time alarm, a button press (or even orientation change). So the code never reach at the end the REPL) because at wake-up it restart (with the option to save state information between runs).
The only time it reach the REPL would be if you don't catch exception and there is a problem (mostly network issue like WIFI being out of reach or the internet API not responding).
This i...
When I add the traditional
while True:loop to the end and the user performsCTRL-Cto get to REPL, there is no reason for the display to refresh but it does.
It is helpful to know user code is finished. Generally it should keep running. ctrl-c into the repl is a corner case. Autoreload will already skip the refresh to run a new version of code.py. We could skip the refresh if code ended from a keyboard interrupt too. That's a much smaller change than what you are attempting.
eP...
Let's bubble back up a few levels ...
As a board developer, if I have set CIRCUITPY_TERMINALIO = 0 and #define CIRCUITPY_REPL_LOGO 0 then I would expect no terminal activity to affect the display.
That is not currently the case.
The code @tannewt pointed to bases its decision to refresh off of epaper_display.core.current_group != &circuitpython_splash. Since this has not been explicitly set, then something has implicitly set it.
Consistency is incredibly valuable.
I don't disagree.
However, if there are established preprocessor and build flags to prevent the display from being used by the core, and I used those build options, then I do not understand why something is refreshing the display.
However, if there are established preprocessor and build flags to prevent the display from being used by the core, and I used those build options, then I do not understand why something is refreshing the display.
I don't think boards should set these both so I'd consider it unsupported.
The reason for setting them both is because setting just CIRCUITPY_TERMINALIO = 0 resulted in a clipped version of the python logo displaying.
There does seems to be a forward looking precedent for board developers to indicate a display should not be used for core output.
This is being considered as part of #8675 and the creation of supervisor.runtime.display.
This sounds good, as long as I can still set supervisor.runtime.display in board init code to the display that got initialized there.
I wonder, though if we don't want to make release_displays() do supervisor.runtime.display.deinit() for compatibility reasons, possibly with a warning?
CircuitPython version
Adafruit CircuitPython 8.2.9 on 2023-12-06; FeatherS3 with ESP32S3
Code/REPL
import json
import time
datastr = json.dumps([111, 222, 333, 444, 555] * 10)
# somehow slower than loads_plus_dumps
def loads_alone(datastr):
return json.loads(datastr)
# somehow faster than loads_alone
def loads_plus_dumps(datastr):
json.dumps(None) # adding this line boosts performance!?
return json.loads(datastr)
# test ...
why is this an error on rp2040 boards? all those pins have internal pull-ups. surely this error is unnecessary. if the pin isn't high, just enable the pull-up.
The internal pull-ups are way too weak for I2C.
What is the downside to freezing modules in the CircuitPython firmware?
Takes firmware space. Frozen modules can become obsolete and have to be overridden, so users have to understand sys.path.
Thanks @tulip sleet. I am assuming the modules are up-to-date as the CircuitPython version itself - e.g. if someone has CircuitPython 8.2.9 then the frozen modules are current as of that release.
Of course, users may not be quick to update to the latest CircuitPython version. And modules can receive bug fixes more often than CircuitPython releases.
Also, I really appreciate the contributors. They are quick to help with answers 👍🏼👍🏼
No, we don't update the frozen modules on stable releases every time. Sometimes there are major changes, and we don't have the mechanisms for thoroughly testing the frozen modules. 8.2.9 has not had its frozen modules updated in a while. Generally for a stable release, we will update modules that we know have a bug that needs fixing.
We update more often on the alpha/beta releases.
Oh. Good detail to know. I was not aware.
it's based on support experience, and a few things that went wrong. We are not hesitant to make new releases: it's not a lot of work to make a new releases, and there are plenty of integers. But we don't want to make a stable release that is a regression.
Really appreciate the insights
yw!
How does circuit python handle memory. Are object placed one after another or is there blocks that small objects go in
like blocks of memory for smaller objects
one after the other, with long-lived objects placed at the other end
Ok thanks
there really isn't enough memory to do many of the smart tricks that big python does
what is the pallette object in displayio. Is it just a set of colors. If it is then could I just make one and use that on a whole bunch of OnDiskBitmaps. All my bitmaps are 256 colors
Exactly. For example if pallette color 1 is 0xff2255. If that mapping holds for all bitmaps you can share
Ok thank you. I need this because I have memory issues and ~6 bitmaps all having 4096 byte (256 colors * sizeof(_displayio_color_t)) pallettes does not help
I tried to make the palette get allocated once and reused. I didn't get a error and my memory errors were fixed (so far) but the colors are sometimes messed up a bit. All the bitmaps are 256 indexed colors. What I did is in OnDiskBitmap.c I defined a pointer that then when creating the palette I check if the palette is NULL and if it is then I would allocate space for the palette and construct the object. I will upload my modified OnDiskBitmap.c file and a image
the logos are supposed to be this
here is my code
You may want to move this to #help-with-circuitpython as this isn't a dev issue. LEDs act different than screens so you'll usually need to process the images to look more correct. Here's one article about doing that: https://learn.adafruit.com/image-correction-for-rgb-led-matrices?view=all Also Liz has some specifc tips for team logos here: https://learn.adafruit.com/led-matrix-sports-scoreboard/prep-the-team-logos
I used the code in that article to generate the images. The images were fine until I modified the ondiskbitmap file
Not sure what you mean, what's the difference between "file" and "images"? But most logos are designed to work very small number of colors. When I'm making BMPs I usually try for 2, 8 or 64 colors (when converting using ImageMagick's -type palette -colors 64 options). It helps keep the palette sizes down in CircuitPython
I modified the ondiskbitmap file in circuit pythons source and that Is the cause of my errors. I used the script to download images that was provided in the article and they worked until I modified the OnDiskBitmap.c file
ah got it
maybe there is an option to not remove unused colors?
you can also convert them manually in gimp
What do you mean. I think the palette gets generated when saving the image using colors the image uses
you can tell it to use a predefined palette, at least you can in gimp
another manual thing you could do, is to put both images on one image, side by side, convert that to 256 colors, and then clip back each one to the individual image, but without touching the palette
yes, this is what I've done since I do most of my BMP processing on the commandline and couldn't figure out how to tell ImageMagick to use one palette for all the images 🙂
hmm, I'm thinking I need to install the requirements for Python3 in order to build CP in a pipenv - i'm getting errors about dependency conflicts
running on macOS Sonoma with Python 3.11.6
How can I do this?
oh yea, pipenv was definitely the path forward
woo - doing my first board make on my mac
looking forward to diving into new things
done - successful build of the grandcentral_m4_express
and, ugh, that board is at the other place 🤦♂️
guess I'm testing it out later :)
If using ImageMagick on the commandline, I do stuff like this:
# take two images, make one image of them side-by-side
montage -mode concatenate -tile x1 img1.gif img2.gif img-all.png
# take that image, compress it to BMP3 with reduced colorspace
convert img-all.png -type palette -colors 64 -compress None BMP3:imgall_for_cirpy.bmp
And then I use CircuitPython TileGrid on the combined image to select which of the images I want:
bitmap = displayio.OnDiskBitmap(open("imgall_for_cirpy.bmp", "rb"))
palette = bitmap.pixel_shader
imgall = displayio.TileGrid(bitmap, pixel_shader=palette,
width = 1, height = 1,
tile_width = 64, tile_height = 64) # assumes each image is 64x64
# ... pick an image
imgall[0] = 0 # pick first image
imgall[0] = 1 # pick second image
Opened up my draft pull request on first steps towards a unified socket handler here: https://github.com/adafruit/Adafruit_CircuitPython_Requests/pull/146
Would love any feedback if this is something I can continue to push through.
That would be a lot easier but I figured it out. I used image magick to combine the images then split them localy on my pc. Then I renamed the files to the team names with a python script that didn't do everything perfectly so
I am still having color issue but they are worse. The palettes on the images are the same
Louis Beaudoin has it worked out in the SmartMatrix library. Maybe you could steal his code.
This works for me 64x64 panel, SmartMatrix, Teensy 3.6
void setBrightness(uint8_t brightness);
@atomic summit (or @ anyone who might know) I'm building a KMK split keyboard with a couple of FeatherS3s and only now just found that BLE isn't fully working, with ESP-32 S3 apparently? Is it clear what does and doesn't work and what sort of effort is still needed to get it done?
a keyboard won't work
And are there workarounds of any sort?
you can use zmk or qmk instead
though I'm not sure they have the support for s3
generally esp32 boards are very power hungry, so not many people want to use them for keyboards
On ZMK, there should be support in Zephyr, but not directly in ZMK. I don't think there is in QMK.
I understand the power hungry aspect, sure.
most people fall back to nrf52
let me find the issue for you
thanks
Ah, well, looks like espressif fixed dynamic services on their end so it may be coming to CP.
what works right now is advertising
yes, but it's not planned right now by Adafruit, so unless someone else works on it, it may take a while
there are always too many things to work on
Ah well, rats. I know, they're spread thin.
I have a keyboard that waits for ble support myself: https://hackaday.io/project/184163-vegemite-sandwich-keyboard
Oh, yes, I saw that just the other day! Cool kit!
works as wired so far
That's probably what I'll do.
I suppose I could make it work with espnow and a dongle
I'll build it, get it working in KMK with all the other bits, then when BLE arrives on S3 (and is better implemented in KMK), hook up the batteries.
So the dongle woudl be a USB device on the computer and the halves would chat to it via espnow?
yeah
Not a bad idea... So espnow could just relay the hid reports? But for the halves to stay synched they'd need to talk to each other, too. Could have KMK on all three devices and a espnow transport.
Or keep the halves connected and just send reports.
Spent part of my morning rewiring the TFT featherwing to have backlight pwm capability. The only place I've seen this documented is in the adafruit forums.
Started my circuit python journey with an NRF52840 board which the LITE mod was designed to work for. I've seen no documentation about requiring to change that pin location to work with an ESP32-S2 or S3.
Unsure if anyone wants to document this with the TFT Featherwing V1 or V2
There are power draw implications for screen dimming that I feel like should be documented for those attempting to put the power hungry TFT to sleep until touched.
just had this occur again with alpha.6