Lpc2000

I have posted my project for the MMC FAT16 DOS driver system.  This is 
build on NewLib stubs and the RDCF2 filesystem driver code.  Also, the 
project has support for the gettimeofday() and settimeofday() library 
functions, as well as the fopen(), fclose(), fread(), fwrite(), etc..

The site is http://openhardware.net 

and for the impatient:  
<http://www.openhardware.net/?title=RDCF2%20DOS%20FAT%20Filesystem%20for%20LPC2138&dir=rdcf2&file=rdcf2lpc2138.html> 


Enjoy!

TomW

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Walsh wrote:
> I have posted my project for the MMC FAT16 DOS driver system.  This is 
> build on NewLib stubs and the RDCF2 filesystem driver code.  Also, the 
> project has support for the gettimeofday() and settimeofday() library 
> functions, as well as the fopen(), fclose(), fread(), fwrite(), etc..
> 
> The site is http://openhardware.net 
> 
> and for the impatient:  
> <http://www.openhardware.net/?title=RDCF2%20DOS%20FAT%20Filesystem%20for%20LPC2138&dir=rdcf2&file=rdcf2lpc2138.html> 

This is cool stuff. Also nice to release it under BSD style license!

By the way, I think the Keil USB mass storage example for LPC214x
would be a nice complement to this software, see:
http://www.keil.com/download/docs/307.asp
This would allow you to use the LPC to write files on the SD/MMC
card, then plug the LPC into a PC's USB port and let the PC
access the SD/MMC card like it was a removeable drive (and read
the files).
The device layer needs to be sufficiently independent, which
already seems to be the case in your code, although the API
probably needs to be a bit more elaborate. For example not just
read / write sector, but also functions to get card info (for the
SCSI INQUIRY command) and to get the size of the card (for the
SCSI GET CAPACITY command), etc.

I am myself thinking of using FAT32. I found this driver (GPL)
that already provides FAT32 read support:
http://www.robs-projects.com/filelib.html
I am investigating if it is possible to add write support to it.

There really should be something small, portable and configureable
for FAT like lwIP (light-weight IP) is for embedded TCP/IP stacks.
Would be cool to call that "light-weight FAT" :)

All the best,
Bertrik Sikken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDe3W/ETD6mlrWxPURAmYdAKC50Syy5LrykBWvzaHoLhUYwyvJqACbBpBf
582ttm7mNkF9+4Uh2gZfiOo=
=R618
-----END PGP SIGNATURE-----

Bertrik Sikken wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Tom Walsh wrote:
>  
>
>>I have posted my project for the MMC FAT16 DOS driver system.  This is 
>>build on NewLib stubs and the RDCF2 filesystem driver code.  Also, the 
>>project has support for the gettimeofday() and settimeofday() library 
>>functions, as well as the fopen(), fclose(), fread(), fwrite(), etc..
>>
>>The site is http://openhardware.net 
>>
>>and for the impatient:  
>><http://www.openhardware.net/?title=RDCF2%20DOS%20FAT%20Filesystem%20for%20LPC2138&dir=rdcf2&file=rdcf2lpc2138.html> 
>>    
>>
>
>This is cool stuff. Also nice to release it under BSD style license!
>
>  
>
Thanks.  The original author had released the source into public 
domain.  I felt it appropriate to continue with the spirit in which I 
had received it.  FAT16 filesystem is not some huge, mind-boggling thing 
of which only uber-programmers can achieve.  It is a simple filesystem 
which is actually based on the original CP/M-80 filesystem, which was 
based on ...


>By the way, I think the Keil USB mass storage example for LPC214x
>would be a nice complement to this software, see:
>http://www.keil.com/download/docs/307.asp
>This would allow you to use the LPC to write files on the SD/MMC
>card, then plug the LPC into a PC's USB port and let the PC
>access the SD/MMC card like it was a removeable drive (and read
>the files).
>The device layer needs to be sufficiently independent, which
>already seems to be the case in your code, although the API
>probably needs to be a bit more elaborate. For example not just
>read / write sector, but also functions to get card info (for the
>SCSI INQUIRY command) and to get the size of the card (for the
>SCSI GET CAPACITY command), etc.
>
>I am myself thinking of using FAT32. I found this driver (GPL)
>that already provides FAT32 read support:
>http://www.robs-projects.com/filelib.html
>I am investigating if it is possible to add write support to it.
>
>  
>
I would suspect that you are more interested in long filenames as 
opposed to a FAT32 FAT table?

Be carefull of long filenames, I do believe that Microsoft has patented 
that.  While as a hobbist this may not be much of a concern, what do you 
if you come up with a cool product and start selling it?  There are 
"entrance fees" to Microsoft technologies, the per-unit royalty may be 
attractive, but you have that "entrance fee" + a minimum usage / year 
requirement.

A company I had worked for, 15 years ago, looked into licensing of MSDOS 
Version 3.x filesystem.  We were told at that time that a minimum order 
of 500 licenses per year for every year that we shipped product.  If we 
did not use the purchased licenses, we were to destroy the remaining 
licenses and purchase another 500.  Each license was $70 per, this 
translated into a minimum of $35K / year just to include MSDOS into the 
product.  Keep in mind, MSDOS 3.x was retailing off-the-shelf for around 
$30 at that time.  Microsoft's response to that had been that "they are 
volume dealers".  No, we could not purchase MSDOS 3.x from those 
dealers, pre-install it into our product and pass it along to our 
customers: this was not allowed, we needed a re-seller license!


>There really should be something small, portable and configureable
>for FAT like lwIP (light-weight IP) is for embedded TCP/IP stacks.
>Would be cool to call that "light-weight FAT" :)
>
>  
>
Something like that, RDCF2 is a bit lame.  :-/

TomW


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

Version 1.2 of the rdcf2 MMC DOS FAT16 filesystem is available on: 
http://openhardware.net

Those of you with Internet Explorer may consider using FireFox to access 
the site.  I don't use IE and recently was told that the site does not 
render properly with IE.  Will I fix that? ... Don't use IE to access 
the site.  ;-)

Changes in v1.2 are that subdirectories are supported and files may be 
renamed.  You may open a file over a directory path in the following 
manner (also see the main2138.c file):

========== fopen path ==========
fopen ("/mmc/logfiles/errorlog.bin", "w");
============ snip ==============

Note the "/" slash instead of the "\" backslash?

Files are renamed with:

=========== rename ===========
rename ("/mmc/logfiles/errlog.bin", "errorlog.txt");
=========== snip =============

Note that no path is given for the new name?  Also, make sure a file 
does not already exist by that name or the rename will fail.

Regards,

TomW



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

> I am myself thinking of using FAT32. I found this driver (GPL)
> that already provides FAT32 read support:
> http://www.robs-projects.com/filelib.html
> I am investigating if it is possible to add write support to it.

I'd like to remind y'all of the implications of GPL.

In a small embedded environment (ie where you do not have OS-level 
partitioning) If you use code under GPL, then you will need to make the rest 
of your code freely available if you distribute any product that contains 
this code.

Charles Manning wrote:

>>I am myself thinking of using FAT32. I found this driver (GPL)
>>that already provides FAT32 read support:
>>http://www.robs-projects.com/filelib.html
>>I am investigating if it is possible to add write support to it.
>>    
>>
>
>I'd like to remind y'all of the implications of GPL.
>
>In a small embedded environment (ie where you do not have OS-level 
>partitioning) If you use code under GPL, then you will need to make the rest 
>of your code freely available if you distribute any product that contains 
>this code.
>
>
>  
>
This is somewhat correct, not entirely.  We don't need to get into a 
copyright discussion here, there has been enough written about GPL vs 
LGPL licensing on other sites.  What you need to understand is that if 
you create software using GPL'ed tools, that _does not_ automatically 
place your code under the GPL (or LGPL).  If you bind (link) GPL or LGPL 
code into your code, then _yes_, you are bound by the copyright of the 
code you linked in.

The MMC DOS FAT filesystem is _not GPL_, the only license on that is 
from public domain and I only ask that you keep my name in it, as well 
as that of the original author.  This is merely respect, not a license.  
The original code was public domain, I'd like to keep it unrestricted use.

NewLib on the other hand, has various licenses, most of which are BSD 
style.  There is _no LGPL or GPL licensed code_ within NewLib!  You do 
have some requirements, read the COPYING.NEWLIB in the NewLib sources to 
see what your obligations are.  Basically, they wish you to give credit 
to the original authors and to disclaim any Fitness-for-Use (legalese to 
avoid entanglements).

What is your point?  To create confusion over using GNC gcc tools to 
build code?  Create confusion over using MMC FAT DOS over a commercially 
licensed product?  What?

TomW



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

AFAIK you're not correct there.  If I take GPL code I only need to 
make source code available if I have modified the GPL'd code itself.  
Even in that case I only have to make available the modified code, not 
my entire code base.  Locally we've been using GPL'd code for a while, 
we keep it in a seperate library and since we have modified it, the 
library source is available, but not the source to our entire 
application.

--- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...> wrote:
>
> 
> > I am myself thinking of using FAT32. I found this driver (GPL)
> > that already provides FAT32 read support:
> > http://www.robs-projects.com/filelib.html
> > I am investigating if it is possible to add write support to it.
> 
> I'd like to remind y'all of the implications of GPL.
> 
> In a small embedded environment (ie where you do not have OS-level 
> partitioning) If you use code under GPL, then you will need to make 
the rest 
> of your code freely available if you distribute any product that 
contains 
> this code.
>

seangra wrote:

>AFAIK you're not correct there.  If I take GPL code I only need to 
>make source code available if I have modified the GPL'd code itself.  
>Even in that case I only have to make available the modified code, not 
>my entire code base.  Locally we've been using GPL'd code for a while, 
>we keep it in a seperate library and since we have modified it, the 
>library source is available, but not the source to our entire 
>application.
>
>  
>
No, read the license discussions on other websites.  If you statically 
link proprietary code to GPL code, then you must release source, if you 
dynamically link at runtime, then you do not have to distribute source 
of your application.  However, you must distribute the object files of 
the proprietary application.

Open Source Software does place some obligations on you.  You simply 
cannot say "oh, but I download the source, so it is now mine to do what 
I please with it".  Some OSS you can do that, as per their license, not 
with GPL.

TomW


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

Tom Walsh wrote:

>seangra wrote:
>
>  
>
>>AFAIK you're not correct there.  If I take GPL code I only need to 
>>make source code available if I have modified the GPL'd code itself.  
>>Even in that case I only have to make available the modified code, not 
>>my entire code base.  Locally we've been using GPL'd code for a while, 
>>we keep it in a seperate library and since we have modified it, the 
>>library source is available, but not the source to our entire 
>>application.
>>
>> 
>>
>>    
>>
>No, read the license discussions on other websites.  If you statically 
>link proprietary code to GPL code, then you must release source, if you 
>dynamically link at runtime, then you do not have to distribute source 
>of your application.  However, you must distribute the object files of 
>the proprietary application.
>  
>
Correction on my part: LGPL static linking requires object modules to be 
available from the proprietary app. Not GPL, in either case where you 
dynamically link at runtime, you can protect your proprietary source.  
Static linking is where the problems can arise.

Regards,

TomW



>Open Source Software does place some obligations on you.  You simply 
>cannot say "oh, but I download the source, so it is now mine to do what 
>I please with it".  Some OSS you can do that, as per their license, not 
>with GPL.
>
>TomW
>
>
>  
>


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

Hi Tom,

What is the RAM/ROM footprint of your example code?

Joel

On Thu, 2005-11-17 at 14:55 -0500, Tom Walsh wrote:
> Tom Walsh wrote:
> >No, read the license discussions on other websites.  If you statically 
> >link proprietary code to GPL code, then you must release source, if you 
> >dynamically link at runtime, then you do not have to distribute source 
> >of your application.  However, you must distribute the object files of 
> >the proprietary application.
> >  
> >
> Correction on my part: LGPL static linking requires object modules to be 
> available from the proprietary app. Not GPL, in either case where you 
> dynamically link at runtime, you can protect your proprietary source.  
> Static linking is where the problems can arise.
> 

Actually, according to the FSF, you cannot use GPL code with non-GPL
code even while dynamically linking.

http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL


An exception seems to be if you are using the a GPL library where you
call into it in a plugin-style form of use.

http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins



Adam



[Non-text portions of this message have been removed]

Joel Winarske wrote:

>Hi Tom,
>
>What is the RAM/ROM footprint of your example code?
>
>  
>

Turning off the HAS_MMC in the include/config.h gives:

-rwxrwxr-x  1 tom tom 24076 Nov 17 15:34 main2138.bin*

With HAS_MMC turned on:

-rwxrwxr-x  1 tom tom 34044 Nov 17 15:36 main2138.bin*

This is not an accuate test of size though.  However, it does give a 
rough idea of how much larger the code will grow including the: module 
driver, newlib stubs, mmc hardware drivers, and RDCF2 sources.  So what 
are we, 9..10K additional code for an MMC FAT filesystem?

RAM is dependant upon how many file buffers you choose (MaxFileBuffers), 
it appears that each file buffer takes at least 1K.  I have not looked 
very closely at how newlib is alloc()ing memory on the heap.  So far, 
newlib is heap-ing about an additonal 12K, but that is not all file related.


To me, that is worth spending as the host processor is an LPC2138 (512K 
of Flash).

Regards,

TomW


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

Adam Goode wrote:

>On Thu, 2005-11-17 at 14:55 -0500, Tom Walsh wrote:
>  
>
>>Tom Walsh wrote:
>>    
>>
>>>No, read the license discussions on other websites.  If you statically 
>>>link proprietary code to GPL code, then you must release source, if you 
>>>dynamically link at runtime, then you do not have to distribute source 
>>>of your application.  However, you must distribute the object files of 
>>>the proprietary application.
>>> 
>>>
>>>      
>>>
>>Correction on my part: LGPL static linking requires object modules to be 
>>available from the proprietary app. Not GPL, in either case where you 
>>dynamically link at runtime, you can protect your proprietary source.  
>>Static linking is where the problems can arise.
>>
>>    
>>
>
>Actually, according to the FSF, you cannot use GPL code with non-GPL
>code even while dynamically linking.
>
>http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
>http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
>
>
>An exception seems to be if you are using the a GPL library where you
>call into it in a plugin-style form of use.
>
>http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins
>
>
>  
>
Exactly why I did not choose glibc as the library.  heh

