Prev: Router hardware
Next: Need suggestion for 'file system' in data logger project
From: kishor on 31 Mar 2010 05:01
Hi friends,

I am working on Data logger project, which stores data on micro-sd
card.
This data will then be uploaded to PC.

which is the best file system for this type of application?

I have "FatFS" sample code ported to luminary micro lm3s6965.
Is this is a good option???....

Thanks & regards,
Kishore.

From: D Yuniskis on 31 Mar 2010 13:28
Hi Kishore,

kishor wrote:
> Hi friends,
>
> I am working on Data logger project, which stores data on micro-sd
> card. This data will then be uploaded to PC.
>
> which is the best file system for this type of application?

Ask yourself: what functionality do I expect from the filesystem?
How will it interact with other aspects of the user's experience?
What value is it adding to the product?

I.e., *if* your "files" are going to be in human readable form,
then there could be a big advantage to presenting (and naming!)
them in a manner by which other *existing*, familiar tools
can be used to examine that data (e.g., NOTEPAD.EXE). OTOH,
if these "files" are going to contain binary data in some
application specific format that *requires* a utility that
*you* write/wrote to decode, then the advantage of a filesystem
may be illusory.

> I have "FatFS" sample code ported to luminary micro lm3s6965.
> Is this is a good option???....
From: kishor on 1 Apr 2010 05:21
Hi Yuniskis,

Yes, "data" will be in human readable (ascii) format.

I have readymeade "FatFS" option, ported to luminary micro lm3s6965.
This is "Fat" file system.

Should I go with this????

Kishore.
From: Peter Dickerson on 3 Apr 2010 01:50
"kishor" <kiishor(a)gmail.com> wrote in message
news:395ef1be-3699-4dcd-9381-f0b89a5cb0fb(a)x12g2000yqx.googlegroups.com...
> Hi Yuniskis,
>
> Yes, "data" will be in human readable (ascii) format.
>
> I have readymeade "FatFS" option, ported to luminary micro lm3s6965.
> This is "Fat" file system.
>
> Should I go with this????

You need to do some testing to ensure that it delivers the performance,
functionality and reliability you need. I have used FatFS successfully in an
environment which didn't require speed. I made quite a few changes, though,
to hook into what I had and optionally to use long file names. I found one
problem, though it was a long time ago, something like using a 16-bit
allocation unit number in one intermediate that broke FAT32 beyond
2^16*allocation units. One thing though. The innards are a real mess - lots
of magic byte offsets and the like.

Peter


From: Mark Borgerson on 3 Apr 2010 10:59
In article <hp6kv4$3p5$1(a)news.eternal-september.org>,
first.last(a)tiscali.invalid says...
> "kishor" <kiishor(a)gmail.com> wrote in message
> news:395ef1be-3699-4dcd-9381-f0b89a5cb0fb(a)x12g2000yqx.googlegroups.com...
> > Hi Yuniskis,
> >
> > Yes, "data" will be in human readable (ascii) format.
> >
> > I have readymeade "FatFS" option, ported to luminary micro lm3s6965.
> > This is "Fat" file system.
> >
> > Should I go with this????
>
> You need to do some testing to ensure that it delivers the performance,
> functionality and reliability you need. I have used FatFS successfully in an
> environment which didn't require speed. I made quite a few changes, though,
> to hook into what I had and optionally to use long file names. I found one
> problem, though it was a long time ago, something like using a 16-bit
> allocation unit number in one intermediate that broke FAT32 beyond
> 2^16*allocation units. One thing though. The innards are a real mess - lots
> of magic byte offsets and the like.
>
One other problem that I found with one FAT file system (I'm not sure
whether it was FatFS): As files got longer, the time to do a file
write got longer also. The problem was that the code would scan through
a lot of the FAT in order to allocate a new cluster when needed. When
a file got very large, that could mean reading many FAT sectors to find
a new cluster to add to the file. When files are often open, written,
and deleted, the empty clusters in the FAT can be anywhere in the
table, and you may need to scan a lot of the table to find
an empty cluster. There are ways around this. Some involve making
assumptions about single-threaded file access, only one open file,
or caching the FAT.

If you will be writing large files and deleting files on the disk,
I recommend you study the code that allocates a new cluster.


Mark Borgerson


 |  Next  |  Last
Pages: 1 2
Prev: Router hardware
Next: Need suggestion for 'file system' in data logger project