Hi there;
I’m currently finishing up my updates for Pollen8+FM, and I’ve made the decision to remove the fatfs file system for saving patches to SD, and to replace it with the QSPI - as the fatfs system was taking up more flash than I had room for.
My concern with this, is that I’m sure people are already using the QSPI flash for saving other “stuff” (I believe owlsy uses this, not sure about oopsy or any other projects).
While I’m currently trying to make the impact as minimal as possible (by looking for a large contiguous 0xFF blank space to store the rudimentary file system), I just wanted to judge the kind of impact messing with the QSPI flash would have on people’s “other” projects - e.g. I wouldn’t want to be the cause of a scenario where you’ve been in the middle of working with something, and upload the new synth to try it out only to wipe out any other save data etc. Implementing an “are you sure?” function on the field / patch is admittedly a bit easier to implement vs the pod, and this synth supports all 3 modules.
Do note - I haven’t tried owlsy or oopsy or any other projects that use the qspi flash at this time, so I am not familiar with how the flash data is being used, so this might be moot anyway if it can all be re-downloaded with ease from a PC etc…
Please let me know your thoughts if you have any / have a chance!
Thank you!
Yes, the entire firmware and user patches would be stored on QSPI. Internal flash is only used for bootloader. It’s not a problem, because there’s no expectation that OWL firmware would be running along with anything else on the same hardware.
Owlsy would use first 512k of QSPI for storing firmware and remaining would be utilized as data storage (for patches and resources). So if you’d like to avoid corrupting patches/data for anyone running OWL, you could only use the first 512k. This would require reflashing firmware after your patch, but it’s not a big deal.
Alright, thanks that’s good to know…!
If I don’t write from the first byte onwards (likely < 512K for presets anyway), I was thinking on either searching through the qspi for a large blank region and put stuff a bit “beyond” there, or simply writing backwards from the end address - really the synth uses about 4K - maybe - per patch and I don’t foresee anyone storing more than 20-30 presets with it - then again you never know.
Interesting - I’ve been meaning to try to get software running from the sdram and/or the qspi… Curiously, how much of a pain was that to get to build/link, and how is the performance for firmware running on the qspi…?
Thanks!
If you’ll be releasing source for this, you could just make address configurable. Otherwise, don’t worry too much. Eventually there would be some kind of official data storage in libDaisy.
Owlsy is actually not running from QSPI, it gets copied to SRAM by bootloader. This is required because we want to write patches from firmware and we can’t do that while we execute from QSPI. So performance is not a problem - it’s as fast as it can be. Executing from QSPI would be somewhat slower, but it shouldn’t be too bad thanks to cache.
Yes, this requires a custom linker script and bootloader. Most things gets configured via linker script. Firmware is placed in several sections of memory, not just one. Info about addresses/sizes of those areas are stored in a separate structure as firmware header - also exported by linker. The bootloader reads that structure and preloads everything to correct addresses before running firmware. The pain… it hurts just to describe it! But results are pretty flexible and at least I didn’t have to customize the assembly startup script.
1 Like