Is it worth to implement small filesystem for an EEPROM

Question

I have bought an I2C EEPROM. I want to store sensor and voltage data. I'm assuming that value can be bigger than one byte, and there can be a lot of data. Is it worth is such case to implement a filesystem with small file allocation table? It would make me easier to peek trought EEPROM for example.

Forsooth

How big is the EEPROM? – Axes

This is Atmel 24C16 I2C EEPROM (16K) – Forsooth

EEPROMS are generally not very big, so it might be easier to store data as structures at specific offsets from the beginning. If you then have a "master structure" telling where the structures are stored, you have, for all practical reasons, your "file system". – Jiggle

It depends on how many files you'll store. A FAT8 would probably work perfectly. – Arbela

@JoachimPileborg Good idea, I will try to do that. Thanks for comments. :) – Forsooth

Answer 1

I see two causes for a FAT on EEPROM

1. If there is a requirement for the flexibility of having different files. Such as for data logging or configurations. It allows multiple such configuration/log files, to be independent and easily added in the future. This can be a very successful building block for future projects.
2. For ease of access by other devices or libraries. Typically only an option if the memory device is directly accessible by other interface. Where as in this case it is an EEPROM. If your device was directly USB capable, such as a ATmega32u4 (leo) then you can use LUFA tools to have the USB show up as MASS storage. Making FAT an ideal solution. Or possibly if the device has an Ethernet Shield.

with all being said and if this case simply a datalogger, then the KISS (Keep It Simple Solution) may be a good way to go. So that one can keep focus on the original subject for collecting the data itself.

---

It is worth noting that SdCards can be easily added for cheap either of the well established Sd library (IDE stock) or SdFat Library (GitHub more features) adding an almost infinite capacity of logging of FAT32. The only trade off is they consume a fair chunk of code space.

Snowberry

Answer 2

I think mpflaga is on the right path.

Some options you should consider include:

1. Is the device/microcontroller that is writing the data going to be the same as the one that is reading the data?
2. How many records are you hoping to fit into your storage device?
3. How robust/recoverable do you want your storage format to be to events such as reboots/power outages/etc?

My opinion regarding these points is that:

1. It is going to be the same device reading and writing, so you can probably get away with a very specific/custom format rather than a full blown file system.

2. You probably want to extract as many bytes as possible for use as storage, so a format well-designed for your application will probably help.

3. This is tricky. You could use self-describing structures, such as a TLV, which would pack your bytes tightly but be harder to search; OR you could use a fixed-length structure, which wastes a lot of bytes but allows easy access. Also, you could just assume the storage will always remain valid, but what happens if power is removed half-way through a write!

Overall, my recommendation would be:

1. Use an existing library
2. Use an application-specific format first, but ensure you abstract the storage of the data from the data itself.
3. If you find you need a filesystem, rewrite the storage layer to use a filesystem.

Ridings

Answer 3

Having a small standard file system, like FAT16, is worth implementing because you can map this file system over the USB or Network to other devices/computers.

Standardization in your design is a big compliance advantage.

You can find ready sources/libraries or, if it's FAT16 and because it is really simple and well described/documented, try implementing yourself.

Tug