PaulStoffregen
Well-known member
I would like to define a simple allocation table for the optional SPI Flash that can be used with the audio library. This thread is meant to discuss ideas for how this table could work.
My main goal is for the table to express at least 4 fields, for each section of the flash memory containing data:
The address and length should probably be 32 bit numbers.
Perhaps the type can be a 1 byte code? Or maybe 3 bytes corresponding to file name extensions would be more convenient?
How many bytes to allow in the filename is also a good question...
Maybe the 4096 bytes should be divided up into 16 or 32 byte sections, or quicker and easier access? Or maybe info should just be packed, requiring a linear parsing of all 4096 bytes to find anything at the end? Or maybe some format where a filename entry could span multiple sections would work?
As we develop more ways to read different types of data from the SPI flash (raw audio, mp3 encoded streams, special wavetable synthesis formats, etc), and later when GUI-based tools are developed to manage the memory, a well defined allocation table will make using the library much easier.
My main goal is for the table to express at least 4 fields, for each section of the flash memory containing data:
- Beginning address
- Length of data
- Type of data
- File name (string)
The address and length should probably be 32 bit numbers.
Perhaps the type can be a 1 byte code? Or maybe 3 bytes corresponding to file name extensions would be more convenient?
How many bytes to allow in the filename is also a good question...
Maybe the 4096 bytes should be divided up into 16 or 32 byte sections, or quicker and easier access? Or maybe info should just be packed, requiring a linear parsing of all 4096 bytes to find anything at the end? Or maybe some format where a filename entry could span multiple sections would work?
As we develop more ways to read different types of data from the SPI flash (raw audio, mp3 encoded streams, special wavetable synthesis formats, etc), and later when GUI-based tools are developed to manage the memory, a well defined allocation table will make using the library much easier.