Re: Raspberry Pi, Real-Time and Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 6 Feb 2014 13:04:19 -0800 (PST), Rego, P. wrote:

>> Using the general definition, if your application has deadlines with
>> tolerances on the order of 0.1 seconds, then the answer is clearly
>> "yes".
> Very slow, but based on what?

I don't think that 10ms would be a problem even for ARM.

On an Intel board 200µs loops (read inputs, calculate, write outputs) are
doable.
 
>> For tighter tolerances, you'd have to measure the actual performance,
>> and possibly use an enhanced kernel as you discussed.

> Measuring could be excelent. Do you know some tools that I could use for
> measuring the RPi performance?

Ada has everything you need for that.

The main problem is how good the RT clock is. Windows and VxWorks typically
have miserable RT clock services on x86. x86 Linux has a decent one.

Regarding ARM Linux, I didn't tested its clock, so I cannot tell. The
primary test is to call Ada.Real_Time.Clock twice and to compare if the
reading is same. If they are you should look for an alternative
implementation of. The second test is to measure how close delay 1.0 is to
1 second using Ada.Real_Time.Clock. The deviation from 1s tells how coarse
OS programmable timer services are. There are OS means to attune that (on
the performance cost).

Once you have Ada.Real_Time.Clock it is no problem to measure the control
loop your system does. Usually you would measure several thousands of
cycles to get min, max and average times. If you have background services
to run, you do measures under load (with other services) and without load.

The OS latencies (in the driver etc) is a more difficult stuff. If the OS
does not have means to measure these times (VxWorks has), you still can
estimate these by subtracting known durations from the whole cycle time.
You can also use digital outputs which are considerably faster than
analogue ones and the oscilloscope, etc. You can calibrate digital output
times by measuring many thousands of write-cycles and taking the mean.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de