new fat handler project

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Id like to know who is interrested in a 'near' full feature fat16/32 handler.

The Good:
+Long filename support
+Multi(any) media support
+Multiple mounted media (incl partitions)
+Multi open files (depends on available memory)
+c standard alike Read and Write file functions
+make and delete files/folders
+List folders and file names one by one.
+Multi level folder resolving (/dir1/dir2/dir3/file.dat)

The Bad:
- Dynamic memory allocation (Possible memory fragmentation?)
- Heavy on memory due to buffering. ~ 2kb ram needed atleast, opening a file will require another ~ 750bytes

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't Long File Name support under a patent from Microsoft? I am under the impression you can't do LFN without paying royalties - but then again this is not a commercial product and neither does Linux pay royalties.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

loyalties are a few pennies per product. up to a limit of $10000 or so.
These loyalties are to be payed by the one selling/manufacturing the product ;-)

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some tests results that may be of interrest:

PDF sheet

Attachment(s): 

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Updates, ive been adding comments to the code and think its coming to a state where its readable for others.

Im going to need alpha testers for this project, as im not sure it will hold up in the real world.

Needed to test:
1. An AVR board with mmc or a hdd connector
2. Testing skills
3. Fair/Good C knowledge

Anyone interrested?

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jepael wrote:
Isn't Long File Name support under a patent from Microsoft? I am under the impression you can't do LFN without paying royalties - but then again this is not a commercial product and neither does Linux pay royalties.

- Jani

Interesting.

Is the whole IDEA of LFN patented so that no one can even use a long file name, or is the code they wrote to ACHIEVE the support patented? (I would have thought that would be a case for a copyright.)

I'd have thought that the IDEA of a LFN can not be patented, so if you write your own code to achieve the LFN support, then you will owe no royalties....

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Spamiam wrote:
Is the whole IDEA of LFN patented so that no one can even use a long file name [...]
Although I haven't read all of the claims of the patent, I believe that the one of interest here is the process for mapping between 8.3 and long filenames bidirectionally. As long as that patent claim remains valid, no one can use the same process commercially even if they write their own code for doing so.

If the mapping process weren't patented, then Microsoft could protect their implementation using a copyright or as a trade secret and others could implement it as well as long as they didn't infringe on the copyright or trade secret.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Max,

I would be interested in testing.

good:
- knowledge of C.

Not so Good:
- I only have ARM boards with MMC/SD card connectors.
two from NXP and one Atmel.

- No formal Testing skills

Troy

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there much other than LFN that isn't already in Elm's FatFS libraries?

Clancy _________________ Step 1: RTFM Step 2: RTFF (Forums) Step 3: RTFG (Google) Step 4: Post

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't want to steal thunder, but I've been off on my own implementing a FAT16/32 LFN capable library that offers the features listed, (except the libc-style interface).

Mine requires only about 1024 bytes to run (one needs two buffers during a write access, since a tmp buf is needed to update the FAT sector before writing the new data to disk) and does not do any dynamic memory allocations.

I'm almost done with it (when I last checked in here, FATFS wasn't around, though I may see if I can add my multiple partition support and LFN support to that codebase. You're free to the codebase if you'd like (I make no claims on superior code, I wrote it becuase I didn't like the single partition or single file constraints in earlier projects)

Jim

Jim Brain

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is a slightly old thread, but I'll post anyway. See link:

http://sourceforge.net/projects/efsl/

Matt.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Spamiam wrote:
Jepael wrote:
Isn't Long File Name support under a patent from Microsoft? I am under the impression you can't do LFN without paying royalties - but then again this is not a commercial product and neither does Linux pay royalties.

- Jani

Interesting.

Is the whole IDEA of LFN patented so that no one can even use a long file name, or is the code they wrote to ACHIEVE the support patented? (I would have thought that would be a case for a copyright.)

I'd have thought that the IDEA of a LFN can not be patented, so if you write your own code to achieve the LFN support, then you will owe no royalties....

-Tony

What is patented is the mechanism for adding/supporting long file names with the FAT filesystem while retaining the 8.3 backwards compatibility. Not the code itself, that is protected under copyright.

One is free to invent a new mechanism to do it, only problem is, when you read the disk using a PC it won't recognize it, unless you write code for it to understand your mechanism as well.

ANY implementation of FAT LFN support that remains compatible with windows is covered by the Microsoft patent, so if you produce a marketable device you are subject to royalties.

Technically you are subject to royalties for just using FAT (Microsoft has a patent for FAT as well, though it may not be an enforceable patent), though Microsoft is not going after people simply using FAT, only people using LFN on FAT.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think there are already plenty of FAT libraries out there. I'm currently using EFSL and it works fine. Wish somebody would give it LFN support though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

as everybody is jumping on the "fat handler" bandwagon I'll post mine:

3 times a week in the gym for a good hour.
Cut down carbs, more proteins.
Do some walking, dancing or activity other than mouse clicking and forum postings.

That will do for now... :)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John,
Glad to see you are trying to "Trim the FAT" :lol:

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user