Crazy Idea of the Day: FLASH Expansion Modules

1

Flash memory on Proffieboards is often a bottleneck for styles and things. Less-so with the new v3.9, but I’ve still seen people manage to use it all up.

A very common thing for modern microcontrollers is to use QSPI to attach external flash, and increase the storage capacity by just a stupid amount relative to the amount of storage we’re used to.

I’ve just glanced over the STM32L433xx datasheet and it seems to support external QSPI flash, which means this should be possible, but that brings up a couple of questions:

How would it be wired up? I’m not sure exactly what all the pins on the PB are used for atm as far as audio, gyro, etc, but I know GPIOs are always a valuable resource, so I don’t know if there’s even pins left to do this.

I also don’t know how one would be able to connect these. I’d need to look at the datasheet and look closer at the PB hardware to get an idea…

I’m unfamiliar with how timing-sensitive these chips are, but I’d figure they need to stay fairly close with limited interference, and I’m not sure if that concept alone would hurt this idea.

I have no clue how Arduino handles this kind of stuff. I know from using the ESP-IDF w/ Arduino it was fairly limited there (moved my codebase over to custom tools just because I couldn’t handle it), so I’m not sure what has to be configured in Arduino to make it work, or if it’d be possible via changes to the plugin? Either way it seems like it would be somewhat difficult to setup from a software side.

Anyways, it seems like it would be, at least theoretically, possible to create an “expansion” chip for the Proffieboard, allowing someone who wanted it to wire up something one way or another and relatively easily quadruple their FLASH space. The ESP series of chips has about the same onboard flash as the PBs, but just the ESP boilerplate for a lot of those projects takes ~500KB on it’s own, so virtually every ESP chip (save for the super tiny ones… even then those often have it) has a QSPI chip right beside it.

Just made me think if this concept was anyway portable to Proffies…

2

Interesting idea… :slight_smile:

I think this is most likely something that will happen with a new generation of boards rather than as an add-on to existing boards. I just don’t think the right pins would be available, and even if they were, it would be hard to spare 6 pads on the board, and then there is the issue of wire length. QSPI operates at fairly high frequencies, so it may be problematic if it’s not located right next to the CPU.

The MCU market is moving in interesting ways right now though. At the same time, there is a trend towards putting flash and memory outside the main chip, and there is also a trend towards chiplets, where CPU, memory, and potentially other components are incorporated into one package. Naturally, I prefer the latter one, since it makes it easier to make really small boards.

What I would really like is a QSPI solution that support really large memory sizes, like 128Mb or more. With a solution like that, the font could also be stored in QSPI memory, and we could stop using SD cards, which would be nice. Unfortunately, I have not seen any QSPI setups that support memory sizes over 16Mb.

One potential problem with QSPI is that it is generally slower than onboard flash memory. The Teensy 4.x deals with this by having a special keyword that you can put on code that you want to be really fast. The Teensy copies this code into SRAM at boot time, and SRAM is very very fast. Not that this really matters to us, all new chips are faster than what we actually need… :slight_smile:

3

Yeah, I kinda agree with that thought process.

So, in a similar vein… because fonts are read from the SD card, and a slow SD card slows everything down, wonder if being able to get just a massive amount of RAM would be useful to be able to load at least a single font into memory… I don’t think that’s a viable option yet though with the current chip offerings… (maybe I’m wrong)

Yeah, I know the esp stuff has all kinds of fancy ways of dynamically loading highly-used functions and stuff into RAM during runtime that you can configure, and I know you can similarly mark certain things explicitly to be loaded and such… all that’s frankly beyond me though, hah.

4

Well, the milk-V duo 256M has 256Mb of RAM.
With a setup like that, we can boot from SD, load everything we need into ram and then everything will be fast. (Boot might take a few seconds though.)

5

Oh… I guess I didn’t realize it had that much RAM…

That’d make things interesting :rofl: