Lpc2000

I have posted about this before but now I am finally done with 
ALFAT. I used LPC2114 chip and programmed it with full FAT file 
system where you can send SPI or UART(serial) commands to it and it 
will save FAT files to many kinds of medias SD, MMC, CF and hard 
disks!

The development board can be used for other purposes as it has 
LPC2114, RS232 level converter, MMC/SD/CF connectors, and IDE header 
for your hard disk!

Thanks for your time,

Gus Issa
gissa@...

Hi Gus,

What are your plans for this? to sell the code royalty free or the
programmed IC as it seems to me a bad investment if you're selling the
programmed IC when a FAT can be purchased for a pack of beers :D

Regards
Lasse Madsen

-----Original Message-----
From: Gus [mailto:gus_is_working@...] 
Sent: 20. september 2004 19:49
To: lpc2000@yahoogroups.com
Subject: [lpc2000] FAT file system

I have posted about this before but now I am finally done with 
ALFAT. I used LPC2114 chip and programmed it with full FAT file 
system where you can send SPI or UART(serial) commands to it and it 
will save FAT files to many kinds of medias SD, MMC, CF and hard 
disks!

The development board can be used for other purposes as it has 
LPC2114, RS232 level converter, MMC/SD/CF connectors, and IDE header 
for your hard disk!

Thanks for your time,

Gus Issa
gissa@... 




 
Yahoo! Groups Links

implementing simple read file on FAT is not hard but when it comes
to having FAT12, FAT16 and FAT32 where you do read and write is not
a simple task. Anyway....the idea here is that you don't have to 
worry about file system stuff as ALFAT will do the job.

hmmmmmmm, pack of beer! as far as I know, FAT source code costs
$4,000 and up so if you know otherwize please send me a link to that
website

Gus

--- In lpc2000@yahoogroups.com, "Lasse Madsen" <lasse.madsen@e...> 
wrote:
> Hi Gus,
> 
> What are your plans for this? to sell the code royalty free or the
> programmed IC as it seems to me a bad investment if you're selling 
the
> programmed IC when a FAT can be purchased for a pack of beers :D
> 
> Regards
> Lasse Madsen
> 
> -----Original Message-----
> From: Gus [mailto:gus_is_working@y...] 
> Sent: 20. september 2004 19:49
> To: lpc2000@yahoogroups.com
> Subject: [lpc2000] FAT file system
> 
> I have posted about this before but now I am finally done with 
> ALFAT. I used LPC2114 chip and programmed it with full FAT file 
> system where you can send SPI or UART(serial) commands to it and 
it 
> will save FAT files to many kinds of medias SD, MMC, CF and hard 
> disks!
> 
> The development board can be used for other purposes as it has 
> LPC2114, RS232 level converter, MMC/SD/CF connectors, and IDE 
header 

> for your hard disk!
> 
> Thanks for your time,
> 
> Gus Issa
> gissa@g... 
> 
> 
> 
> 
>  
> Yahoo! Groups Links

Hi Gus and others...

 

Have a look at this from PRLLC
(http://www.prllc.com/prllc_homemainFlash.htm) it's a 139 USD (ok maybe
a little more than a pack of beer but certainly dirt cheap)

I've used it with both ARM and AVR with much success with will both read
and write FAT12 and FAT16

 

There really isn't any need for FAT 32 in an embedded application using
either AVR or LPC ARM I have never seen a place where it was necessary
to log over a GB of data.

FAT32 reading would be nice tough but then again even my brand new
Panasonic video camera doesn't support FAT-32 so why bother :-)

 

Gus I think you have a nice application but make your product a source
code solution and at a price like PRLLC (maybe a few hundred more if
it's really that great) because a lot of people my self included wont
purchase an IC solution where all you could settle with was in fact the
source code. I've been an embedded designer and programmer for more than
four years now and educated electronics mechanic of background the only
things I purchase (IC) is processor, RF integrated IC's and such things
that cant be made by one self.

 

I would think around 350$ was adequate for code like that but maybe you
cant sell it to that price and that's ok.

 

That's just my thought

 

Best regards and I hope you will make fortunes on your product :o) 

 

Lasse Madsen

-----Original Message-----
From: Gus [mailto:gus_is_working@...] 
Sent: 20. september 2004 20:01
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: FAT file system

implementing simple read file on FAT is not hard but when it comes
to having FAT12, FAT16 and FAT32 where you do read and write is not
a simple task. Anyway....the idea here is that you don't have to 
worry about file system stuff as ALFAT will do the job.

hmmmmmmm, pack of beer! as far as I know, FAT source code costs
$4,000 and up so if you know otherwize please send me a link to that
website

Gus

--- In lpc2000@yahoogroups.com, "Lasse Madsen" <lasse.madsen@e...> 
wrote:
> Hi Gus,
> 
> What are your plans for this? to sell the code royalty free or the
> programmed IC as it seems to me a bad investment if you're selling 
the
> programmed IC when a FAT can be purchased for a pack of beers :D
> 
> Regards
> Lasse Madsen
> 
> -----Original Message-----
> From: Gus [mailto:gus_is_working@y...] 
> Sent: 20. september 2004 19:49
> To: lpc2000@yahoogroups.com
> Subject: [lpc2000] FAT file system
> 
> I have posted about this before but now I am finally done with 
> ALFAT. I used LPC2114 chip and programmed it with full FAT file 
> system where you can send SPI or UART(serial) commands to it and 
it 
> will save FAT files to many kinds of medias SD, MMC, CF and hard 
> disks!
> 
> The development board can be used for other purposes as it has 
> LPC2114, RS232 level converter, MMC/SD/CF connectors, and IDE 
header 
> for your hard disk!
> 
> Thanks for your time,
> 
> Gus Issa
> gissa@g... 
> 
> 
> 
> 
>  
> Yahoo! Groups Links




 
Yahoo! Groups Links

At 10:08 PM 9/20/04 +0200, you wrote:
>Have a look at this from PRLLC
>(http://www.prllc.com/prllc_homemainFlash.htm) it's a 139 USD (ok maybe
>a little more than a pack of beer but certainly dirt cheap)

These guys may win a prize for obscure licensing.  It's not what they say, 
it's that they don't say anything (that I could find) about what you are 
actually purchasing a license to.  If it's a license for linking into your 
projects and distributing as many copies as you want it's certainly a good 
price.  If it's for a single embedded copy the toll could add up rather 
quickly.

Any idea what the license is?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Hi Robert

It's a once pay license... once you have paid for the software you are
free to use it.

/*
	Software License
	The use of Progressive Resources LLC FlashFile Source Package
indicates 
	your understanding and acceptance of the following terms and
conditions. 
	This license shall supersede any verbal or prior verbal or
written, statement 
	or agreement to the contrary. If you do not understand or accept
these terms, 
	or your local regulations prohibit "after sale" license
agreements or limited 
	disclaimers, you must cease and desist using this product
immediately.
	This product is C Copyright 2003 by Progressive Resources LLC,
all rights 
	reserved. International copyright laws, international treaties
and all other 
	applicable national or international laws protect this product.
This software 
	product and documentation may not, in whole or in part, be
copied, photocopied, 
	translated, or reduced to any electronic medium or machine
readable form, without 
	prior consent in writing, from Progressive Resources LLC and
according to all 
	applicable laws. The sole owner of this product is Progressive
Resources LLC.

	Operating License
	You have the non-exclusive right to use any enclosed product but
have no right 
	to distribute it as a source code product without the express
written permission 
	of Progressive Resources LLC. Use over a "local area network"
(within the same 
	locale) is permitted provided that only a single person, on a
single computer 
	uses the product at a time. Use over a "wide area network"
(outside the same 
	locale) is strictly prohibited under any and all circumstances.
                                           
	Liability Disclaimer
	This product and/or license is provided as is, without any
representation or 
	warranty of any kind, either express or implied, including
without limitation 
	any representations or endorsements regarding the use of, the
results of, or 
	performance of the product, Its appropriateness, accuracy,
reliability, or 
	correctness. The user and/or licensee assume the entire risk as
to the use of 
	this product. Progressive Resources LLC does not assume
liability for the use 
	of this product beyond the original purchase price of the
software. In no event 
	will Progressive Resources LLC be liable for additional direct
or indirect 
	damages including any lost profits, lost savings, or other
incidental or 
	consequential damages arising from any defects, or the use or
inability to 
	use these products, even if Progressive Resources LLC have been
advised of 
	the possibility of such damages.
*/

