Hi everyone,
I am designing the next PCB of a device which connects and sends data to a mobile application over BLE.
I want to add a feature which saves data onto the device when the device is not connected to the app.
Would you recommend saving data into the internal flash of the processor (I am using the SAM D21 w/ Arduino) or saving it to an onboard SPI flash chip such as the W25Q80DV. What is more efficient, saves battery, and is better practice in industry?
Thanks for your help,
D
how much data and how often?
I have seen EEPROMs or flash burned out after a few months when a specification was changed from saving data every few months to every few minutes
if I am storing system configuration information which may updated every few months I use EEPROM or simulated EEPROM in flash
otheewise FRAM or for large volumes of data SD cards or USB drive
it seems that the raspberry pi burns out SD cards after some months in operation.
wear leveling is needed to prolong SD card life.
this underscores the first line of post #1 how much and how often ?
horace:
. . .
otherwise FRAM or for large volumes of data SD cards or USB drive
Do you mean here a USB drive connected directly to the Arduino, or do you mean more generally as a storage medium ? If direct, I'm curious to know how it is done.
I would use a microcontroller with USB host support (e.g. PIC24FJ256GB110) and a USB drive to store log files
there is a arduino-usb-host-shield
Hi everyone,
I think there was a misconception on my device. I am developing a wearable and thus cannot use a USB drive. It has to be stored on the device itself
I would need to write new data (steps, HR, and time) perhaps once a minute and read from it once a day (this will really depend).
The two options are using:
I am trying to determine what is the best decision based on efficiency, power, and good practice.
D
a USB host can talk to a USB memory stick which can be small
again, how much data and how often?
Hello,
I need to save data once every minute and about 4 bytes.
The USB stick is not an option as mentioned. I want to find the best option between the two I mentioned.
This is a wearable project and the PCB size is 35 x 35 mm.
D
You're storing 1440 bytes/day.
If you used eeprom with 100,000 cycles in the same place that'd be only 70 days.
If you used flash in a ring buffer 200k long you'd get about 100,000 times this - ought to be plenty.
Allan
Hi allanhurst,
Is an external flash chip better than using the internal flash of my microcontroller better?
D
No.
Allan
dave-in-nj:
it seems that the raspberry pi burns out SD cards after some months in operation.
wear leveling is needed to prolong SD card life.
this underscores the first line of post #1 how much and how often ?
That's from people using SD like HD or as HD.
A different set of practices needs to be used like don't sort data files but instead write a file of sorted links into the data. Don't edit the original, save the changes or the whole edited file as a revision file instead. And last, get a USB HD.
ddesousa:
Hi allanhurst,Is an external flash chip better than using the internal flash of my microcontroller better?
D
With AVR-Arduino you have to use a bootloader that allows writing to flash. This may apply to the SAM chip?
Does your SAM chip have EEPROM? You get more writes with EEPROM.
1440 bytes per day, can that be saved every day then you won't need so much.
If you could keep a serial RAM chip alive with a supercap, could you get the data back out later? Change that all you want.
As already stated by allanhursdt, IMO a circular buffer and wear levelling to emulate EEPROM in Flash is by far the best option. There is an application note from Atmel for wear levelling:
SD is supposed to wear-level too. There is a controller with semi-complex code in SD. You deal with it, not the flash.
If you think different, look up SD.
EEPROMs are under-rated in my view. It takes some time to learn, but is nice to be in control of the data flow. And EEPROMs are very very cheap.
By contrast I found SDs as really mysterious pieces of a devilish character. Not to mention that SD are really hard to find. Perhaps there is SDHC or even better SDXC readers for Arduino, but I could not find one.
On the other hand, more complex tasks or high volume of date looks to me as a tasks for Raspberry Pi or similar, rather than one for Arduino.
But is a matter of taste, of course.