Lpc2000

At 09:49 AM 4/20/06 +0000, jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> > For a standard single application system though there is no
> > advantage(1).
>
>What you mean by "single application system" is important.
>
>I prefer to look the "application" running on an embedded system as a
>set of independent and cooperating tasks, where a task in an entity
>that has a own state (stack), and which it returns to when it is
>suspended (for any reason) and then resumed.

Much the same as I do. A single application would be a single loadable 
entity.  It could be one or more tasks.  But the threads of execution are 
closely related.  There is a bit of a grey area between a single and 
multiple applications, more so than there used to be.  Tasking if present 
could be co-operative or pre-emptive.

The key differences are
         In a single application the threads are usually fairly tightly 
coupled.  In a multiple application environment they are more loosely 
coupled.  Not very precise, I know.
         In a single application the code for the tasks/threads are loaded 
into the flash as a single unit. In a multiple applications the pieces can 
be loaded separately. The latter case practically requires some sort of 
BIOS/Kernal communicated with in some indirect fashion like SWI.

Indeed I have not seen a real time kernal (as opposed to a heavier real 
time OS) that wasn't supplied as a linkable library.  Even ecos which is a 
relative heavyweight is, I think,  a linkable library.  OS/Kernal is a 
distinction I maintain but the distinction seems to have lost much of it's 
meaning over the years with items like uCOS etc. referring to themselves as 
RTOS's

As I said though, I am intrigued by the thought of restricting interrupt 
off periods to a user mode protected kernal.  I don't find leaving 
interrupts off to have been a big problem in my development but I am in 
favour of anything that will protect me from myself, especially if it's 
free.  I just have to figure out what exactly the benefits of restricting 
that access will be compared to the cognitive cost of a decoupled interface 
and loss of type checking across the SWI barrier.

>I did not think that any of the things that participants here are
>doing with the LPC falls in the latter category.  This is why I
>started with the SWI approach to my simple example atomic feed of
>watchdog timer.

A monolithic single application.  I suspect there are.  I've used the LPC 
to quickly prototype a monolithic app. It was overkill for it but for a 
prototype it allowed a rather quick assembly of components.  There was a 
time people used DOS for single monolithic embedded applications.  Actually 
I suspect some people still do.  I would be surprised if the LPC family 
wasn't being used in the same fashion.


>It does not matter to me what term is used to describe what happens on
>the two sides of the SWI fence.  It could well be public vs private,
>system vs user, kernel vs user, or infrastructure vs application.
>
>Jaya
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>

" '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/