TomW

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

Adam Goode ha scritto:

>On Thu, 2005-11-17 at 14:55 -0500, Tom Walsh wrote:
>  
>
>>Tom Walsh wrote:
>>    
>>
>>>No, read the license discussions on other websites.  If you statically 
>>>link proprietary code to GPL code, then you must release source, if you 
>>>dynamically link at runtime, then you do not have to distribute source 
>>>of your application.  However, you must distribute the object files of 
>>>the proprietary application.
>>> 
>>>
>>>      
>>>
>>Correction on my part: LGPL static linking requires object modules to be 
>>available from the proprietary app. Not GPL, in either case where you 
>>dynamically link at runtime, you can protect your proprietary source.  
>>Static linking is where the problems can arise.
>>
>>    
>>
>
>Actually, according to the FSF, you cannot use GPL code with non-GPL
>code even while dynamically linking.
>
>http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
>http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
>
>
>An exception seems to be if you are using the a GPL library where you
>call into it in a plugin-style form of use.
>
>http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins
>
>
>
>Adam
>
>
>  
>
Ok guys, this i s pure theory. What may happen if anyone changes or 
extend some part of code? And what happens if anyone include GPL source 
code in an embedded project and he don't say that? In practice it is 
virtually impossible to be sure that nobody includes some source code 
parts extracted from other source codes (not only gpl, lgpl or open source).

>[Non-text portions of this message have been removed]
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>


  ----------

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.3/173 - Release Date: 16/11/2005


[Non-text portions of this message have been removed]

Could you?:
>arm-elf-objdump <objfile> -h

On 11/17/05, Tom Walsh <tom@openhardware.net> wrote:
>  Joel Winarske wrote:
>
>  >Hi Tom,
>  >
>  >What is the RAM/ROM footprint of your example code?
>  >
>  >
>  >
>
>  Turning off the HAS_MMC in the include/config.h gives:
>
>  -rwxrwxr-x  1 tom tom 24076 Nov 17 15:34 main2138.bin*
>
>  With HAS_MMC turned on:
>
>  -rwxrwxr-x  1 tom tom 34044 Nov 17 15:36 main2138.bin*
>
>  This is not an accuate test of size though.  However, it does give a
>  rough idea of how much larger the code will grow including the: module
>  driver, newlib stubs, mmc hardware drivers, and RDCF2 sources.  So what
>  are we, 9..10K additional code for an MMC FAT filesystem?
>
>  RAM is dependant upon how many file buffers you choose (MaxFileBuffers),
>  it appears that each file buffer takes at least 1K.  I have not looked
>  very closely at how newlib is alloc()ing memory on the heap.  So far,
>  newlib is heap-ing about an additonal 12K, but that is not all file
> related.
>
>
>  To me, that is worth spending as the host processor is an LPC2138 (512K
>  of Flash).
>
>  Regards,
>
>  TomW
>
>
>  --
>  Tom Walsh - WN3L - Embedded Systems Consultant
>  http://openhardware.net, http://cyberiansoftware.com
>  "Windows? No thanks, I have work to do..."
>  ----------------------------------------------------
>
>
>
>
>  ________________________________
>  YAHOO! GROUPS LINKS
>
>
>  Visit your group "lpc2000" on the web.
>
>  To unsubscribe from this group, send an email to:
>  lpc2000-unsubscribe@yahoogroups.com
>
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>  ________________________________
>


--
Bryce Schober

On 11/17/05, Micron Engineering <micronpn@...> wrote:
>  Ok guys, this i s pure theory. What may happen if anyone changes or
>  extend some part of code? And what happens if anyone include GPL source
>  code in an embedded project and he don't say that? In practice it is
>  virtually impossible to be sure that nobody includes some source code
>  parts extracted from other source codes (not only gpl, lgpl or open
> source).

No, it is not pure theory. It is business ethics. Sure, you can
disregard them if you want, but don't be surprised when the lawyers
come to close your business.

--
Bryce Schober

Bryce Schober ha scritto:

>On 11/17/05, Micron Engineering <micronpn@...> wrote:
>  
>
>> Ok guys, this i s pure theory. What may happen if anyone changes or
>> extend some part of code? And what happens if anyone include GPL source
>> code in an embedded project and he don't say that? In practice it is
>> virtually impossible to be sure that nobody includes some source code
>> parts extracted from other source codes (not only gpl, lgpl or open
>>source).
>>    
>>
>
>No, it is not pure theory. It is business ethics. Sure, you can
>disregard them if you want, but don't be surprised when the lawyers
>come to close your business.
>
>  
>
You really think that lawyers may see our source code? Yes ok if they 
pay we may show it to them but if they can't say with absolute security 
that you have infringed some patents or licenses they can't and in 
embedded world (solid state flash to be more precise) is impossible to 
recognize a part of object code as a part of source code illegally used.

>--
>Bryce Schober
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>


  ----------

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.362 / Virus Database: 267.13.3/173 - Release Date: 16/11/2005


[Non-text portions of this message have been removed]

Sorry folk I did not want to start a huge thing. I've spent a lot of time 
trying to understand GPL and what it means, as well as having released large 
bodies of code under GPL and just wanted to make people aware.

There have been huge wars fought on what GPL does and does not mean. There are 
some imprecise grey areas, particularly the static vs dynamic linking thing.

The FAQ is interesting, but it is not legally binding because it is not part 
of the actual GPL (which forms the legal part of the license), though it 
might be legally binding on FSF-owned code because it is a public statement 
of their interpretation. Things are further muddied by various GPL variants 
(eg. the Linux licence) which are based on GPL, have certain degrees of GPL 
compatability, but are no longer GPL because they are modified.

Under copyright law, only the copyright owner can sue for infringement, so 
talk to the copyright holder.

IMHO, the best way to handle GPL code is as follows:
1) If you can, stay in the undisputed zone. Stay away from the grey areas.
2) If you must go in the grey-zone (eg. dynamic linking) then talk to the 
original author/copyright holder. Get their interpretation. For instance a 
company I work with publicly state that they will not pursue dynamically 
linked usage as infringement, only statically linked usage.
3) State your case to the copyright holder and perhaps ask them to relicense 
the code under LGPL. LGPL allows you to use the code with any linking model, 
but you must contribute back fixes/changes to that code. Often people are 
open to relicensing and I have successfully had people relicence their code 
as LGPL before.
4) If nothing else succeeds then ask the copyright holder for an alternative 
license. Quite a few bodies of code are released under GPL + alternative 
licencing (perhaps for a fee) to allow use of the code in non-GPL situations.

On Friday 18 November 2005 09:30, Adam Goode wrote:
> On Thu, 2005-11-17 at 14:55 -0500, Tom Walsh wrote:
> > Tom Walsh wrote:
> > >No, read the license discussions on other websites.  If you statically
> > >link proprietary code to GPL code, then you must release source, if you
> > >dynamically link at runtime, then you do not have to distribute source
> > >of your application.  However, you must distribute the object files of
> > >the proprietary application.
> >
> > Correction on my part: LGPL static linking requires object modules to be
> > available from the proprietary app. Not GPL, in either case where you
> > dynamically link at runtime, you can protect your proprietary source.
> > Static linking is where the problems can arise.
>
> Actually, according to the FSF, you cannot use GPL code with non-GPL
> code even while dynamically linking.
>
> http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
> http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
>
>
> An exception seems to be if you are using the a GPL library where you
> call into it in a plugin-style form of use.
>
> http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins

On Friday 18 November 2005 08:39, Tom Walsh wrote:
> Charles Manning wrote:
> >>I am myself thinking of using FAT32. I found this driver (GPL)
> >>that already provides FAT32 read support:
> >>http://www.robs-projects.com/filelib.html
> >>I am investigating if it is possible to add write support to it.
> >
> >I'd like to remind y'all of the implications of GPL.
> >
> >In a small embedded environment (ie where you do not have OS-level
> >partitioning) If you use code under GPL, then you will need to make the
> > rest of your code freely available if you distribute any product that
> > contains this code.
>
> This is somewhat correct, not entirely.  We don't need to get into a
> copyright discussion here, there has been enough written about GPL vs
> LGPL licensing on other sites.  What you need to understand is that if
> you create software using GPL'ed tools, that _does not_ automatically
> place your code under the GPL (or LGPL).  If you bind (link) GPL or LGPL
> code into your code, then _yes_, you are bound by the copyright of the
> code you linked in.
>
> The MMC DOS FAT filesystem is _not GPL_, the only license on that is
> from public domain and I only ask that you keep my name in it, as well
> as that of the original author.  This is merely respect, not a license.
> The original code was public domain, I'd like to keep it unrestricted use.
>
> NewLib on the other hand, has various licenses, most of which are BSD
> style.  There is _no LGPL or GPL licensed code_ within NewLib!  You do
> have some requirements, read the COPYING.NEWLIB in the NewLib sources to
> see what your obligations are.  Basically, they wish you to give credit
> to the original authors and to disclaim any Fitness-for-Use (legalese to
> avoid entanglements).
>
> What is your point?  To create confusion over using GNC gcc tools to
> build code?  Create confusion over using MMC FAT DOS over a commercially
> licensed product?  What?


Hey I never created the confusion, but clearly there are a bunch of people 
that do not understand the GPL and are confused.

It was not me that said this code was GPL and I have not checked whether it 
is. Whoever made the statement that is GPL clearly does not understand what 
GPL means (if indeed it is not GPL).

I use GPL code a lot (using some right now as I type this) and I have 
written/published a lot of GPL code, as well as LGPL code and I released some 
code under LGPL for a particular reason. I **know** that a lot of my code is 
used in ways that violate GPL which does piss me off some, but not enough to 
chase them. I always respect other people GPL licensing.

What I wanted to point out was that if you're going to use GPL code then be 
mindful of your obligations. It is not a free lunch. Respect that people are 
allowing you to use their code with some limitations. Most folk are 
reasonable and you can often negotiate alternative requirements if needed.

Bryce Schober wrote:

>Could you?:
>  
>
>>arm-elf-objdump <objfile> -h
>>    
>>
>
>  
>



rdcf2.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000178c  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000020  00000000  00000000  000017c0  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  000017e0  2**0
                  ALLOC
  3 .stab         0000318c  00000000  00000000  000017e0  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      0000448e  00000000  00000000  0000496c  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  00008dfa  2**0
                  CONTENTS, READONLY

close_r.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000070  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  000000a4  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  000000a4  2**0
                  ALLOC
  3 .stab         00000720  00000000  00000000  000000a4  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00002dd4  00000000  00000000  000007c4  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  00003598  2**0
                  CONTENTS, READONLY

fstat_r.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000010  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000044  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000044  2**0
                  ALLOC
  3 .stab         00000840  00000000  00000000  00000044  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00003322  00000000  00000000  00000884  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  00003ba6  2**0
                  CONTENTS, READONLY

gettimeofday_r.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000068  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  0000009c  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  0000009c  2**0
                  ALLOC
  3 .stab         00000984  00000000  00000000  0000009c  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00003409  00000000  00000000  00000a20  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  00003e29  2**0
                  CONTENTS, READONLY

link_r.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000000dc  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000110  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000110  2**0
                  ALLOC
  3 .stab         0000078c  00000000  00000000  00000110  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00002e36  00000000  00000000  0000089c  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  000036d2  2**0
                  CONTENTS, READONLY

lseek_r.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000008c  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  000000c0  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  000000c0  2**0
                  ALLOC
  3 .stab         0000078c  00000000  00000000  000000c0  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00002e4f  00000000  00000000  0000084c  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  0000369b  2**0
                  CONTENTS, READONLY

open_r.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000000d0  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000104  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000104  2**0
                  ALLOC
  3 .stab         00000780  00000000  00000000  00000104  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00002de9  00000000  00000000  00000884  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  0000366d  2**0
                  CONTENTS, READONLY

read_r.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000088  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  000000bc  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  000000bc  2**0
                  ALLOC
  3 .stab         00000768  00000000  00000000  000000bc  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00002de8  00000000  00000000  00000824  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  0000360c  2**0
                  CONTENTS, READONLY

sbrk_r.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000002c  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000060  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000004  00000000  00000000  00000060  2**2
                  ALLOC
  3 .stab         0000066c  00000000  00000000  00000060  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00002bc4  00000000  00000000  000006cc  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  00003290  2**0
                  CONTENTS, READONLY

unlink_r.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000000d0  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  00000104  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  00000104  2**0
                  ALLOC
  3 .stab         00000948  00000000  00000000  00000104  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00003216  00000000  00000000  00000a4c  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  00003c62  2**0
                  CONTENTS, READONLY

write_r.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000088  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  000000bc  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  000000bc  2**0
                  ALLOC
  3 .stab         00000768  00000000  00000000  000000bc  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00002df3  00000000  00000000  00000824  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  00003617  2**0
                  CONTENTS, READONLY

mmc_hardware.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000003f4  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000012  00000000  00000000  00000428  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000001  00000000  00000000  0000043a  2**0
                  ALLOC
  3 .stab         00000fc0  00000000  00000000  0000043c  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00003a38  00000000  00000000  000013fc  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  00004e34  2**0
                  CONTENTS, READONLY

mmc_init.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000001c4  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  000001f8  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  000001f8  2**0
                  ALLOC
  3 .stab         00000b70  00000000  00000000  000001f8  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      00003cf4  00000000  00000000  00000d68  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .comment      00000012  00000000  00000000  00004a5c  2**0
                  CONTENTS, READONLY

mmc_module.o:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000002a8  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data         00000000  00000000  00000000  000002dc  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00000000  00000000  00000000  000002dc  2**0
                  ALLOC
  3 .stab         0000105c  00000000  00000000  000002dc  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING
  4 .stabstr      000040ff  00000000  00000000  00001338  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .rodata.str1.4 00000004  00000000  00000000  00005438  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .rodata       00000020  00000000  00000000  0000543c  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  7 .comment      00000012  00000000  00000000  0000545c  2**0
                  CONTENTS, READONLY

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

Thanks for the info Tom.  I may port the code for use with IAR if I have
some free time.  If I do I'll send you project for distribution.

Regards,
Joel

http://www.the-interweb.com/serendipity/index.php?/archives/55-Proof- 
that-F4I-violates-the-GPL.html#extended

This is an example of GPL code being discovered recently in a binary,  
as a violation of GPL license.

