|Mike C ed9ae9b212||7 years ago|
|Datasheets||7 years ago|
|SimpleFileSystem||7 years ago|
|Upstream_Projects||7 years ago|
|.gitignore||7 years ago|
|License_Apache-2.0.txt||7 years ago|
|License_CC_BY-SA_3.0.txt||7 years ago|
|README.md||7 years ago|
|cc-by-sa.png||7 years ago|
This project is a simple filesystem meant to be used on top of an EEPROM or SRAM chip. It provides basic functionality for files, complex data type storage and some other niceities without the overhead. It can likely work with an SD card as a raw storage device, but its use is geared towards EEPROM's and SRAM.
This library has been tested on an Arduio Due as well as Arduino Leonardo. Implementers can assume things will "just work" on the avr Arduino devices and the Due. There are some practical differences between the avr and arm Arduino's that this library addresses behind the scenes.
For those implementing a new driver, data type sizes are different between avr and arm. For example an int is twice as large on arm compared to avr. The pre-existing drivers address this difference, your driver should also take this difference into account.
All documentation and graphical content contained on this website and within the sources unless otherwise noted is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license.
Source code is licensed under the Apache License, Version 2.0 unless otherwise specified.
If you are concerned about the size of the library given it may have more chips supported than you need: You can delete any drivers (or move them out of the way) from the project. Drivers are prefixed with "Driver" and can be safely removed prior to build.
Each driver also has a testChip method that is not compiled into the final binary by default. If you go into the drivers code, you can enable the method to be build for initial testing of the chip. After that you'll want to disable the method as they can be quite large and should not generally be used beyond an initial test.
The structure of the library is as follows:
FS <> IO API <> Drivers (I2C / SPI / Chip)
Because it is a layered approach, the underlying storage (EEPROM/SRAM) and any chip specific details are abstracted away from the program being developed. All you need to ensure is that there is a driver available for the chip being used for storage. I have implemented support for a few different chips already, you'll want to use these implementations as a template if adding support for a new chip.
The drivers are named according to the following:
DriverProtocolChip where "Driver" is a static prefix, "Protocol" is I2C, SPI or similar and Chip is "MC23x256". For example the driver for the Microchip 23K256 chip is "DriverSPIMC23x256".
The following projects/guides/snippets were used in the development of this library. They provided me with a lot pre-existing solutions and inspiration.