-----Original Message-----
From: Robert Adsett [mailto:subscriptions@...] 
Sent: 20. september 2004 23:18
To: lpc2000@yahoogroups.com
Subject: RE: [lpc2000] Re: FAT file system

At 10:08 PM 9/20/04 +0200, you wrote:
>Have a look at this from PRLLC
>(http://www.prllc.com/prllc_homemainFlash.htm) it's a 139 USD (ok maybe
>a little more than a pack of beer but certainly dirt cheap)

These guys may win a prize for obscure licensing.  It's not what they
say, 
it's that they don't say anything (that I could find) about what you are

actually purchasing a license to.  If it's a license for linking into
your 
projects and distributing as many copies as you want it's certainly a
good 
price.  If it's for a single embedded copy the toll could add up rather 
quickly.

Any idea what the license is?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III




 
Yahoo! Groups Links

Gus,
Is your dev board available?
Is the ALFAT software available?

I require compact flash read/write only (no need for fat32)

Please advise,
Kind Regards,

Peter

--- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote:
> I have posted about this before but now I am finally done with 
> ALFAT. I used LPC2114 chip and programmed it with full FAT file 
> system where you can send SPI or UART(serial) commands to it and 
it 
> will save FAT files to many kinds of medias SD, MMC, CF and hard 
> disks!
> 
> The development board can be used for other purposes as it has 
> LPC2114, RS232 level converter, MMC/SD/CF connectors, and IDE 
header 

> for your hard disk!
> 
> Thanks for your time,
> 
> Gus Issa
> gissa@g...

I have read parts of the thread on FAT file system, and feel some 
moral responsibility to raise a warning.

If you're using FAT as a method of storing/retrieving non-critical 
data, fine.

Sometimes you need to share data with Micriosft PCs and don't have 
much choice.

If, however, you're using FAT to store critical data (ie FAT fails, 
then system fails), be warned that FAT is terrible at this job and you 
should consider some other file system strategy.

According to http://www.datalight.com/product_detail.asp?
p_id=22&archive=0  up to 80% of product failures in devices using FAT 
can be blamed on FAT file system corruption. Of course they have 
something to sell, so one should treat their view with some suspicion. 
[Having written a log-structured file system, I disagree with most of 
the things they say about those too].
Still, I am aware of FAT causing significant problems for many 
systems.

IMHO use something other than FAT if you can.


-- Charles

Hi Charles

I've been working with FAT for a long time and it really isn't that
bad...
of cause there's a lot of ways to go bad (messing up allocation tables
etcetera) but Microsoft Scandisk (and others) can almost always save the
most damaged errors I've tried to make both on purpose and by accident
(bad code) and if you know how to handle the FAT you can use WinHex to
make a read out of the good portions... also there's a lot of counter
measures build into FAT for instance there's two (or more) allocation
tables so that if one of them goes bad the other one (which is
constantly updated) should be able to replace it with out user
intervention 

I personally think you won't have a problem with writing/reading to/from
FAT if you have a way of un mounting the file system before you remove
the media and have a Power fail circuit that detect under voltage on the
main supply and un mounts the FAT automatically ...  (been there done
that, and working on second year in real life :)

Best regards
Lasse Madsen

-----Original Message-----
From: embeddedjanitor [mailto:manningc2@...] 
Sent: 23. september 2004 22:17
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: FAT file system ==>warning

I have read parts of the thread on FAT file system, and feel some 
moral responsibility to raise a warning.

If you're using FAT as a method of storing/retrieving non-critical 
data, fine.

