Saving data from Adc to SD card

[jendoubi saif ddine]

Posted on April 12, 2018 at 17:13

Hello everyone,

i've been trying to save adc values into a .txt file or .CSV

they both work fine, but i can't finda way to keep saving the current data directly '

f_write(&MyFile, msg, sizeof(msg), (void *)&byteswritten);

this function always go to the first line of the file and writeover the previous data, 

can anyone help with an example, And thanks in advance

🙂

 

[Tesla DeLorean]

Posted on April 12, 2018 at 17:37

>>this function always go to the first line of the file and writeover the previous data,

It shouldn't unless you keep f_open/f_close-ing the file and don't advance the pointer to the end of the file.

  if (f_open(&fil, 'LOG.TXT', FA_OPEN_ALWAYS | FA_WRITE) == FR_OK)

  {    UINT BytesWritten;    const char string[] = 'Another line gets added\r\n';

    f_lseek(&fil, f_size(&fil));

    f_write(&fil, string, strlen(string), &BytesWritten);    f_close(&fil);  }

Opening, Closing and writing small amounts of unaligned data will have brutal performance implications, and can be very damaging to flash based devices.

[jendoubi saif ddine]

Posted on April 12, 2018 at 17:48

you are a savior as always, 

what do you suggest then, i need to keep on truck of electrical performance so i thought saving the values to a .txt file or .CSV and then with a html i generate statistics calculated by those values , i would really appreciate an expert's idea

[Tesla DeLorean]

Posted on April 12, 2018 at 18:14

ASCII data tends to be overly verbose, so eats card capacity and bandwidth, but clearly easier to import into Excel, etc.

If I wanted to maximize things I'd be writing large blobs of binary data (say 16 or 32KB), and keeping the file open. Then process the data on your 3GHz PC with 16GB of RAM.

How many lines are you writing, how frequently are you doing it?

Generally people open/close files so they don't lose data when someone randomly removes the card. A better solution is to have a button to indicate you plan to eject the card so you can f_close() and flush data cleanly, or periodically f_sync() a file that remains open. If the device is in a case you could have adaptive behaviour depending if the box is open or not. ie it becomes more conservative if random card removal could occur.

I have data loggers that generate hourly files (ie opens a new one top-of-hour), the data here is ASCII, I have a spill buffer 32KB + maxlinelength, whenever I have 32KB or more I write the 32KB, and then copy whatever spill/overflow I have to the beginning of the buffer to start the next 32KB block. When closing I flush whatever content remains. This way all except the last write are aligned 32KB blocks, which works well for the file system and the block storage system.

[Andrew Neil]

Posted on April 13, 2018 at 09:43

Clive One wrote:

>>this function always go to the first line of the file and writeover the previous data,

It shouldn't unless you keep f_open/f_close-ing the file

Indeed - the FatFs documentation tells you this:

Description

The function starts to write data to the file at the position pointed by the read/write pointer. The read/write pointer advances as number of bytes written.

http://elm-chan.org/fsw/ff/doc/write.html

 

Opening, Closing and writing small amounts of unaligned data will have brutal performance implications, and can be very damaging to flash based devices

.So don't do that, then!

You can keep the file open, and use 

http://elm-chan.org/fsw/ff/doc/sync.html

  to 'flush' the data to the card from time-to-time...

Or open the file in Append mode: 

http://elm-chan.org/fsw/ff/doc/open.html