Embedded Linux questions

[Alan Dayley]

At 02:11 AM 11/1/01 -0700, you wrote:
>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.

I have not studied uClinux yet but full-blown Linux would not be needed.

> > 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?

Correct.


>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.

The app it's self would have multiple tasks.  Because, in this part of my 
discussion, the app would need to be running it's own kernel as it would in 
the target system, I would want to run it's task switching kernel as part 
of the app.  What I mean by context switching is the ability to swap stacks 
and directly load CPU registers as the "kernel" contained within the app 
switches it's tasks.


> > 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.

Yes.  The target processor is currently a 586 class CPU.

>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.

I have studied books on embedded systems but none specific to embedding 
Linux, hence all my questions.  Is this book specific to Linux?  The title 
sounds more general.  Not that a general book would be bad, I am just 
digging for Linux info right now.

Alan