Lpc2000

At 03:29 AM 4/16/06 +0000, jayasooriah wrote:
>Robert, given we are digressing, I hope you dont mind the my change of
>the thread title.

I should have thought of it myself.  I'll trim it a little further :)

>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> > >The second (probably more insidious) is that the distinction between
> > >of user and system modes appear to have been lost in the process.
> >
> > Is this distinction actually useful?  If user mode actually provided
>memory
> > protection or I/O protection mechanisms I could see a use.  As it is
>the
> > only real use I see for the mode distinctions is the register
> > saving/shadowing on interrupts.  The inability to manipulate the
>interrupt
> > flags appears to just be an annoyance/relic held over from ARM's larger
> > general purpose computer roots.
>
>One can ignore (and not enter) user mode to avoid the annoyance as you
>put it.

I realize that.

>If however one makes the distinction between user and kernel (or
>system) modes there are benefits.  Off the top of my head:
>
>1/  The designer is forced to make the distinction between
>infrastructure (kernel) from application specific (user) components.
>
>Infrastructure code is generic to multiple systems.  Application code
>does the particular task the system is designed to do.

Well, yes but that's independent of user/system mode.  I can see system 
mode being useful in large systems especially when you are loading an 
application in RAM and using a flash image as the OS/kernel.  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.

>2/  Application code can be run at a lower privilege level so as to
>avoid having to resort to extreme debugging measures when there is
>interference.

Well, yes but that was the real point of my question.  Other than the 
ability to affect the interrupt state there doesn't appear to be a 
privilege level difference between system and user modes.

>For example they could start developing an application on the target
>using techniques as simple as printf() equivalents.

You can do that anyway.  You can do a lot of debugging with simple serial 
I/O and a few pins to toggle.  Indeed there is a lot of useful , especially 
timing, information that is difficult or impossible to get other than 
through I/O pins and an oscilloscope and/or logic analyzer.

There are other times when the only real recourse is multi-megabyte trace 
and good trigger and more than a little persistence.  A problem I had on 
another processor with a commercial kernel comes to mind.

>3/  The different privilege modes supports the decomposition of
>embedded systems into a set independent and cooperating concurrent tasks.
>
>This usually means there is a simple (almost always better) way to
>describe system in terms of its constituents and how these
>constituents interact.
>
>I accept (although I do not know of one) that the distinction between
>kernel and user mode may not be appropriate in every case.

I suspect there is a legion of them.  However let me give you a simple 
one.  Linear actuator motor control.  Two, possibly three inputs (forward, 
reverse and optionally a deadman) Outputs H bridge control of the motor and 
a brake release coil. Add in ramping, deceleration tracking overload 
protection etc.

You can argue that an ARM is overkill and for the simplest variant of this 
it surely is, but with the price and them getting as low as they are it can 
make a lot of sense to use them in very similar applications in the same 
way it made sense to replace discrete logic with microcontrollers to begin 
with.

>However, in removing this distinction in the LPC family just makes it
>less usable that it could otherwise be.  Bear in mind implementors
>have the option of gating any operation with privilege mode bits
>available in the ARM core.

Well, if they had I could see an argument.  I am not aware of any who 
do.  Certainly the four I am most familiar with (Philips, ST, Atmel and 
Analog) do not.  I've yet to use a micro that had that support.

Again this was sort of the point of the question.  Since that support is 
not there is there any real advantage to the use of user mode?

If the micro provided I/O protection or memory protection I could see 
gating I/O operation to/from user mode to gain a little more protection 
from inadvertent manipulation of I/O.  A lot of the time inadvertently 
flipping a bit at the wrong time is more dangerous than changing the 
interrupt state, it's also a lot easier to do.


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/