Searching \ for '[EE] Interfacing a PIC to a microSD or TransFlash' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/memory.htm?key=flash
Search entire site for: 'Interfacing a PIC to a microSD or TransFlash'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Interfacing a PIC to a microSD or TransFlash '
2006\11\09@170427 by Herbert Graf

flavicon
face
On Thu, 2006-11-09 at 15:12 +0100, Peter Bindels wrote:
> Hello,
>
> On 07/11/06, Herbert Graf <spam_OUTmailinglist3TakeThisOuTspamfarcite.net> wrote:
> > Win2k/XP will not allow
> > you to create a FAT32 partition bigger then 32GB. There is NO technical
> > reason for this, it's simply MS shoving NTFS down our throats. The
> > interesting bit is if you create a FAT32 partition bigger then 32GB with
> > another tool, both 2K and XP will have ZERO problem using it!
>
> There are technical reasons they should strongly disrecommend FAT. But

Strongly? FAT32 has it's problems, but in the consumer space it's
perfectly fine. The ONLY noticeable problem I can think of is the max
file size limit is "only" 2GB (technically 4GB but most FAT32 routines
are limited to 2GB). The only reason this has become an issue recently
is because of DVD images. For most people it's a non issue since most
tools will automatically by default split big images into <2GB chunks.

Even on a system WITH NTFS I've had problems with some software not
being able to handle 2GB+ files, so the limit is often in more then just
the file system.

Some people report alot of stability problems with FAT32, but I've never
had an issue.

> > Ahh, the beauty of alternate OS's...
>
> The alternate OSes that allow you to choose between dozens of file
> systems without any document on their relative merits might be worse,
> depending on the time and experience you want to expend on it.

Why? We are talking about the consumer space. It's a space where a file
system choice rarely presents any problems to the user.

> Windows
> may only have two choices, but that does make the choice pretty
> trivial. Are you talking "alternative" as in "not windows" or as in
> "not with a million-plus user base" ?

Not windows. In my mind I think mostly MacOS and Linux, both excellent
choices and LIGHT YEARS better then Windows. Other OSs are also good.

As an aside, I've yet again been tremendously annoyed by Mickeysoft.
Just got the latest update for my Xbox360. It promised "streaming video
support from a WindowsXP machine running WMP11". GREAT, I thought.

So, I installed WMP11 on my only windows machine in the home, connected
my X360 and everything looked great, pictures worked, music worked. Then
I tried videos. Even though I had about 40 videos in the "library", none
showed up on the X360. Tried a bunch of things. On a hunch, I downloaded
one of the WMV format HDTV demos files from Mickeysoft's website. The
X360 now showed ONE video, that wmv file. It looks like it ONLY supports
WMV files, great if that's what you've got, BAD if you don't have a
SINGLE video in that format (all the videos I have are either MPG from
my camera, or re-encoded as Xvid). Guess I'll stick with my $70 Divx
capable media player.

I understand Mickeysoft wants to be more like Sony, but this is NOT the
way to go IMHO. They've turned a potentially wonderful feature into a
useless waste of time and space.

Makes me even happier I didn't actually pay for my X360, because if I
had I would be much more ticked. Just wanted to give a heads up to
others out there.

Sorry for the rant. TTYL

2006\11\10@060051 by Peter Bindels

picon face
On 09/11/06, Herbert Graf <.....mailinglist3KILLspamspam@spam@farcite.net> wrote:
> On Thu, 2006-11-09 at 15:12 +0100, Peter Bindels wrote:
> > There are technical reasons they should strongly disrecommend FAT. But
>
> Strongly? FAT32 has it's problems, but in the consumer space it's
> perfectly fine. The ONLY noticeable problem I can think of is the max
> file size limit is "only" 2GB (technically 4GB but most FAT32 routines
> are limited to 2GB). The only reason this has become an issue recently
> is because of DVD images. For most people it's a non issue since most
> tools will automatically by default split big images into <2GB chunks.
>
> Even on a system WITH NTFS I've had problems with some software not
> being able to handle 2GB+ files, so the limit is often in more then just
> the file system.
>
> Some people report alot of stability problems with FAT32, but I've never
> had an issue.

