#circuitpython-dev
onyx hinge
unsigned i; return (i>=0) doesn't trigger any kind of warning? Oh, it needs -Wtype-limits, enabled by -Wextra, which we don't.
-Werror=type-limits]
244 | if (*sm_out >= 0) {
| ^~
```would have caught it. and there are more interesting diagnostics that stem from adding this flag.
mortal kernel
@onyx hinge You've ninja'ed me in the best way possible. Thank you for #10188!
onyx hinge
It didn't cross my mind to check whether you'd started on it.
mortal kernel
Absolutely no problem at all.
lone axle
It seems that the lists at https://circuitpython.org/contributing did not get generated or included in the page properly, all of them are blank. I don't see any failed actions runs that jump out as responsible though.
jaunty juniper
I ran a debug build to try to catch the safe mode that will happen sometimes when running a httpserver, but instead it was freezing with this:
jaunty juniper
that's not much though š¤· maybe because it's "corrupted"
0x420152e9: range_subscr at ports/espressif/../../py/objrange.c:182
(inlined by) range_subscr at ports/espressif/../../py/objrange.c:162
tulip sleet
no, unfortunately. maybe the use of range() could found. It may be being passed a bad object
onyx hinge
while entering a weird bug in the micropython issue tracker, I notice their bug form makes you answer "Code of Conduct" with "Yes, I agree". https://github.com/micropython/micropython/issues/17016
manic glacierBOT
mortal kernel
How do I go about correcting a pinout pdf?
manic glacierBOT
lone axle
How do I go about correcting a pinout pdf?
Where is the one in need of correction? for the "pretty pins" document there is typically an SVG source file
mortal kernel
@danh I'm having some difficulties getting a serial console on the debug uart pins of a Metro ESP32-S3. I've soldered headers to DEBUG_RX/TX, connected them to a Pico running debugprobe (just to get the serial port), built with a modified mpconfigboard.h with these lines added:
#define CIRCUITPY_CONSOLE_UART_RX &pin_GPIO44
#define CIRCUITPY_CONSOLE_UART_TX &pin_GPIO43
put the whole thing together with an Adafruit plastic mounting plate #275, and nothing out on uart ā¹ļø
mortal kernel
Where is the one in need of correction? for the "pretty pins" document there is ...
It's for the ESP32-S3 Feather, the GPIO pin numbers are incorrect. I've found the PDF, but can't locate the SVG.
lone axle
It's for the ESP32-S3 Feather, the GPIO pin numbers are incorrect. I've found th...
The two places that I know of to look for them are: The PCB repo i.e. https://github.com/adafruit/Adafruit-Feather-ESP32-S3-PCB/ and the "resources" page on the learn guide, which is typically hidden for most users, I'm not sure if you have access to it. There doesn't appear to be an SVG in either place for the Feather S3 though. I'll ask around a bit further to see if it's around anywhere.
@mortal kernel which GPIO pin number is incorrect? If we can't get the SVG source file, I'm imagining the next best option at this point is to modify the biggest raster image and then use that as the new one.
Also is this the pinout that you are meaning?
tulip sleet
@danh I'm having some difficulties getting a serial console on the debug uart pi...
Are you trying to get ESP_LOGI() printouts, etc.? They should be directed to the Metro Debug header automatically. I haven't had to define the pins to get that to happen.
from the schematic:
I usually use a USB-serial adapter on this, and just connect the TX pin (don't forget ground too)
happens with DEBUG=1 builds
mortal kernel
<@849815081251766292> which GPIO pin number is incorrect? If we can't get the SV...
Let me double-check them all and I'll get back to you.
tulip sleet
the TX pin is the one closer to the center of the board
mortal kernel
from the schematic:
Ah ha! I got the pins reversed. It's my morning for pin confusion. š
tulip sleet
the pin assignment should happen automatically via CONFIG_CONSOLE_UART_DEFAULT et al in sdkconfig when a debug build is enabled
i'm doing a debug metro s3 build to check the settings...
mortal kernel
I've got both my console and IDF debug output with the mpconfigboard.h changes. Very useful to have both. And right there is the answer to #10004, double memory release.
tulip sleet
Ah ha! I got the pins reversed. It's my morning for pin confusion. š
I write TX and RX on the metal case of the module š
mortal kernel
BTW, those mounting plates you suggested are THE BOMB.
tulip sleet
yes, very convenient for wiring, since the arduino-shaped boards are not breadboardable
mortal kernel
A Pico with debugprobe installed makes a fine serial adapter, too.
tulip sleet
that i didn't know. I got https://www.adafruit.com/product/70 long ago
lots of variations on that
slender iron
@tulip sleet need anything from me?
tulip sleet
I thought we'd finish the bug triage on the 9.x.x milestone, but doesn't have to be today. I have been doing a little of that myself.
manic glacierBOT
Does the Waveshare S3 Geek share the SPI bus between the display and SD card?
It looks like two separate SPI busses...
lone axle
https://circuitpython.org/contributing contains blank reports again today.
lone axle
I think it might be an action on the circuitpython-org repo that updates the live page at circuitpython.org/contributing, but I do think it uses the adabot tool to generate it.
mortal kernel
@onyx hinge Maybe the changes I made to PSRAM init in my timing tests will get it working overclocked to 264 MHz.
tulip sleet
I think it might be an action on the circuitpython-org repo that updates the liv...
yeah, not sure which
onyx hinge
<@426200547024961539> Maybe the changes I made to PSRAM init in my timing tests ...
do you have a link for that?
mortal kernel
(I was running 240 MHz, but 264 MHz would still be in range without having to adjust the PSRAM timings again)
Line 100-128 set the burst wrapping and 155-162 adjust the timing. Otherwise, it's Scott's original code.
mortal kernel
@onyx hinge The critical setting is MIN_DESELECT. It needs to work out to be > 50ns to allow time for PSRAM refresh between block bursts.
onyx hinge
#ifndef RP2350_PSRAM_MIN_DESELECT_FS
#define RP2350_PSRAM_MIN_DESELECT_FS (50000000)
#endif
```I think it's trying to obey that requirement in the code I have
edgy flax
lost my dev environment, and all my notes....so rebuilding on a new box with the goal of getting back to contributing. Are the guides still up to date as far as pylint, black, pre-commit? I'll be using pycharm community so are there any gotcha's to consider in rebuilding? I hear we moved from black to ruff? Thanks in advance - and I'm open to any devs that have helpful suggestions regarding their own dev environments......
onyx hinge
@edgy flax https://learn.adafruit.com/building-circuitpython is where I would start, though the instructions tend to become out of date so don't hesitate to ask further questions or drop feedback on the guide pages.
manic glacierBOT
lone axle
I seem to recall there being something about some kind of extra "plumping" needed in the core for classes to be extendable and get all of the functionality of the parent. I've found this case where I am seeing that a subclass seems to have access to a function but gets the wrong / different result of the base class calling the same function with all other things being equal:
from displayio import TileGrid, Bitmap, Palette
palette = Palette(1)
palette[0] = 0x0
bmp = Bitmap(100, 100, 1)
tg = TileGrid(bitmap=bmp, pixel_shader=palette, tile_width=100, tile_height=100)
print(tg.contains((50, 50, 0)))
class SpecialTileGrid(TileGrid):
def __init__(self, **kwargs):
super().__init__(**kwargs)
special_tile_grid = SpecialTileGrid(bitmap=bmp, pixel_shader=palette, tile_width=100, tile_height=100)
print(special_tile_grid.contains((50, 50, 0)))
# outputs:
# True
# False
Does this indicate that something else needs to be hooked up for contains() to work properly or the same as it does for the base class?
manic glacierBOT
manic glacierBOT
edgy flax
<@784147837834231839> https://learn.adafruit.com/building-circuitpython is where...
thanks for that. I'm rebuilding an environment for circuitpython, not one to compile circuitpython. Sorry for not being clear.
also curiously, https://circuitpython.org/contributing/open-issues lists no open issues. that was a surprise, if it's true.....
lone axle
thanks for that. I'm rebuilding an environment for circuitpython, not one to *c...
Unfortunately there is a bug or some other issue causing those pages not to get generated properly the last few days. It's on my list to dig further into today.
tulip sleet
I seem to recall there being something about some kind of extra "plumping" neede...
Maybe you are remembering that there are routines added to that include "native" in their name in various places in, say, displayio. Look for that word.
lone axle
Oooh, that does seem like a good possibility
inside TileGrid shared bindings most properties use displayio_tilegrid_t *self = native_tilegrid(self_in); but contains() is different and doesn't use native
Yep, that was it. Thank you!
for some reason, not using native_tilegrid() was causing the values for self->tile_width and self->tile_height in core code in shared-bindings not to get proper values. Which then made the contains conditions change.
slender iron
This is ready for review @tulip sleet. Should be quick
manic glacierBOT
I had to use the hack from @rgrizzell to allow sharing of the DC pins but here is 6 displays off an ESP32-S3 Feather :grin:
manic glacierBOT
Simple CircuitPython timer:
:grin:
manic glacierBOT
manic glacierBOT
manic glacierBOT
lone axle
thanks for that. I'm rebuilding an environment for circuitpython, not one to *c...
The contributing pages on circuitpython.org are fixed now and contain their links out to Github.
austere acorn
Ohai, anyone know what is up with this error I'm getting in my local circuitpython fork ?
I am not working at all in that folder, never modified it, and there are no actual changes to be staged.
I tried discarding the changes, deleting the folder completely and rebasing, nothing works, this message keeps coming back.
jaunty juniper
Ohai, anyone know what is up with this error I'm getting in my local circuitpyth...
if go into it and git status, does it list something ?
jaunty juniper
ok that doesn't ring a bell, what's the diff ? could it be a permission issue ?
austere acorn
there are a whole bunch of changes in diff
jaunty juniper
if I git submodule update from an empty sdk directory I get f6c93ee too with no changes (I usually leave the submodule directories empty for ports I don't build for)
manic glacierBOT
manic glacierBOT
manic glacierBOT
mortal kernel
@tulip sleet While playing around with pico-mac, I built a Pico SDK board header for Adafruit Metro RP2350. Is there a preferred process for sending these upstream?
manic glacierBOT
onyx hinge
<@329766224093249548> While playing around with pico-mac, I built a Pico SDK boa...
@mortal kernel https://github.com/raspberrypi/pico-sdk/pull/2363 dan's PR is in draft mode, I don't know the deets (but hopefully it's written there)
mortal kernel
@danh I've gotten my head scrambled re: HSTX signal polarity in the pico sdk PR #2363. If you've got a FruitJam schematic handy, it's probably worth giving it look.
tulip sleet
@danh I've gotten my head scrambled re: HSTX signal polarity in the pico sdk PR ...
I checked the pins against the schematic, and also copied from the Metro, if I remember right, which itself was derived from the original HSTX Feather. And they work as currently assigned. So I think it's OK.
tulip sleet
<@329766224093249548> While playing around with pico-mac, I built a Pico SDK boa...
It's fine to submit a PR from us to upstream. Maybe first submit a PR to our fork, and then you or I can submit a PR upstream. That makes it clear it's coming from us.
mortal kernel
@danh The adafruit/pico-sdk fork is slightly out of date. It's at 2.1.0, current is 2.1.1. CP uses upstream raspberrypi/pico-sdk at 2.1.1. I'm not sure how the Adafruit fork gets used.
onyx hinge
@tulip sleet fwiw I am using your PR branch for pico-mac and haven't noticed any problems
tulip sleet
@danh The `adafruit/pico-sdk` fork is slightly out of date. It's at 2.1.0, curre...
we only use our fork when we have a required fix that's not in upstream yet. So go ahead and bring it up to date.
tulip sleet
<@329766224093249548> fwiw I am using your PR branch for pico-mac and haven't no...
do you mean the draft PR in pico-sdk?
I will leave it draft until Limor has tested completely.
onyx hinge
yes
- name: get pico-sdk
run: git clone --depth=1 -b adafruit-fruit-jam https://github.com/adafruit/pico-sdk ../pico-sdk
thanks - that makes me think it will be fine as is once we know it's really final. I was churning it too much in advance
tulip sleet
Random GitHub tidbit: when typing markdown to GitHub, you can use ctrl-E to wrap selected text in backticks. If nothing is selected, it will insert an empty pair of backticks you can type into.
jaunty juniper
I noticed that the adafruit_cst8xx library doesn't a have a release, even though it has version tags and is in the Adafruit Bundle. https://github.com/Neradoc/Adafruit_CircuitPython_CST8XX
tulip sleet
I noticed that the adafruit_cst8xx library doesn't a have a release, even though...
@lone axle see message above this is replying to
urban vigil
How does getting a PID and VID for custom RP2040 boards work? Since it uses CDC, wouldn't that come under RPI's 0x2E8A:0x000A address? I got everything working for my custom board and this is the last thing I need to PR it in!
Edit: the form has been filled and we are just waiting for a reply, but until then, what do we do?
lone axle
I noticed that the adafruit_cst8xx library doesn't a have a release, even though...
I see releases listed here https://github.com/adafruit/Adafruit_CircuitPython_CST8XX/releases they seem to look normal to me. Was there some issue installing it from the bundle or circup or anything?
jaunty juniper
I see releases listed here https://github.com/adafruit/Adafruit_CircuitPython_CS...
oh I must have been looking at my fork at 3 AM when I should have been in bed š¤¦
sorry for the ping
lone axle
No worries
ornate breach
How does getting a PID and VID for custom RP2040 boards work? Since it uses CDC,...
If itās open source
If it isnāt open source, you can purchase a vendor ID from USB IF for like $5k
That renews annually
urban vigil
It will be open source in the future but not now, and we don't intend on mass manufacturing or selling it so 5k/yr is nonsensical
ornate breach
When itās open source, you can request a VID/PID from the above. You can often test locally with a dummy VID/PID
urban vigil
Is there an issue with using the 0x2e8a:0x000a address for the rp2040 cdc devices?
stuck elbow
Is there an issue with using the 0x2e8a:0x000a address for the rp2040 cdc device...
no, as long as you have the permission from the Raspberry Pi Foundation to use their VID
ornate breach
They do give out a limited number of PID if requested
Not sure the criteria for that
jaunty juniper
000A is like a generic "I'm using the SDK" PID ?
stuck elbow
but if it's not unique vid/pid combination, you won't get the board definition merged in the circuitpython repository
jaunty juniper
yep Circuitpython requires unique VID/PID (although they can be shared between variants sometimes for simplicity)
urban vigil
ornate breach
Lolā¦
urban vigil
We did register for a PID in the list but while that application is being processed, can we not use 0x000A for circuit python
urban vigil
Alright, thanks for the info
lone axle
It seems like there isn't a doc for todays meeting. I'm going to create and pin one.
Here is the notes document for today'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! https://docs.google.com/document/d/1ivqAyDSbfqrDEdh5DtdmgPa8ZEVbA5e5PxGpttQjnyg/edit?usp=sharing
lone axle
It might be nice if this page https://learn.adafruit.com/welcome-to-adafruit-io/circuitpython-and-adafruit-io has the settings.toml setup required for using adafruit.io.
fleet hollow
I'm currently working on removing synthio.Biquad and replacing it with synthio.BlockBiquad in 10.x. I'm considering merging the biquad_filter_state struct in with the synthio_biquad struct for simpler management (and minimal flash savings), but doing so would make sharing a single Biquad object with multiple audiosample entities have unintended consequences because they'd be sharing the same filter state. Is that acceptable or should I continue managing those two objects separately?
manic glacierBOT
random junco
The split ortho keyboard picture on the new circuitpython.org is broken - should I file an issue in GitHub or is someone internal at Adafruit already aware do you think?
blissful pollen
I'm currently working on removing `synthio.Biquad` and replacing it with `synthi...
Do we have any places where we would reference two Biquad objects at the same time? I think if we document it there wouldn't be a problem. If we can detect a duel use (no clue if that is possible) that would be nice too. Does this basically mean 1 filter to one audio sample use?
I'm not super familiar with it but can try to deep dive into it more if you need, but I'd trust your judgement on it.
fleet hollow
Do we have any places where we would reference two `Biquad` objects at the same ...
I think I might walk back on this. I could definitely see where you'd want to use a single Biquad for all of your synthio.Note objects. If the biquad_filter_state is attached to each note, there won't be any conflicts and the filter shouldn't have to recalculate for each object (I'll have to dive deeper into common_hal_synthio_biquad_tick to make sure that's the case).
lone axle
<@&356864093652516868> The weekly meeting will occur here on discord at the usual time today 11am US Pacific / 2pm US Eastern. That is just under 2 hours from now. Add your notes and hug reports to the doc https://docs.google.com/document/d/1ivqAyDSbfqrDEdh5DtdmgPa8ZEVbA5e5PxGpttQjnyg/edit?usp=sharing We look forward to hearing from everyone.
lunar crown
@onyx hinge I would suggest that you add a comment to your Circuit Playground note about making a Random Number Generator, that any transistor that has been operated in base-emitter avalanche mode should not be used as a regular transistor afterwards. Operation in base-emitter avalanche causes the gain of the transistor to drop permanently, and it may no longer meet specifications. The circuit works as you describe, but the transistor in avalanche changes permanently. You can search the internet for something like "Current gain degradation induced by emitter-base avalanche breakdown in silicon transistors."
onyx hinge
@lunar crown an interesting point I was unaware of.
I'm getting a 500 error trying to edit the note otherwise I'd be sure to add this info
lunar crown
@onyx hinge š
tulip sleet
The split ortho keyboard picture on the new circuitpython.org is broken - should...
File an issue, thanks
tulip sleet
It might be nice if this page https://learn.adafruit.com/welcome-to-adafruit-io/...
I'd say let Brent know about that.
turbid radish
Please subscribe for free
mortal kernel
Have a great week, everyone! Thank you, Tim.
tulip sleet
@lone axle don't forget to convert the raw markdown to formatted text in the notes: copy a section, and then paste over it with right-click "Paste as markdown". Then you can download the formatted it as markdown. No other fixups needed
explained in the third paragraph at the top
austere acorn
Thanks for the hug report @slender iron ! š
Still plenty of work to do on the Daisy, I enabled the audiopwmio module, and playing audio crash-resets the board ...
Fun times ahead, lol
slender iron
I'm sure you'll figure it out
lone axle
@slender iron for when you get into the editor stuff: Jeff forked a library that provides a subset of Curses, and the editor itself and got them both working under CircuitPython (originally made for CPython). The first paragraph on the overview page https://learn.adafruit.com/circuitpython-text-editor-on-the-go links to the prior work. The main thing that I added to it at the time was a visible cursor. But it's done in a "cheaty" way by having a Label containing a single character put on top of the rest of the editor. TilePaletteMapper should provide an easier way to make the cursor visible without the need for that extra layered object.
slender iron
<@252717193496756235> for when you get into the editor stuff: Jeff forked a libr...
I'll definitely check in with you before I do any of this stuff. I also want to come up with a way to bundle multiple programs into one zip
so we can have a games collection
and an editor
and switcher
I've been really tempted to add support for the TPM to the default terminal
tulip sleet
@slender iron Thinking we might make a 10.0.0-alpha.1 very soon, so we can get 10.0.0-something into circuitpython.org and then figure out the bootloader stuff, etc. I can merge from 9.2.x once more before I do that.
Not sure I would even announce this yet, but we could use a visible placeholder besides the alpha.0 tag
manic glacierBOT
slender iron
ok, I think it's fine to do this transition during the alpha phase
tulip sleet
we can switch to beta once we settle down the partition scheme for all boards. Could do ESP-IDF v5.4 in alpha too.
jaunty juniper
speaking of partitions and 5.4, BLE is still broken on C3 right ?
tulip sleet
in 5.3.2 yes
lone axle
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/1YPAPoECwKzqUCmavSv04hAZjQAgRlVLxPIYjfHTctbE/edit?usp=sharing
tulip sleet
<@329766224093249548> were you mounting the SD card from a code.py in your testi...
I donāt remember, but I think not. Was I supposed to? Out on a walk. Iāll get back to you.
slender iron
I suspect the pyportal library was doing it for you
np, i'm around for two more hours
tulip sleet
Yeah, maybe so. I was using the NASA image program.
tulip sleet
np, i'm around for two more hours
If I don't run any program at all, then I see the second drive show up in /var/log/syslog as /dev/sdc, but nothing is mounted, which makes sense because it wasn't mounted manually, right?
tulip sleet
@slender iron this hangs after the second or third print(), with the pyportal artifact from the PR:
import board
import busio
import sdcardio
import storage
import time
spi = board.SPI()
cs = board.SD_CS
sdcard = sdcardio.SDCard(spi, cs)
vfs = storage.VfsFat(sdcard)
storage.mount(vfs, "/sd")
while True:
print(time.time())
time.sleep(1)
and eventually disconnects
the output on the display is essentially the same
slender iron
@tulip sleet I'm not going to make it work on pyportal
tulip sleet
well, this is so simple it should work on the pyportal too.
slender iron
I tried with a sd card that works on rp2 and it doesn't on pyportal
I'm doing this for rp2 first and foremost
we can always expand it later
slender iron
pyportal shares the clock line with the ESP32 and I'm worried that it can mess up the SD card
slender iron
updating it now
tulip sleet
@slender iron on fruit jam will the SD card be shared with the C6 or anything else?
tulip sleet
@slender iron ok! works on Win 11 and on macOS 15.3.2 on an M1 Mac Mini.
If I wanted to have the sd card be r/w to the host computer, could I remount it? It is readonly now.
tulip sleet
`storage.remount("/sd", False)` iirc
the second arg is readonly=True. It works when put in boot.py. Doesn't work from the REPL (not surprising since it doesn't redo the USB enumeration), though it doesn't give an error in the REPL.
slender iron
I'd expect it to work from the repl if the drive is ejected from the host
I can look at that more tomorrow. seems like it should raise an exception if it thinks it won't work
orchid basinBOT
slender iron
@lone axle have time today to talk about fruit jam?
lone axle
<@382939733107408897> have time today to talk about fruit jam?
Yes, I am eating lunch in a moment and then need to check into one thing afterward. But can any time the rest of the day after that. Starting maybe 1hr or so from now
slender iron
that'll be lunch for me. maybe 2 hours from now?
lone axle
Yep, that works.
orchid basinBOT
slender iron
@lone axle I'm around whenever you are free
manic glacierBOT
lone axle
<@382939733107408897> I'm around whenever you are free
I am good to go any time.
tulip sleet
https://blog.adafruit.com/2025/04/01/circuitpython-9-2-7-released/
Highlights: bug fixes.
slender iron
@tulip sleet did you push 10.0.0-alpha.0 to the adafruit repo?
tulip sleet
<@329766224093249548> did you push 10.0.0-alpha.0 to the adafruit repo?
yes, it is the commit after the 9.2.x branch
I will make a 10.0.0-alpha.1 after a couple more PR's on main
slender iron
we may actually need 10 tags after every 9.2.x branch merge
tulip sleet
slender iron
I'm not seeing 10.0.0-alpha.0 in my tags after make fetch-tags
ah, I do see it
with rg
tulip sleet
10 doesn't alphabetize as nicely š
slender iron
I think our version computation is filtering it out too
I think I'll add --first-parent too
that way only tags on the main branch will be considered
slender iron
This is on the merge commit that merged in the one that alpha.0 is on
--first-parent ignores it
(and will ignore 9.2.7)
slender iron
@lone axle The animation is definitely slower with group scale=2
I think it'd be ok if we center it and scale=1 though
lone axle
Heh, whoops š
@slender iron in addition to not looping, it might be nice to ultimately let the user break out with a key press.
slender iron
<@252717193496756235> in addition to not looping, it might be nice to ultimately...
ya, makes sense
slender iron
@lone axle can you send me sized group when you have a chance?
slender iron
thanks!
lone axle
it (and/or GridLayout) may get wonky when used with scales other than 1, I don't think I've tested much.
@slender iron here is all of the icons as well. You may have made placeholders already, if not these may help
mortal kernel
@tulip sleet @slender iron For Espressif debugging, I'm looking for tips re: setting up and using coredump to uart.
jaunty juniper
should we start the CP10 bundle ? (in the bundle releases and circup)
tulip sleet
<@329766224093249548> <@252717193496756235> For Espressif debugging, I'm lookin...
I've never done this!
mortal kernel
@tulip sleet It doesn't work. After a few hours I've gotten JTAG to work. What a journey.
mortal kernel
JTAG requires blowing a fuse on the ESP32-S3, pulling GPIO3 to ground on power-up, connecting a J-Link, starting the Espressif OpenOCD and GDB in the ESP virtual environment, and building CP with DEBUG=1 and ENABLE_JTAG=1. After that, everything needs to be powered up in just the right sequence. Whew.
tulip sleet
JTAG requires blowing a fuse on the ESP32-S3, pulling GPIO3 to ground on power-...
I did get SWD to mostly work -- no fuses. Are some pins now stuck as only JTAG?
mortal kernel
No, but the ENABLE_JTAG stops CP from resetting the JTAG pins.
The fuse I blew was EFUSE_STRAP_JTAG_SEL. It lets you choose the interface (SWD over USB or JTAG) by strapping GPIO3 at power-up. Once the board is up, GPIO3 is available as usual.
I'm writing up a gist so I don't lose the recipe.
So far, it's stable. I'm going to call it a day and hopefully I'll have a crash I can poke at in the morning.
tulip sleet
You could copy it to https://adafruit-playground.com/ to make it more visible.
We could put it in a Guide later.
tulip sleet
thanks!
zinc walrus
@jaunty juniper, I noticed that you forked adafruit_fancyled recently and, assuming that was in preparation of adding hsv2rgb_rainbow() to it, might I suggest also making that function capable of handling normalized floats as well.
Your [recent port](#help-with-circuitpython message) of that function was extremely convenient for me when converting some existing code to CircuitPython, but its 8-bit resolution is admittedly somewhat limiting. In my opinion, hsv2rgb_rainbow() would be far more capable if its input could also accept (0.0-1.0) floats similar to rainbowio.colorwheel() and fancyled.CHSV().
I don't want to look a gift horse in the mouth, and I greatly appreciate the time you took to port the existing function, but while it's on your brain's front burner, please consider improving it slightly to meet the fantastic capabilities of other CircuitPython libraries.
manic glacierBOT
lone axle
Could we add the CPSAVES drive to Metro RP2350 to make it more closely mimic the Fruit Jam?
tulip sleet
@slender iron I made draft release notes for 10.0.0-alpha.1. Anything you want to include in that, that's not merged yet, like https://github.com/adafruit/circuitpython/pull/10214 (CIRCUITPY_DISPLAY_LIMIT)?
jaunty juniper
<@199811382793863168>, I noticed that you forked `adafruit_fancyled` recently an...
I opened an issue in the repo to discuss how to integrate it into the library. I'll also probably upload my scripts as a standalone library later today, we can surely make a version that works like colorwheel
mortal kernel
@tulip sleet Is 9.2.x closed out? If so, I'll re-base my pending work to main.
tulip sleet
<@329766224093249548> Is `9.2.x` closed out? If so, I'll re-base my pending work...
We would fix important bugs on 9.2.x but not add new features. I think HTTP server bugs can be fixed in 10. We can point people to 10 alphas and betas if they encounter bugs we have fixed.
mortal kernel
I'll move the BLE macro PR (the conflict is fixed) to main as well.
tulip sleet
I thought I merged that already
oh, I guess not!
yeah, go ahead and move that one. I was a little worried about churn with that.
slender iron
<@252717193496756235> I made draft release notes for 10.0.0-alpha.1. Anything y...
It'll be alpha.2 since I added another alpha.1 tag yesterday.
I think it's fine to get it out as-is
@lone axle looks like I'm missing the default icon too
lone axle
<@382939733107408897> looks like I'm missing the default icon too
whoops,
slender iron
and arrow_*.bmp
lone axle
and arrow_*.bmp
slender iron
k, looks like I have all of the assets
lone axle
I figured out that it is specifically Fruit Jam -> XR1 -> 7" HDMI display that is not supported with the 360x200 resolution. It seem that the XR1 does support it and tries to pass it along in a comprable format, but the display itself does not so it gets "unsupported format" error. If you go Fruit Jam -> 7" HDMI display directly it does negotiate a size that it supports.
lone axle
right, the xr1 supports it, but then it passes it to the display which doesn't
I think it's more a problem between the XR1 and the display. Not worth trying to fix from the Fruit Jam, just an unfortunate quirk of those devices together.
slender iron
kk, I can look after I get this OS stuff setup
gonna add serial input support to the launcher
since it isn't finding my mouse
lone axle
for the mouse you may need to change adafruit_usb_host_descriptors.find_mouse_endpoint to find_boot_mouse_endpoint
slender iron
I uncommented the find_all loop and it doesn't find anything
and no keyboard either
jaunty juniper
@lone axle would it be interesting to add a function to switch the device mode from boot to report to the usb host descriptors library ? (or is it already ?)
lone axle
<@382939733107408897> would it be interesting to add a function to switch the de...
it isn't already AFAIK, and I think it'd be great to have there. That is what is needed to get the scroll wheel data from mice right?
jaunty juniper
yep
slender iron
@tulip sleet hold off on 10.x prerelease. I think usb host may be broken
it looks like critical_section_enter_blocking isn't being inlined for me
and ending up in flash
tulip sleet
it looks like `critical_section_enter_blocking` isn't being inlined for me
Surprising this was not noticed by other pico-sdk users earlier.
slender iron
could be a compiler + settings thing
tulip sleet
@slender iron the change in adafruit/pico-sdk caused a failure in CI in the Bazel build. Copilot suggests attribute((always_inline)) instead of __force_inline.
The former is available in both gcc and clang
slender iron
__force_inline is a macro in the sdk I thought
tulip sleet
maybe you are including that macro in the includes where it's used for us, but not in the .h directly.
so it's failing on other compiles in their tests
so need another include in the .h you changed?
slender iron
ya, maybe
tulip sleet
ya, maybe
I think #include "pico/platform/compiler.h"
that is the include that actually defines __force_inline
slender iron
welp, the close endpoints thing breaks us too
slender iron
āļø @lone axle this should fix your usb
hollow gazelle
@slender iron just curious - was pico-sdk pull request found by inspection, or did it actually bite circuit pyton ?
https://github.com/adafruit/pico-sdk/commit/96b363a15598d0a17a77542ba63150b7d3fa5fd5
slender iron
it bit me on my build
because we run usb host on the core1 with the MPU set to block flash accesses
hollow gazelle
( I now scroll back and see how it hit )
hollow gazelle
because we run usb host on the core1 with the MPU set to block flash accesses
thanks, at work we use COPY_TO_RAM for everything - so it would not have hit us yet - that's an interesting bug!
slender iron
the whole firmware is in RAM?
hollow gazelle
the whole firmware is in RAM?
less than 64K at that too
slender iron
ya, that simplifies things!
lone axle
āļø <@382939733107408897> this should fix your usb
I no longer get USBError, but something seems to be broken for the 2 mouse code (https://github.com/adafruit/Adafruit_CircuitPython_USB_Host_Descriptors/blob/main/examples/usb_host_descriptors_two_boot_mice.py). both mice are recognized, one of them works perfectly, but the other one only moves in the Y axis, it's like it's X is locked, or perhaps that index of it's buffer is getting wiped or not read correctly somehow
slender iron
my mouse is doing that too
not sure why
you know, I think the native HID driver sets the mouse back to boot protocol
so maybe the non-working mouse is in non-boot mode
lone axle
I did end up getting a USBError after ctrl-c / ctrl-D a few times
lone axle
one of my mice is actually a keyboard / trackpad combo, I'll try it with two plain ones.
slender iron
is my current state
lone axle
@slender iron mouse.read() is returning 8 bytes now. and the buffer it's writing to is only 4 bytes in size so that is one issue at least.
slender iron
ya, probably a regular report
slender iron
@lone axle here is a fix for the other usberror: https://github.com/adafruit/circuitpython/pull/10220/commits/15620cb40b4058207dfa363f48e13cf25fe487a4
it'd help if we actually closed endpoints ourselves
lone axle
Building now, I'll try this one
lone axle
Is there any way for code to check if a device is going to send 4 byte reports or 8? Or is it best to just assume 8 and always check the returned value from read()?
hollow gazelle
because we run usb host on the core1 with the MPU set to block flash accesses
thank you, I see the code that disables flash now in core1_main in circuitpython/ports/raspberrypi/common-hal/usb_host/Port.c
jaunty juniper
Is there any way for code to check if a device is going to send 4 byte reports o...
I believe the size of the report is in the descriptor. I don't know how it works with the boot vs report stuff, is it a separate descriptor ? Does it change ? How do we know which is which ?
we can always assume 8 though for simplicity
lone axle
The brand new build from that PR that Scott linked maybe does some of the additional mouse setup that you figured out recently but inside the core. So a mouse that on the old (current) version returned 4 byte boot reports is now returning 8 byte reports under this bleeding edge build.
tulip sleet
is there any parsing of the incoming HID report descriptor? Or is it assuming it is a "boot" device? In that case the actual descriptor is ignored and a standardized descriptor is used. The descriptor can having anything in it. I don't know whether the USB host code in TinyUSB is doing that work.
lone axle
Or maybe it's different from the work you've done. I'm not really sure tbh. But it did return only 4 bytes before I believe and now does 8. I haven't looked closer at what all is in the bytes yet though.
lone axle
is there any parsing of the incoming HID report descriptor? Or is it assuming it...
I've been using this function to parse the descriptor https://github.com/adafruit/Adafruit_CircuitPython_USB_Host_Descriptors/blob/main/adafruit_usb_host_descriptors.py#L80
slender iron
tinyusb was setting it back to boot protocol: https://github.com/hathach/tinyusb/blob/master/src/class/hid/hid_host.c#L522 we now escape it early and so it doesn't
looks like hid defaults to "report" mode instead of boot
tulip sleet
@mortal kernel what is your new strategy for fractional tick delays? Are you counting subticks by getting the subtickvalue with get_raw_ticks(&subticks). Or are you using mp_hal_delay_us() for fractional ms?
jaunty juniper
The docs page title on latest: https://docs.circuitpython.org/en/latest/README.html is
CircuitPython ā Adafruit CircuitPython 1 documentation
and on stable (which would be 9.2.7 ?)
CircuitPython ā Adafruit CircuitPython 3 documentation
and on the 9.2.x branch it says 9.2.6
not that anybody reads page titles but still
tulip sleet
The docs page title on latest: https://docs.circuitpython.org/en/latest/README.h...
latest saying 9.2.x I think is the result of the bug that Scott fixed with https://github.com/adafruit/circuitpython/pull/10216
i will check on the stable version
mortal kernel
<@849815081251766292> what is your new strategy for fractional tick delays? Are ...
I'm using get_raw_ticks(). I've wrapped it in get_raw_subticks() for convenience.
manic glacierBOT
tulip sleet
@slender iron I didin't do an alpha yesterday because of https://github.com/adafruit/circuitpython/pull/10220#issuecomment-2775423820
slender iron
<@252717193496756235> I didin't do an alpha yesterday because of <https://github...
I'll do USB updates this morning
slender iron
@tulip sleet āļø
tulip sleet
<@329766224093249548> āļø
great! tested?
tulip sleet
i'll merge after CI finishes
mortal kernel
Great! The first one is where every time the current areas fill, gc does a full collect. Lots of small allocations, like return tuples from functions, will cause very frequent collects.
slender iron
yup
mortal kernel
The other looks more like a bug. When a large allocation is made that is bigger than area size the heuristic wants to allocate, it will cause the heuristic on the next filled area to allocate a new area that is double the sum of all areas, including very large allocations.
For example, if a framebuffer is allocated, then the next time an area is added it will eat up most or all of the tlsf heap.
mortal kernel
We run out of tlsf heap space so code that allocates outside of the VM cannot allocate. It's not causing the bug I'm working on, but I've hit it playing with framebuffer.
orchid basinBOT
slender iron
We run out of tlsf heap space so code that allocates outside of the VM cannot al...
No heap growing approach will be perfect ĀÆ_(ć)_/ĀÆ
for the timing bug, why not just round up and call it good?
tulip sleet
i've been talking about the timing stuff with Bob when you were gone. I think he's on a good track. There was a bug in the RP2 subticks calculation as well.
slender iron
i've been talking about the timing stuff with Bob when you were gone. I think he...
kk, just don't let perfect be the enemy of good
tulip sleet
not at all -- this is fixing some technical debt
slender iron
right but that debt doesn't actually break much
tulip sleet
these are not big changes. It's an improvement to time.sleep() to do sub-millisecond better and a bug fix
slender iron
they just aren't that high priority for me even though they are under 10.x
mortal kernel
@slender iron Please let me know what you'd rather I work on and I'll switch to it.
slender iron
<@252717193496756235> Please let me know what you'd rather I work on and I'll sw...
I think you are on the right track. The ESP crash needs someone in the weeds
I can video/audio chat with you about heaps if you want too. Or talk about it on deep dive
mortal kernel
I can video/audio chat with you about heaps if you want too. Or talk about it on...
Let's take it up during deep dive. I see you're busy and don't want to take up your time on something that's not too important right now.
slender iron
Sure. It's important to me that you get my brain dumps before I'm on leave though too
lone axle
@slender iron did the HSTX display change to 8bit color even for the smaller resolutions like 320x240? The other day Bitmapsaver was working for those displays when I tested, but now I seem to always get ValueError: Display must have a 16 bit colorspace raised even if I change the display to 320x240 in settings.toml.
slender iron
yes, I think so. I think you can change bit dept in settings.toml too
lone axle
fill_row() function seems to only support 16bit, which is what bitmapsaver uses. Ahh that is good to know.
slender iron
lone axle
maybe we can add support for 8bit fill_row() in FrameBufferDisplay so that screenshots can work.
slender iron
sure! should be easy
lone axle
I had a quick try it at. It was easy enough to get it to not raise the exception, but I'm not quite understanding where a color conversion needs to occur to account for it. The resulting screeshot comes out with white sections ending up as a mix of yellow and blue, which does seem like a 16bit to 8bit conversion issue where it might be truncating instead of converting to me perhaps. fill_row() ends up using fill_area() from Group and ultimately TileGrid or Vectorio objects. There is some logic inside of TileGrid fill_area() which references 8 bit color depth already, but I'm not sure entire what it's doing or if that part of the code is relavent to the color issue.
claude was happy to attempt to modify TileGrid fill_area() in a few different ways, but none that worked. I don't have my head wrapped fully around what is input_pixel and what is output_pixel in the use-case of bitmapsaver / display.fill_row() and which one needs to be converted to what colorspace in order to account for the display being in 8 bit depth. I'll move on for now, but maybe circle back and try some more later.
slender iron
claude was happy to attempt to modify TileGrid `fill_area()` in a few different ...
post your diff to a branch so I can see what I came up with
looks like it's reading the wrong bits sometimes
but looks close
lone axle
post your diff to a branch so I can see what I came up with
https://github.com/FoamyGuy/circuitpython/tree/8bit_color_screenshot the only change needed to get that far was removing the logic in fill_row() that was raising on color depths other than 16. This branch has it.
None of claude and I's attempts at changes inside of TileGrid.fill_area() ended up with improving the colors any.
Here is the logic I found in there that seems to be dealing with 8 bit depth: https://github.com/adafruit/circuitpython/blob/main/shared-module/displayio/TileGrid.c#L569
slender iron
I think you'd need to expand the row from 8 bits to 16bits before returning from fill_row
because the bitmap saver assumes it is 16bit color
jaunty juniper
hey since we have selectable sockets, is there any code using it ?
ionic elk
I've finished a simple compiling implementation of my microROS support module, but unfortunately I'm getting a hardfault on init. Going to be deep diving on why but if anyone would be willing to give my allocator code a glance and tell me if I'm doing something deeply misinformed, I'd be very greatful! https://github.com/adafruit/circuitpython/blob/f171c44c4a72716f37db736f7063e05bf3943610/ports/espressif/common-hal/rclcpy/__init__.c
microros needs an allocator object to be able to store stuff like the strings it uses for node names. I implemented what it recommended with micropython's m_ versions but evidently something has gone wrong
manic glacierBOT
manic glacierBOT
lone sandal
candid sun
<@&356864093652516868> We'll have our weekly meeting in about 90 minutes from now in this text channel and in the circuitpython voice channel. Please take the time to add your notes in advance to the document: https://docs.google.com/document/d/1YPAPoECwKzqUCmavSv04hAZjQAgRlVLxPIYjfHTctbE/edit?tab=t.0 -- I look forward to everyone's updates!
lone axle
Thanks for hosting Liz, have a great week everyone! š
slender iron
@mortal kernel are you going to stay in esp32 debugging land or move to another platform?
you could also try doing the esp-idf update
mortal kernel
<@849815081251766292> are you going to stay in esp32 debugging land or move to a...
I'm keeping it alive as a background task for now, but moving on. I'm testing a PR for #9710 (RP2350 won't enter safe mode). The SRAM gets reset to garbage on a POR, so our method of saving a word for a reset press won't work. I've implemented a workaround using the BOOTSEL button. After that's done, I can take on the esp-idf update.
slender iron
ok, sounds good. let me know if you have any questions about any of it
There are other esp32 issues to debug as well if you want to do debugging
safe mode on rp2350 would be good though
mortal kernel
safe mode on rp2350 would be good though
I love debugging. Please point me to the issues you'd like me to look into.
slender iron
updating idf first is probably best though. since it could be a bug on their side
anything in 10.0.0 with an esp32* label
mortal kernel
Sounds good. I just got into safe mode on my first try of my BOOTSEL update. A bit flaky, but the whole sense the flash CS line thing works. Woot!
slender iron
on what board? most boards besides pico can do it as a normal input
I wouldn't add something special for pico
candid sun
Here is the notes document for next Mondayās CircuitPython Weekly meeting. It is at the normal time of 11am Pacific / 2pm Eastern here on Discord. Everyone is encouraged to attend! Please add your hug reports and status updates even if youāll be attending the meeting - itās super helpful! If you are unable to attend but would still like to include updates, feel free to include them in the notes and weāll read them off during the meeting. Hope to see you there! <@&356864093652516868>
https://docs.google.com/document/d/1q0T9l-qybjcu0ID3zVOcn2vIgiXJgV_teC48ew8GNrI/edit?tab=t.0
slender iron
mortal kernel
on what board? most boards besides pico can do it as a normal input
I'm looking at the schematic for the Feather RP2350, like the Pico boards, the BOOTSEL button connects only to QSPI_CS.
slender iron
this is metro rp2350
mortal kernel
Hmmm, we've got some variation among boards.
slender iron
feather 2350
how are you reading it?
you should be able to read the usbboot pin rather than cs
jaunty juniper
I don't know if most RP2(350) boards supported by CP have the boot button on a pin, do the Waveshare and Seeed ones do it for example ? And then we still want a way to put the pico 2 in safe mode, speaking as someone who does support
mortal kernel
I don't see USBBOOT making its way to any of the RP2350 pins on the Feather.
slender iron
ah true
it seems like a bad idea to mess with cs directly
the bootrom can do it because flash isn't active yet
mortal kernel
We're early enough in the boot process (no second core started), so it should be safe. But I'm not rejecting your caution. I didn't isolate the reason that SRAM was getting garbaged. Maybe I should take another look?
slender iron
the first core is running code from flash
mortal kernel
It is, but I jump into SRAM with interrupts disabled to sense the pin.
slender iron
I'm curious what the datasheet says about ram clearing
timid igloo
heya, not to butt in, but can i ask a quick sanity-checking question? I'm doing a project with some RGBMatrix hub75 displays, on an rp2350, and i have the basic code working which is fine. But my stretch goal is to have an SD card connected via SPI, and stream many frames of 32x32 or 64x64 bitmap data off it, ideally at like 8-10fps (or more of possible but not required) ... i know that sd cards on spi are running the slowest way possible, so I'm wondering if i'm within the ballpark of a doable idea or if i need to think of an alternative
slender iron
heya, not to butt in, but can i ask a quick sanity-checking question? I'm doing ...
This is a better question for #help-with-circuitpython
timid igloo
got it, ok! , my bad!
slender iron
np this channel is for developing CP itself
mortal kernel
I went over it carefully. It doesn't say anything specifically about clearing in the hardware, but bootrom code clears it under certain circumstances. What it does say is that the POR does a complete power up on all of the power boundaries.
After just now repeating a test on the saved location a number of times, it looks like what I was taking for garbage is actually a repeating pattern. Powering SRAM up/down wouldn't do that. Maybe we're getting clobbered by the much more complex bootrom code?
slender iron
yup, that could be. though there is separate bootram too
we definitely had that problem on nrf
mortal kernel
Mysterious. Let me spend a few more cycles on it.
slender iron
looks like we'll have to use the boot button
ram is powered down by run
@jaunty juniper would safe mode from repl help people?
mortal kernel
OK, that issue and the one it links are congruent with what I'm seeing. No SRAM breadcrumbs for us. I wonder if we could use the double-tap hardware flag mentioned in #2043/#2083?
slender iron
I don't think so because the bootrom will be triggered then
mortal kernel
Yeah, you're right. I'll put it aside for now and wait to hear whether we want to pursue the BOOTSEL path.
slender iron
ya, go ahead with reading cs
I agree its best to have safe mode working
I ran into this myself last week
mortal kernel
I've used it, too. So I agree.
jaunty juniper
<@199811382793863168> would safe mode from repl help people?
well safe mode is mostly for 2 cases: when boot.py sets the drive to read only or hides it, and when there's some boot loop caused by user code or a bug. The first case can usually be handled with the REPL, but it's more practical to have safe mode. The other is quite a challenge without safe mode.
and might end with having to nuke the flash
devout jolt
Thank you @candid sun for hosting the meeting! Sorry I couldn't be there
wraith crow
@slender iron I've started playing with your pathlib branch, I know it's in early dev but when I spot things do you want me to submit PRs to your fork, post issues or just wait until it's further along?
slender iron
PRs to my branch are fine! thanks!
slender iron
@lone axle did you try buffering the audio at all?
lone axle
<@382939733107408897> did you try buffering the audio at all?
I haven't tried anything different from the code here really: https://github.com/adafruit/Fruit-Jam-OS/issues/1 (code-wise at least. I did try different audio files and display resolutions)
I don't know how to buffer the audio from a wave file. Is there example code of that somewhere?
slender iron
Looks like you can provide a buffer: https://docs.circuitpython.org/en/latest/shared-bindings/audiocore/index.html#audiocore.WaveFile
the 720x400 is definitely more taxing on the memory bus
lone axle
Looks like you can provide a buffer: <https://docs.circuitpython.org/en/latest/s...
I tried changing the wave init line to be like this: wave = WaveFile(wave_file, bytearray(1024)) and there are loud chirping and scratching sounds in the audio playback with it that way. Similar to the artifacts that were audible witht he larger .wav files. If I remove the bytearray(1024) argument and run the same code and audio file I don't hear the loud chirping and scratching. This was all with the 360x200 display size. I will try 720x400 in a moment.
lone axle
Essentially the same with 720x400, there is more loud chirping and scratching when using bytearray(1024) than without. Though at that resolution there is some scratching and chirping even without bytearra(1024) The visual artifacts of static and letters disappearing are the same in both cases at 720x400 as well.
slender iron
ya, I bet it is just pushing memory bandwidth too hard
I remember seeing code.py slow with 720x400 too
I wonder if we should make picodvi able to switch modes
the problem with starting up in a lower res is that it's unlikely you'll be able to allocate a bigger framebuffer later
for a text editor
blissful pollen
I have found when the audio doesn't get the CPU cycles required you start to hear more scratchy type behavior. Sometimes (depending what is taking those cycles) a time.sleep(0.01) is enough to help trigger RUN_BACKGROUND_TASKS to go
lone axle
I don't know. Honestly I have very little experience with audio.
lone axle
want me to play with it?
I do not have confidence that I can make it any better than the current version posted to the issue with it running at 360x200 with the reduced size wave file that is attached to the issue.
If there is a desire to improve it beyond that, or run it on the 720x400 resolution display and have the animation run without the blinking in and out and loud audio artifacts then I do not feel like I can do that, so I would need more direct help or ideas from you or someone else.
slender iron
ok, I'll do that this week
I think mark is onto something because we have to do conversions to match the output format of the i2s
blissful pollen
I don't really have time at the moment but feel free to send me something @lone axle and I can take a look at it.
You can also use audiomixer on top of the wave and it allows larger buffers if that helps.
lone axle
I don't really have time at the moment but feel free to send me something <@3829...
The current version is here: https://github.com/adafruit/Fruit-Jam-OS/issues/1 If you get time and have thoughts feel free to post there on the issue or pint me here on discord.
slender iron
it looks like the i2s output always does a copy too
lone axle
(running at 720x400) time.sleep(0.01) inserted into that code after display.refresh() does maybe make the audio slightly better, but still some scratches remain, and the leters are still disappearing.
slender iron
I'll look at it later this week
wanton knot
I ran into similar things recently. No amount of sleep really helped. Only thing that helped was increasing the buffer size.
My dog REALLY hates the 'scratching' sound as you described it.
lone axle
I did try overclocking using the way shown in: https://www.youtube.com/watch?v=vBAJ0AmmGn4 and it was leading to weird things printed out and then hard fault memory error.
slender iron
I'd rather get it working without overclocking
lone axle
If there is something incompatible with the overclocking technique shown in that video and the Fruit Jam or something else about newer version of circuitpython it might be good to add a warning to the description of that video or as a popout in it if possible.
slender iron
my thinking is to put gpio highs and lows around sound processing and display processing to see how they interact
I consider overclocking to be you do it at your own risk
lone axle
That isn't mentioned in the description or introduction of the video, and the video does kind of make it seem like this is supported functionality IMO.
manic glacierBOT
mortal kernel
@danh I need a small assist getting the UF2 bootloader flashed onto an oddball board, the SAM E54 Xplained Pro. This is for issue #10172. No hurry.
manic glacierBOT
The disambiguated _bleio didn't show up exactly as I expected. It looks, for example, like this in https://docs.circuitpython.org/en/latest/shared-bindings/support_matrix.html:
blissful pollen
@lone axle Took a look at the issue and code, and I suspect there is a load of disk loading from the sprite sheets and the wave file that are probably slow. I'll try to see if I can run it on a RP2350 even without a display hooked up (I don't have one).
If you want to try a larger buffer with audiomixer you could like:
mixer.voice[0].play(wave)
audio.play(mixer)
mortal kernel
I'm looking for some help getting the uf2 bootloader flashed onto a SAM E54 Xplained Pro board.
tulip sleet
@danh I need a small assist getting the UF2 bootloader flashed onto an oddball b...
That board has a second microcontroller on it that provides an "EDBG" (Embedded Debugger). The documentation could be better but it says it's usable from Atmel Studio. https://onlinedocs.microchip.com/oxy/GUID-AA358083-AEED-4BA8-8511-9F986D3390A5-en-US-2/index.htmlhttps://ww1.microchip.com/downloads/en/devicedoc/atmel-42096-microcontrollers-embedded-debugger_user-guide.pdf
You can also connect something like a J-Link via SWD: https://onlinedocs.microchip.com/oxy/GUID-AA358083-AEED-4BA8-8511-9F986D3390A5-en-US-2/GUID-561FB075-0555-4441-A9EF-9D50F20850C7.html
Atmel Studio has flash programming features. It is huge to install but oh well.
I can't remember, do you have a BlackMagic probe or a J-Link?
tulip sleet
J-Link supports JFlashLiteExe, a simple flasher, and I imagine there may be something similar for other SWD probes
mortal kernel
I have a J-Link and an Atmel programmer. I wanted to avoid Atmel Studio, but if it must be...
tulip sleet
the J-Link would be the simplest, assuming you have the cables
mortal kernel
I do.
tulip sleet
the Atmel programmer is probably also fine, and there may be standalone tools. I have only used Atmel Studio a few times, to mess with fuses.
The UF2 bootloader fixes up the fuses (setting BOOTPROT properly) if it detects they are wrong. It sets the fuses properly and then restarts itself.
JFlashLiteExe is part of the J-Link software package
mortal kernel
That's a nice feature re: fuses. So I should be able to build the binary and flash with JFlashLiteExe without having to install Atmel Studio?
tulip sleet
yes, you can build it in Linux with adafruit/uf2-samdx1 and just flash the .bin
tulip sleet
there are a couple of boards already there that might just work or you just need to tweak: generic-atsame54 and same54_xplained
manic glacierBOT
mortal kernel
@danh One quick thing before I head out the door: The SAME54-Xplained boards have switched to the SST26VF064 flash part. The new boards with that part are red while the older boards with the original flash part are blue. There may be a few blue boards with the SST26VF064 out there that were made during the chip shortage, but I'm not 100% sure about that. The key difference between the boards (aside from the new red boards not working with CP that I'm fixing) is that red boards have 8MB of flash while the older blue boards have 16MB. This info should go into doc somewhere...
