Lpc2000

Bertrik Sikken wrote:

>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
>
>  
>
Ah, better licensing terms.

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------