Future SD access

PropBoard
#1

Hi @Ivan,
will it be available in the future the possibility to access a text file stored into the SD?
Like a configuration file, as other cards do.

The second option to write in it would be nice :grinning:

#2

We second this. Weā€™re currently tinkering with it, as mentioned to Ivan.

#3

You should be able to access SD files for reading with the current version. The core uses FatFs on top of SDIO and these functions are available from the sketches too.

Have in mind that you donā€™t need to mount the file system as it is already mounted (or will be automatically mounted at the first SD access).

For example you can do:

FIL myFile;
uint8_t buffer[256];

bool myFunc()
{
	uint32_t read;
	
	if (f_open(&myFile, "myFile.txt", FA_READ | FA_OPEN_EXISTING) != FR_OK)
		return false;
		
	if (f_read(&myFile, buffer, sizeof(buffer), &read) != FR_OK)
		return false;
		
	f_close(&myFile);

    return true;
}

Is there a compatible SD library for the PropBoard?

Probably not. Reasons why:

  • most libraries are based on sdfat or sdfatlib (i.e. whenever SD.h is included in projects).
  • most libraries uses SPI instead of SDIO

So libraries for managing configuration files based on said libraries wonā€™t work. Libraries on which you stuff the data in (independently of the source of the data) could work.

Work in progress

There is an attempt to write a wrapper around FatFS divided into several classes to open/read/write files. On top of that, we should build a library to manage simple configuration files (sort of ā€œitemā€=ā€œvalueā€).

IIRC there are libraries that already do this (have to check again), but I remember the ones I found made difficult to replace the included FatFs functionality with our own.

Notes about writing on the SD

I have to say that you need to know how and when to write on the SD. Remember that SD cards have wear leveling and housekeeping procedures that can can take up to 250ms to complete, when writing.

This means that if you are playing a WAV file and a 250ms (or even less) delay on SD access occurs, sound will start to glitch. On systems with more RAM (a PC) you can read a big chunk (several megs) from the SD at once and donā€™t worry about concurrent accesses. On the PropBoard we have a couple of 512 samples buffers, that at 22050fs 16-bit mono means a SD read access every ~46ms. Thatā€™s the window you have to do the writing; the window shortens when multiple files are playing, so itā€™s better to save files when you are not playing from the SD.

Another consideration is that if you are writing a file and you disconnect the battery, send the board into low-power or there is a reset of any kind, you can blow the FAT and the SD wonā€™t be accessible again until you format it. All the opened files should be properly closed and the FAT partition unmounted before removing power from the board/SD.

Thatā€™s one of the reasons the BETA doesnā€™t include writing functions, the other reason was time :wink:

#4

My idea of the write function is, for example, to store when changed the configuration number of the sound bank used, so not a big data.
And this has to be done in a configuration menu, not inside some cyclic SD wav chunk reading.

#5

Yes, thatā€™s a use case that can be compatible and easy to achieve.

Off the top of my head I imagine that someone could write every single accelerometer data for later analysis. Thatā€™s a case that has to be planned and executed correctly.

#6

I seeā€¦ but for my programming skills is easier to copy them from the serial port monitorā€¦ :joy:

1 Like
#7

Reading from SD works. :slightly_smiling_face:
Iā€™m having problems writing (both string and single char).
Surfing the interned I found many people having problems writing files with fatFs.
It seems you have to write 256 bytes of data in order to have them written. Working on it.

#8

At the moment there is no way to write in the SD. See this.

To be added in the next SW version. Planned to release in about a week more or less.

#9

Sorry, I got confused by this:

I thought it could be possible with this release.

#10

I have forked and started to modify the standard SD library for Arduino to make it compatible with the PropBoard.

The objective is that you can use other libraries that depend on the SD library, like this.