Lpc2000

At 02:25 AM 4/19/2006 +0000, jayasooriah wrote:
>I will start with the list of advantages I have already pointed out as
>arising from making the distinction between user and system modes of
>operation as follows:
>
>1/  allows codes of different maturity level (system vs user,
>operational vs experimental, infrastructure vs application) to coexist
>in the (embedded) system in a way that failure of (user) code does not
>result in failure of the entire system;

Nonsense.  If the user application hangs up the fact that the user code is 
in user mode but the kernal in system mode won't make recovery easier or 
harder.  If the user application sets the output to short a 200A hour 
battery through a FET capable of handling a 10A surge the placement of the 
kernal will affect things not one whit.

There is zero extra protection available by placing the kernal in system 
mode and the application in user mode.

>2/  provides isolation between caller and callee in providing the
>kernel primitives that will work under variety of conditions,
>including that not anticipated by the provider; and

Like what?  The closest example you have provided is ARM vs Thumb.  I don't 
buy that as significant.  If you cannot recompile your library you 
shouldn't be in this field.

>3/  renders the resulting system friendly in relation to probing by
>hooking onto kernel primitives without the need to touch user code.
>
>[This helps track down problems of the type that go away when you add
>code to the application to watch what happens.]

How is that different from a linked library similarly equipped and more to 
the point how does the user/system mode deal with it in a way that's 
different from not using user mode.

>The tools I listed as useful in achieving the above goals, without
>making the system complicated, large or inefficient are:
>
>1/  Inline functions: These behave exactly like a function that does
>not have this attribute (for type checking and so on), but at the same
>time makes the implementation visible to the compiler (and user).

Have they become standard with C99?  If so I'll probably consider them as a 
replacement for some macros when C99 support becomes more widespread.

>2/  Inline assembler: This allows target code to generate the
>appropriate binary instance of the same source code depending on how
>it is compiled (16- or 32-bit mode, interworking paradigm, and so on)
>to accommodate style and preference requirements of the application
>programmer.

We've already disagreed on this point, no point in going over it again.

>--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> > >The atomicFeed() example shows the benefits of making even just a
> > >single procedure call a kernel primitive.  I have boot loaders that
> > >run with as little as three of four kernel primitives.
> >
> > I don't yet see a benefit in using SWI over a function call.  Only
> > disadvantages.  That is the question here; not the size of whatever we
> > refer to as the kernal, since presumably that's why we are using
>user mode
> > rather than system mode.
>
>If the advantages I listed above does not apply to your scenario, then
>I can accept this statement.  I cannot see why the do not though.

The advantages listed above seem to everything to do with using a standard 
kernal/support library and nothing to do with system/user mode.  There is 
nothing I see there that has to do with CPU mode.


> > Let's see
> >
> > function call -> SWI -> Irq  cracker -> function call
> >
> > vs
> >
> > function call
> >
> > As I said earlier I don't consider this an important point.
>Remember I'm
> > one of those who think inline code is a bad idea, I'm not going to
>quibble
> > about the extra execution time of a SWI unless maybe you are calling
>it in
> > a small time critical loop.  "Premature optimization is the root of all
> > evil"  Knuth (I think)
>
>Even taking into account the, I cannot see how to make it more
>efficient :)  Probably because I do not like assembler too much!

Taking into account the what? And who said anything about assembler?


> > One line functions tend to lead to a proliferation of functions.
>
>The fact that a feature or technique can also be misused is (to me)
>not sufficient justification to barr its use.

My point exactly.  Just because you can turn something into a function 
doesn't mean you should,  I've gone down the road you suggested with 
AtomicFeed and come to the conclusion it offered no useful increase in 
abstraction, it just obscured the intent of the code.  You've obviously 
come to a different conclusion.

> > >1)  implementation does not know (and does not rely on knowing) if the
> > >caller is in 16- or 32-bit mode; and
> >
> > ?? How is that an issue? We've been talking about user/system
> > mode.  Compiling libraries for ARM/Thumb is a simple exercise.
>Trivial if
> > your 2 or 3 assembly routines are written to accommodate both.
>
>I think you do not appreciate the fact that there is only one instance
>of the kernel binary, not multiple variants depending on what mode the
>application was compiled in.

You're right I don't.  I generally don't switch modes on a regular 
basis.  On the LPC2000 family I don't see a reason to use thumb unless 
there is a space issue.  I would be surprised to find projects that did 
switch application modes often enough for this to be an issue.  I'd also be 
very worried about their quality.

>I use the ARM primitives designed just for this purpose.  Doing it
>otherwise would be more expensive in terms of code and space.

A compile switch is expensive?  Dammed if I can see how a SWI take less 
space/time than a call.  Or how switching modes reduces code space.

> > >This means that there is no need to maintain multiple version
> > >libraries for the four permutations of the two modes.
> >
> > I can see maintaining ARM/Thumb but why maintain system and user
>versions?
>
>If you use ARM/THUMB, you have to maintain two version.  In my method,
>you do not need to.

Well I see no need to ever design a system where one day I use ARM and the 
next day Thumb.  And it is quite possible to have one application require 
an ARM kernal for performance reasons and another to require a Thumb kernal 
for space reasons.  The same reasons you would need to choose between the 
two in the linked library case.  If you need to maintain two variants for 
one case you are likely to need to for the other.

Ah, maybe I see where the difference is.

Maybe you are working in an environment where you are supporting a 
multitude of simultaneous projects.

I and I suspect most others here work a little more serially.  Any one 
project is only going to use a single mode. The time spent to compile the 
support library appropriately is insignificant in this context.  Each 
project must have it's own support library/kernal carried with it since 
upgrading it will require retesting the application.

> > Your solution also needs to maintain both.  You still need a library
>
>This is where I think you have not understood the code snippet that I
>hoped will speak for itself.
>
>The kernel is compiled with the interface header and in 32-bit mode.
>There is only one instance of the kernel in memory.

Of course

>The user code is compiled in 16- or 32-bit mode, and only one version
>of its binary is in the system.  You can have one application compiled
>in 16-bit mode, and another in 32-bit mode, coexist in the same
>system, and use the same calls, with only one copy of the binary of
>each of these applications.

OK, now we are getting somewhere.  You are talking about the large system 
similar to the RAM loaded case I was talking about in an earlier 
post.  Different world entirely.  This would be possible to do with a jump 
table but that's the same thing in less convenient clothing.  Here I see an 
advantage and a big one.  It also explains why you'd want a unified image 
for the kernal. All the applications I need to deal with run a single 
application.  Multiple threads sometimes but a single application.

> >          - How does implementing a kernal help you narrow that region
> > down?
>
>Because the kernel handles all interrupt enable and disable
>operations, this is where one starts looking for problems relating
>interrupts disabled but not enabled thereafter.

OK, I can see what you are getting at,  You can instrument the function/SWI 
calls.  That's how I would normally implement a disable/restore pair in any 
case.  That still leaves the issue of finding the mismatched pair.   An 
appropriate trigger on a trace could narrow it down in a hurry though.

I just normally refer to my support library as a support library and 
reserve kernal for when I bring in task switching/threads whether 
cooperative or preemptive.  Different word choices.

>This is where I ask people to include memory protection in their
>selection of targets for their application.

I'd like to have memory protection, but I've yet to see a small inexpensive 
microcontroller with memory protection.  Actually I've yet to see a 
microcontroller (IE only internal memory) with memory protection but I 
freely admit there are many micros I've not perused.  Generally I/O is my 
first consideration.

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/