I’ve downloaded and installed the circuitpython-swan_r5.uf2 file from your quickstart guide and it works fine.
There are a couple minor parameter changes I’d like to make to the CircuitPython image though and I figured I’d simply use the latest release from the Adafruit github site since they have a build directory for the Swan.
However, when I build my own image of CircuitPython the swan boot loader doesn’t seem to recognize it. Copying my image to the SWANBOOT folder doesn’t result in the board reset, and if I manually reset the board, the existing image hasn’t been flashed.
I also used the DFU-UTIL program to burn my version to the SWAN board and that did seem to load the custom image, however the CircuitPython boot loader functionality is gone (that’s not a big problem since I can always reflash it or simply use the DFU-UTIL instead) and more critically, I’m only left with about 111K of available flash space.
In searching these forums I did see that the low flash space was a problem with an earlier boot loader version. I’m guessing whatever fix was made to the boot loader that resolved that issue I broke by dropping my CircuitPython image on top of the normal bootloader.
I guess I have two questions, either one of which will allow me to get running with my application.
Is there something I can do to the Adafruit current release of CircuitPython that will allow the SWAN boot loader to recognize and flash it?
If not, can I implement the same file system fix that was implemented in the boot loader in my custom CircuitPython image to enable > 111K free flash space?
I’m assuming that if I make my parameter changes to CircuitPython source on the Blues Wireless github fork that the resulting CircuitPython image would work but I actually haven’t tested that yet but that’s my next planned move (it’s just getting too late tonight ).
If with your assistance I am able to get the Adafruit build working, I’ll be happy to submit pull requests to the Adafruit repository.
Welcome to the community @RetiredWizard, great to have you here!
At present, the Adafruit release doesn’t incorporate our latest development changes, which includes support for the UF2 bootloader, 1MB of storage for scripts and a few other goodies.
I’ll update our development PR with the latest changes from Adafruit and submit our PR before the end of the month.
But I imagine you want to get started now! Your suggestion of building from our development PR is a good way to go. Building from that image will work - I am doing this almost daily.
Please let me know how it goes and if you have any other questions.
Perhaps I muddled up the clone, after cloning your repository I issued the command “git checkout 7.1.x-larger_program_storage_swan_r5” which seemed to work fine.
but after taking care of the standard CircuitPython intermediate steps (make fetch-submodules/mpy-cross) when I issue the “make -j4 BOARD=swan_r5” command I get the following make error:
make: *** No rule to make target ‘common-hal/audiobusio/I2SOut.c’, needed by ‘build-swan_r5/genhdr/qstr.split’. Stop.
You did everything fine, but some sneaky WiP changes crept in there. I’ve cleaned everything up, and made a new PR that is based on the latest main, which I’ll submit to Adafruit for including in their next release.
I actually was able to grab the changes you had made for the larger flash space and compile them into my custom image which gets me going for now. I’m sure I’m missing a bunch of features so I’m looking forward to the updated release from Adafruit.
Just as an update, I cloned the current Adafruit CircuitPython repository, made my changes and built the swan_r5 image and it seems to be working great.
I’m curious about your use case and the changes you are making to the CircuitPython runtime. If you’re able to share, feel free to DM me - perhaps we can get them in a mainstream build.
I’m a bit embarrassed as I know you offer the Swan as part of your wireless product solutions but I was drawn to the Swan board because it uses the stm32 microcontroller and I wanted to see if my operating shell (PyDOS) would run on it.
As I’m doing something rather unconventional with Circuitpython my application exhausts the standard stack allocations so my modifications to Circuitpython consist of turning off the circuitpython “MICROPY_ENABLE_PYSTACK” parameter and turning on the “MICROPY_STACKLESS” parameter. I’m not a Circuitpython expert, but I believe these changes result in potential board crashes if you do actually exhaust memory through stack operations however with the newer microcontrollers that are coming out with 256K or more or RAM that hasn’t been a problem for me.
I suspect that my use is far outside your normal user use case and the standard stack configuration is going to be fine for most Swan users.
I really appreciate your responses to my questions and have been blown away by the quick PRs fired off to Circuitpython. Thanks!
Thank you for for sharing that. Swan is a powerful workhorse of an MCU with it’s 640K of SRAM and is a great host for our wireless solutions, but is also a great solution too for non-connected applications. We’re delighted you are finding it a good solution for your use case.
I wasn’t aware of the stack options, so thank you for illuminating that. It’s an advanced use case for sure! I’ll be keeping my eye on what we might be able to do to create a unified build, or multiple flavors with different stack options, as well as the support for AOT-compiled micropython native code for performance-critical functions.
Thanks for your kind words, always happy to help!
Warm regards,
mat
).