Seeks on a FAT32 disk are, if you cache the entire FAT table, linear
in time depending on the file position. The file system has no support
for avoiding fragmentation and thereby requires defragmentation. Using
a FAT disk in memory only for a 250GB disk (pretty common today) with
4K clusters would take 250MB of memory just for the FAT table,
ignoring that you might need to update the second FAT table as well.
Updating the file system is highly nontrivial to get right and if
interrupted, commonly results in parts being lost, disk space being
lost or the entire file system ending up in a state of limbo, that is
not discovered until everything goes down by it. The file system
structures are outdated, even by 1980's technology, are dog slow,
assume failures are spread-out, have a lot of single points of failure
(boot sector, a single sector in the FAT failing, bootup code that's
not dynamic), and to top it all off, it supports Unicode and afaik
also combining unicode sequences, so if somebody adds two files, one
with an i in the name one with a Turkish i (without dot) and a
combiner that puts a dot on it, you get two files with the exact same
name that coexist. Not to mention that you can't find the second file,
you can't create directories of certain arbitrary names, you can't
rename files to lower-case in Windows since it thinks you didn't
change the name, and you can get into trouble if it somehow screws up
anyway. I've had a directory with a backslash in the name. Can't
delete it in any way I've tried. And for a nice flavor, you can't even
support it without patent trouble.

That's a five-minute summary of my recent trouble with it. NTFS fixes
a lot of these problems introducing other problems.

> Why? We are talking about the consumer space. It's a space where a file
> system choice rarely presents any problems to the user.

Consumer space chooses NTFS because windows tells you to, HFS because
MacOS tells you to (not sure on this one), Ext3 or Reiser because your
Linux distro tells you to and ignore the rest. They're not the best
choices, however, as people will learn later on, but they won't be
able to tell why the rest could be better.

{Quote hidden}

Risking a mark of [OT], Microsoft wants you to conform to everything
they have, so you'll spend more money on their products to keep using
what you've made yourself. It's a business model. Sony just tries to
keep both halves of the market (consumers and suppliers) equally
supported and tries to keep everything under covers that the other
half doesn't like. They sell CD burners and copy protection schemes,
support DAE and rootkits to prevent you from using it.

Regards,
Peter

2006\11\10@065048 by Tamas Rudnai

face picon face
> Even on a system WITH NTFS I've had problems with some software not
> being able to handle 2GB+ files, so the limit is often in more then just
> the file system.

Wait a minute! Those softwares nothing to do with the underlaying filesystem
drivers. The programmers of those just refused to use 64 bit file pointers,
so that when you use normal fseek/fread/fwrite etc commands or the Windows
API equivalents for these you are not able to address more than the 31bit
can do (the 31. bit is the sign bit...).

Tamas


On 11/9/06, Herbert Graf <mailinglist3spamKILLspamfarcite.net> wrote:
{Quote hidden}

> -

2006\11\10@072006 by Tamas Rudnai

face picon face
> Seeks on a FAT32 disk are, if you cache the entire FAT table, linear
> in time depending on the file position.

..all depends on how smart is your filesystem driver. I will not argue on
specific ones, however, wrote several FAT or FAT-like filesystem drivers and
can tell you that you can do lots of speed enforcements so you will not able
to tell by the speed that a particular file is stored on an NTFS or FAT.

> The file system has no support
> for avoiding fragmentation and thereby requires defragmentation.

again, depends on the driver, but do not forget that FAT was designed as
simple as possible, so nobody wanted to write a driver that took care of
fragmentation. Today in a digital camera for example you could rely on three
things:

1. you take lots of pictures with the same settings which needs almost the
same size of each, so when you delete one picture you can store the next one
to the same place.

2. you delete all files from time to time from your media, so the entire
system will be unoccupied so the new entries will be placed in unfragmented
areas

3. you will not update files too often as there is no database or the like
so you do not need to insert new records or append to the same file from
time to time.

So why would you use other filesystem? You do not need journaling, you do
not need volume management, you do not need ACL or anything like that. You
just need to store the pictures / music files statically and use them as it
is.

On a PC or a Mainframe I agree that you need something more sophisticated
but basically the binary structure of a filesystem is nothing if the driver
does not use it right. My problem with the NTFS is that even though that has
a root to HPFS MS keeps it propriety so nobody could write an official
driver for it so everybody is having the risk that Microsoft makes changes
on its binary structure without any further notification.

Tamas

2006\11\10@074202 by Peter Bindels

picon face
On 10/11/06, Tamas Rudnai <EraseMEtamas.rudnaispam_OUTspamTakeThisOuTgmail.com> wrote:
> > Seeks on a FAT32 disk are, if you cache the entire FAT table, linear
> > in time depending on the file position.
>
> ..all depends on how smart is your filesystem driver. I will not argue on
> specific ones, however, wrote several FAT or FAT-like filesystem drivers and
> can tell you that you can do lots of speed enforcements so you will not able
> to tell by the speed that a particular file is stored on an NTFS or FAT.

Most of what you can do with this is take the structures that FAT
offers you and transform them to other, smaller or faster, structures
that contain the same information. If you can make a smaller or faster
structure, why not store it? This way, you both need to derive them
time and time again (slowing stuff down needlessly) and/or you need to
cache / buffer them in full (making your FS library eat memory). That
seems very wasteful.

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...