To my knowledge there is no recorded case of prosecution on the basis  
of GPL violation, ever ?
p/.

On Nov 17, 2005, at 2:20 PM, Charles Manning wrote:

>
> Sorry folk I did not want to start a huge thing. I've spent a lot  
> of time
> trying to understand GPL and what it means, as well as having  
> released large
> bodies of code under GPL and just wanted to make people aware.
>
> There have been huge wars fought on what GPL does and does not  
> mean. There are
> some imprecise grey areas, particularly the static vs dynamic  
> linking thing.
>
> The FAQ is interesting, but it is not legally binding because it is  
> not part
> of the actual GPL (which forms the legal part of the license),  
> though it
> might be legally binding on FSF-owned code because it is a public  
> statement
> of their interpretation. Things are further muddied by various GPL  
> variants
> (eg. the Linux licence) which are based on GPL, have certain  
> degrees of GPL
> compatability, but are no longer GPL because they are modified.
>
> Under copyright law, only the copyright owner can sue for  
> infringement, so
> talk to the copyright holder.
>
> IMHO, the best way to handle GPL code is as follows:
> 1) If you can, stay in the undisputed zone. Stay away from the grey  
> areas.
> 2) If you must go in the grey-zone (eg. dynamic linking) then talk  
> to the
> original author/copyright holder. Get their interpretation. For  
> instance a
> company I work with publicly state that they will not pursue  
> dynamically
> linked usage as infringement, only statically linked usage.
> 3) State your case to the copyright holder and perhaps ask them to  
> relicense
> the code under LGPL. LGPL allows you to use the code with any  
> linking model,
> but you must contribute back fixes/changes to that code. Often  
> people are
> open to relicensing and I have successfully had people relicence  
> their code
> as LGPL before.
> 4) If nothing else succeeds then ask the copyright holder for an  
> alternative
> license. Quite a few bodies of code are released under GPL +  
> alternative
> licencing (perhaps for a fee) to allow use of the code in non-GPL  
> situations.
>
>
>
>
> On Friday 18 November 2005 09:30, Adam Goode wrote:
>> On Thu, 2005-11-17 at 14:55 -0500, Tom Walsh wrote:
>>> Tom Walsh wrote:
>>>> No, read the license discussions on other websites.  If you  
>>>> statically
>>>> link proprietary code to GPL code, then you must release source,  
>>>> if you
>>>> dynamically link at runtime, then you do not have to distribute  
>>>> source
>>>> of your application.  However, you must distribute the object  
>>>> files of
>>>> the proprietary application.
>>>
>>> Correction on my part: LGPL static linking requires object  
>>> modules to be
>>> available from the proprietary app. Not GPL, in either case where  
>>> you
>>> dynamically link at runtime, you can protect your proprietary  
>>> source.
>>> Static linking is where the problems can arise.
>>
>> Actually, according to the FSF, you cannot use GPL code with non-GPL
>> code even while dynamically linking.
>>
>> http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
>> http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
>>
>>
>> An exception seems to be if you are using the a GPL library where you
>> call into it in a plugin-style form of use.
>>
>> http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins
>
>
> ------------------------ Yahoo! Groups Sponsor -------------------- 
> ~-->
> Get fast access to your favorite Yahoo! Groups. Make Yahoo! your  
> home page
> http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/dN_tlB/TM
> -------------------------------------------------------------------- 
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

Joel Winarske wrote:

>Thanks for the info Tom.  I may port the code for use with IAR if I have
>some free time.  If I do I'll send you project for distribution.
>
>  
>
Thank you.  I think that I'm going to have to get my CVS server up onto 
the web again.  It looks like I'll need something better than just 
distributing tarballs.  ;-)

TomW



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

If only there were some site, some service for OS projects... :)

Why not just sourceforge it?

--  Sean


--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:

>
> I think that I'm going to have to get my CVS server up onto 
> the web again.  It looks like I'll need something better than just 
> distributing tarballs.  ;-)

Micron Engineering <micronpn@...> schrieb am Thu, 17 Nov 2005 22:54:55

> You really think that lawyers may see our source code? Yes ok if they
> pay we may show it to them but if they can't say with absolute security
> that you have infringed some patents or licenses they can't and in
> embedded world (solid state flash to be more precise) is impossible to
> recognize a part of object code as a part of source code illegally used.

It is not impossible. Every compiler has a certain foodprint and if I know
my code I can compare it.
If it is something very common like FATFS, it is maybe hard esp. as there
aren't millions of ways to do it.
But _I_ won't rely on the matter that a lawyer is not smart enough to trap
me.


-- 
42Bastian Schick

Charles Manning <manningc2@...> schrieb am Fri, 18 Nov 2005 
11:20:33 +1300:


> IMHO, the best way to handle GPL code is as follows:
> 1) .. 4)

Let me add
5) Think about why it is not possible to make your code GPL as well.
Most software in embedded space is tight to the hardware. So, keeping some 
details of the hardware secret keeps out competiors.

-- 
42Bastian Schick

--- In lpc2000@yahoogroups.com, 42Bastian Schick <bastian42@m...> 
wrote:
>
> Micron Engineering <micronpn@t...> schrieb am Thu, 17 Nov 2005 
22:54:55
> 
> > You really think that lawyers may see our source code? Yes ok if 
they
> > pay we may show it to them but if they can't say with absolute 
security
> > that you have infringed some patents or licenses they can't and 
in
> > embedded world (solid state flash to be more precise) is 
impossible to
> > recognize a part of object code as a part of source code 
illegally used.
> 
> It is not impossible. Every compiler has a certain foodprint and 
if I know
> my code I can compare it.
> If it is something very common like FATFS, it is maybe hard esp. 
as there
> aren't millions of ways to do it.
> But _I_ won't rely on the matter that a lawyer is not smart enough 
to trap
> me.
> 
> 
> -- 
> 42Bastian Schick
>

The usual way these things get going is a disgruntled former 
employee.  There is no need for forensic science to dismantle the 
chip or even a clever lawyer.  The DFE simply turns over a printed 
or machine readable copy of the code.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Walsh wrote:
> Bertrik Sikken wrote:
>>I am myself thinking of using FAT32. I found this driver (GPL)
>>that already provides FAT32 read support:
>>http://www.robs-projects.com/filelib.html
>>I am investigating if it is possible to add write support to it.
> 
> I would suspect that you are more interested in long filenames as 
> opposed to a FAT32 FAT table?

No, I don't care about long filenames. I looked at FAT32 because I
got the impression that it is even simpler and easier to implement
than FAT16.

Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDgGRJETD6mlrWxPURAjEmAKCc6VVGwR4hHVXeh45yxiAfwgxTuQCfaW5z
QKfM3JIQqVeMus2bITlfdUQ=
=4ZDX
-----END PGP SIGNATURE-----

Let's take a look at:

Embedded Filesystem Library Version 0.3.4 on the Source Forge Site:

http://sourceforge.net/projects/efsl

I have tried it, it has both read and write support for FAT12/FAT16/FAT32,

I tried FAT12 for LPC214x and it is perfect.

If you use it be sure not to use very small disk sizes with small root
entry counts in their format descriptor. Also make sure to modify the
2 functions ex_getb16 and ex_getb32 in file extract.c to correct
version of your own (considering endianness and byte alignment)

Yours,
Ali.
 

--- In lpc2000@yahoogroups.com, Bertrik Sikken <bertrik@z...> wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Tom Walsh wrote:
> > Bertrik Sikken wrote:
> >>I am myself thinking of using FAT32. I found this driver (GPL)
> >>that already provides FAT32 read support:
> >>http://www.robs-projects.com/filelib.html
> >>I am investigating if it is possible to add write support to it.
> > 
> > I would suspect that you are more interested in long filenames as 
> > opposed to a FAT32 FAT table?
> 
> No, I don't care about long filenames. I looked at FAT32 because I
> got the impression that it is even simpler and easier to implement
> than FAT16.
> 
> Bertrik
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDgGRJETD6mlrWxPURAjEmAKCc6VVGwR4hHVXeh45yxiAfwgxTuQCfaW5z
> QKfM3JIQqVeMus2bITlfdUQ=
> =4ZDX
> -----END PGP SIGNATURE-----
>

Problem Solver wrote:

>Let's take a look at:
>
>Embedded Filesystem Library Version 0.3.4 on the Source Forge Site:
>
>http://sourceforge.net/projects/efsl
>
>I have tried it, it has both read and write support for FAT12/FAT16/FAT32,
>
>I tried FAT12 for LPC214x and it is perfect.
>
>  
>
It is also LGPL code.


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

> >Let's take a look at:
> >
> >Embedded Filesystem Library Version 0.3.4 on the Source Forge Site:
> >
> >http://sourceforge.net/projects/efsl
> >
> >I have tried it, it has both read and write support for
FAT12/FAT16/FAT32,
> >
> >I tried FAT12 for LPC214x and it is perfect.
> >
> >
> >
> It is also LGPL code.

Bottom of page @ http://efsl.be/

"License
This project is released under the Lesser General Public license, which, in
short, means that you may use the library and it's sourcecode for any
purpose that you want, that you may link with it and use it commercially,
but that ANY change to the code must be released under the same license.
That means, if you add hardware suport, you share it, so that the community
may benefit from access to all kinds of hardware."


Joel

Joel Winarske wrote:

>>>Let's take a look at:
>>>
>>>Embedded Filesystem Library Version 0.3.4 on the Source Forge Site:
>>>
>>>http://sourceforge.net/projects/efsl
>>>
>>>I have tried it, it has both read and write support for
>>>      
>>>
>FAT12/FAT16/FAT32,
>  
>
>>>I tried FAT12 for LPC214x and it is perfect.
>>>
>>>
>>>
>>>      
>>>
>>It is also LGPL code.
>>    
>>
>
>Bottom of page @ http://efsl.be/
>
>"License
>This project is released under the Lesser General Public license, which, in
>short, means that you may use the library and it's sourcecode for any
>purpose that you want, that you may link with it and use it commercially,
>but that ANY change to the code must be released under the same license.
>That means, if you add hardware suport, you share it, so that the community
>may benefit from access to all kinds of hardware."
>
>
>  
>
Also read Section 6a of the LGPL to see if the following constraints are 
acceptable, the LGPL text is found at: 
http://www.gnu.org/copyleft/lesser.html#SEC3

As quoted (emphasis mine):

