gnupic: flash filesystem for pic and 24xxx EEPROMs?
Subject:
Re: flash filesystem for pic and 24xxx EEPROMs?
From:
"Vangelis Rokas" ####@####.####
Date:
7 Jan 2005 09:00:54 +0000
Message-Id: <001801c4f497$5fd09240$78f0673e@Odyssey>
----- Original Message -----
From: "David McNab" ####@####.####
To: "Vangelis Rokas" ####@####.####
Subject: Re: flash filesystem for pic and 24xxx EEPROMs?
> Those aren't too hard. I've already got a lib for I2C.
That's nice. It might be even easier if you already have interfaced
an I2C EEPROM in the past. You may have to rewrite some
functions from scratch to reduce overhead.
> Are they in C?
Yeap. They compile with SDCC and pic16 port. You also
need GPUTILS to build the objects.
> I'd be certainly interested in having a look at it.
Good. Let me do some refinements in the sources and
I'll publish them immediately.
> There's certainly a strong need for a good filesystem for PIC.
That's why I started writing it. I think I got the idea from the
uIP project.
> Some basic requirements that come to mind are:
> 1) wear-leveling - the only tolerable type of failure is an
> 'out of space' error
I still can't understand what do you mean with 'wear-leveling'!
> 2) Option to write large files on contiguous blocks (if available).
> I justify this with audio playback applications in mind. If stream
> playback requires block switching, a 400kHz device would have an
> absolute maximum of 10k frames/sec playback, whereas if there's no
> block-switching, 40k frames/sec is feasible.
When you read from the filesystem, initially you call a 'read-begin' function
to setup appropriate parameters of reading. (This way you can setup I2C
for reading). Then you continously call 'read' as long as you like. At the
end you call 'read-end' to shutdown I2C. So you don't have to initialize
I2C at every read. The same procedure is followed for writing.
> 3) tiny code footprint
At the moment the code size is around 5.1K. You can reduce it to around
~4K if writing procedures are omitted. Its quite large, so it might be necessery
to rewrite some functions in assembler.
> 4) smallest possible RAM control block per opened file
Its around 13 bytes per file handle.
> It's possible that between us, we could come up with a comprehensive
> solution which could be posted on the piclist website for all to enjoy.
>
> So please, send me your code.
I'll be glad to share my project with you.
regards,
Vangelis