Sometimes you need to share data with Micriosft PCs and don't have 
much choice.

If, however, you're using FAT to store critical data (ie FAT fails, 
then system fails), be warned that FAT is terrible at this job and you 
should consider some other file system strategy.

According to http://www.datalight.com/product_detail.asp?
p_id=22&archive=0  up to 80% of product failures in devices using FAT 
can be blamed on FAT file system corruption. Of course they have 
something to sell, so one should treat their view with some suspicion. 
[Having written a log-structured file system, I disagree with most of 
the things they say about those too].
Still, I am aware of FAT causing significant problems for many 
systems.

IMHO use something other than FAT if you can.


-- Charles





 
Yahoo! Groups Links

On Fri, Sep 24, 2004 at 01:37:50AM +0200, Lasse Madsen wrote:

> make a read out of the good portions... also there's a lot of counter
> measures build into FAT for instance there's two (or more) allocation
> tables so that if one of them goes bad the other one (which is
> constantly updated) should be able to replace it with out user
> intervention 

As far as I remember M$ system software does not use the second table in
case of damage of the otner one. Only special software (e.g. norton disc
doctor) can use it to repair your fs (maybe scandisk or chkdsk also). You
really need user invention in case of failure in the first table.

        Matthias

Peter,

Yes, board and chips are available. Why you don't want FAT32? did 
you think that at some point in the future you will need a larger 
media that is FAT32?

Thanks,

Gus
--- In lpc2000@yahoogroups.com, "bty639886" <peter.brown@b...> wrote:

> Gus,
> Is your dev board available?
> Is the ALFAT software available?
> 
> I require compact flash read/write only (no need for fat32)
> 
> Please advise,
> Kind Regards,
> 
> Peter
> 
> --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote:
> > I have posted about this before but now I am finally done with 
> > ALFAT. I used LPC2114 chip and programmed it with full FAT file 
> > system where you can send SPI or UART(serial) commands to it and 
> it 
> > will save FAT files to many kinds of medias SD, MMC, CF and hard 
> > disks!
> > 
> > The development board can be used for other purposes as it has 
> > LPC2114, RS232 level converter, MMC/SD/CF connectors, and IDE 
> header 
> > for your hard disk!
> > 
> > Thanks for your time,
> > 
> > Gus Issa
> > gissa@g...

Hi,

ALFAT chip does save both FAT tables (if media is formatted with 2 
tables) so if one got corrupted the second will be fine. I can't see 
how FAT can be a problem! If you lose power on ANY file system you 
will lose data. Simply close all open file handles and no data would 
be lost.

Thanks,

Gus
--- In lpc2000@yahoogroups.com, Matthias Weingart <lpc2000@p...> 
wrote:
> On Fri, Sep 24, 2004 at 01:37:50AM +0200, Lasse Madsen wrote:
> 
> > make a read out of the good portions... also there's a lot of 
counter
> > measures build into FAT for instance there's two (or more) 
allocation
> > tables so that if one of them goes bad the other one (which is
> > constantly updated) should be able to replace it with out user
> > intervention 
> 
> As far as I remember M$ system software does not use the second 
table in
> case of damage of the otner one. Only special software (e.g. 
norton disc
> doctor) can use it to repair your fs (maybe scandisk or chkdsk 
also). You

> really need user invention in case of failure in the first table.
> 
>         Matthias

Gus wrote:
> Hi,
> 
> ALFAT chip does save both FAT tables (if media is formatted with 2 
> tables) so if one got corrupted the second will be fine. I can't see 
> how FAT can be a problem! If you lose power on ANY file system you 
> will lose data. Simply close all open file handles and no data would 
> be lost.

There are file system layouts that avoid that problem - transactional 
ones, for example, tend to have a commit operation. If the power fails 
before you commit, or during the commit, then when it comes back up the 
filesystem is untouched - it was as it was at the end of the last 
successful commit. Changes made since that commit are lost, yes, but 
they weren't comitted, so the filesystem has not yet "promised" their 
safekeeping, and the existing data is never mangled due to filesystem 
inconsistency caused by the power failure.

