Split from: [Troubleshooting] Can't get the FatFs R0.13 example running on my Atmega32

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good evening,

after some hassle I managed to get FatFs running and can mount, open/create files and write to them.

 

Now I have a few questions about the writing process.

If I understand it correctly, if I use the configuration FF_FS_TINY 1, it will create one "FF_MAX_SS" large buffer (512 byte) in the FATFS object for all files I might open.

If I use FF_FS_TINY 0, each FIL object will receive it's own "FF_MAX_SS" large buffer.

Since I have eight sensors and only a limited RAM of 2kB, I could either create individual files for each and see if the shared 512 byte buffer would be sufficiet or I could give them individual names and store them in one single file. If I go with one file for all sensors, would there be a way to increase the buffer size, if needed? Reading the ffconfig.h, it sounds like one should mostly use 512 byte for FF_MAX_SS, since it's the common SD card sector size.

So, if the 512 byte buffer shouldn't be enough, how could you increase it?

 

Another question I have is: What would be a good way to store the data?
Since I want to easily process the data on a PC later on, I thought of using f_printf to write it as a formated string into a .txt file that can be opened with Excel.

What I don't understand yet is how this would look like when you use f_write. For example, if I have a something like a string sensor.text = "In1" and a uint16_t sensor.value = 1023, how would you combine the two in order to save them with f_write?

 

And a more general question:
My program does ADCs from up to 8 sensor values every 1-1000ms. The approach I thought of so far is that after each conversion is completed, I would immediately send them to the sd card via f_printf.
Something like this:

Sensor1.value = read_adc(0);

f_printf(&file1, "%s %d \n",Sensor1.name, Sensor1.value);

 

This way, depending on how long f_printf takes, I could end up getting delays before I can read Sensor2. Would it be better to read all sensors and throw the data into some FIFO and then take them out of the fifo to write them with f_printf to the card? So the ADC would feed a fifo which woul feed f_printf to the sd card. But I am not sure if this would be a good idea since intended roughly 15 bytes of data for each adc conversion.

 

Would be great if somebody could share some thoughts or hints. Thank you and have a nice day. :)

Last Edited: Tue. Oct 3, 2017 - 01:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you need to write the sensor-name everytime ?
I would use the simple .CSV file-format ;
In1,In2,In3,In4,In5,In6.In7,In8 <- column headers
12,0,333,555,2,-5,999,41 <- 8 samples
99,44,22,-551,2,918,441,6666 <- another lot of 8 samples
...


It seems that you have a bit of a juggling-act, memory versus time.
Calling file-routines is 'expensive' in terms of time because there are usually a lot of overheads (checking, updating of internal data, etc), and then eventually writing to the storage media.
The effects of those overheads can be reduced by writing more bytes per invocation., but that now requires more memory to store data.


How much timing 'skew' can your application tolerate ?
ie. is it a high-priority that all the sensors are sampled with minimal delay between samples ? If yes, then you will need to store the samples and file them afterwards.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mikech wrote:
I would use the simple .CSV file-format ;
+1

 

Or an alternative is to simply write data as binary. So after each read you just write 16 bytes each time which are made up of eight 2 byte ADC readings.

 

The latter is more difficult to debug as you can't just "type" the file at a command prompt (or load it into an editor) and see something sensible to humans but is more speed and size efficient.

 

Something like:

uint16_t readings[8];
uint8_t i;
UINT written;

for (i = 0; i < 8; i++) {
    readings[i] = read_adc(i);
}

f_write(my_file, read_adc, 16, &written);

Obviously you now need code (rather than just Excel or something) on the PC to read/process the data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another +1 for CSV.

 

clawson wrote:
 an alternative is to simply write data as binary ... you now need code (rather than just Excel or something) on the PC to read/process the data.

Python has facilities to write Excel files: http://www.python-excel.org/

 

So you could have a simple Python script to read the binary and write an Excel file.

 

Or you could do all the analysis in Python; eg, https://www.scipy.org/