Embedded Linux questions

[Victor Odhner]

Hi, Alan.

These comments are probably way too elementary to be
of any use to you, but maybe there's something you
haven't thought of ...

Alan Dayley wrote:
> 1 - If I have my specific embedded application task
> running and only the absolutely required system tasks,
> what is the minimum and maximum latency from a switch
> out of my task and back into my task?

In an embedded system you're not going to be doing things
like rolling logs, running cron jobs, etc.  So you won't
have arbitrary "noise" jobs blocking your work.
I wouldn't expect much in the way of "required system
tasks".  Only the tasks you design into your system will be
running.  Your application will consist of a carefully-
designed master loop, possibly supported by authorized
daemons which should not hog any time.

Task-switching time will depend partly on the hardware, and
on how many registers each interrupt handler has to save.
Interrupt handlers should be very terse, leaving most of
the work for the main loop.

Also, you want to make sure your code doesn't spend any more
time than necessary with interrupts masked off -- this is
a design issue.  I don't know how uClinux stacks up in this
regard, but I presume it is done intelligently.

I presume from your description that you are planning to use
uClinux, and would not need a full-blown Linux.

> 2 - Connected to the question above, would a real-time Linux
> solve this question with hard latency times?

I presume it would firmly control any background noise tasks,
and might do less masking of interrupts inside the OS, but
the mechanics of handling interrupts per se would depend
more on the hardware's interrupt mechanism, right?

I think I saw recently that RTLinux became Free Software.
Don't trust me on that.

> How difficult is it to create a Linux app that allows
> direct writes to I/O space and stack context switching
> while still running as a Linux app?

Shouldn't this be more a function of the compiler you are
using to generate code for your device?  I don't know what
you mean by context switching -- that's just part of your
interrupt mechanism I think.  Your compiler needs to have
facilities for disabling interrupts, designating interrupt
handlers, doing absolute addressing, etc.

> This would be for the development environment, allowing
> debugging etc. on the Linux platform and then making
> the app PROM bootable and loadable before moving it into
> the target product.  We can do this sort of setup now in
> DOS.

Is your product x86 based?  Otherwise, debugging of the
platform-dependent code on an x86 development machine would
be missing some of the platform specific behavior.

> ... just point me to the book(s), online or on dead
> tree media.

Have you studied any books on this?  Rob Wehrli has
recommended this one:
  "An Embedded Software Primer" by David E. Simon

... which I'm trying to assimilate currently, and
have largely been parroting above.

Vic