Log-structured and journalling filesystems have this property - and log 
structured file systems can be good for FLASH memory, too, since they 
tend to spread writes out evenly!

However, they're not as widely supported as FAT, by any stretch of the 
imagination. So good for local storage only, rather than interchange, in 
general.

ABS

-- 
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/categories/alaric/

Hi,

Maybe it would be better for the file system structures but the data 
that was about to go on the media when the power failure happened is 
lost!
The idea of ALFAT chip is that you can EASILY share data between 
systems and your PC and the only choice is FAT as it is supported by 
almost any OS

Thanks,

Gus

--- In lpc2000@yahoogroups.com, Alaric Snell-Pym <alaric@s...> wrote:
> Gus wrote:
> > Hi,
> > 
> > ALFAT chip does save both FAT tables (if media is formatted with 
2 
> > tables) so if one got corrupted the second will be fine. I can't 
see 
> > how FAT can be a problem! If you lose power on ANY file system 
you 
> > will lose data. Simply close all open file handles and no data 
would 
> > be lost.
> 
> There are file system layouts that avoid that problem - 
transactional 
> ones, for example, tend to have a commit operation. If the power 
fails 
> before you commit, or during the commit, then when it comes back 
up the 
> filesystem is untouched - it was as it was at the end of the last 
> successful commit. Changes made since that commit are lost, yes, 
but 
> they weren't comitted, so the filesystem has not yet "promised" 
their 
> safekeeping, and the existing data is never mangled due to 
filesystem 
> inconsistency caused by the power failure.
> 
> Log-structured and journalling filesystems have this property - 
and log 
> structured file systems can be good for FLASH memory, too, since 
they 
> tend to spread writes out evenly!
> 
> However, they're not as widely supported as FAT, by any stretch of 
the 
> imagination. So good for local storage only, rather than 
interchange, in 

> general.
> 
> ABS
> 
> -- 
> Alaric Snell-Pym
> Work: http://www.snell-systems.co.uk/
> Play: http://www.snell-pym.org.uk/alaric/
> Blog: http://www.snell-pym.org.uk/categories/alaric/

Gus wrote:
> Hi,
> 
> Maybe it would be better for the file system structures but the data 
> that was about to go on the media when the power failure happened is 
> lost!

It applies for both - whenever the system comes up, the filesystem state 
(data and structures) is at it was when the last successful commit() 
call completed. Anything you write before a commit() may be lost unless 
you commit() it. If efficiency isn't such a problem, you can do a 
commit() after every write. Sure, if power fails during or before the 
commit you may lose stuff, but what you gain over systems like FAT is 
that you don't run the risk of a power failure during write causing the 
existing data that was being overwritten from being lost - you don't 
need all this "backup FAT" stuff to repair broken filesystems.

The techniques used for this are quite fascinating - I've done some work 
on them myself. To cut a long story short, if you can organise the 
entire filesystem as a tree of blocks, with each block containing some 
mix of data and pointers to child blocks and its parent block (eg, a 
B-Tree, or something like that) you can handle updates by just writing 
new copies of the modified data blocks. This means that the address of 
the most recent versions of those blocks has changed, so you need to 
also "modify" the parent blocks by writing newly updated copies of them 
out, too, all the way up the tree until you finally get a new root pointer.

Now, the current root pointer is stored TWICE on the filesystem, once at 
each end or similar. Update one, then the other. Your commit has now 
finished.

When the system starts up, read the root pointer from both copies; if 
they differ, the system died between updating the two, so use the one 
with the highest timestamp. If they don't differ, then that's your root.

Voila!

Now all you need is a way of managing free space that clears up all 
those blocks that have been superseded by more recent copies - that's 
where the fun part is.

There are other techniques, too, like journalling.

> The idea of ALFAT chip is that you can EASILY share data between 
> systems and your PC and the only choice is FAT as it is supported by 
> almost any OS

