Lpc2000

Tom Walsh wrote:
> Bertrik Sikken wrote:
> 
>> Sagaert Johan wrote:
>>  
>>
>>> Hi
>>>
>>> - does the efsl fat library work with SD and MMC or only with SD cards ?
>>> - has anyone ported this to keil ?
>>> - are there other good alternatives for a SD/MMC fat library (small
>>> footprint in terms of RAM use )
>>>    
>>>
>> Make sure to also check out the work done by Tom Walsh to port RDCF2
>> to the LPC2xxx microcontroller. I have not actually used it yet. See
>> http://openhardware.net/ under Embedded stuff / Philips LPC2000
>>
>> An advantage is that this FAT implementation works together with
>> newlib, so you can just use standard C functions like fopen, fread
>> (etc) to access the filesystem on the memory card.
>> A disadvantage (as far as I know) is that it only supports FAT16.
>>
>>  
>>
> Yes, it only supports 12/16 bit FATs.  As far as I know, the only way 
> you can get a Compact Flash or SD card with 32bit FATs is to format them 
> under windows?  Since a primary feature of FAT32 is the long filenames, 
> and long filenames are under patent (AFAIK), RDCF2 will not support 
> FAT32.  I am not aware of any NAND Flash devices which are shipped with 
> FAT32, FAT32 is therefore a non-issue.

Indeed, windows xp offers FAT32 as default for my 256MB SD-card and
128MB flash drive when formatting, but I have no doubt that linux can
also format them as FAT32.

As far as I understand from the wikipedia article on FAT
http://en.wikipedia.org/wiki/File_Allocation_Table
the long filename feature is not unique to FAT32 and not required.

It also says that it is actually FAT32 itself that is under patent...

> RDCF2 remains under a Public Domain license.   IMO, a more practical 
> license than LGPL or GPL, as it places no burden on the resulting 
> product to publish anything.
> 
> FWIW, this is why I used newlib instead of uClibc, the LGPL license 
> requires you to distribute (make available) the object files to the 
> customer.  This is so the customer may get the original source of the 
> LGPL objects, recompile and relink to build a new binary.
> 
> A rather silly requirement with an embedded system, however, that 
> license term does exist.  And, if you are developing for a corporation, 
> you should avoid violating licensing issues such as this.  If you are a 
> hobbist and only ever intend to be the only person using the system you 
> build; you will never mass market it, then you can ignore the licensing 
> terms.  This is because you are the agreed end-user, however, if you 
> mass market the device, the license may come back to bite you later?
> 
> Newlib is a BSD style of license (for most of it) and only requires you 
> to add their copyright notice whereever  you have your (company) 
> copyright notices.  Not a burden.  They merely want recognition (BSD 
> authors) and disclaimer from liability.
> 
> IMHO, EFSL would be better if they dropped the LGPL license in favor of 
> a BSD license.

EFSL recently changed its license from LGPL to the eCos license, which
is basically GPL + a special exception, see
http://ecos.sourceware.org/license-overview.html

Regards,
Bertrik