Non-volatile memory options to store synth patch data in teensy 4.0 ?

Status
Not open for further replies.

rvh

Well-known member
I have a midi-controller driving a teensy-4.0 based synth and would like to store patch parameters that comprise on the order of 100 bytes per patch in non-volatile memory. I would like to be able to read/write something like 100 patches, so 16kB would be plenty. I started reading about using the program flash memory, but it seems to get cleared when a new program is loaded. Please advise what my best approach would be, and if possible point me to example code.
Thanks,
Richard
 
Currently, there is no other way than to use the SD-Card, an external eeprom or extra flash chip.
The size of the emulated eeprom is 4K.
 
If you use 1.54-beta7, LittleFS supports storing files in the program memory. But it has 2 major limitations. The filesystem gets wiped when you upload a new program. But files do persist between power cycling, as long as you don't upload new code. The other issue is writing to the program memory needs to wait with interrupts disabled, so if you're running the audio library and it needs to erase a block, you'll probably glitch the audio.
 
If you use 1.54-beta7, LittleFS supports storing files in the program memory. But it has 2 major limitations. The filesystem gets wiped when you upload a new program. But files do persist between power cycling, as long as you don't upload new code. The other issue is writing to the program memory needs to wait with interrupts disabled, so if you're running the audio library and it needs to erase a block, you'll probably glitch the audio.

Hi Paul, I've been very interested in this new feature and the limitations are okay with me. Is there any examples on how to use this with the onboard flash? I couldn't find examples of the following two things but I may have missed them.

1) How do I create/populate the LittleFS so that it is included during flash programming?
2) How do access a LittleFS that is stored on the onboard flash?
 
Hi Paul, I've been very interested in this new feature and the limitations are okay with me. Is there any examples on how to use this with the onboard flash? I couldn't find examples of the following two things but I may have missed them.

1) How do I create/populate the LittleFS so that it is included during flash programming?
2) How do access a LittleFS that is stored on the onboard flash?

This 34 page thread covers LittleFS: LittleFS-port-to-Teensy-SPIFlash

Best version in Beta 7 of TD 1.54.

There is an example sketch : LFSIntegrity.ino
> It demos usage of the startup with typical functions used.

Re #1: Upload blanks the Flash - the LittleFS is created by the sketch starting
> this explains the loss of LittleFS on upload as noted
> The unused Flash over the stored program is available for use.

Re #2: using ...\hardware\teensy\avr\libraries\LittleFS\examples\LFSintegrity\LFSintegrity.ino
Set this for use of onboard FLASH
Code:
//#define TEST_RAM
//#define TEST_SPI
//#define TEST_QSPI
//#define TEST_SPI_NAND
//#define TEST_QSPI_NAND
[B]#define TEST_PROG[/B]
//#define TEST_MRAM

Find this to declare the desired size:
Code:
#elif defined(TEST_PROG)
	if (!myfs.begin(1024 * 1024 * 6)) {
> That shows creation and use of PROGRAM FLASH - integrating to your sketch is TBD with that as an example.

After Upload the 'media' will all be formatted - so writes will be fast without formatting:
> All writes typically move to FRESH space until it is used up - then abandoned space will need to be Formatted before use.
> If Teensy restarts - without upload - it will find the existing files in place on the LittleFS media.
> If multiple restarts or runtime uses up the free formatted space and writes format space used before then the interrupts will get disabled as noted.
> If desired on startup [or as desired] when all used space could be formatted in advance to prevent 'on the fly' formatting try:
>> Only the BOLD line is needed in the sketch - and format of the PROG flash is quite fast - and any existing files or data will be preserved.
Code:
	case 'f': // Reclaim all unused format
		lastTime = micros();
		Serial.printf( "\n myfs.formatUnused( 0 ) ...\n" );
		timeMe = micros();
		[B]myfs.formatUnused( 0, 0 );[/B]
		timeMe = micros() - timeMe;
		Serial.printf( "\n\t formatUnused :: Done Formatting Low Level in %lu us.\n", timeMe );
		chIn = 0;
		break;
 
Thanks all, it sounds like using the audio shield's SD is the simplest solution for now. For saving/recalling synth patches, speed is irrelevant, and losing the patches each time I change the synth code would be unacceptable.
 
I have my SD card working, but to do so had to avoid the use of pin 13 as an output to drive the led. I'm not sure why that is because according to the SD card examples I looked at in the library, pin 14 is used as the clock pin when the audio card SD is used. The three pins I've defined in my code as per the examples I borrowed from are:

SPI.setMOSI(7); // Audio shield has MOSI on pin 7
SPI.setSCK(14); // Audio shield has SCK on pin 14
const int chipSelect = 10;

Is there something defined in the library that I need to change if I want to be able to use both the Audio shield's SD and use pin 13 to drive the onboard led?
 
I have my SD card working, but to do so had to avoid the use of pin 13 as an output to drive the led. I'm not sure why that is because according to the SD card examples I looked at in the library, pin 14 is used as the clock pin when the audio card SD is used. The three pins I've defined in my code as per the examples I borrowed from are:

SPI.setMOSI(7); // Audio shield has MOSI on pin 7
SPI.setSCK(14); // Audio shield has SCK on pin 14
const int chipSelect = 10;

Is there something defined in the library that I need to change if I want to be able to use both the Audio shield's SD and use pin 13 to drive the onboard led?

These directions only work on the Teensy 3.x/LC processors. The Teensy 4.0/4.1 processors do not have alternate pins for the main SPI bus. You have to use pin 11 for MOSI, pin 12 for MISO, and pin 13 for SCLK.

In the Teensy 3.x/LC space, the alternate SPI pins were primarily used because the I2S sound support used some of the traditional SPI pins, and if you used the audio shield, you needed to use the alternate pins. For the Teensy 4.0/4.1, you need to use the revision D audio shield, which uses the normal SPI pins. Just delete the SPI.setMOSI and SPI.setSCK calls on Teensy 4.0/4.1. Note, the audio shield description page highlights the pinouts of the revision D audio shield.

If you have a revision A-C audio shield, you will need to do some re-wiring to adjust for the different pins used. I can point you to directions that were posted before the revision D audio shield came out, but it is simpler if you just get the revision D audio shield.
 
Thanks Michael. I am using Teensy 4.0 with Audio shield rev.D and it was actually working with SPI.setMOSI(7) and SPI.setSCK(14), but presumably that was just ignored by the compiler because as you suggested it works fine without those commands too. I guess I will need to connect a led to another pin.
 
Status
Not open for further replies.
Back
Top