Quite, I wouldn't argue with that. There's nothing quite as universal as 
FAT! Apart from death and taxes... :-) Strange file system structures 
may be very nice, but they're still not widely deployed at all... 
despite the foundations of them dating back to about the 60s or so! But 
I'm not attacking your choice of FAT for interoperability, not one bit, 
and sorry if it seemed otherwise!

> 
> Thanks,
> 
> Gus
> 

ABS

-- 
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/categories/alaric/

Hi Gus
Actually having fat32 is OK, its just that for our particular 
embedded application we will NEVER exceed something like 100Mbyte. 
If my understanding is correct then fat16 can handle this ok.
We also do not need to support long filenames as this is an embedded 
product.
The only time we need to interface to the PC is when we upload the 
data onto the flash card at production, or during inservice product 
upgrades.

If you could point me to a website or similar for info on the system 
you have then that would be great.

We will be starting to lay out PCB out shortly for the main 
controller and as such we may not need to get the board you have - 
so is just the source code available to purchase for fat file system 
and interface to a compact flash card?

thanks for your help,
rgds
pete


--- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote:
> Peter,
> 
> Yes, board and chips are available. Why you don't want FAT32? did 
> you think that at some point in the future you will need a larger 
> media that is FAT32?
> 
> Thanks,
> 
> Gus
> --- In lpc2000@yahoogroups.com, "bty639886" <peter.brown@b...> 
wrote:
> > Gus,
> > Is your dev board available?
> > Is the ALFAT software available?
> > 
> > I require compact flash read/write only (no need for fat32)
> > 
> > Please advise,
> > Kind Regards,
> > 
> > Peter
> > 
> > --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> 
wrote:
> > > I have posted about this before but now I am finally done with 
> > > ALFAT. I used LPC2114 chip and programmed it with full FAT 
file 
> > > system where you can send SPI or UART(serial) commands to it 
and 
> > it 
> > > will save FAT files to many kinds of medias SD, MMC, CF and 
hard 

> > > disks!
> > > 
> > > The development board can be used for other purposes as it has 
> > > LPC2114, RS232 level converter, MMC/SD/CF connectors, and IDE 
> > header 
> > > for your hard disk!
> > > 
> > > Thanks for your time,
> > > 
> > > Gus Issa
> > > gissa@g...

That is funny! I never posted the website :-)
www.ghielectronics.com

By the way ALFAT is doing 70KB/S now! We also added 256 FIFO to UART 
and SPI


--- In lpc2000@yahoogroups.com, "Pete" <peterbrown_abroad@y...> 
wrote:
> Hi Gus
> Actually having fat32 is OK, its just that for our particular 
> embedded application we will NEVER exceed something like 100Mbyte. 
> If my understanding is correct then fat16 can handle this ok.
> We also do not need to support long filenames as this is an 
embedded 
> product.
> The only time we need to interface to the PC is when we upload the 
> data onto the flash card at production, or during inservice 
product 
> upgrades.
> 
> If you could point me to a website or similar for info on the 
system 
> you have then that would be great.
> 
> We will be starting to lay out PCB out shortly for the main 
> controller and as such we may not need to get the board you have - 
> so is just the source code available to purchase for fat file 
system 
> and interface to a compact flash card?
> 
> thanks for your help,
> rgds
> pete
> 
> 
> --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote:
> > Peter,
> > 
> > Yes, board and chips are available. Why you don't want FAT32? 
did 
> > you think that at some point in the future you will need a 
larger 
> > media that is FAT32?
> > 
> > Thanks,
> > 
> > Gus
> > --- In lpc2000@yahoogroups.com, "bty639886" <peter.brown@b...> 
> wrote:
> > > Gus,
> > > Is your dev board available?
> > > Is the ALFAT software available?
> > > 
> > > I require compact flash read/write only (no need for fat32)
> > > 
> > > Please advise,
> > > Kind Regards,
> > > 
> > > Peter
> > > 
> > > --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> 
> wrote:
> > > > I have posted about this before but now I am finally done 
with 
> > > > ALFAT. I used LPC2114 chip and programmed it with full FAT 
> file 
> > > > system where you can send SPI or UART(serial) commands to it 
> and 
> > > it 
> > > > will save FAT files to many kinds of medias SD, MMC, CF and 
> hard 
> > > > disks!
> > > > 
> > > > The development board can be used for other purposes as it 
has 
> > > > LPC2114, RS232 level converter, MMC/SD/CF connectors, and 
IDE 

