View Full Version : EEFS - EEprom File System.
01-19-2009, 01:30 AM
My first contribution to the Hydra community is my EEProm File System. It works sort of like the HAM system, in fact, I'm using the NS_EEprom_Drv code used by HAM to access the EEProm. I'm even using HAM to debug my app while working on it. What you can do with EEFS are the following.
Save blocks of memory (or files) into EEProm from within your SPIN code by 'Name' (file name).
List files saved in EEProm.
Load files (by file name) from EEProm into a buffer.
I intend this to be an extension to Tiny Basic, so you can save and load programs to the upper 96k of EEProm memory.
I'm still working on removing files from EEProm (kill function).
You can download the latest source code, and check it out for your self here:
01-19-2009, 02:04 AM
Thanks for your contribution, but I believe you're not allowed to distribute ns_eeprom_drv.
01-19-2009, 02:48 AM
I love the idea.. Please continue this project!
(Of course for now, you'll have to drop the file, and provide instruction to finding it.)
Maybe we can get Andre to weigh in on this and allow the driver to be distributed.
New to the Propeller?
Check out: Protoboard Introduction (http://jeffledger.googlepages.com/Protoboard_Introduction.pdf) , Propeller Cookbook 1.4 (http://ucontroller.com/Propeller%20Protoboard%20Designs%20for%20the%20Beg inner.pdf) & Software Index (http://forums.parallax.com/showthread.php?p=770318)
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us (http://propeller.warrantyvoid.us)
Got an SD card connected? - PropDOS (http://www.orrtech.net/propdos/)
01-19-2009, 05:56 AM
The Propeller OS (here: http://forums.parallax.com/showthread.php?p=620700) includes an EEPROM file system that allows you to name 32K "pages" of EEPROM and copy files by name. You're welcome to strip out just the file system. Essentially, it stores a file name, some checksum information, and flag bits (for the content type) in the last few bytes of any EEPROM present on any pair of I/O pins. There's a routine that "mounts" an I2C bus on a pair of I/O pins so the file system knows about it. There are routines to look up a name or to look up a blank name (for an available area), then rename an area.
01-19-2009, 08:13 AM
@Mike:· I'd love to take a look at what you have for the propeller OS.· I thought about paging the EEProm.· But I wanted 'file space' to be dynamically allocatable.· My next task will be adding the ability to delete a 'file' from EEProm.
@mpark:· I believe you can redistribute the NS Eeprom driver, because, Rich Benson (keebler) had it packaged up with his Hydra Asset Manager.· If I'm wrong, then I appologize, didn't mean to step on any toes, and I'll be happy to get permission from whomever, or even write my own, but there should be no need to re-invent the wheel.
@OldbitCollector: I don't think Andre' minds.· I posted about this project first on the Hydra forums over at xgs, and he just asked that I start up a source forge entry (http://sourceforge.net/projects/eefilesystem), update the wiki (which I haven't done yet), and tell you guys about it here on these forums.
I'm not using any kind of File Allocation tables for file location information.· I wanted to keep it simple and just have one growing heap for 'file' storage.· Everything is done in a sequential manor.· One file is located directly after another.· Kind of like on the old tape drives.· What happens is EEFS prepends a 16 byte header to your data.
Bytes:· $0000 - $0001· File Block Identifier - Word - Constant value: '$ABCD'.· Identifies block as a file. Bytes:· $0002 - $0003· File Length - Word - Length of file data (not including header). Bytes:· $0004 - $000F· File Name - 3 x Long·- 12 bytes for file name (file name can be 11 bytes, followed by $0) Bytes:· $0010 - $0010 + (File Length) File Data
The next header block, and file are located right after the file data.
To delete a file, I'll just have it shift all the file information upward to cover up the file you are deleting.· Kind of like a scroll function.· I'll have it write all zeros at the bottom of the file storage space to cover up the old copy of the last file so it's not duplicated.· The problem with this method is that it could be time consuming.· I'd have to use a temporary buffer, bring in a chunk of memory from EEProm, and re-write it to a spot further above it's old location back onto the EEProm.· I want this to have a small of a footprint as possible, so I'll have to limit the size of the temporary buffer.