Lpc2000

At 12:20 PM 4/17/2006 +0000, jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> > SWI then acts
> > as an indirect jump table to the underlying kernel functions.  But
>with the
> > small micros, especially those w/o an external bus, programs can as
>easily
> > be built with a static link and avoid the extra overhead of the SWI.
>  Both
> > the simple timing overhead and the need to build a gateway library that
> > provides the prototypes and parameter conversion from standard C
>type call
> > to an SWI based call.
>
>I know of many who think along the lines you have expressed.  They
>associate "kernel" with what is found in general purpose operating
>systems.

Actually I was thinking more along the lines of a real time 
kernel,  threads, semaphores etc..  I can see the term being extended a bit 
beyond that but at the risk of its losing its meaning.

>Allow me to challenge your perceptions relating to timing overheads
>and gateway library requirements for SWI in embedded ARM context.  I
>will use the watchdog feed example that got me involved in the earlier
>thread.

I was referring to more than just timing overhead, although that's in there 
too.

>Here is the interface

<snip>

>and the implementation

<snip>


You appear to have left out the cracker function.  Unless you are planning 
a one function kernal?


>Have a go and see how much you can trim off this implementation in
>terms of timing and gateway library interface overheads by using
>procedure calls and consider what you would stand to lose.

In this case somewhere between 50 and 80% since all you are left with is 
the implementation function.  That's not really fair though I would expect 
a real kernal to use somewhat heavier functions. I wouldn't pass the WD as 
an address to the function like that, it just confuses the interface.  Also 
something I wouldn't do inline but we've been through that ;)

However the bigger issue hasn't been addressed which is the rest of the 
overhead.  The rather simple to maintain simple function interface has been 
replaced by two functions separated by an interrupt.  Across this interrupt 
you have lost the type checking and other interface protection C normally 
provides.

You also have not addressed the issue of what this approach actually 
achieves.  Since there appears to be no extra protection added by being in 
user mode all that appears to have happened is that you've replaced one 
function call with two calls plus an interrupt (one call to setup the 
registers for the interrupt, one call from the interrupt cracker to the 
actual function).  The calls maybe inlineable but conceptually they are 
still there and what they do still needs to be done.  In return for this 
the net gain is the user mode app can't manipulate the interrupt bits.  I 
don't see the point.

I also don't see anything being lost by using a library that links directly 
rather than through a SWI.  Quite the reverse actually.

I can see three cases where this approach could be useful
         1- A large system where the kernal is loaded separately from the 
application.  Possibly with the application in RAM
         2- A multi-language app with the kernal and application having 
incompatible calling conventions.
         3- An appliance application where the kernal and chip are shipped 
as a unit.

Only for the external bus versions does 1 make much sense.  The memory 
available on the 2100's. and non external bus micros from Atmel, AD and ST 
just isn't that large.

In case two, well that's what assembly language is for :).  Or just a 
better tool set.

Case 3, well that's rather specialized.  Personally I have no desired to 
handcuff my chip source to my kernal supplier.

>Incidentally, the "vectored SWI" approach I use allows any team member
>who are play with custom "system mode" kernel calls.

"to play with" maybe?

Which is different from a linked library in what fashion?

>PS:  E&OE applies here too :)  If you spot mistakes, please do not
>hesitate to point it out.

E&OE?

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/