Yahoo Groups archive
Thread
2005-10-10 by SR
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
2005-10-10 by wmwiese
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
2005-10-10 by donhamilton2002
--- In lpc2000@yahoogroups.com, "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
2005-10-10 by douglasbolton
--- In lpc2000@yahoogroups.com, "donhamilton2002" <hamilton@d...> wrote: > > --- In lpc2000@yahoogroups.com, "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
2005-10-10 by wmwiese
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@...m, "donhamilton2002" <hamilton@d...> wrote:
> > --- In lpc2000@yahoogroups.com, "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 >
2005-10-10 by Rob Jansen
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,
Rob2005-10-10 by Sten
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/ ************************************************/
2005-10-11 by Charles Manning
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.
2005-10-11 by Paul Curtis
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
2005-10-11 by embeddedjanitor
--- In lpc2000@yahoogroups.com, "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.
2005-10-11 by Samuel
Basically I need to use it to send stuff out from the LPC2294 board to a terminal after logging is done, is the JFFS2 file compatible with that we use in windows, (sorry for my ignorance) Samuel --- Charles Manning <manningc2@...> wrote: > 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. > > > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
2005-10-11 by Charles Manning
On Tuesday 11 October 2005 14:20, Samuel wrote: > Basically I need to use it to send stuff out from the > LPC2294 board to a terminal after logging is done, is > the JFFS2 file compatible with that we use in windows, > (sorry for my ignorance) There are two ways I can think of doing this: 1) USB Mass Storage model: Data gets saved in a file on the device. At some stage, the device gets hooked up to a PC via USB Mass Storage interface (like a USB disk) and the data can be read off. For this to work, you really need to use FAT because the PC has to understand the file system layout. 2) Device transfers data via a serial pipe or equivalent download mechanism. The device can store the data in any format (the PC does not care) and at some stage it is connected to the PC, the data is dumped, and the file si purged. For this model you can store the data in any form. JFFS2 will work for the second scenario. However integrating JFFS2 is quite hard because it expects Linux or eCOS.
2005-10-11 by Sten
Paul Curtis 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. > Due to the small sector sizes of LPC flashes it would be a good compromise to simply erase a whole sector, write to this sector block-by-block (not byte-by-byte :-) until this is sector is full. It is possible to programm a block more than once if you keep in mind that bits can only be erased. So you can modify a block byte-by-byte continiously. If you implement a methode "read sector to RAM, modify sector in RAM, erase sector in ROM, programm sector from RAM to ROM" than you still have a base implementation of a flash file system. 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/ ************************************************/
2005-10-11 by Sten
Charles Manning wrote: > On Tuesday 11 October 2005 14:20, Samuel wrote: > >>Basically I need to use it to send stuff out from the >>LPC2294 board to a terminal after logging is done, is >>the JFFS2 file compatible with that we use in windows, >>(sorry for my ignorance) > > > There are two ways I can think of doing this: > 1) USB Mass Storage model: Data gets saved in a file on the device. At some > stage, the device gets hooked up to a PC via USB Mass Storage interface (like > a USB disk) and the data can be read off. > > For this to work, you really need to use FAT because the PC has to understand > the file system layout. > > 2) Device transfers data via a serial pipe or equivalent download mechanism. > The device can store the data in any format (the PC does not care) and at > some stage it is connected to the PC, the data is dumped, and the file si > purged. > > For this model you can store the data in any form. > > JFFS2 will work for the second scenario. However integrating JFFS2 is quite > hard because it expects Linux or eCOS. > Hello, how is your data transfered to your PC? If your PC depends on visible FS on your device (e.g. your device acts as USB mass storage device) you also can emulate a FS with exactly one file on it. Your log data is written block-by-block and the PC side read the "file" transparently through "virtual FAT file system". If you upload your data via serial line or something else a FS is definitely not needed. 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/ ************************************************/
2005-10-11 by Samuel
I will be recieving the File via Xmodem on the PC, any help on how I can implement a virtual filesystem? --- Sten <list@...> wrote: > Charles Manning wrote: > > On Tuesday 11 October 2005 14:20, Samuel wrote: > > > >>Basically I need to use it to send stuff out from > the > >>LPC2294 board to a terminal after logging is done, > is > >>the JFFS2 file compatible with that we use in > windows, > >>(sorry for my ignorance) > > > > > > There are two ways I can think of doing this: > > 1) USB Mass Storage model: Data gets saved in a > file on the device. At some > > stage, the device gets hooked up to a PC via USB > Mass Storage interface (like > > a USB disk) and the data can be read off. > > > > For this to work, you really need to use FAT > because the PC has to understand > > the file system layout. > > > > 2) Device transfers data via a serial pipe or > equivalent download mechanism. > > The device can store the data in any format (the > PC does not care) and at > > some stage it is connected to the PC, the data is > dumped, and the file si > > purged. > > > > For this model you can store the data in any form. > > > > JFFS2 will work for the second scenario. However > integrating JFFS2 is quite > > hard because it expects Linux or eCOS. > > > > Hello, > > how is your data transfered to your PC? If your PC > depends on visible FS > on your device (e.g. your device acts as USB mass > storage device) you > also can emulate a FS with exactly one file on it. > Your log data is > written block-by-block and the PC side read the > "file" transparently > through "virtual FAT file system". > If you upload your data via serial line or something > else a FS is > definitely not needed. > > 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/ > > ************************************************/ > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
2005-10-11 by bdmlpc
If you receive it through a serial communication via Xmodem you do not need a FS. Just send your log data within Xmodem protocol to your PC where your PC application stores this data into a file. It is simple! Sten --- In lpc2000@yahoogroups.com, Samuel <emddjava@y...> wrote:
> > I will be recieving the File via Xmodem on the PC, any > help on how I can implement a virtual filesystem? > > --- Sten <list@n...> wrote: > > > Charles Manning wrote: > > > On Tuesday 11 October 2005 14:20, Samuel wrote: > > > > > >>Basically I need to use it to send stuff out from > > the > > >>LPC2294 board to a terminal after logging is done, > > is > > >>the JFFS2 file compatible with that we use in > > windows, > > >>(sorry for my ignorance) > > > > > > > > > There are two ways I can think of doing this: > > > 1) USB Mass Storage model: Data gets saved in a > > file on the device. At some > > > stage, the device gets hooked up to a PC via USB > > Mass Storage interface (like > > > a USB disk) and the data can be read off. > > > > > > For this to work, you really need to use FAT > > because the PC has to understand > > > the file system layout. > > > > > > 2) Device transfers data via a serial pipe or > > equivalent download mechanism. > > > The device can store the data in any format (the > > PC does not care) and at > > > some stage it is connected to the PC, the data is > > dumped, and the file si > > > purged. > > > > > > For this model you can store the data in any form. > > > > > > JFFS2 will work for the second scenario. However > > integrating JFFS2 is quite > > > hard because it expects Linux or eCOS. > > > > > > > Hello, > > > > how is your data transfered to your PC? If your PC > > depends on visible FS > > on your device (e.g. your device acts as USB mass > > storage device) you > > also can emulate a FS with exactly one file on it. > > Your log data is > > written block-by-block and the PC side read the > > "file" transparently > > through "virtual FAT file system". > > If you upload your data via serial line or something > > else a FS is > > definitely not needed. > > > > 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/ > > > > ************************************************/ > > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com >
2005-10-11 by Charles Manning
On Tuesday 11 October 2005 22:37, Samuel wrote: > I will be recieving the File via Xmodem on the PC, any > help on how I can implement a virtual filesystem? If you are using XModem then you can use any soft of file system or Linear File Store (LFS). Look at http://www.cs.tau.ac.il/~stoledo/pubs.html for some interesting ideas on flash storage. Here is what I would do: A tiny log structured file system. This is a well-proven mechanism that I used for YAFFS etc. -- Charles