"*6a)* Accompany the work with the complete corresponding 
machine-readable source code for the Library including whatever changes 
were used in the work (which must be distributed under Sections 1 and 2 
above); and, */_if the work is an executable linked with the Library, 
with the complete machine-readable "work that uses the Library", as 
object code and/or source code, so that the user can modify the Library 
and then relink to produce a modified executable containing the modified 
Library_/*. (It is understood that the user who changes the contents of 
definitions files in the Library will not necessarily be able to 
recompile the application to use the modified definitions.)"


The LGPL also requires you to make available to customers, the object 
modules of your program.  This is so that they can change the LGPL 
source and then link in your object modules to create a new program.  
While the LGPL does protect your proprietary sources, it does impose 
some restriction as to static linking.

For some, the additional burden of maintaining versions of the object 
code may be something that they wish to avoid.  A BSD sytle of license 
does not impose the object code restriction.  However, that also means 
that changes to the source would not be distributed.

Regards,

TomW


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

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>
> Joel Winarske wrote:
> 
> >>It is also LGPL code.
> >>    
> >>
> >
> >Bottom of page @ http://efsl.be/
> >
> >"License
> >This project is released under the Lesser General Public license, 
which, in
> >short, means that you may use the library and it's sourcecode for 
any
> >purpose that you want, that you may link with it and use it 
commercially,
> >but that ANY change to the code must be released under the same 
license.
> >That means, if you add hardware suport, you share it, so that the 
community
> >may benefit from access to all kinds of hardware."
> >
> >
> >  
> >
> Also read Section 6a of the LGPL to see if the following 
constraints are 
> acceptable, the LGPL text is found at: 
> http://www.gnu.org/copyleft/lesser.html#SEC3
> 
> As quoted (emphasis mine):
> 
> "*6a)* Accompany the work with the complete corresponding 
> machine-readable source code for the Library including whatever 
changes 
> were used in the work (which must be distributed under Sections 1 
and 2 
> above); and, */_if the work is an executable linked with the 
Library, 
> with the complete machine-readable "work that uses the Library", 
as 
> object code and/or source code, so that the user can modify the 
Library 
> and then relink to produce a modified executable containing the 
modified 
> Library_/*. (It is understood that the user who changes the 
contents of 
> definitions files in the Library will not necessarily be able to 
> recompile the application to use the modified definitions.)"
> 
<snip>
> 
> TomW

Note that the LGPL is mainly for libraries, and quite explicitly 
states that if you maintain the LGPL'd code in it's own library, and 
use a shared library methodology to use it, you don't have to make 
available any of your own code.  The only code you have to make 
available is any portions of the LGPL'd code that you modified.

It's not all that difficult to modularize the code into a seperate 
library, especially since you're obtaining the code as a module in 
the first place.

In any case, note that 6a says "machine readable source code", which 
is quite ambiguous.  Technically an object file is "machine readable 
source code", as a C-source file is more of a "human readable source 
code" file.  Assembler output of a C-source code file with all 
comments stripped definitely falls under "machine readable source 
code" and doesn't give anything that the user couldn't already get 
by using a disassembler.

What this does mean, however, is that if you don't use an external 
library then you can't charge for your application anymore, because 
you must provide it for free to anyone who asks.

In any case, if the only good pieces of OSS software that do what 
you need are under LGPL there's no reason not to use it and to 
instead use a lesser piece of code that isn't under LGPL.

seangra wrote:

>Note that the LGPL is mainly for libraries, and quite explicitly 
>states that if you maintain the LGPL'd code in it's own library, and 
>use a shared library methodology to use it, you don't have to make 
>available any of your own code.  The only code you have to make 
>available is any portions of the LGPL'd code that you modified.
>
>  
>
I think you mis-spoke when you used the term "shared library" and you 
meant to say "dynamically linked library"?

A.k.a. runtime linking of program code + library code at the time it is 
executed.

>It's not all that difficult to modularize the code into a seperate 
>library, especially since you're obtaining the code as a module in 
>the first place.
>  
>
How do you do that, segregate the code into a subdirectory and call it a 
"module" ?  heh

You are not getting a "module", it is a library.  I think that "module" 
is too generic a term to use when speaking in a the specific tense.

>In any case, note that 6a says "machine readable source code", which 
>is quite ambiguous.  Technically an object file is "machine readable 
>source code", as a C-source file is more of a "human readable source 
>code" file.  Assembler output of a C-source code file with all 
>comments stripped definitely falls under "machine readable source 
>code" and doesn't give anything that the user couldn't already get 
>by using a disassembler.
>  
>
You are twisting words.  There can be, and often is, a vast difference 
between the Technical meaning of a term and that of the Legal meaning!  
"machine readable" means the execution (interpretation) of code by the 
computing device, not that you can view it on a computer.  "machine 
readable" is a legal term as it is used here within a copyright. 

Please refer to:  
http://www.google.com/search?hl=en&q=define%3A+machine+readable&btnG=Google+Search


>What this does mean, however, is that if you don't use an external 
>library then you can't charge for your application anymore, because 
>you must provide it for free to anyone who asks.
>  
>
Not true.  You can sell programs which are based upon OSS software, or 
are programs derived from OSS software.   It is called "value added" and 
is entirely possible to do under GPL + LGPL.  By doing so, you still 
must abide the original license terms.   The use of the terms "GPL" and 
"LGPL" mean freedom not free.

>In any case, if the only good pieces of OSS software that do what 
>you need are under LGPL there's no reason not to use it and to 
>instead use a lesser piece of code that isn't under LGPL.
>
>
>
>  
>

Regards,

TomW


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

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>
> seangra wrote:
> 
> >Note that the LGPL quite explicitly states that if you maintain
> >the LGPL'd code in it's own library, and use a shared library
> >methodology to use it, you don't have to make available any of
> >your own code.  The only code you have to make available is any
> >portions of the LGPL'd code that you modified.
> >
> I think you mis-spoke when you used the term "shared library" and 
> you meant to say "dynamically linked library"?
> 
> A.k.a. runtime linking of program code + library code at the time 
> it is executed.

I agree with your interpretation, however I'm just using the 
language of the LGPL itself.  Section 6b starts with "Use 
a suitable shared library mechanism for linking with the Library".  
Nowhere in the LGPL does it mention "dynamic".

> >It's not all that difficult to modularize the code into a 
> >seperate library, especially since you're obtaining the code as a
> >module in the first place.
> >
> How do you do that, segregate the code into a subdirectory and 
> call it a "module" ?  heh.  You are not getting a "module", it is
> a library.  I think that "module" is too generic a term to use
> when speaking in a the specific tense.

A library is a module, by definition.  A module can be a single 
file, or a selection of files.  However for our intents and 
purposes "library" is a more accurate term.

> >What this does mean, however, is that if you don't use an
> >external library then you can't charge for your application
> >anymore, because you must provide it for free to anyone who asks.
> >
> Not true.  You can sell programs which are based upon OSS 
> software, or are programs derived from OSS software.   It is
> called "value added" and is entirely possible to do under GPL +
> LGPL.  By doing so, you still must abide the original license
> terms.   The use of the terms "GPL" and "LGPL" mean freedom not
> free.

From what I understand if you do not use an external library then 
under the terms of the LGPL you (essentially) must provide the 
application to anyone who wants it.  If you must give it away for 
free (or a nominal charge) then how can you sell it?

I will leave the discussion about the legalities alone.

I would like to know, those whom have used this code.

What is the speed of writing a file to the media?

Whether using an AVR or an ARM chip.

Just how fast can I (we) write to the media?

There is a lot of code here to run through, latency is my interest.

Thank You

hamilton

At 02:46 AM 11/21/05 +0000, seangra wrote:
>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
> >
> > seangra wrote:
> >
> > >Note that the LGPL quite explicitly states that if you maintain
> > >the LGPL'd code in it's own library, and use a shared library
> > >methodology to use it, you don't have to make available any of
> > >your own code.  The only code you have to make available is any
> > >portions of the LGPL'd code that you modified.
> > >
> > I think you mis-spoke when you used the term "shared library" and
> > you meant to say "dynamically linked library"?
> >
> > A.k.a. runtime linking of program code + library code at the time
> > it is executed.
>
>I agree with your interpretation, however I'm just using the
>language of the LGPL itself.  Section 6b starts with "Use
>a suitable shared library mechanism for linking with the Library".
>Nowhere in the LGPL does it mention "dynamic".

'Shared' in this case I believe refers to the Linux equivalent to a dll. I 
don't see a way to achieve that in a micro in any sort of useful manner.


> > >What this does mean, however, is that if you don't use an
> > >external library then you can't charge for your application
> > >anymore, because you must provide it for free to anyone who asks.
> > >
> > Not true.  You can sell programs which are based upon OSS
> > software, or are programs derived from OSS software.   It is
> > called "value added" and is entirely possible to do under GPL +
> > LGPL.  By doing so, you still must abide the original license
> > terms.   The use of the terms "GPL" and "LGPL" mean freedom not
> > free.
>
> >From what I understand if you do not use an external library then
>under the terms of the LGPL you (essentially) must provide the
>application to anyone who wants it.  If you must give it away for
>free (or a nominal charge) then how can you sell it?

You can sell it, you just have to provide something that your users can use 
to link to a (possibly modified) copy of the library to recreate the 
original application.  I belive you can still place restrictions on your 
portion of the application so that it cannot be legally re-sold or 
distributed.  Of course if all the guts of your application is in the LGPL 
library that doesn't give you much protection but that is rather the 
point.  There is no requirement that you give away the application at no-cost.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

If you had a transfer vector (an array of library entry points) at a 
fixed location and all of the proprietary code called library 
functions indirectly via the vector, you could just provide your 
object code and the location of the vector (leaving space for 
expansion, I suppose).  If the customer upgrades the library the entry 
points in the vector change but the library is never actually 'linked' 
into the application.  There is this clear line, the vector, where 
LGPL/GPL code is separated from proprietary code.

I'm trying to get at the functionality of a dll in an embedded 
environment.  It's a little tough...  But the idea is that the 
proprietary stuff is shipped as a pure binary 'block' and the linker 
never really needs to know what is inside - just where the transfer 
vector should be placed.

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:

>'Shared' in this case I believe refers to the Linux equivalent 
> to a dll. I don't see a way to achieve that in a micro in any 
> sort of useful manner.

Let's say that I split my application into my code, and the LGPL'd 
library.  Either can be compiled independantly of the other.  

So, when compiled, I have 2 seperate binary files to load into the 
uC.  The library must be loaded at a specific offset in the uC, and 
must begin with a jump table containing function pointers that my code 
requires in order to interface to it.

I provide the source code to my version of the LGPL'd library to 
anyone for free, but you must buy my side of the app.

That satisfies (and is in the spirit of) the LGPL, no?

seangra wrote:

>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
>wrote:
>
>  
>
>>'Shared' in this case I believe refers to the Linux equivalent 
>>to a dll. I don't see a way to achieve that in a micro in any 
>>sort of useful manner.
>>    
>>
>
>Let's say that I split my application into my code, and the LGPL'd 
>library.  Either can be compiled independantly of the other.  
>
>So, when compiled, I have 2 seperate binary files to load into the 
>uC.  The library must be loaded at a specific offset in the uC, and 
>must begin with a jump table containing function pointers that my code 
>requires in order to interface to it.
>
>I provide the source code to my version of the LGPL'd library to 
>anyone for free, but you must buy my side of the app.
>
>That satisfies (and is in the spirit of) the LGPL, no?
>  
>
Yes, the key is "the spirit of", empowering the user rather than 
chaining them.  For example, if a user did not want to write files to 
your MMC device (via your driver), they could get a copy of the library 
source, modify it in such a way to provide their own I/O desires, then 
load the library back into the controller.

You have empowered the user to make changes.  From a technical 
standpoint, would it work successfully?  It is an interesting idea, one 
that I have conisdered.  I would like to dynamically load programs off 
the MMC drive into RAM, then excute them from RAM.    These would be 
transitory programs, setup programs.  Where it doesn't make sense to put 
a bunch of code that only gets once a year into FLASH.

I have not looked into the technical aspects of this, have you?

BTW, I'm using newlib.

Regards,

TomW



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

Here's my 2 cents on this. I think the LGPL was intended to cover all
kinds of "libraries" in a very generic sense. I think it was intended
to allow people to link their proprietary project against a "chunk of
code" covered under LGPL, and still be OK with commerical deployment
without requiring the rest of the source to be open.
  I think of "shared" in the sense of being "reusable" or "linkable"
as separate units. I don't think they meant that many programs on one
computer had to be able to use it. I think they were talking about
cross computer shared modules in a very generic way.
  A lot of people link to LGPL libraries with gcc and the deploy to
microcontrollers without releasing the entire source of their project.
The gcc compiler would be almost useless if you couldn't link to their
libraries and still keep your main source code protected.
  A lot of people don't know this, but even GPL (I'm not talking about
LGPL here) code can be used inside a company without requiring the
entire source code base to be released publicly. The GPL license is
all about public distribution. If your final product is only used
within a company and is never publicly released, then you don't need
to publicly release your source code, even for GPL code. But, the
minute you start selling controllers to the public you would then fall
under the requirement to open your code base if you are using GPL
code. The linksys routers use a lot of GPL code, so they were required
to release their entire source code publicly. However, if they only
linked to LGPL code they could still hide most of their source from
the public.
  LGPL code is fine for commercial deployment as long as it is somehow
separately linked to your code (at compile time or run time). Of
course, if you modify any of the LGPL code and you make some kind of
public release of a product that uses it, then you have to release the
LGPL source code that you changed. But even then, most of your code
can still be hidden from the public as long as the LGPL code can be
considered a separate body of code that was linked to your project.

I'm not a lawyer, but I think my statements are legally correct.

Eric

> If you had a transfer vector (an array of library entry points) at a
> fixed location and all of the proprietary code called library
> functions indirectly via the vector, you could just provide your
> object code and the location of the vector (leaving space for
> expansion, I suppose).  If the customer upgrades the library the entry
> points in the vector change but the library is never actually 'linked'
> into the application.  There is this clear line, the vector, where
> LGPL/GPL code is separated from proprietary code.

The EFSL lib requires two function pointers to be assigned prior to making
calls.  So implementing this shouldn't be a problem.

I just ported it to LPC214x and IAR.  Here's a memory footprint for a simple
example that reads contents of a text file on SD card to Com port, no
date/time support, no stack size optimizations:

Thumb:
 12 772 bytes of CODE  memory 
    512 bytes of DATA  memory (+ 77 absolute ) 
    851 bytes of CONST memory 

ARM / generating no interwork code:
 20 020 bytes of CODE  memory 
    512 bytes of DATA  memory (+ 77 absolute ) 
    851 bytes of CONST memory 

Compiled with IAR V4.30A.

This is a pretty nice library.


Joel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

donhamilton2002 wrote:
> I will leave the discussion about the legalities alone.
> 
> I would like to know, those whom have used this code.
> 
> What is the speed of writing a file to the media?
> 
> Whether using an AVR or an ARM chip.
> 
> Just how fast can I (we) write to the media?
> 
> There is a lot of code here to run through, latency is my interest.

I'm wondering about this too.

Tom, do you have a general idea about how long the card
responds with a busy condition after issuing the WRITE_BLOCK
command?

And have you tried the WRITE_MULTIPLE_BLOCK command?
- From what I've read in some of the sandisk documents,
their flash products internally use blocks much larger
than a single 512-byte sector, so using the WRITE_MULTIPLE_BLOCK
command may help to write more efficiently (faster, smoothly) and
probably also reduce wear of the flash medium.

I'm looking into this for my hobby project, a digital bat
detector. It records ultrasonic bat audio at around 250 kS/s
and writes it directly onto a flash disk. This recording can
then be slowed by 16 times to make it audible to humans or be
read in on a PC for frequency analysis.
Since the data is coming in at a steady rate and there's not a lot
of RAM to buffer incoming samples, I think I have to be careful
to avoid delays when writing to the flash.

I expect to receive the hardware (LPC2148) this week, so I hope
I can help to answer some of these questions myself in a few weeks.

Kind regards,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDgkIBETD6mlrWxPURAgw6AKCdZRN0kj35a05QsfkBppHePOy1IwCfap3Y
LYi3H36Tj/rez8XbjniIjBY=
=ir/I
-----END PGP SIGNATURE-----

Bertrik Sikken wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>donhamilton2002 wrote:
>  
>
>>I will leave the discussion about the legalities alone.
>>
>>I would like to know, those whom have used this code.
>>
>>What is the speed of writing a file to the media?
>>
>>Whether using an AVR or an ARM chip.
>>
>>Just how fast can I (we) write to the media?
>>
>>There is a lot of code here to run through, latency is my interest.
>>    
>>
>
>I'm wondering about this too.
>
>Tom, do you have a general idea about how long the card
>responds with a busy condition after issuing the WRITE_BLOCK
>command?
>  
>
No, it is not a consideration.  I am doing a commercial product and the 
processor running the SD/MMC drive has few time critical constraints, so 
a write could take 1ms or 1 second and it wouldn't affect me that much 
at all.

I'm happy that I finally have file streams working with an MMC drive for 
my project!

>And have you tried the WRITE_MULTIPLE_BLOCK command?
>- From what I've read in some of the sandisk documents,
>their flash products internally use blocks much larger
>than a single 512-byte sector, so using the WRITE_MULTIPLE_BLOCK
>command may help to write more efficiently (faster, smoothly) and
>probably also reduce wear of the flash medium.
>
>  
>
The program is not structure for Multiple Sector operations.  However, 
using Multiple Sectors is problematic at best.  To effectively write 
data in chunks larger than 512bytes, you would have to configure the 
BLOCK_SIZE (CMD51) so that both reads and writes would use the larger 
block.  This becomes a huge problem of now that you have to deblock down 
to a smaller size to utilize 512byte sectors within the RDCF2.

Doing Multiple Writes of a BLOCK_SIZE of 512bytes gains you nothing.  
Each BLOCK_SIZE of data is treated by the SD/MMC as a unit which must be 
programmed, regardless of the physical blocking on the device.

Why not take the RDCF2 code and try some of this out?

>I'm looking into this for my hobby project, a digital bat
>detector. It records ultrasonic bat audio at around 250 kS/s
>and writes it directly onto a flash disk. This recording can
>then be slowed by 16 times to make it audible to humans or be
>read in on a PC for frequency analysis.
>Since the data is coming in at a steady rate and there's not a lot
>of RAM to buffer incoming samples, I think I have to be careful
>to avoid delays when writing to the flash.
>  
>
So, treat the MMC device as a block mapped device rather than a file 
structured device.  You won't have a filesystem on it, but you'll have 
your data.   You can use dd to extract your data.  If you are are under 
cygwin the dd command should be there.  Under windows itself you would 
have to write some software to do what un*x gives you for free.

>I expect to receive the hardware (LPC2148) this week, so I hope
>I can help to answer some of these questions myself in a few weeks.
>
>  
>
-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

> 
> So, treat the MMC device as a block mapped device rather than a file 
> structured device.  You won't have a filesystem on it, but you'll have 
> your data.   You can use dd to extract your data.  If you are are under 
> cygwin the dd command should be there.  Under windows itself you would 
> have to write some software to do what un*x gives you for free.

If you use Cygwin and are used to Linux where you can mount devices
in a raw format, then the utility filedisk works out to be pretty
useful. You can mount iso images via a loopback device as under
Linux, you can create a fake floppy and dd data to and from it
to use as a boot floppy for VmWare, and I am sure it'll be
useful for raw sector access to an MMC.

(I've no affiliation with this, just played with it when using
Vmware).

A Google search for 'filedisk' shows up this site:

http://www.acc.umu.se/~bosse/

I think this is the utility I am referring to :)
(Haven't used it for a while)

Dave

Time to set the record straight.

From the LGPL:

'For example, if you distribute copies of the library, whether gratis or 
for a fee, you must give the recipients all the rights that we gave you. 
You must make sure that they, too, receive or can get the source code. 
If you link other code with the library, you must provide complete object 
files to the recipients, so that they can relink them with the library 
after making changes to the library and recompiling it.  And you must show 
them these terms so they know their rights.'

In others words you don't have to release your source, just the source for 
changes to the library. However you must also release the object files for 
the source that links with the LPGL code.

This isn't a big deal for applications that link dynamically since the 
binary you would have distributed is in fact object code (for example if 
you make a new web browser that links with the LGPL OpenSSL library, you 
just need to provide your users with the binary, which you would have done 
anyway). However in an embedded system without dynamic linking you would 
have to provide ALL of your object code (i.e. all the .o files) and the 
makefile/scripts or whatever you used to build your embedded target.

Note that if the creator of the LGPL library adds a clause allowing 
'release without your object code provided the changes are outside the 
LGPL library' (for example the ECOS project) then you don't need to 
release your object code. However I have not seen such a clause for the 
EFSL library (please correct me if I am wrong).

The net result is that if you use an LGPL libary in your embedded target 
you must provide the changes to the EFSL library in addition to the object 
code built from your source. If you have dynamic linking this can be the 
executable itself. However if you only have static linking then you must 
provide all of your object code plus any makefiles you used to build your 
target.

Many people are familiar with the uIP and lwIP stacks, which started out 
very strict and changed to BSD. Another example is libTomCrypt which was 
GPL (or LGPL, I can't remember) and is now public domain. They changed 
because people couldn't use their libraries in statically linked embedded 
designs without releasing their object code (or worse, they used GPL 
resulting in release of all the source). Hopefully the EFSL maintainers 
will either add a clause (as in ECOS) or change the license to BSD/MIT/PD.

If you have any questions please feel to email me directly (off the list 
if you want).

- Rod

--
                          ___  ____  ___    _      ___
  Rod Moffitt            / _ \/ __ \/ _ \  (_)__  / _/__
  http://rod.info       / , _/ /_/ / // / / / _ \/ _/ _ \
  rodANTISPAM@... /_/|_|\____/____(*)_/_//_/_/ \___/
  =======================================================
  ~ Where loved ones are remembered http://memoriam.org ~

Update on EFSL licensing as of today:

"I just took a look at the ecos license and it seems to be what we're
looking for. I'll speak with Lennart tomorrow about this. Expect to see
the license changed in the next efsl-release. Until then, feel free to
use the library with closed-src programs, we won't sue you ;)"

Thanks for the input Rod!

Joel

Glad that I could help out.

I am very pleased that the EFSL folks are changing their license. ECOS is 
a wonderful example of how an embedded friendly open-source license can 
protect the contributions while also allowing closed source use.

- Rod

--
                          ___  ____  ___    _      ___
  Rod Moffitt            / _ \/ __ \/ _ \  (_)__  / _/__
  http://rod.info       / , _/ /_/ / // / / / _ \/ _/ _ \
  rodANTISPAM@... /_/|_|\____/____(*)_/_//_/_/ \___/
  =======================================================
  ~ Where loved ones are remembered http://memoriam.org ~

On Tue, 22 Nov 2005, Joel Winarske wrote:

> Update on EFSL licensing as of today:
>
> "I just took a look at the ecos license and it seems to be what we're
> looking for. I'll speak with Lennart tomorrow about this. Expect to see
> the license changed in the next efsl-release. Until then, feel free to
> use the library with closed-src programs, we won't sue you ;)"
>
> Thanks for the input Rod!
>
> Joel
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Version 1.4 of the RDCF2 filesystem is available.  This release allows 
fseek() to be used with fread() & fwrite() on files opened with r+, w+, 
a+ modes to perform random file I/O.

The example and rdcf2 sources are on: http://openhardware.net

Regards,

TomW


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

Tom,

I just looked, and I can only see up to version 1V3.

Yup, I was using Firefox to look!   :-)

--Dave



--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:

>
> Version 1.4 of the RDCF2 filesystem is available.  This release allows 
> fseek() to be used with fread() & fwrite() on files opened with r+, w+, 
> a+ modes to perform random file I/O.
> 
> The example and rdcf2 sources are on: http://openhardware.net
> 
> Regards,
> 
> TomW
> 
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>

Since there is alot of intrest for the FAT fie system, why don't 
someone setup a seperate yahoo group for it.

Gus
--- In lpc2000@yahoogroups.com, "derbaier" <dershu@s...> wrote:
>
> Tom,
> 
> I just looked, and I can only see up to version 1V3.
> 
> Yup, I was using Firefox to look!   :-)
> 
> --Dave
> 
> 
> 
> --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
> >
> > Version 1.4 of the RDCF2 filesystem is available.  This release 
allows 
> > fseek() to be used with fread() & fwrite() on files opened with 
r+, w+, 

> > a+ modes to perform random file I/O.
> > 
> > The example and rdcf2 sources are on: http://openhardware.net
> > 
> > Regards,
> > 
> > TomW
> > 
> > 
> > -- 
> > Tom Walsh - WN3L - Embedded Systems Consultant
> > http://openhardware.net, http://cyberiansoftware.com
> > "Windows? No thanks, I have work to do..."
> > ----------------------------------------------------
> >
>

> Version 1.4 of the RDCF2 filesystem is available.  

Would it be possible to adapt this to the use of SD cards?


	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

derbaier wrote:

>Tom,
>
>I just looked, and I can only see up to version 1V3.
>
>Yup, I was using Firefox to look!   :-)
>
>  
>
You were too fast!  I forgot to put the link in there until a few 
minutes after posting.  heh

TomW




>--Dave
>
>
>
>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>  
>
>>Version 1.4 of the RDCF2 filesystem is available.  This release allows 
>>fseek() to be used with fread() & fwrite() on files opened with r+, w+, 
>>a+ modes to perform random file I/O.
>>
>>The example and rdcf2 sources are on: http://openhardware.net
>>
>>Regards,
>>
>>TomW
>>
>>
>>-- 
>>Tom Walsh - WN3L - Embedded Systems Consultant
>>http://openhardware.net, http://cyberiansoftware.com
>>"Windows? No thanks, I have work to do..."
>>----------------------------------------------------
>>
>>    
>>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>


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

haare_in_der_dusche wrote:

>>Version 1.4 of the RDCF2 filesystem is available.  
>>    
>>
>
>Would it be possible to adapt this to the use of SD cards?
>
>
>  
>
I cannot say, that is proprietary information an you have to sign your 
life away to get it.

TomW



>	
>
>	
>		
>___________________________________________________________ 
>Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>


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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

haare_in_der_dusche wrote:
>>Version 1.4 of the RDCF2 filesystem is available.  
> 
> 
> Would it be possible to adapt this to the use of SD cards?

I'm currently working on getting it to work with an SD card.
As far as I understand, SD cards also support the "SPI mode",
just like MMC cards.
If/when I get something working, I'll let you know.

My hardware platform is an LPC2148 quickstart board + a
protoboard from embedded artists. This board has an SD/MMC
connector attached to the SPI0 port.

Kind regards,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDhKozETD6mlrWxPURAhI8AKC0T6N+QckPex7Q3wvPtAXZCl79jgCeMSto
PV/22pj0TheuhvFEwtpS/CU=
=beLW
-----END PGP SIGNATURE-----

Bertrik Sikken wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>haare_in_der_dusche wrote:
>  
>
>>>Version 1.4 of the RDCF2 filesystem is available.  
>>>      
>>>
>>Would it be possible to adapt this to the use of SD cards?
>>    
>>
>
>I'm currently working on getting it to work with an SD card.
>As far as I understand, SD cards also support the "SPI mode",
>just like MMC cards.
>If/when I get something working, I'll let you know.
>
>  
>
I'm getting really confused here.  AFAIK: MMC cards you can purchase 
don't have the encyrpto capabilities.   While Secure Digital card can 
have encrypted data, but also can behave as an MMC protocol card.  While 
I also understand that pure MMC cards do exist, they are becomming very 
very hard to find???

Here comes the confusion on my part: If I have a Secure Digital / MMC 
card that is working with my system, but I don't have the encryption 
information to do the security mode: isn't this, in fact, an MMC Card?

The stickers on the BOX it came in say "SD Memory Card".

Maybe I should just avoid using the term "MMC" altogether??  It sounds 
to me like a "name game"?

TomW



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

I haven't really followed this thread so I might be missing a point or 
two. We ought to remember that SD cards are not only "Secure Digital" 
capable but usually operate in a 4-bit data transfer mode in most 
high-speed commercial interfaces. It does however support the slower SPI 
mode which is how the MMC cards work although I have never looked into 
the MMC myself.

There are some enhancements to the operation of the SD card over the MMC 
etc but basically they are driven much the same way. MMC is fast being 
replaced if not so already by SD, so I would always gear my efforts 
purely towards SD.

I have never used the crypto feature of the SD as I have never required 
it plus I would need the documents/registration/NDA etc to implement it 
anyway.

MMC = SPI accessed memory
SD  = SPI or 4-bit access crypto/open memory

*Peter*


Tom Walsh wrote:

> I'm getting really confused here.  AFAIK: MMC cards you can purchase 
> don't have the encyrpto capabilities.   While Secure Digital card can 
> have encrypted data, but also can behave as an MMC protocol card.  While 
> I also understand that pure MMC cards do exist, they are becomming very 
> very hard to find???
>
> Here comes the confusion on my part: If I have a Secure Digital / MMC 
> card that is working with my system, but I don't have the encryption 
> information to do the security mode: isn't this, in fact, an MMC Card?
>
> The stickers on the BOX it came in say "SD Memory Card".
>
> Maybe I should just avoid using the term "MMC" altogether??  It sounds 
> to me like a "name game"?
>
> TomW

At 01:31 PM 11/24/05 +1000, Peter Jakacki wrote:
>I haven't really followed this thread so I might be missing a point or
>two. We ought to remember that SD cards are not only "Secure Digital"
>capable but usually operate in a 4-bit data transfer mode in most
>high-speed commercial interfaces. It does however support the slower SPI
>mode which is how the MMC cards work although I have never looked into
>the MMC myself.

Actually MMC cards use a protocol that is different from SPI and optionally 
support SPI for most but not all of their functions.  I read through the 
specs at one point since I was considering using them for a project that 
didn't end up going in that direction.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Hi all,

Since there are a bunch of knowledgable microcontroller
and Linux developers that read this list, I want to
describe a concept and see if anyone has developed
parts.

I want to look into connecting devices using networking
interfaces. In some cases the 'network' will be a
simple point-to-point link using a serial port (PLIP)
or the parallel port (PLIP), or a real network controller
(eg. like the CS8900's on the Olimex boards and others).

To see how PLIP works, I've just setup a couple of
Linux boxes and I can ping between them. I have a way
to go before understanding all the low-level details, but
at least I have a starting point to 'hack on'.

Now, at some point I'd like to replace the second
Linux box with an LPC. The caveat is now the LPC needs
to implement the other side of the PLIP protocol,
and include a TCP/IP stack for dealing with packets.

Yeah yeah, not the most efficient way to deal with
things, this is purely for entertainment at the moment.
I can however think of applications where it would make
sense to waste a little processing power to gain the
advantage of having multiple independent socket
communications between devices. (For example;
communicating between a host processor and another
processor running on a PCI board - networking
without a network interface).

I haven't played with LwIP yet, I have an Olimex board
that I'll use at some point with the CS8900 interface.
But I was wondering if anyone had used SLIP or PLIP
in applications (LPC or not really)?

Of course I will share my results.

Happy Thanksgiving! (to all the Americans out there anyway)

Dave

> Yeah yeah, not the most efficient way to deal with
> things, this is purely for entertainment at the moment.
> I can however think of applications where it would make
> sense to waste a little processing power to gain the
> advantage of having multiple independent socket
> communications between devices. (For example;
> communicating between a host processor and another
> processor running on a PCI board - networking
> without a network interface).

An interesting fit for the LPC214x series is the USB Ethernet Emulation
Model.  Linux directly supports it, and Win32 via an inf file.
 
http://www.usb.org/developers/devclass_docs/CDC_EEM10.pdf


Regards,
Joel

Tom,

>I'm getting really confused here.  AFAIK: MMC cards you can purchase 
>don't have the encyrpto capabilities.   While Secure Digital card can 
>have encrypted data, but also can behave as an MMC protocol card.  While 
>I also understand that pure MMC cards do exist, they are becomming very 
>very hard to find???
>
>Here comes the confusion on my part: If I have a Secure Digital / MMC 
>card that is working with my system, but I don't have the encryption 
>information to do the security mode: isn't this, in fact, an MMC Card?
>  
>

I can only tell you if you sign your life away ...

SD originated from MMC on top of MMC it contains 4 bit mode and encryption.
To distinguish between SD and MMC there are some differences; the SD 
card is thicker than MMC (so you can never put an SD card in a pure MMC 
slot) and the initialization is different.
As far as I know they both share the same SPI mode commands, but I have 
to get this from the specs since I only used the real MMC/SD modes on 
LPC3000 and other ARM variants.
All basic commands for reading and writing from the card are the same 
and result in the same responses. SD has extra commands for security and 
SDIO and MMC has some extra commands for a streaming mode.

Originated from the same source, MMC and SD are changing into different 
directions.
MMC is now also coming with more bits (up to 8 bits) and a higher clock 
frequency (52 MHz).

Having told you this, your life not only belongs to Bill Gates but also 
to me :~)

Rob

Rob Jansen wrote:

>Tom,
>
>  
>
>>I'm getting really confused here.  AFAIK: MMC cards you can purchase 
>>don't have the encyrpto capabilities.   While Secure Digital card can 
>>have encrypted data, but also can behave as an MMC protocol card.  While 
>>I also understand that pure MMC cards do exist, they are becomming very 
>>very hard to find???
>>
>>Here comes the confusion on my part: If I have a Secure Digital / MMC 
>>card that is working with my system, but I don't have the encryption 
>>information to do the security mode: isn't this, in fact, an MMC Card?
>> 
>>
>>    
>>
>
>I can only tell you if you sign your life away ...
>
>SD originated from MMC on top of MMC it contains 4 bit mode and encryption.
>To distinguish between SD and MMC there are some differences; the SD 
>card is thicker than MMC (so you can never put an SD card in a pure MMC 
>slot) and the initialization is different.
>As far as I know they both share the same SPI mode commands, but I have 
>to get this from the specs since I only used the real MMC/SD modes on 
>LPC3000 and other ARM variants.
>All basic commands for reading and writing from the card are the same 
>and result in the same responses. SD has extra commands for security and 
>SDIO and MMC has some extra commands for a streaming mode.
>
>Originated from the same source, MMC and SD are changing into different 
>directions.
>MMC is now also coming with more bits (up to 8 bits) and a higher clock 
>frequency (52 MHz).
>
>  
>
Thank you, since working with these cards for the first time, I was 
getting confused.  A lot of people seem to be calling the 4bit interface 
"SD" and the SPI interface "MMC".  AFAIK, the only real difference, the 
thickness aside, is that one does encryption and the other doesn't.

I was beginning to become concerned that if I continued to refer to MMC 
that others wouldn't know that you can plug an SD card into the software 
and have it runs just fine.  Maybe I'll just drop the term altogether 
then, after all, I am using SD cards + an SD socket.

Regards

TomW

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

Version 1.5 is now available.  This corrects a bug where creating a new 
file (open for write on a new file) would trash an existing one.  My fault.

I've eliminated the problem of sector thrashing when deleting files, 
rdcf2 would toggle between first & second FAT copy while deleting each 
element of the existing FAT chain.  This change has decreased the file 
write times by 100%.

The next version will need to have an IOCTL added to flush the internal 
directory state to the drive.  Currrently, if the file is not closed and 
the card removed from the socket, the filesize would be 0 bytes.  It 
appears that no data is lost, but the directory is incorrect as to the 
filesize.


TomW


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

Isn't all of the information (with the exception of the cryptography 
details) available publicly for SD?  I know that the interface 
specifications, protocols and commands for implementation of SD are 
pretty widely available.

What is it that this expensive SDIO membership gets you?



--- In lpc2000@yahoogroups.com, Rob Jansen <rob@m...> wrote:
>
> Tom,
> 
> >I'm getting really confused here.  AFAIK: MMC cards you can 
purchase 
> >don't have the encyrpto capabilities.   While Secure Digital card 
can 
> >have encrypted data, but also can behave as an MMC protocol 
card.  While 
> >I also understand that pure MMC cards do exist, they are 
becomming very 
> >very hard to find???
> >
> >Here comes the confusion on my part: If I have a Secure Digital / 
MMC 
> >card that is working with my system, but I don't have the 
encryption 
> >information to do the security mode: isn't this, in fact, an MMC 
Card?
> >  
> >
> 
> I can only tell you if you sign your life away ...
> 
> SD originated from MMC on top of MMC it contains 4 bit mode and 
encryption.
> To distinguish between SD and MMC there are some differences; the 
SD 
> card is thicker than MMC (so you can never put an SD card in a 
pure MMC 
> slot) and the initialization is different.
> As far as I know they both share the same SPI mode commands, but I 
have 
> to get this from the specs since I only used the real MMC/SD modes 
on 
> LPC3000 and other ARM variants.
> All basic commands for reading and writing from the card are the 
same 
> and result in the same responses. SD has extra commands for 
security and 
> SDIO and MMC has some extra commands for a streaming mode.
> 
> Originated from the same source, MMC and SD are changing into 
different 
> directions.
> MMC is now also coming with more bits (up to 8 bits) and a higher 
clock 
> frequency (52 MHz).
> 
> Having told you this, your life not only belongs to Bill Gates but 
also 

> to me :~)
> 
> Rob
>

>
>  Isn't all of the information (with the exception of the cryptography
>  details) available publicly for SD?  I know that the interface
>  specifications, protocols and commands for implementation of SD are
>  pretty widely available.

Yes and No.
If you go hunt for the current specs you arrive at the SD Card
Association. A stripped down version of the spec is available as a free
download, you have to pay (and AFAIK become a member) to get the full
specs.
I am not sure about use of name/SD compatibility and the logo on your
commercial product. It may be that you have to become an SD Card
Association member but it can also be such that you are allowed to use
this when you use a product from a member (e.g. use an SD interface like
in the LPC3000).

The public available spec is not complete. It does not mention any
commands and responses that are used to communicate with the card. Some
companies seem to relax this a bit an they put a modified version (or
their implementation of the spec) as free on the web. I know that Toshiba
and Sandisk have specs on their websites that contain the full
information.

>  What is it that this expensive SDIO membership gets you?

Being an SD Association member gives you access to the latest specs. The
specs for SDIO (used by I/O cards like Bluetooth, 802.11g wireless, camera
modules etc.) I could not find for free on the web.

For most of us the specs from SanDisk or Toshiba will do.
Also the older MMC specs will do since the SPI mode for SD and MMC is the
same.

Rob

David Hawkins <dwh@...> schrieb am Wed, 23 Nov 2005 21:50:14 
-0800:


> To see how PLIP works, I've just setup a couple of
> Linux boxes and I can ping between them. I have a way
> to go before understanding all the low-level details, but
> at least I have a starting point to 'hack on'.

Why hacking ? Why not reading the RFCs ??

> I haven't played with LwIP yet, I have an Olimex board
> that I'll use at some point with the CS8900 interface.
> But I was wondering if anyone had used SLIP or PLIP
> in applications (LPC or not really)?

SLIP or PLIP encapsulates IP packet for transfer. Same does Ethernet.
You just need to know where LwIP starts working with IP packets.

-- 
42Bastian Schick

>>To see how PLIP works, I've just setup a couple of
>>Linux boxes and I can ping between them. I have a way
>>to go before understanding all the low-level details, but
>>at least I have a starting point to 'hack on'.

> Why hacking ? 

Oh, well I want to start with something that works; PLIP,
and 'port' it over to a DSP running on a PCI board. So, if
I replace the PLIP data transfer routines with my PCI
transfers, I should be able to move from something
working, to something working :)

> Why not reading the RFCs ??

Thats a good point. This is the first time I have played
with the lower-levels of networking layers, so hadn't
even thought of that. I'll make sure to find the relevent
ones.

>>I haven't played with LwIP yet, I have an Olimex board
>>that I'll use at some point with the CS8900 interface.
>>But I was wondering if anyone had used SLIP or PLIP
>>in applications (LPC or not really)?
> 
> 
> SLIP or PLIP encapsulates IP packet for transfer. Same does Ethernet.
> You just need to know where LwIP starts working with IP packets.
> 

That's what I figured. So in much the same way as I am
going to hook into the lowest layer of the PLIP driver,
I'll hook into the lower layer of the LwIP layers.

I just figured I'd see if anyone else out there had
tinkered with this stuff.

Dave

> An interesting fit for the LPC214x series is the USB Ethernet Emulation
> Model.  Linux directly supports it, and Win32 via an inf file.
>  
> http://www.usb.org/developers/devclass_docs/CDC_EEM10.pdf
> 

Hey Joel,

I like this idea too :)

Thanks for the reference!
Dave

Not sure if you guys are aware of this document, but this document:

http://www.freescale.com/files/32bit/doc/ref_manual/MC9328MX1RM.pdf

contains information on the MMC/SD protocol, commands and responses, 
password unlock, and even some details on SDIO.  Far from complete, 
but a pretty good source of information.  Even has functional code 
that illustrates how to do many things.

--- In lpc2000@yahoogroups.com, "Rob Jansen" <rob@m...> wrote:
>
> >
> >  Isn't all of the information (with the exception of the 
cryptography
> >  details) available publicly for SD?  I know that the interface
> >  specifications, protocols and commands for implementation of SD 
are
> >  pretty widely available.
> 
> Yes and No.
> If you go hunt for the current specs you arrive at the SD Card
> Association. A stripped down version of the spec is available as a 
free
> download, you have to pay (and AFAIK become a member) to get the 
full
> specs.
> I am not sure about use of name/SD compatibility and the logo on 
your
> commercial product. It may be that you have to become an SD Card
> Association member but it can also be such that you are allowed to 
use
> this when you use a product from a member (e.g. use an SD 
interface like
> in the LPC3000).
> 
> The public available spec is not complete. It does not mention any
> commands and responses that are used to communicate with the card. 
Some
> companies seem to relax this a bit an they put a modified version 
(or
> their implementation of the spec) as free on the web. I know that 
Toshiba
> and Sandisk have specs on their websites that contain the full
> information.
> 
> >  What is it that this expensive SDIO membership gets you?
> 
> Being an SD Association member gives you access to the latest 
specs. The
> specs for SDIO (used by I/O cards like Bluetooth, 802.11g 
wireless, camera
> modules etc.) I could not find for free on the web.
> 
> For most of us the specs from SanDisk or Toshiba will do.
> Also the older MMC specs will do since the SPI mode for SD and MMC 
is the

> same.
> 
> Rob
>

> I haven't played with LwIP yet, I have an Olimex board that 
> I'll use at some point with the CS8900 interface.
> But I was wondering if anyone had used SLIP or PLIP in 
> applications (LPC or not really)?

I have implemented a SLIP-like application on a MC68360 in the past.
SLIP is really incredibly simple. It's the IP packets straight out of
the TCP/IP stack with a checksum shoved on the end. I suspect PLIP may
be as trivial.
The SLIP I was using wasn't normal...it could communicate multidrop
using cascaded devices all talking synchronously (it was a multi-point
IP network). It never made it out to the real world, but it certainly
all worked.

At the time the processor was running pSOS+ (a thing of the past now)
which had a TCP/IP stack and an poorly/undocumented network interface
layer so I was able to plug in there. pSOS+ = $$$$ and I'd never go
there now.

Despite the fact the 68360 had dedicated communications engines and very
cool serial port support, the power of the LPC main processors is huge
by comparison. You should have no problem.

It's worth including compressed header SLIP support if you're going that
way. It cuts down the traffic by removing redundant TCP/IP packet
headers and replacing them with a token to refers back to the original
header.

> Happy Thanksgiving! (to all the Americans out there anyway)

Oh yeah this is the time of year all you Yanks die from badly cooked
turkeys :)

Cheers,
Bruce

Hi Bruce,

> I have implemented a SLIP-like application on a MC68360 in the past.
> SLIP is really incredibly simple. It's the IP packets straight out of
> the TCP/IP stack with a checksum shoved on the end. I suspect PLIP may
> be as trivial.

It looks pretty straightforward from what I have seen so far.

First I'm just trying to understand this stuff, and then I want
to figure out if I should take PLIP and port it to a faster parallel
interface, or create a tty interface over something that actually
uses a parallel bus (and can run at MB/s, not kB/s) and then
run SLIP over that.

Hence if someone had already got LwIP working with SLIP, I
would obviously lean towards the tty approach. (Actually
I haven't had a chance to ask that on an LwIP message group
yet ... since I haven't played with the LwIP stuff yet).

> The SLIP I was using wasn't normal...it could communicate multidrop
> using cascaded devices all talking synchronously (it was a multi-point
> IP network). It never made it out to the real world, but it certainly
> all worked.
> 
> At the time the processor was running pSOS+ (a thing of the past now)
> which had a TCP/IP stack and an poorly/undocumented network interface
> layer so I was able to plug in there. pSOS+ = $$$$ and I'd never go
> there now.

Yeah, we had some 68k's running pSOS around here until recently.

> Despite the fact the 68360 had dedicated communications engines and very
> cool serial port support, the power of the LPC main processors is huge
> by comparison. You should have no problem.
> 
> It's worth including compressed header SLIP support if you're going that
> way. It cuts down the traffic by removing redundant TCP/IP packet
> headers and replacing them with a token to refers back to the original
> header.

I was reading the 'Linux Network Administrator's Guide' and it mentioned
SLIP and CSLIP. I found the RFC for SLIP, but haven't looked for
CSLIP stuff.

I managed to get a PLIP setup working with the non-ethernetworked
machine being able to surf the web, so I have a much better
understanding of the network configuration now; point-to-point
setup, gateway machine configuration, ARP proxy - all new to me.

I'll play with SLIP after I take a look at the lower-levels
of the Linux PLIP driver to see how the hardware layer works.

>>Happy Thanksgiving! (to all the Americans out there anyway)
> 
> Oh yeah this is the time of year all you Yanks die from badly cooked
> turkeys :)

Actually, they like deep frying them now-a-days. Its nice since
it keeps the fire deparment busy. (I'm from New Zealand,
I just happen to live here, so technically not a Yank :).

Thanks!
Dave

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Walsh wrote:
> Bertrik Sikken wrote:

>>And have you tried the WRITE_MULTIPLE_BLOCK command?
>>- From what I've read in some of the sandisk documents,
>>their flash products internally use blocks much larger
>>than a single 512-byte sector, so using the WRITE_MULTIPLE_BLOCK
>>command may help to write more efficiently (faster, smoothly) and
>>probably also reduce wear of the flash medium.
> 
> The program is not structure for Multiple Sector operations.  However, 
> using Multiple Sectors is problematic at best.  To effectively write 
> data in chunks larger than 512bytes, you would have to configure the 
> BLOCK_SIZE (CMD51) so that both reads and writes would use the larger 
> block.  This becomes a huge problem of now that you have to deblock down 
> to a smaller size to utilize 512byte sectors within the RDCF2.
> 
> Doing Multiple Writes of a BLOCK_SIZE of 512bytes gains you nothing.  
> Each BLOCK_SIZE of data is treated by the SD/MMC as a unit which must be 
> programmed, regardless of the physical blocking on the device.

I have no data on what CMD51 does, but as far as I know, the block
size cannot really be modified. Reading a block smaller than 512
bytes is possible, but writing only allows 512-byte blocks.

According to the documents I have, the WRITE_MULTIPLE_BLOCK can
actually improve performance. For example, it says:
"If speed is critical in a design, Multiblock mode is the faster
and recommended mode.  The more blocks that can be written in
Multiblock mode the better the performance of the design."
and also
"In order to re-write a single 512 byte block, all other blocks
belonging to the same Erase Block will be simultaneously erased
and need to be rewritten."

On the other hand, I understand that it's not quite a natural
match to use multiple blocks with FAT.

> 
> Why not take the RDCF2 code and try some of this out?

Yes, I did. I modified your code to use SPI0 instead of SPI1 + some
other modifications to make it run on my hardware (a LPC2148 quickstart
board + prototype board from embedded artists). Reading seemed to work
fine, but I couldn't get writing to work yet.

I also hope to get some real-world numbers for single vs.
multiple block writes this weekend.

>>I'm looking into this for my hobby project, a digital bat
>>detector. It records ultrasonic bat audio at around 250 kS/s
>>and writes it directly onto a flash disk. This recording can
>>then be slowed by 16 times to make it audible to humans or be
>>read in on a PC for frequency analysis.
>>Since the data is coming in at a steady rate and there's not a lot
>>of RAM to buffer incoming samples, I think I have to be careful
>>to avoid delays when writing to the flash.
>> 
>>
> 
> So, treat the MMC device as a block mapped device rather than a file 
> structured device.  You won't have a filesystem on it, but you'll have 
> your data.   You can use dd to extract your data.  If you are are under 
> cygwin the dd command should be there.  Under windows itself you would 
> have to write some software to do what un*x gives you for free.

Indeed, doing it that way is probably the best way to initially get
something working. Eventually I really like to use a file system.
I'm thinking of a kind of hybrid solution, where I let an existing
FAT driver (yours, or perhaps the embedded-file-system-library)
create a relatively large file for me. Then, when actually starting
the recording, my program simply rewrites the data portion of the
file. For that, I only need a way to make sure that the file is
contiguous and a hook to find out the first sector.

All the best,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDiJXCETD6mlrWxPURAl0iAJ92UTktAhVgY1RV/Jkt477tRIyHQgCgjYJC
9i9ZI7AqNB8rpls70pjdLjk=
=m2ps
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again,

Tom Walsh wrote:
> Bertrik Sikken wrote:
>>And have you tried the WRITE_MULTIPLE_BLOCK command?
>>- From what I've read in some of the sandisk documents,
>>their flash products internally use blocks much larger
>>than a single 512-byte sector, so using the WRITE_MULTIPLE_BLOCK
>>command may help to write more efficiently (faster, smoothly) and
>>probably also reduce wear of the flash medium.
>>
> 
> The program is not structure for Multiple Sector operations.  However, 
> using Multiple Sectors is problematic at best.  To effectively write 
> data in chunks larger than 512bytes, you would have to configure the 
> BLOCK_SIZE (CMD51) so that both reads and writes would use the larger 
> block.  This becomes a huge problem of now that you have to deblock down 
> to a smaller size to utilize 512byte sectors within the RDCF2.
> 
> Doing Multiple Writes of a BLOCK_SIZE of 512bytes gains you nothing.  
> Each BLOCK_SIZE of data is treated by the SD/MMC as a unit which must be 
> programmed, regardless of the physical blocking on the device.
> 
> Why not take the RDCF2 code and try some of this out?

I did some experiments to get a feel for the write speed.
It turns out that, contrary to what I expected, the WRITE_MULTIPLE_BLOCK
command is hardly any faster than the WRITE_BLOCK command.

I measured the time it took to read and write 4MB of contiguous raw data
directly onto the disk (without a file system). Writing was done both
with the WRITE_BLOCK command and the WRITE_MULTIPLE_BLOCK.
The WRITE_MULTIPLE_BLOCK command was configured to write 256 sectors
of 512 bytes (128 kB). I measured the time by looking at my wristwatch.
My hardware is a LPC2148 quickstart board from embedded artists,
configured to run at 60 MHz PCLK and 7.5 MHz SPI clock (highest possible
for SPI0). My results are:

read            13 s
write single    14 s
write multiple  13 s

I find it surprising that the write speed is not significantly slower
than the read speed.

While waiting for the card response the software lights a LED, so this
gives me a rough idea how much time is spent waiting and how much is
spent actually sending data over SPI.
When I look at the LED, I see a distinct flashing pattern. It seems
that for every 128kB (256 sectors) written, the LED lights longer
than for the other sectors, both for single block and multi-block
writes. I guess the card caches 256 contiguous blocks and then
writes those in one go.

This was on a standard Kingston 128 MB SD card, which uses multi-level
memory cells and is specified for up to 1.5 MB/s, which I think is
rather slow. Other cards probably give other/better results.

All the best,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDiOuSETD6mlrWxPURAv/MAJsGMteEYzDpuz6gzGG7ze9DrY8z2QCcCCYA
DqeXFSI5rIbLW/WWBzVEOYo=
=nDGF
-----END PGP SIGNATURE-----

--- In lpc2000@yahoogroups.com, Bertrik Sikken <bertrik@z...> wrote:

> I did some experiments to get a feel for the write speed.
> 
> I measured the time it took to read and write 4MB of contiguous
> raw data directly onto the disk (without a file system). Writing
> was done both with the WRITE_BLOCK command and the
> WRITE_MULTIPLE_BLOCK.  The WRITE_MULTIPLE_BLOCK command was
> configured to write 256 sectors of 512 bytes (128 kB). I measured
> the time by looking at my wristwatch.  My hardware is a LPC2148 
> quickstart board from embedded artists, configured to run at 60
> MHz PCLK and 7.5 MHz SPI clock (highest possible for SPI0). 

Thanks for the test, this is good information.  However 
unfortunately I don't think that this is an accurate representation 
of the speed of the card itself.  Keep in mind that you have several 
limiting factors:
- 7.5MHz SPI clock (max is 25MHz, so you're 1/3rd the throughput 
there), I haven't worked with this chip yet, but why is the max 
speed 7.5MHz?
- Using SPI mode instead of SD mode.
- Optimization and organization of code

SPI mode *maximum* (for either SD or MMC) has 125KB/sec/MHz, so at 
7.5MHz your theoretical max is only 930KB/sec.

I'm not sure of how accurate the speeds reported for the cards are, 
but this may be like how my HD has a "max speed of 60MB/sec! {small 
text: burst mode from cache}", and even though it's on a bus that 
has 100MB/sec max, I only see 30MB/sec on average.

I'm also not sure if this is true, but it may also be that since 
your card is 1.5MB/sec (I assume in SPI mode and not SD 4-bit mode) 
then your card speed may be only 60KB/sec/Mhz (if it is SD) or 
75KB/sec/MHz (if it is MMC).  This translates to 450KB/sec or 
560KB/sec for SD/MMC respectively.

You're seeing about 320KB/sec. I'd guess that the code that you are 
using is not optimized (?), so it's not surprising that you're 
getting only 30% or 60% of the max speed.

Would you be able to run another test, however perhaps with the 
following modifications?

a) figure out if I'm right about the speed limit, try to benchmark 
the card speed on your computer with a USB2.0 card reader (if you 
have one).

b) use a timer algorithm in the LPC2148 to time 
- 1) the amount of time spent waiting per call to the chip
- 2) the total amount of time the read/write operation took.  

c) see if there are any simple optimizations that can be done to the 
code, or post it here and see if anyone has any ideas on how to make 
it more efficient.

It would be interesting to see what those tests show.

> My results are:
> 
> read 13s; write single 14s; write multiple 13s
> 
> I find it surprising that the write speed is not significantly 
> slower than the read speed.

Keep in mind the speed that you're operating at vs the maximum 
speed.  Let's say that on your card (at 7.5MHz) the write operation 
can occur at 400KB/sec, and the read operation at 800KB/sec.  
Because your throughput is only 320KB/sec they will both appear to 
take the same amount of time.

-- Sean

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

seangra wrote:
> --- In lpc2000@yahoogroups.com, Bertrik Sikken <bertrik@z...> wrote:
> 
>> I did some experiments to get a feel for the write speed.
>>
>> I measured the time it took to read and write 4MB of contiguous
>> raw data directly onto the disk (without a file system). Writing
>> was done both with the WRITE_BLOCK command and the
>> WRITE_MULTIPLE_BLOCK.  The WRITE_MULTIPLE_BLOCK command was
>> configured to write 256 sectors of 512 bytes (128 kB). I measured
>> the time by looking at my wristwatch.  My hardware is a LPC2148
>> quickstart board from embedded artists, configured to run at 60
>> MHz PCLK and 7.5 MHz SPI clock (highest possible for SPI0).
> 
> Thanks for the test, this is good information.  However
> unfortunately I don't think that this is an accurate representation
> of the speed of the card itself.  Keep in mind that you have several
> limiting factors:
> - 7.5MHz SPI clock (max is 25MHz, so you're 1/3rd the throughput
> there), I haven't worked with this chip yet, but why is the max
> speed 7.5MHz?

I'm using the SPI0 peripheral. The clock speed of this peripheral
is the PCLK (60 MHz) divided by some divider which has a minimum
value of 8.

> - Using SPI mode instead of SD mode.

I think SD modes are too complicated and even less documentation
is available for them than for SPI mode.

> - Optimization and organization of code

The basic loop for running the test is really simple.
The processor spends most of its time waiting for the card to
respond. I don't think that optimisation will help a lot.

> SPI mode *maximum* (for either SD or MMC) has 125KB/sec/MHz, so at
> 7.5MHz your theoretical max is only 930KB/sec.
> 
> I'm not sure of how accurate the speeds reported for the cards are,
> but this may be like how my HD has a "max speed of 60MB/sec! {small
> text: burst mode from cache}", and even though it's on a bus that
> has 100MB/sec max, I only see 30MB/sec on average.
> 
> I'm also not sure if this is true, but it may also be that since
> your card is 1.5MB/sec (I assume in SPI mode and not SD 4-bit mode)
> then your card speed may be only 60KB/sec/Mhz (if it is SD) or
> 75KB/sec/MHz (if it is MMC).  This translates to 450KB/sec or
> 560KB/sec for SD/MMC respectively.
> 
> You're seeing about 320KB/sec. I'd guess that the code that you are
> using is not optimized (?), so it's not surprising that you're
> getting only 30% or 60% of the max speed.
> 
> Would you be able to run another test, however perhaps with the
> following modifications?
> 
> a) figure out if I'm right about the speed limit, try to benchmark
> the card speed on your computer with a USB2.0 card reader (if you
> have one).

I did that test, the speed with an USB2.0 card reader on a USB2.0
card is disappointing too. The card reader has a NEODIO ND3260 chip.
It took windows XP about 55 secs to copy 36 MB worth of music files,
i.e. 650 about kB/s. I think my SD card is just slow.

> b) use a timer algorithm in the LPC2148 to time
> - 1) the amount of time spent waiting per call to the chip
> - 2) the total amount of time the read/write operation took. 

I don't know how to do this yet.
My aim was to just get a rough idea about the speed.

> c) see if there are any simple optimizations that can be done to the
> code, or post it here and see if anyone has any ideas on how to make
> it more efficient.

My code is based on the stable version of the efsl library (v0.2.5)
In my test, I wasn't even using any filesystem, just writing dummy
data at contiguous sector addresses.

> It would be interesting to see what those tests show.
> 
>> My results are:
>>
>> read 13s; write single 14s; write multiple 13s
>>
>> I find it surprising that the write speed is not significantly
>> slower than the read speed.
> 
> Keep in mind the speed that you're operating at vs the maximum
> speed.  Let's say that on your card (at 7.5MHz) the write operation
> can occur at 400KB/sec, and the read operation at 800KB/sec. 
> Because your throughput is only 320KB/sec they will both appear to
> take the same amount of time.

Ok, let me think about that.

Bertrik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDiQcEETD6mlrWxPURAm0SAJ0auVhi8nv9R8FBFXjWPuBOnv/MogCcCOcg
xxdGnFbm5LrePxKQqPFN3h4=
=+aUB
-----END PGP SIGNATURE-----

On Sun, Nov 27, 2005 at 12:11:14AM +0100, Bertrik Sikken wrote:
> It turns out that, contrary to what I expected, the WRITE_MULTIPLE_BLOCK
> command is hardly any faster than the WRITE_BLOCK command.

It helps if you use the pre-erase command as well, but in your case
I doubt this has any impact.

> The WRITE_MULTIPLE_BLOCK command was configured to write 256 sectors
> of 512 bytes (128 kB). I measured the time by looking at my wristwatch.

> read            13 s
> write single    14 s
> write multiple  13 s

These results are remarkably slow. I have not used an LPC to drive an SD
card, but I have an application that reads/writes an SD card with an
8051 based chip (8051F320) using an SPI clock of 12.5MHz, and I can achieve
around 600 KB/sec read and write speed. Your figures are about 2 orders
of magnitude slower, which suggests there is something drastically wrong
with your code.

Clyde

seangra wrote:

> SPI mode *maximum* (for either SD or MMC) has 125KB/sec/MHz, so at
> 7.5MHz your theoretical max is only 930KB/sec.

So this means theoretical minimum time == 0.137 seconds for 128 kBytes.
This is no where near the measures 13 to 14 seconds (factor 100). If 
these figures were fairly equal (e.g. factor 2~3) I would agree.

And SD or SPI mode makes no difference in read/write speed (not al long 
as we're still 100 times slower than the abs. maximum)

> I'm not sure of how accurate the speeds reported for the cards are,
> but this may be like how my HD has a "max speed of 60MB/sec! {small
> text: burst mode from cache}", and even though it's on a bus that
> has 100MB/sec max, I only see 30MB/sec on average.

I do not believe these values anymore. Sandisk specifies for their 
Extreme III cards (see 
http://www.sandisk.com/Products/Catalog(1049)-SanDisk_Extreme_III_SD_Cards.aspx):

    * Min 20MB/second** sequential read and write
(The note on that same page states that 1 MB = 1 megabyte  = 1 million 
bytes)

This would mean 20 * 8 == 160 Mbits/second and that gives a 80 MHz clock.
That same Sandisk company also states that the max. SD clock == 25 MHz.

I have a Sandisk Ultra II card (10 MB/s read, 9 MB/s write) - still 
gives a 40 MHz clock.
I tried this card on the LPC3000 with different SD clocks (20, 26, 34 
and 52 MHz - these are easy to reach clocks ...). Can still read at 52 
MHz but not write anymore and do defenitely not reach the max. that 
Sandisk states.

> Would you be able to run another test, however perhaps with the
> following modifications?


> b) use a timer algorithm in the LPC2148 to time
> - 1) the amount of time spent waiting per call to the chip
> - 2) the total amount of time the read/write operation took. 

As Bertrik states he does not (yet) know how to do this.
I wrote a fairly simple web page on how to do this: 
http://www.myvoice.nl/electronics/timing-programs.php
Did many of these tests before and can do this for Bertrik's code also 
(Bertrik, if you post your code or drop me an e-mail I can help you out 
on this one).

> c) see if there are any simple optimizations that can be done to the
> code, or post it here and see if anyone has any ideas on how to make
> it more efficient.

Optimizations ...
I was a bit confused (maybe still not fully awake) but it reads 
kilobytes, not megabytes in Bertrik's mail. With 10 kilobytes per 
seconds I am not talking about optimizations anymore.
This is more like a structural design problem ...

Tom's version of RDCF2 has 100 kBytes / second (512K file in 5 seconds)  
and slowest card measures 19 kBytes/second (512K file in 27 seconds).
Still I think this is slow compared to what I would expect.

Rob

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clyde Stubbs wrote:
> On Sun, Nov 27, 2005 at 12:11:14AM +0100, Bertrik Sikken wrote:
>> It turns out that, contrary to what I expected, the WRITE_MULTIPLE_BLOCK
>> command is hardly any faster than the WRITE_BLOCK command.
> 
> It helps if you use the pre-erase command as well, but in your case
> I doubt this has any impact.

Have you tried the pre-erase or do you get this from a datasheet?

>> The WRITE_MULTIPLE_BLOCK command was configured to write 256 sectors
>> of 512 bytes (128 kB). I measured the time by looking at my wristwatch.

You snipped the part where I said I measured the time it took to read
and write *4MB* of contiguous raw data directly onto the disk (without a
file system).
What I meant there, is that I was writing 128 kB _at a time_ with the
WRITE_MULTIPLE_BLOCK command. For the complete test I'm writing 32 of
those 128 kB blocks for a total of 4 megabytes.

>> read            13 s
>> write single    14 s
>> write multiple  13 s
> 
> These results are remarkably slow. I have not used an LPC to drive an SD
> card, but I have an application that reads/writes an SD card with an
> 8051 based chip (8051F320) using an SPI clock of 12.5MHz, and I can achieve
> around 600 KB/sec read and write speed. Your figures are about 2 orders
> of magnitude slower, which suggests there is something drastically wrong
> with your code.

No, just a misunderstanding :)
My speeds come out at roughly 300 kB/s.

Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDiZseETD6mlrWxPURAjY6AKCNj9EUUo0IXtGuqYXl7VOcv1EMyQCeJ/lH
Kq5i93kAYClODkB1ODFX69c=
=/hJf
-----END PGP SIGNATURE-----

--- In lpc2000@yahoogroups.com, Rob Jansen <rob@m...> wrote:

> I do not believe these values anymore. Sandisk specifies for their 
> Extreme III cards *Min 20MiB/second* sequential read and write
> 
> This would mean 160 Mbits/second and that gives a 80 MHz clock.

How did you get that value?  160Mbits/second with the 4-bit 
interface means 40MHz clock, which means the enhanced cards either 
support higher than 25MHz clock, or they're remapping some of the 
pins for a wider data bus.  My assumption is they've just upped the 
clock rate to 40MHz.

> I tried this card on the LPC3000 with SD clocks (20, 26, 34 
> and 52 MHz). Can still read at 52 MHz but not write.

What speed do you get for reading at 52MHz, and what speed do you 
get for writing at 26 and 34MHz?  I'm assuming this is an extreme 
III SD card you're referring to?  They've obviously bent the rules 
for this card, but I can't find any product details as to what "ESP" 
means, do you have any idea?

A different measurement:  Using the LPC2106 at 4 * 14.7456 MHz, 
portions of the WinAVR FAT12/16/32 library and a Kingston 64MB CF, I 
can read 350 KB/s.

The timing was measured while perfoming 10 loops of:
open_file
read_entire_file (6,198,940 bytes)
close file

It took 2m 57s

I haven't looking at the byte transfer timing to see if it can be 
kicked up but I would think it wouldn't go much faster.  After all, 
I haven't implemented any 'wait' state:

void ataReadDataBuffer(unsigned char *Buffer, unsigned short 
numBytes)
{
unsigned short i;

// set up device
IOCLR  = ADDR_MASK;
IODIR &= DB_INPUT;
CS(CS_CF);// select device
	
// read data from drive
for (i=0; i < numBytes; i++)
{
 IOCLR = OEn_MASK;// set OEn low
 *Buffer++ = IOPIN >> DATA_SHIFT;
 IOSET = OEn_MASK;// set OEn high
}
CS(CS_NONE);// deselect device
}

I also haven't reviewed the Kingston spec or tried any of 
the 'faster' CF devices.  About the only thing that 'could' improve 
would be seek time.

For my MP3 application I need to transfer about 1 MB/minute and I am 
about 20 times faster than required.

Richard

Never on a Sunday ...

> > This would mean 160 Mbits/second and that gives a 80 MHz clock.
>
> How did you get that value?  160Mbits/second with the 4-bit

I must have been sleeping. 4 bits interface means 2 * 8 and 160/2 == 80
My mistake, but 40 MHz is still out of spec.

> > I tried this card on the LPC3000 with SD clocks (20, 26, 34
> > and 52 MHz). Can still read at 52 MHz but not write.
>
> What speed do you get for reading at 52MHz, and what speed do you
> get for writing at 26 and 34MHz?  I'm assuming this is an extreme
> III SD card you're referring to?

This was an Extreme II card.
I did not check max. read and write speeds. I was just asked to check if 
we are able to go higher than the max. 25 MHz.
This is not for memory cards but for SDIO as far as I know (they did not 
tell me what kind of SDIO)

Rob

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

seangra wrote:
> c) see if there are any simple optimizations that can be done to the
> code, or post it here and see if anyone has any ideas on how to make
> it more efficient.
> 
> It would be interesting to see what those tests show.
> 
>> My results are:
>>
>> read 13s; write single 14s; write multiple 13s
>>
>> I find it surprising that the write speed is not significantly
>> slower than the read speed.
> 
> Keep in mind the speed that you're operating at vs the maximum
> speed.  Let's say that on your card (at 7.5MHz) the write operation
> can occur at 400KB/sec, and the read operation at 800KB/sec. 
> Because your throughput is only 320KB/sec they will both appear to
> take the same amount of time.

Your were right about the optimisations and the throughput
limitations.

First of all, I realised thath the results above were obtained
with code compiled for thumb, so I changed that to arm.

Also I added a dummy write test, which basically just writes
4 million bytes of value 0xFF (a NOP command for the card).
The theoretical transfer time for sending it over a 7.5 MHz
SPI link is just 4.5 sec. However, this took 11 seconds.
It turns out that the code I was using, calls a subroutine for
every byte transfered. This subroutine selects the SPI slave
and transfers just one byte over SPI, then deselects.
I changed this to do the SPI slave (de)select only once for each
block and then transfer a block without calling any subroutines.

Finally, I tried a different memory card: an "A-DATA SD 60x 256".
This card claims 7 MB/s write speed. In my card reader, I got
3.3 MB/sec.

My results are now (seconds per 4 MB transfered):
                A-Data   Kingston
dummy             6         6
read              8         8
write single      9        10
write multi       7         8

The dummy write time is still a bit above the theoretical maximum,
but it is a large improvement over the original 11 seconds.

My conclusions so far:
* multiple block write is indeed faster than single block write
* but not by much, because most of the time is spent in SPI0 transfer
* SPI0 transfer is a bit disappointing because of the 7.5 MHz max speed.

Kind regards,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDigkKETD6mlrWxPURAmviAKCEUh+dk2kcgDb9MAvR7CfwGQFA/ACeK366
rkqQUkGpK9EDQlw0HF13wxc=
=Qdkc
-----END PGP SIGNATURE-----

At 02:29 PM 11/27/2005, Bertrik Sikken wrote:
>Your were right about the optimisations and the throughput
>limitations.
>
>First of all, I realised thath the results above were obtained
>with code compiled for thumb, so I changed that to arm.
>
>Also I added a dummy write test, which basically just writes
>4 million bytes of value 0xFF (a NOP command for the card).
>The theoretical transfer time for sending it over a 7.5 MHz
>SPI link is just 4.5 sec. However, this took 11 seconds.
>It turns out that the code I was using, calls a subroutine for
>every byte transfered. This subroutine selects the SPI slave
>and transfers just one byte over SPI, then deselects.
>I changed this to do the SPI slave (de)select only once for each
>block and then transfer a block without calling any subroutines.
>
>Finally, I tried a different memory card: an "A-DATA SD 60x 256".
>This card claims 7 MB/s write speed. In my card reader, I got
>3.3 MB/sec.
>
>My results are now (seconds per 4 MB transfered):
>                 A-Data   Kingston
>dummy             6         6
>read              8         8
>write single      9        10
>write multi       7         8

Well, you're up to 680KB/sec for the A-Data dummy mode, whereas your 
computer gets 825KB/sec.  I'm assuming that the 3.3MB/sec is operating in 
SD 4-bit mode, so assuming scaling down to 1-bit mode is 1/4 the speed.  If 
the theoretical max is 4.5 sec and you're getting 6, that's not too 
bad.  If it was heavily assembler optimized you could probably squeeze out 
20-30% more speed to be at the max, but really those speeds aren't bad.


>The dummy write time is still a bit above the theoretical maximum,
>but it is a large improvement over the original 11 seconds.
>
>My conclusions so far:
>* multiple block write is indeed faster than single block write
>* but not by much, because most of the time is spent in SPI0 transfer
>* SPI0 transfer is a bit disappointing because of the 7.5 MHz max speed.

Have you considered trying to use the SSP bus instead of SPI?  I think the 
SSP bus can operate much faster than PCLK/8, no?

-- Sean

On Sun, Nov 27, 2005 at 12:40:14PM +0100, Bertrik Sikken wrote:
> Have you tried the pre-erase or do you get this from a datasheet?

I have implemented it. It makes a small, but measurable difference on writing
sequences of blocks.

> You snipped the part where I said I measured the time it took to read
> and write *4MB* of contiguous raw data directly onto the disk (without a

Sorry, I misread your original post. 

> My speeds come out at roughly 300 kB/s.

So that could be accounted for by a slow card, though the only card I have
tried that is noticeably slower than the 600KB/s I mentioned is an old 32MB
card, and it is slower only for writing, not reading.

In my case the speed is also constrained by streaming the data via full-speed
USB, which has a theoretical upper limit of about 1 MB/s. But in general reading
an SD card should be limited only by the SPI bit rate, so even at your 7.5MHz, it
should be possible to read at closer to 900 than 300 KB/s, so I still suspect some
less than optimal coding might be contributing to your results.

Careful attention to the SPI code was required in my application to achieve
the results that I did (all written in C though, no assembly code).

Clyde

Version 1.7 of the RDCF2 filesystem for the LPC2000 is available.  
Changes include:

* bugfix: checking for drive presence was not being performed.
* added: times() function to return number of ticks since program start.
* sbrk() returns error to malloc() if heap is exhausted.

The example + source can be found at: *http://tinyurl.com/8bmk8

Regards,

TomW
*

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

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>
> The example + source can be found at: *http://tinyurl.com/8bmk8

Tom,

I like your page on building the GNU toolchain:

http://www.openhardware.net/?title=ARM%20tools%20for%20Philips%20LPC2000&dir=ArmTools&file=ThumbToolchain.html

Thanks for your work documenting this!

By the way, this page doesn't have a link to download the files for
the gdb interface:

http://gdb-jtag-arm.sourceforge.net/

But I found the download files here:

http://sourceforge.net/project/showfiles.php?group_id=133410

>The gdb-jtag-arm is documentated as part of Tobias Lorenz's diploma
thesis (pages 80-95, german). The complete diploma thesis is available
upon request

This sounds very interesting. Please let us know if you translate this
to English (maybe just these pages?). I've seen a lot of interest here
in a JTAG interface and I want to learn more about this, also.

Thanks much!
Eric

Eric Engler wrote:

>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>  
>
>>The example + source can be found at: *http://tinyurl.com/8bmk8
>>    
>>
>
>Tom,
>
>I like your page on building the GNU toolchain:
>
>http://www.openhardware.net/?title=ARM%20tools%20for%20Philips%20LPC2000&dir=ArmTools&file=ThumbToolchain.html
>
>Thanks for your work documenting this!
>
>By the way, this page doesn't have a link to download the files for
>the gdb interface:
>
>http://gdb-jtag-arm.sourceforge.net/
>
>But I found the download files here:
>
>http://sourceforge.net/project/showfiles.php?group_id=133410
>
>  
>
There is so much confusing information on the wigglers on the net.  
Almost all of it is half-baked information, they seem to think that 
people have as much understanding about them as they do.  Frustrating!

I did miss finding that.  Let me know how you made out with it and I'll 
add the information to my page so that others can benefit?

The Abatron BDI2000 that I purchased 4 months ago is working great!  
With all the lack of definitive information about wigglers, I just 
decided to take the safe route.  The project I'm doing is for a customer 
and the drop-dead is March of next year.

Regards

TomW


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