Break your project into three different parts:
1st Data monitoring
The requresd sensors are read in, probably at quite different frequencies, since voltages may alter much faster than temperatures
2nd data logging
Comparing pre - defined tresholds this part will use the internal E2Prom for storing the events and an RTC.
3rd Communication with the PC
This includes setting thresholds for the events, transmitting and clearing events, synchronizing RTC etc. IMHO the best would be to use an USBUART interface to accomplish this.
I do not have experiences with directly connecting an E2Prom to the emFile system but the E2Prom size is very limited and thus should be used as efficient as possible.
It's a good idea to using emFile system and USB
EmFile system can manage huge data and
when connect to the PC Host, you can transfer these data.
i have been using emFile+USB, that working quite good.
Btw, I don't understand what you want to,
Usually, emFile system using SD micro disk via SPI interface
I don't know that can use with internal flash memory, maybe NOT
I didn't heard that ever
And to recognize as mass storage is needs Mass Storage protocol of USB.
I don't know how to do with SD or Internal flash.
The emFile component is intented to be used with _external_ SD cards. This means it won't play well with internal storage. You should look maybe at the EEPROM component (or the emulated EEPROM component, but make sure you are at the latest version with this one).
For storage, I suggest you come up with a definition what you need to store. Define a 'C struct', so you get a fixed length record for each entry (if possible make it so its size is a multiple of 16). Then you can create new entries, and store them into the EEPROM.
Some other considerations using internal FLASH -
1) Your overall write rate is min of 15 mS per row, a row = 256 bytes.
You can write < a row, but this tells you effective write time, which sets
overall measurement thruput rate.
2) FLASH write cycle limitation is 10K cycles, 85 degrees C. EEPROM,
if you can live with 2KB limitiation, is -
Thanks for your responses guys.
First of all, the information that I'm monitoring is going to be coming from a variety of sources (multiple I2C and SPI lines, analogue monitoring and discrete digital inputs) so polling rates will be completely varied / non-existant with certain things.
I will be storing all values for a certain amount of time, so that when a fault occurs I can look at all variables in the run-up to the fault and see what might have gone wrong. I was thinking of having a circular buffer that I am continuously writing to as I get data, then when a fault occurs I can copy that buffer to a non-volatile location to be read back at a later date.
I knew that the emFILE component is designed for use with external sd cards, but was wondering if it could be fooled into thinking that the internal flash was the sd card and ignore the use of SPI. The more I think about this approach the less I like it as I think it is too bodgy and will be very bug ridden if it even COULD work.
The system will not always be USB connected so i will probably not be streaming back live data, but I suppose I could stream back (using USBUART as you suggest Bob) the contents of the E2PROM when I connect after a fault. Will this be the easiest way to transfer a block of data over USB in order to import into Excel or MATLAB as I wouldn't need to create a file system?
Does the USBUART require special drivers on the PC (such as the ones used with a USB-RS232 adaptor)?
Thanks again for your help,
I have just found this:
Which seems to explain the driver situation of the USB CDC class (Microsoft natively supports it, but I must supply an .INF file to tell Windows where to look, and this INF file is generated by Creator during the build)
It also has some useful information about sending large amounts (>64bytes) of data over a USBUART connection.
I supose the updated plan would be to store the data in a set format in the EEPROM when a fault occurs, and when I receive a certain command over the USB interface then send the data over USBUART. I can then use the terminal to store this all to a csv file (I think) and read it into Excel.
That sounds much more feasible that messing around with FAT16/32 formatting. What do you think?
Also thanks for the info about the flash life expectancy, I shall remember that when I am writing these buffers.
If this whole thing is about debugging, why not using the emFile component as its intended? Just log your stuff out as a text file (or CSV) to the card. When something goes wrong, just take the card and read it in the PC, and you have a perfect debug log. Only drawback: writing small packats of data to the card will be slow...
That would be ideal as it is about debugging, but we are cannot have an SD card on the board due to various environmental issues, unfortunately.
Thanks again for all of your help everyone, I'm having a look at the USBUART now and attempting to get it to work.