opinions to achieve 3 goals

[gregory.menke at gsfc.nasa.gov]

 > 1. Able to understand *how* rtems makes applications
 > real-time based on the target board?

Its a property of the scheduler- or more generally, a property of the
operating system itself.  If a board has a reasonable clock tick
interrupt, RTEMS will offer nominally "real-time" performance (unless
the bsp doesn't do a very good job).


 > 2. Perhaps fiddle/develop a section of it, to become
 > more familiar with it.

This will take a little while- but its necessary.  Don't sweat all the
networking stuff, find the bsp you're interested in and concentrate on
its libbsp directory, the libcpu directory for the processor and the
processor's exec/score/cpu tree.  Everything else is "userspace" stuff
and you can pick that up later.  It will be helpful if you familiarize
yourself with RTEMS configure/make infrastructure as you'll be making
(but not configuring) the kernel often as you fool with it.  A fast
compiling and easy to modify test program will be helpful, as you'll
need something to run on the target.  Don't enable tests as it takes a
while to relink them with an updated kernel- use them when you're
doing final tests on your modified kernel.


 > 3. Understand how the real-time based accuracy of the
 > rtems can me measured on a board?

We've measured it in a couple ways by virtue of the breadboard we run
RTEMS on.  Its a MIPS R3000 board with the address & data busses
connected to a logic analyzer.  By adding writes to specific memory
addresses in ram, we can trigger the analyzer whenever something we're
interested in happens.  For instance we can store a word when the
interrupt/exception routine is entered, then when the interrupt is
vectored and when the routine returns.  By accumulating this dataset
(and others) over time we can then show the ranges of the various
scheduling and interrupt service delays under various conditions.  The
other way is similar, but measures the time between the assertion of
the hardware interrupt right on the circuit board and when its
vectored.  This gives us an accurate assessment of interrupt latency
(and how much it jitters).

Basically if you want to measure RTEMS characteristics, you shouldn't
use RTEMS to do it.  If you have an onboard resource like a hardware
clocked timer, thats pretty good; read it at interrupt time, read it
again when the vectoring happens, accumulate the differences.

Gregm