<html>
<head>
</head>
<body>
I will explain it a bit better here, however the interaction between boards
is quite complex so I'll make it a bit clearer<br>
<br>
Joel Sherrill wrote:<br>
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com">
<pre wrap=""><br>Are you doing any application data processing in that task? </pre>
</blockquote>
Yes<br>
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com">
<pre wrap=""><br>What mechanism are you using to wake up the task? You have something</pre>
</blockquote>
Event<br>
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com">
<pre wrap=""><br>like <br>this I think:<br><br>Start clock/Feed Test input<br> <br> ISR_Handler:<br></pre>
</blockquote>
read value from I/O board storage register<br>
<br>
CASE Data<br>
enque data
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com"></blockquote>
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com">
<pre wrap=""> Send event to input data task (only if required)</pre>
</blockquote>
send any return data (this would be the feedback data if
any) to I/O board storage register<br>
<br>
CASE houskeeping<br>
return housekeeping data to I/O board storage register OR<br>
send any return data (this would be the feedback data if
any) to I/O board storage register<br>
<br>
END CASE<br>
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com"></blockquote>
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com">
<pre wrap=""><br> RTEMS input data Task:<br> while(1)<br> wait for event</pre>
</blockquote>
while more data<br>
read data from queue <br>
take semaphore<br>
call object methods in algorithm<br>
enque output for feedback<br>
write notification to I/O board interface storage
(we are not writng the data here -- only notifying that data is ready)<br>
release semaphore<br>
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com"></blockquote>
end while more data<br>
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com">
<pre wrap=""> </pre>
</blockquote>
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com"></blockquote>
I/O board // note this is a separate board not running RTEMS<br>
receive notification from RTEMS processor<br>
Read message type (this is an output data notification) (read as
serial data from storage register)<br>
<br>
CASE data message<br>
write feedback to outputs (sent as serial data)<br>
Send housekeeping to I/O storage register (written as serial
data)<br>
Interrupt RTEMS<br>
<br>
CASE data available<br>
Send request data to I/O storage register (written as serial
data)<br>
Interrupt RTEMS<br>
<br>
CASE others<br>
<br>
END CASE <br>
<br>
scan inputs<br>
<br>
IF inputs changed THEN<br>
Send data to I/O storage register (written as serial data)<br>
Interrupt RTEMS <br>
END IF<br>
<br>
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com">
<pre wrap=""><br>I am having trouble seeing the breakdown between application time,<br>RTEMS time, and IDLE time. I can see that the RTEMS time has<br>these components:<br><br> ISR_entry<br> service to wakeup Task<br> ISR exit and scheduling of Task<br> task switch to get to Task (probably from Idle)<br> exit of blocking service in Task<br> <br>I don't think that would be much time at all. I would be guessing but<br>wouldn't think you were looking at over 200 useconds for the RTEMS<br>portion on the slowest CPUs RTEMS supports. There may be more for<br>each of the clock ticks that occurs between the start and end of<br>the process but that shouldn't be more than 4 ticks with <br>ISR entry, clock tick, and minimal exit. <br><br>This whole analysis goes out the window if you have more tasks than<br>I think. :) I think you have 2 ISRs (app and tick) and 2 tasks<br>(App feedback task and IDLE). <br></pre>
</blockquote>
The feedback is actually on a separate board running a microcontroller.<br>
The input data task has 2 ISRs for it, one for MIDI and another for other
data / housekeeping<br>
<br>
<blockquote type="cite" cite="mid:3DE29E2D.9DE0E2E1@OARcorp.com">
<pre wrap=""><br>FYI Greg Menke has some nice related measurements at <br><a class="moz-txt-link-freetext" href="http://that.gsfc.nasa.gov/osgroup/">http://that.gsfc.nasa.gov/osgroup/</a>. I think you will see that even<br>on a 12 Mhz R3000 MIPS, the performance is respectable. Greg ran<br>a number of benchmarks and is normally quite happy to discuss things.<br><br>>From my perspective the important thing is the algorithmic order of<br>the operations required. In that light, the most important places<br>that are of non-costant order in RTEMS are:<br><br> + memory allocation<br> + clock tick (multiple events can fire in the same tick)<br> + broadcasting a message (rtems_message_queue_broadcast)<br><br>Critically, the scheduling required when a task is blocked or unblocked <br>executed in constant order time. There is a research paper on the net<br>claiming that RTEMS is non-predictable execution time but it was wrong.<br>>From what I could
tell, their tool couldn't follow the use of inlines<br>in RTEMS and they just through up their hands and said it can't <br>be analyzed. That's wrong. I have counted assembly instructions<br>in the maximum interrupt disable code fragments and can assure you that<br>it isn't many. <br><br>If you know of better algorithms, please let us know.<br><br>--joel<br> <br><br><br><br><br></pre>
<blockquote type="cite">
<pre wrap="">I have not done exhaustive tests yet, but I hope that this is of some<br>help to you.<br><br>azzedine wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">Hi all,<br><br><br><br>Has anybody got documentations about overhead measurements with RTEMS OS<br>(N tasks with HPF scheduling)?<br><br>I looking for implementations examples of real time systems with temporal<br>analysis (tasks time execution + OS time overhead), is there anybody who can<br>provide me such cases studies ?<br><br><br><br>----------------------------------<br>Azzedine Abdenour<br>PH.D student<br>LESTER/Universite de Bretagne Sud<br>Lorient, France<br><br><br><br></pre>
</blockquote>
<pre wrap="">--<br>Angelo Fraietta<br><br>PO Box 859<br>Hamilton NSW 2303<br><br>Home Page<br><br><a class="moz-txt-link-freetext" href="http://www.users.bigpond.com/angelo_f/">http://www.users.bigpond.com/angelo_f/</a><br><br>There are those who seek knowledge for the sake of knowledge - that is CURIOSITY<br>There are those who seek knowledge to be known by others - that is VANITY<br>There are those who seek knowledge in order to serve - that is LOVE<br> Bernard of Clairvaux (1090 - 1153)<br></pre>
</blockquote>
<pre wrap=""><!----><br></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">--
Angelo Fraietta
PO Box 859
Hamilton NSW 2303
Home Page
<a class="moz-txt-link-freetext" href="http://www.users.bigpond.com/angelo_f/">http://www.users.bigpond.com/angelo_f/</a>
There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
Bernard of Clairvaux (1090 - 1153)</pre>
<br>
</body>
</html>