> > > header 
> > > > for your hard disk!
> > > > 
> > > > Thanks for your time,
> > > > 
> > > > Gus Issa
> > > > gissa@g...

Hi Gus

Does your file system write a packet at a time (512 bytes) or do you
write along the way for instance 

For ( x = 0 ; x < 1024 ; x++ )
fputchar('U');

You claim 70KB/s on your system but how is this measured according to
the above example ... will the file system save a packet when x = 512 or
save along the way (x=1,x=2,x=3..) if you write a packet at a time I
would say its difficult to determine the actual speed as you will have a
"stall" time when writing the packet and a buffer overflow could occur
while writing the packet if you catch my draft ? 

Regards
Lasse Madsen

-----Original Message-----
From: Gus [mailto:gus_is_working@...] 
Sent: 27. september 2004 18:35
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: FAT file system

That is funny! I never posted the website :-)
www.ghielectronics.com

By the way ALFAT is doing 70KB/S now! We also added 256 FIFO to UART 
and SPI


--- In lpc2000@yahoogroups.com, "Pete" <peterbrown_abroad@y...> 
wrote:
> Hi Gus
> Actually having fat32 is OK, its just that for our particular 
> embedded application we will NEVER exceed something like 100Mbyte. 
> If my understanding is correct then fat16 can handle this ok.
> We also do not need to support long filenames as this is an 
embedded 
> product.
> The only time we need to interface to the PC is when we upload the 
> data onto the flash card at production, or during inservice 
product 
> upgrades.
> 
> If you could point me to a website or similar for info on the 
system 
> you have then that would be great.
> 
> We will be starting to lay out PCB out shortly for the main 
> controller and as such we may not need to get the board you have - 
> so is just the source code available to purchase for fat file 
system 
> and interface to a compact flash card?
> 
> thanks for your help,
> rgds
> pete
> 
> 
> --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote:
> > Peter,
> > 
> > Yes, board and chips are available. Why you don't want FAT32? 
did 
> > you think that at some point in the future you will need a 
larger 
> > media that is FAT32?
> > 
> > Thanks,
> > 
> > Gus
> > --- In lpc2000@yahoogroups.com, "bty639886" <peter.brown@b...> 
> wrote:
> > > Gus,
> > > Is your dev board available?
> > > Is the ALFAT software available?
> > > 
> > > I require compact flash read/write only (no need for fat32)
> > > 
> > > Please advise,
> > > Kind Regards,
> > > 
> > > Peter
> > > 
> > > --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> 
> wrote:
> > > > I have posted about this before but now I am finally done 
with 
> > > > ALFAT. I used LPC2114 chip and programmed it with full FAT 
> file 
> > > > system where you can send SPI or UART(serial) commands to it 
> and 
> > > it 
> > > > will save FAT files to many kinds of medias SD, MMC, CF and 
> hard 
> > > > disks!
> > > > 
> > > > The development board can be used for other purposes as it 
has 
> > > > LPC2114, RS232 level converter, MMC/SD/CF connectors, and 
IDE 
> > > header 
> > > > for your hard disk!
> > > > 
> > > > Thanks for your time,
> > > > 
> > > > Gus Issa
> > > > gissa@g...




 
Yahoo! Groups Links

Hello,

The system has a lot of buffering going on for the file system work. 
Old firmware did write every time you call fputchar() This makes the 
system better in case of power loss but it was very slow, about 
5KB/S. Then we decided to change that. Now, ALFAT buffers the data 
and only writes when a full sector is full. The disadvantage is that 
you have to close the files before you shut down the system or you 
have to flush the data every few milliseconds ( this will be 
automatic in future)

