Paul, Al,
 
Thanks, I'd be using the internal flash of the F149, but could imagine
that i be using it with external flash as well. I don't need to be FAT
compatible, since I'll be storing data that was received over a serial
connection i.e. usart spi whatever. For now I have a situation in which
I'll be receiving data  several times a day, that needs to be stored an
displayed at request. So therefore I thought it would be nice to have
something like a fat system. So I could store, fetch, delete, change the
data at any given time.. the product only needs to survive 2 years, in
which I could imagine that it will receive new data between 2 to 20
times a day of varying length but with a max of 314 char (for now, so I
have to stay open here) .
 
thanks,
Martijn
-----Oorspronkelijk bericht-----
Van: Paul Curtis [mailto:plc@plc@...] 
Verzonden: maandag 21 juli 2003 13:48
Aan: msp430@msp4...
Onderwerp: RE: [msp430] Tiny Flash File System
 
Martijn,

> Could you tell me where i can find more info on
how these ffs 
> systems work?

The FFS implementation depends upon the flash technology you're managing
(NAND, NOR).  A Google around for TrueFFS and Flash Filing System will
get you somewhere.  There is Linux code, by Aleph One I believe, that
manages a NAND-technology FLASH disk.  Anything that manages flash on an
SD/MMC/SmartMedia card or Compact Flash card will require wear leveling
and requisite protection, so start looking around for that.  Intel used
to have their Small Block Manager software available for download if you
were using an Intel flash, but I think that is now only available
through a license agreement.  Similarly, Samsung had management code if
you used the Smart Media cards (I used these for one project, but
didn'Pt
use their code to implement the filing system).

For myself, I implemented the flash filing code from scratch for
customer use--twice, for different customers.  It didn't need to be FAT
compatible, so a simple file system on top of a robust block manager was
all that was required of these two embedded systems.

-- Paul.





 
<http://rd.yahoo.com/M%1812.3170658.4537139.1261774/D=egroupweb/S05
005378:HM/A52963/R=0/SIGtvulr8i/*http:/www.netflix.com/Default?mqs
o`178275&partid170658> click here

 
<http://us.adserver.yahoo.com/l?M%1812.3170658.4537139.1261774/D=egrou
pmail/S=:HM/A52963/rand'1185903> 

.



">http://docs.yahoo.com/info/terms/>  Terms of Service. 

Martijn Broens wrote:

> Paul, Al,
>  
> Thanks, I'd be using the internal flash of the F149, but could imagine
> that i be using it with external flash as well. I don't need to be FAT
> compatible, since I'll be storing data that was received over a serial
> connection i.e. usart spi whatever. For now I have a situation in which
> I'll be receiving data  several times a day, that needs to be stored
an
> displayed at request. So therefore I thought it would be nice to have
> something like a fat system. So I could store, fetch, delete, change the
> data at any given time.. the product only needs to survive 2 years, in
> which I could imagine that it will receive new data between 2 to 20
> times a day of varying length but with a max of 314 char (for now, so I
> have to stay open here) .

Okay, so you need a permanent store of ALL messages, not, as is my case, 
a store of the most recent history, which periodically gets downloaded. 
In that case the maths is simple, 20msgs x 730 days x 314 bytes 4584400 bytes,
somewhere over 4 megaqbytes of data, and a total of 14600 
messages maximum. This is very different to what I needed to do. I 
would, in this instance, use the internal flash of the 149 to store an 
entry for each message in 1 word. easily fitting in the 32k above 8000H. 
I would store the message length here. For bulk storage I would use 
something like the Atmel serial data flash. Last time I looked it was 
around US$9 a pop for 32Mbits. (true binary Mbits as well, not 1,000,000 
mibits, kibits or rabbits, to suit Euro mania). You may be able to get 
more optimal storage by analysing the data being stored, and removing 
any noise/surplus etc.

Al


>  
> thanks,
> Martijn
> -----Oorspronkelijk bericht-----
> Van: Paul Curtis [mailto:plc@plc@...] 
> Verzonden: maandag 21 juli 2003 13:48
> Aan: msp430@msp4...
> Onderwerp: RE: [msp430] Tiny Flash File System
>  
> Martijn,
> 
> 
>>Could you tell me where i can find more info on how these ffs 
>>systems work?
> 
> 
> The FFS implementation depends upon the flash technology you're
managing
> (NAND, NOR).  A Google around for TrueFFS and Flash Filing System will
> get you somewhere.  There is Linux code, by Aleph One I believe, that
> manages a NAND-technology FLASH disk.  Anything that manages flash on an
> SD/MMC/SmartMedia card or Compact Flash card will require wear leveling
> and requisite protection, so start looking around for that.  Intel used
> to have their Small Block Manager software available for download if you
> were using an Intel flash, but I think that is now only available
> through a license agreement.  Similarly, Samsung had management code if
> you used the Smart Media cards (I used these for one project, but
> didn'Pt
> use their code to implement the filing system).
> 
> For myself, I implemented the flash filing code from scratch for
> customer use--twice, for different customers.  It didn't need to be
FAT
> compatible, so a simple file system on top of a robust block manager was
> all that was required of these two embedded systems.
> 
> -- Paul.
> 
> 
> 
> 
> 
>  
> <http://rd.yahoo.com/M%1812.3170658.4537139.1261774/D=egroupweb/S05
> 005378:HM/A52963/R=0/SIGtvulr8i/*http:/www.netflix.com/Default?mqs
> o`178275&partid170658> click here
> 
>  
> <http://us.adserver.yahoo.com/l?M%1812.3170658.4537139.1261774/D=egrou
> pmail/S=:HM/A52963/rand'1185903> 
> 
> .
> 
> 
> 
> ">http://docs.yahoo.com/info/terms/>  Terms of Service. 
> 
> 
> 
> 
> 
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
>