Embedded Linux questions

[Thomas Mondoshawan Tate]

--98e8jtXdkpgskNou
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 31, 2001 at 10:38:34PM -0700, Alan Dayley wrote:
> Well, we are suddenly getting down to serious decision time at my=20
> employer.  We are designing a product that potentially could have embedde=
d=20
> Linux.  Some questions have come up.
>=20
> 1 - If I have my specific embedded application task running and only the=
=20
> absolutely required system tasks, what is the minimum and maximum latency=
=20
> from a switch out of my task and back into my task?  I know a definitive=
=20
> answer here is dependent on what tasks are running so my question is vagu=
e=20
> at best.  What we need at the moment is some sort of ball-park figure to=
=20
> know if Linux is simply possible for our needs.

Difficult to say, since it depends on what CPU architecture is available,
nice priority, and what scheduler priority have been assigned to the
process. It also depends on _who_ the process is run as (I'm assuming root).
Generally, on a single-processor, lightly loaded machine (approx 2-3
processes running as root), Linux can get about 2-4ms switching times,
though if you're doing heavy IRQ work, chances are that's going to increase
fairly fast.

What kind of process were you thinking of running? Eg: what is the general
target for these kinds of applications?

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

Possibly...=20
In Linus Torvalds exact words, "In many cases I just think that RTLinux is a
worse fix than the disease. I think RTLinux is perfect for those things that
truly need latency guarantees: no OS at _all_ in the way. But using it for
'normal' stuff like just streaming audio and video is overkill. They don't
have microsecond latency requirements."

According to the linux-kernel mailing list, it is possible to give your
application realtime priority (this has little to do with the nice()
priority and deals directly with the Linux scheduler) via a
sched_setscheduler() call on a vanilla linux kernel. Thing is, the app has
to be run as root to do this. An example pair of programs that do this is
available in the archives at this URL:
http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D100108757109536&w=3D2

> 3 - If we cannot use Linux embedded, we will be using our own task=20
> switching kernel as the embedded "OS"  and we could us DOS as our=20
> development platform with the development embedded app running as a DOS=
=20
> app.  I would rather not use DOS as the development platform since it is =
a=20
> limited platform.  How difficult is it to create a Linux app that allows=
=20
> direct writes to I/O space and stack context switching while still runnin=
g=20
> as a Linux app?  This would be for the development environment, allowing=
=20
> debugging etc. on the Linux platform and then making the app PROM bootabl=
e=20
> and loadable before moving it into the target product.  We can do this so=
rt=20
> of setup now in DOS.

Well, first off, userland applications should _never_ do direct writes to
I/O, DMA, or IRQ space -- that should be reserved for kernel operations,
since you will never know when the kernel needs access to that specific
space or address. Besides, the actual code for this operation has to go
through a context switch just to run -- in other words, it's faster to do it
in the kernel rather than in user space.

If you absolutely need to do this, I'd suggest writing a driver and api for
the vanilla Linux kernel, and if you decide on doing this, I'd stay _far_
away from the RTLinux kernel. It has a ton of incredibly hackish code in
there to provide the quick latency times (eg: <=3D1ms per task switch) and =
can
make code managment quite difficult. Besides, as long as you're not doing
anything that has a high priority in another task (eg: system call for a
video capture routine via the V4L system), you shouldn't have a problem with
task switch latencies.

If you're needing something with picoseconds of latency, I would _not_
suggest any form of the Linux system for this use -- use a system that has
very little, if any at all, of the OS in the way of the actual applications.

> Hey, if you can't answer my questions because they are too general and=20
> could fill a book, just point me to the book(s), online or on dead tree
> media.

The absolute _best_ source for information regarding this is the
linux-kernel mailing list archives (don't bother subscribing to it -- far
too much information is posted to make it useful for someone not doing core
kernel work). They can be actively searched on the MARC mailing list
archives at http://marc.theaimsgroup.com/?l=3Dlinux-kernel

There are other list archives, but I've found them to have a poor, if any,
search program, which makes looking for answers quite difficult.

Also, if you're thinking about posting to it (they accept non-subscribed
posting) have a look at the linux-kernel FAQ beforehand -- people tend to be
rather busy and will ignore a post if you don't follow guidelines. The FAQ
is available at http://www.tux.org/lkml

Hope that helps.

--=20
Thomas "Mondoshawan" Tate
phoenix@psy.ed.asu.edu
http://tank.dyndns.org

--98e8jtXdkpgskNou
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE74O52Yp5mUsPGjjwRAmHgAKCB0Fi8//QD69zY5REGx6pQgQp+nwCfVeCm
9dZGhBLYd+1650zb3enHuOE=
=SlU0
-----END PGP SIGNATURE-----

--98e8jtXdkpgskNou--