There is no stall time because we have 256-byte buffer for UART and 
SPI so even if ALFAT is saving a sector it will still keep your 
commands and data in FIFO till it is ready. Now 70KB/S is when a 
media is not fragmented a lot and for a media that is still fairly 
new. FLASH seems to slow down after a long use. But if you are 
looking into 50K then that should be no problem at all.

All the best,

Gus
www.ghielectronics.com

--- In lpc2000@yahoogroups.com, "Lasse Madsen" <lasse.madsen@e...> 
wrote:
> Hi Gus
> 
> Does your file system write a packet at a time (512 bytes) or do 
you
> write along the way for instance 
> 
> For ( x = 0 ; x < 1024 ; x++ )
> fputchar('U');
> 
> You claim 70KB/s on your system but how is this measured according 
to
> the above example ... will the file system save a packet when x = 
512 or
> save along the way (x=1,x=2,x=3..) if you write a packet at a time 
I
> would say its difficult to determine the actual speed as you will 
have a
> "stall" time when writing the packet and a buffer overflow could 
occur
> while writing the packet if you catch my draft ? 
> 
> Regards
> Lasse Madsen
> 
> 
> 
> 
> -----Original Message-----
> From: Gus [mailto:gus_is_working@y...] 
> Sent: 27. september 2004 18:35
> To: lpc2000@yahoogroups.com
> Subject: [lpc2000] Re: FAT file system
> 
> That is funny! I never posted the website :-)
> www.ghielectronics.com
> 
> By the way ALFAT is doing 70KB/S now! We also added 256 FIFO to 
UART 
> and SPI
> 
> 
> --- In lpc2000@yahoogroups.com, "Pete" <peterbrown_abroad@y...> 
> wrote:
> > Hi Gus
> > Actually having fat32 is OK, its just that for our particular 
> > embedded application we will NEVER exceed something like 
100Mbyte. 
> > If my understanding is correct then fat16 can handle this ok.
> > We also do not need to support long filenames as this is an 
> embedded 
> > product.
> > The only time we need to interface to the PC is when we upload 
the 
> > data onto the flash card at production, or during inservice 
> product 
> > upgrades.
> > 
> > If you could point me to a website or similar for info on the 
> system 
> > you have then that would be great.
> > 
> > We will be starting to lay out PCB out shortly for the main 
> > controller and as such we may not need to get the board you 
have - 
> > so is just the source code available to purchase for fat file 
> system 
> > and interface to a compact flash card?
> > 
> > thanks for your help,
> > rgds
> > pete
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> 
wrote:
> > > Peter,
> > > 
> > > Yes, board and chips are available. Why you don't want FAT32? 
> did 
> > > you think that at some point in the future you will need a 
> larger 
> > > media that is FAT32?
> > > 
> > > Thanks,
> > > 
> > > Gus
> > > --- In lpc2000@yahoogroups.com, "bty639886" <peter.brown@b...> 
> > wrote:
> > > > Gus,
> > > > Is your dev board available?
> > > > Is the ALFAT software available?
> > > > 
> > > > I require compact flash read/write only (no need for fat32)
> > > > 
> > > > Please advise,
> > > > Kind Regards,
> > > > 
> > > > Peter
> > > > 
> > > > --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> 
> > wrote:
> > > > > I have posted about this before but now I am finally done 
> with 
> > > > > ALFAT. I used LPC2114 chip and programmed it with full FAT 
> > file 
> > > > > system where you can send SPI or UART(serial) commands to 
it 
> > and 
> > > > it 
> > > > > will save FAT files to many kinds of medias SD, MMC, CF 
and 

> > hard 
> > > > > disks!
> > > > > 
> > > > > The development board can be used for other purposes as it 
> has 
> > > > > LPC2114, RS232 level converter, MMC/SD/CF connectors, and 
> IDE 
> > > > header 
> > > > > for your hard disk!
> > > > > 
> > > > > Thanks for your time,
> > > > > 
> > > > > Gus Issa
> > > > > gissa@g...
> 
> 
> 
> 
>  
> Yahoo! Groups Links