h4yn0nnym0u5e
Well-known member
...well, that's my opinion!
TL;DR:
I'm working on a project where SPI busses are at a premium, and dedicating the LPSPI hardware for driving the multiple displays is preferable. As the SD card may be used, SPI2 is not an option. Some on-board storage is desirable, and the PM004M MRAM 4Mb part looked like an attractive option (it's very cheap at JLCPCB), if it could be supported by LittleFS; FlexIOSPI capability would be a bonus.
On the face of it adding the PM004M looked simple enough; just add a line into the supported chips list. MRAM is very much like FRAM, in principle. However:
I've only implemented FlexIOSPI use for the
During the course of this, I discovered that the current FlexIOSPI does not treat null pointers the same as SPIClass does. Specifically,
Shout out to @KurtE for the FlexIOSPI stuff, and @Paul for the LittleFS port.
TL;DR:
- LittleFS - added one MRAM type and ability to use FlexIOSPI to access FRAM/MRAM chips, if you have
- FlexIO_t4 - fixes for dealing with null buffer pointers
I'm working on a project where SPI busses are at a premium, and dedicating the LPSPI hardware for driving the multiple displays is preferable. As the SD card may be used, SPI2 is not an option. Some on-board storage is desirable, and the PM004M MRAM 4Mb part looked like an attractive option (it's very cheap at JLCPCB), if it could be supported by LittleFS; FlexIOSPI capability would be a bonus.
On the face of it adding the PM004M looked simple enough; just add a line into the supported chips list. MRAM is very much like FRAM, in principle. However:
- the chip ID readout isn't the same as anything else - it requires a dummy 24-bit address; easy enough to fix
- after a lot of head-scratching, it turns out that 4Mb is not 512kBytes x 8 - it's actually 256kWords x 16; 18 bits of the 24-bit address are used to read/write 16-bit words. It's vaguely referred to in section 4 of the datasheet ... kinda.
addrbits semantics slightly, so the bottom 3 bits are used to shift the memory address down to match the chip's expectations.I've only implemented FlexIOSPI use for the
LittleFS_SPIFram class - it could be ported to the other SPIClass-based classes, but that's probably best left to someone who has the hardware to check it's working. From the user's point of view, it's as simple as passing a FlexIOSPI& reference to begin(), along with the /CS pin number, in exactly the same way as you'd pass a SPIClass. Internally there's a bit of messing with wrappers and templates to make the code changes minimal.During the course of this, I discovered that the current FlexIOSPI does not treat null pointers the same as SPIClass does. Specifically,
transfer(buf, retbuf, count) fails quite badly if either buf or retbuf are null. Gory details are in the pull request, and are required if you want to use LittleFS_SPIFram with FlexIOSPI.Shout out to @KurtE for the FlexIOSPI stuff, and @Paul for the LittleFS port.
