Just like to find out if anyone has any ideas on how I can add a
filesystem to 2138 or the 2294's flash portion, i am thinking of
FAT32, is there any material/book I can get for a comprehensize study
on this, I need to basically do relative addressing when logging or
calling the log file, any help will be appreciated
Thanks
Samuel
Adding Filesystem on LPC2138 or 2294
Started by ●October 9, 2005
Reply by ●October 9, 20052005-10-09
Samuel...
>["SR" <emddjava@y...> wrote:]
> ... if anyone has any ideas on how I can add a filesystem
> to 2138 or the 2294's flash portion, i am thinking of FAT32
> is there any material/book I can get for a comprehensize
> study on this, I need to basically do relative addressing when
> logging or calling the log file, any help will be appreciated
As I recall, FAT32 disk partitions need a minimum 'disk' size of 260MB
(that's MEGAbytes). The old FAT12 is good for 'disks' up to about
16MB; I believe FAT16 is good for 16MB to around 2GB.
Given the internal flash of the 2294 (and prob the 2138) = 256kB,
you'd want to use FAT12.
I believe there was an open FAT12 implementation in a fairly recent
Circuit Cellar magazine article in the last 6 months. Not sure; this
may have been a read-only implementation.
For a commercial product, you'll likely use one of various commercial
vendors' file systems out there (NucleusFILE, SMX, Fusion, etc.) with
licensing, etc. - prob source code and linkable library versions are
out there.
You may have to figure out flash wear-levelling, flash erase block
size, and reuse strategies yourself if the filesystem isn't
flash-aware (or is only set up to talk to consumer flash devices like
SD/MMC, CF, etc. which manage this aspect inside the card).
A basic FAT filesystem has format, open, close, delete, rename, and
various read & write calls. These can be hooked, with some effort, and
tied into C library functions - or you just use the FAT library calls
instead. The basic FAT filesystems are used to working with block
devices and expect to call a read or write function that reads/writes
1...256 blocks of 512 bytes each (usu sector size, but this can be
changed). You'll have to play w/cluster size vs erase block size.
If DOS compatibility is not needed (likely) there are probably better
filesystems to use ---- unless your LPC2xxx flash will sometimes be
viewed as a USB memory device by a PC host. Bill Wiese
San Jose, CA USA
>["SR" <emddjava@y...> wrote:]
> ... if anyone has any ideas on how I can add a filesystem
> to 2138 or the 2294's flash portion, i am thinking of FAT32
> is there any material/book I can get for a comprehensize
> study on this, I need to basically do relative addressing when
> logging or calling the log file, any help will be appreciated
As I recall, FAT32 disk partitions need a minimum 'disk' size of 260MB
(that's MEGAbytes). The old FAT12 is good for 'disks' up to about
16MB; I believe FAT16 is good for 16MB to around 2GB.
Given the internal flash of the 2294 (and prob the 2138) = 256kB,
you'd want to use FAT12.
I believe there was an open FAT12 implementation in a fairly recent
Circuit Cellar magazine article in the last 6 months. Not sure; this
may have been a read-only implementation.
For a commercial product, you'll likely use one of various commercial
vendors' file systems out there (NucleusFILE, SMX, Fusion, etc.) with
licensing, etc. - prob source code and linkable library versions are
out there.
You may have to figure out flash wear-levelling, flash erase block
size, and reuse strategies yourself if the filesystem isn't
flash-aware (or is only set up to talk to consumer flash devices like
SD/MMC, CF, etc. which manage this aspect inside the card).
A basic FAT filesystem has format, open, close, delete, rename, and
various read & write calls. These can be hooked, with some effort, and
tied into C library functions - or you just use the FAT library calls
instead. The basic FAT filesystems are used to working with block
devices and expect to call a read or write function that reads/writes
1...256 blocks of 512 bytes each (usu sector size, but this can be
changed). You'll have to play w/cluster size vs erase block size.
If DOS compatibility is not needed (likely) there are probably better
filesystems to use ---- unless your LPC2xxx flash will sometimes be
viewed as a USB memory device by a PC host. Bill Wiese
San Jose, CA USA
Reply by ●October 10, 20052005-10-10
--- In lpc2000@lpc2..., "wmwiese" <wmwiese@y...> wrote:
> As I recall, FAT32 disk partitions need a minimum 'disk' size of 260MB
> (that's MEGAbytes). The old FAT12 is good for 'disks' up to about
> 16MB; I believe FAT16 is good for 16MB to around 2GB.
>
This is one of those posts that I have to say something.
Bill you are wrong about your statments above.
I am not interested in educating the masses, but this is just wrong.
hamilton
> As I recall, FAT32 disk partitions need a minimum 'disk' size of 260MB
> (that's MEGAbytes). The old FAT12 is good for 'disks' up to about
> 16MB; I believe FAT16 is good for 16MB to around 2GB.
>
This is one of those posts that I have to say something.
Bill you are wrong about your statments above.
I am not interested in educating the masses, but this is just wrong.
hamilton
Reply by ●October 10, 20052005-10-10
--- In lpc2000@lpc2..., "donhamilton2002" <hamilton@d...>
wrote:
>
> --- In lpc2000@lpc2..., "wmwiese" <wmwiese@y...> wrote:
>
> > As I recall, FAT32 disk partitions need a minimum 'disk' size of
260MB
> > (that's MEGAbytes). The old FAT12 is good for 'disks' up to about
> > 16MB; I believe FAT16 is good for 16MB to around 2GB.
> >
>
> This is one of those posts that I have to say something.
>
> Bill you are wrong about your statments above.
>
> I am not interested in educating the masses, but this is just wrong.
>
> hamilton
>
I'm in agreement Hamilton, but will add my little bit to educate the
masses since this is what user groups are for. The FAT type 12,16,32
bit is determined by the count of clusters of the device. Nothing else.
Get your hands on a copy of a microsoft document called "FAT:General
Overview of On-Disk Format" this describes in detail the FAT system.
Doug
>
> --- In lpc2000@lpc2..., "wmwiese" <wmwiese@y...> wrote:
>
> > As I recall, FAT32 disk partitions need a minimum 'disk' size of
260MB
> > (that's MEGAbytes). The old FAT12 is good for 'disks' up to about
> > 16MB; I believe FAT16 is good for 16MB to around 2GB.
> >
>
> This is one of those posts that I have to say something.
>
> Bill you are wrong about your statments above.
>
> I am not interested in educating the masses, but this is just wrong.
>
> hamilton
>
I'm in agreement Hamilton, but will add my little bit to educate the
masses since this is what user groups are for. The FAT type 12,16,32
bit is determined by the count of clusters of the device. Nothing else.
Get your hands on a copy of a microsoft document called "FAT:General
Overview of On-Disk Format" this describes in detail the FAT system.
Doug
Reply by ●October 10, 20052005-10-10
Yes probably am - working from memory, and I was probably relying on
default 4K cluster size on many disks.
It may make sense to align cluster size w/flash erase block size.
Bill W.
San Jose --- In lpc2000@lpc2..., "donhamilton2002" <hamilton@d...> wrote:
>
> --- In lpc2000@lpc2..., "wmwiese" <wmwiese@y...> wrote:
>
> > As I recall, FAT32 disk partitions need a minimum 'disk' size of 260MB
> > (that's MEGAbytes). The old FAT12 is good for 'disks' up to about
> > 16MB; I believe FAT16 is good for 16MB to around 2GB.
> >
>
> This is one of those posts that I have to say something.
>
> Bill you are wrong about your statments above.
>
> I am not interested in educating the masses, but this is just wrong.
>
> hamilton
>
default 4K cluster size on many disks.
It may make sense to align cluster size w/flash erase block size.
Bill W.
San Jose --- In lpc2000@lpc2..., "donhamilton2002" <hamilton@d...> wrote:
>
> --- In lpc2000@lpc2..., "wmwiese" <wmwiese@y...> wrote:
>
> > As I recall, FAT32 disk partitions need a minimum 'disk' size of 260MB
> > (that's MEGAbytes). The old FAT12 is good for 'disks' up to about
> > 16MB; I believe FAT16 is good for 16MB to around 2GB.
> >
>
> This is one of those posts that I have to say something.
>
> Bill you are wrong about your statments above.
>
> I am not interested in educating the masses, but this is just wrong.
>
> hamilton
>
Reply by ●October 10, 20052005-10-10
Bill W. wrote:
> It may make sense to align cluster size w/flash erase block size.
Indeed.
The 21xx flash memory has got some weird sector seizes.
The 213x series has 8 x 4kB, 14 x 32 kB and then 5 x 4kB (in that order)
and for the 212x it is even worse: 8 x 8kB, 2 x 64 kB and 7 x 8kB.
The 210x and 211x series use a sector size of 8kB for all their sectors.
You can (as far as I know - never did this myself) perform partial
programming of a sector. The IAP functions as described in the 213x user
manual will allow you to write to Flash in 256/512/1024/4096 byte blocks
but you have to erase sectors on full sector sizes. This will definitely
not match your FAT file system.
Samuel wrote:
> I need to basically do relative addressing when logging or
> calling the log file, any help will be appreciated
I'm not sure what you mean by "relative addressing"?
If it is just logging data you need to do the easiest way is to just use
reserve some sectors for logging and start using these without any
difficult file system. You could either create a directory which tells
you date/time/filename and the start position of the file in memory or
define a structure that defines what the block is about and what its
length is.
Depending on the application and the amount of data I would opt for an
MMC/SD card for logging. Log the data on your application and then just
plug the SD card into a PC and a PC application will show your data.
I am going to use this for logging data and updating software (on boot
check for presence of SD card, check for new software and reprogram
flash if needed)
See also http://groups.yahoo.com/group/lpc2000/message/9293
Regards,
Rob
> It may make sense to align cluster size w/flash erase block size.
Indeed.
The 21xx flash memory has got some weird sector seizes.
The 213x series has 8 x 4kB, 14 x 32 kB and then 5 x 4kB (in that order)
and for the 212x it is even worse: 8 x 8kB, 2 x 64 kB and 7 x 8kB.
The 210x and 211x series use a sector size of 8kB for all their sectors.
You can (as far as I know - never did this myself) perform partial
programming of a sector. The IAP functions as described in the 213x user
manual will allow you to write to Flash in 256/512/1024/4096 byte blocks
but you have to erase sectors on full sector sizes. This will definitely
not match your FAT file system.
Samuel wrote:
> I need to basically do relative addressing when logging or
> calling the log file, any help will be appreciated
I'm not sure what you mean by "relative addressing"?
If it is just logging data you need to do the easiest way is to just use
reserve some sectors for logging and start using these without any
difficult file system. You could either create a directory which tells
you date/time/filename and the start position of the file in memory or
define a structure that defines what the block is about and what its
length is.
Depending on the application and the amount of data I would opt for an
MMC/SD card for logging. Log the data on your application and then just
plug the SD card into a PC and a PC application will show your data.
I am going to use this for logging data and updating software (on boot
check for presence of SD card, check for new software and reprogram
flash if needed)
See also http://groups.yahoo.com/group/lpc2000/message/9293
Regards,
Rob
Reply by ●October 10, 20052005-10-10
Rob Jansen wrote:
> Bill W. wrote: >>It may make sense to align cluster size w/flash erase block size. > Indeed.
> The 21xx flash memory has got some weird sector seizes.
> The 213x series has 8 x 4kB, 14 x 32 kB and then 5 x 4kB (in that order)
> and for the 212x it is even worse: 8 x 8kB, 2 x 64 kB and 7 x 8kB.
> The 210x and 211x series use a sector size of 8kB for all their sectors.
>
> You can (as far as I know - never did this myself) perform partial
> programming of a sector. The IAP functions as described in the 213x user
> manual will allow you to write to Flash in 256/512/1024/4096 byte blocks
> but you have to erase sectors on full sector sizes. This will definitely
> not match your FAT file system.
>
> Samuel wrote: >>I need to basically do relative addressing when logging or
>>calling the log file, any help will be appreciated > I'm not sure what you mean by "relative addressing"?
> If it is just logging data you need to do the easiest way is to just use
> reserve some sectors for logging and start using these without any
> difficult file system. You could either create a directory which tells
> you date/time/filename and the start position of the file in memory or
> define a structure that defines what the block is about and what its
> length is.
>
> Depending on the application and the amount of data I would opt for an
> MMC/SD card for logging. Log the data on your application and then just
> plug the SD card into a PC and a PC application will show your data.
> I am going to use this for logging data and updating software (on boot
> check for presence of SD card, check for new software and reprogram
> flash if needed)
>
> See also http://groups.yahoo.com/group/lpc2000/message/9293
>
> Regards,
>
> Rob
>
Correct! If you want to log data continously only, why you want to spent
a lot of time in implementing a file system? Just write your data
byte4byte to your flash and wrap around if it is full.
If there are other reasons for using a file system, a flash file system
like JFFS(2) could be better solution than FAT. Because it is balancing
write/erase cycles to your flash other than FAT. Just have look to the
Linux kernel (the greatest resource of open-source code in this world!).
Check the uClinux resources and mailing list for a good (bug-free)
implementation, too.
Regards,
Sten --
/************************************************
Do you need a tiny and efficient real time
operating system (RTOS) with a preemtive
multitasking for LPC2000 or AT91SAM7?
http://nanortos.net-attack.de/
Or some open-source tools and code for LPC2000?
http://www.net-attack.de/
************************************************/
> Bill W. wrote: >>It may make sense to align cluster size w/flash erase block size. > Indeed.
> The 21xx flash memory has got some weird sector seizes.
> The 213x series has 8 x 4kB, 14 x 32 kB and then 5 x 4kB (in that order)
> and for the 212x it is even worse: 8 x 8kB, 2 x 64 kB and 7 x 8kB.
> The 210x and 211x series use a sector size of 8kB for all their sectors.
>
> You can (as far as I know - never did this myself) perform partial
> programming of a sector. The IAP functions as described in the 213x user
> manual will allow you to write to Flash in 256/512/1024/4096 byte blocks
> but you have to erase sectors on full sector sizes. This will definitely
> not match your FAT file system.
>
> Samuel wrote: >>I need to basically do relative addressing when logging or
>>calling the log file, any help will be appreciated > I'm not sure what you mean by "relative addressing"?
> If it is just logging data you need to do the easiest way is to just use
> reserve some sectors for logging and start using these without any
> difficult file system. You could either create a directory which tells
> you date/time/filename and the start position of the file in memory or
> define a structure that defines what the block is about and what its
> length is.
>
> Depending on the application and the amount of data I would opt for an
> MMC/SD card for logging. Log the data on your application and then just
> plug the SD card into a PC and a PC application will show your data.
> I am going to use this for logging data and updating software (on boot
> check for presence of SD card, check for new software and reprogram
> flash if needed)
>
> See also http://groups.yahoo.com/group/lpc2000/message/9293
>
> Regards,
>
> Rob
>
Correct! If you want to log data continously only, why you want to spent
a lot of time in implementing a file system? Just write your data
byte4byte to your flash and wrap around if it is full.
If there are other reasons for using a file system, a flash file system
like JFFS(2) could be better solution than FAT. Because it is balancing
write/erase cycles to your flash other than FAT. Just have look to the
Linux kernel (the greatest resource of open-source code in this world!).
Check the uClinux resources and mailing list for a good (bug-free)
implementation, too.
Regards,
Sten --
/************************************************
Do you need a tiny and efficient real time
operating system (RTOS) with a preemtive
multitasking for LPC2000 or AT91SAM7?
http://nanortos.net-attack.de/
Or some open-source tools and code for LPC2000?
http://www.net-attack.de/
************************************************/
Reply by ●October 10, 20052005-10-10
On Monday 10 October 2005 20:24, Sten wrote:
>
> Correct! If you want to log data continously only, why you want to spent
> a lot of time in implementing a file system? Just write your data
> byte4byte to your flash and wrap around if it is full.
Definitely concur on this point. Using a file system just to do some
append-only logging like using a chainsaw to cut butter.
> If there are other reasons for using a file system, a flash file system
> like JFFS(2) could be better solution than FAT.
Again, concur, JFFS(2) and other log structured fs are far less corruption
prone than FAT. However, these fs tend to need quite a bit of RAM for large
flash partitions.
> Because it is balancing
> write/erase cycles to your flash other than FAT.
Most FTLs (eg the Smartmedia one) will effect sufficient wear levelling to
make this a non-issue.
> Just have look to the
> Linux kernel (the greatest resource of open-source code in this world!).
> Check the uClinux resources and mailing list for a good (bug-free)
> implementation, too.
Be mindful of the GPL. This might limit what you can do with the code.
>
> Correct! If you want to log data continously only, why you want to spent
> a lot of time in implementing a file system? Just write your data
> byte4byte to your flash and wrap around if it is full.
Definitely concur on this point. Using a file system just to do some
append-only logging like using a chainsaw to cut butter.
> If there are other reasons for using a file system, a flash file system
> like JFFS(2) could be better solution than FAT.
Again, concur, JFFS(2) and other log structured fs are far less corruption
prone than FAT. However, these fs tend to need quite a bit of RAM for large
flash partitions.
> Because it is balancing
> write/erase cycles to your flash other than FAT.
Most FTLs (eg the Smartmedia one) will effect sufficient wear levelling to
make this a non-issue.
> Just have look to the
> Linux kernel (the greatest resource of open-source code in this world!).
> Check the uClinux resources and mailing list for a good (bug-free)
> implementation, too.
Be mindful of the GPL. This might limit what you can do with the code.
Reply by ●October 10, 20052005-10-10
Hi,
> > Correct! If you want to log data continously only, why you want to
> > spent a lot of time in implementing a file system? Just write your
> > data byte4byte to your flash and wrap around if it is full.
>
> Definitely concur on this point. Using a file system just to
> do some append-only logging like using a chainsaw to cut butter.
You can't write byte-by-byte to the LPC flash. IIRC, an ECC byte cannot
be changed without erasing the flash so you cannot over-program and
already-programmed word. Hence you must write in groups of four bytes
aligned to a word boundary. The other thing to say is that the IAP
routines write a minimum of 256 bytes to a 256-byte-aligned page, so to
synthesize word-wise writing you need a buffer of 256 bytes and a copy
of the previous flash contents for the page.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors
> > Correct! If you want to log data continously only, why you want to
> > spent a lot of time in implementing a file system? Just write your
> > data byte4byte to your flash and wrap around if it is full.
>
> Definitely concur on this point. Using a file system just to
> do some append-only logging like using a chainsaw to cut butter.
You can't write byte-by-byte to the LPC flash. IIRC, an ECC byte cannot
be changed without erasing the flash so you cannot over-program and
already-programmed word. Hence you must write in groups of four bytes
aligned to a word boundary. The other thing to say is that the IAP
routines write a minimum of 256 bytes to a 256-byte-aligned page, so to
synthesize word-wise writing you need a buffer of 256 bytes and a copy
of the previous flash contents for the page.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors
Reply by ●October 10, 20052005-10-10
--- In lpc2000@lpc2..., "Paul Curtis" <plc@r...> wrote:
>
> Hi,
>
> > > Correct! If you want to log data continously only, why you want
to
> > > spent a lot of time in implementing a file system? Just write
your
> > > data byte4byte to your flash and wrap around if it is full.
> >
> > Definitely concur on this point. Using a file system just to
> > do some append-only logging like using a chainsaw to cut butter.
>
> You can't write byte-by-byte to the LPC flash. IIRC, an ECC byte
cannot
> be changed without erasing the flash so you cannot over-program and
> already-programmed word. Hence you must write in groups of four
bytes
> aligned to a word boundary. The other thing to say is that the IAP
> routines write a minimum of 256 bytes to a 256-byte-aligned page, so
to
> synthesize word-wise writing you need a buffer of 256 bytes and a
copy
> of the previous flash contents for the page.
Yes, that is very true for the LPC flash. Indeed, I cound not get the
partial page programming to work reliably. Only full-page proigramming
works reliably in my experience anyway.
Still, putting a full fs on the LPC flash would be overkill for
sequential updates.
One thing to consider would be doing a very lightweight log structured
fs.
>
> Hi,
>
> > > Correct! If you want to log data continously only, why you want
to
> > > spent a lot of time in implementing a file system? Just write
your
> > > data byte4byte to your flash and wrap around if it is full.
> >
> > Definitely concur on this point. Using a file system just to
> > do some append-only logging like using a chainsaw to cut butter.
>
> You can't write byte-by-byte to the LPC flash. IIRC, an ECC byte
cannot
> be changed without erasing the flash so you cannot over-program and
> already-programmed word. Hence you must write in groups of four
bytes
> aligned to a word boundary. The other thing to say is that the IAP
> routines write a minimum of 256 bytes to a 256-byte-aligned page, so
to
> synthesize word-wise writing you need a buffer of 256 bytes and a
copy
> of the previous flash contents for the page.
Yes, that is very true for the LPC flash. Indeed, I cound not get the
partial page programming to work reliably. Only full-page proigramming
works reliably in my experience anyway.
Still, putting a full fs on the LPC flash would be overkill for
sequential updates.
One thing to consider would be doing a very lightweight log structured
fs.
