Lpc2000

> 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