<span style=" font-size:10pt;font-family:sans-serif">> We can test
this with Fernando, by changing the code to avoid printing - and instead
</span>
<br><span style=" font-size:10pt;font-family:sans-serif">> add integer
values in a log buffer... and dump all the log at the end.</span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
</span>
<br><span style=" font-size:10pt;font-family:sans-serif">CONFIRMED.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Did a quick check,
commenting out the printfs and changing the code to do this instead:</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">void task_begin(int
task_no)</span>
<br><span style=" font-size:10pt;font-family:sans-serif">{</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
logBuffer[logBufferIdx++] = 64+task_no;</span>
<br><span style=" font-size:10pt;font-family:sans-serif">}</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">void task_end(int
task_no)</span>
<br><span style=" font-size:10pt;font-family:sans-serif">{</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
logBuffer[logBufferIdx++] = 128+task_no;</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
rtems_event_send(g_init_task_id, RTEMS_EVENT_0 << task_no);</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
rtems_task_delete(RTEMS_SELF);</span>
<br><span style=" font-size:10pt;font-family:sans-serif">}</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">..then if we dump
the contents of the buffer at the end, the proper - in sequence - output
is indeed shown, as expected:</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 64
<- TASK1 starts</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 128
<- TASK1 ends</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 65
<- TASK2 starts</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 129
<- TASK2 ends</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 66
.... etc.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 130</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 67</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 131</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">If I uncomment
the printfs, and re-introduce them...</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 64
<- TASK1 starts</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 65
<- TASK2 starts</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 66
<- TASK3 starts</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 67
<- TASK4 starts</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 128
<- TASK1 ends</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 129
<- TASK2 ends</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 131</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Log: 130</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">That settles it.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Thank you Thomas
and Chris - mystery solved.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">And lesson learned
- console output is pre-emption point with some BSPs (ZynQ), but not with
others (GR712RC, GR740).</span>
<br>
<br><span style=" font-size:10pt;color:#000080;font-family:sans-serif"><b>Thanassis
Tsiodras</b></span>
<br><span style=" font-size:10pt;font-family:sans-serif">Real-time Embedded
Software Engineer </span>
<br><span style=" font-size:10pt;font-family:sans-serif">System, Software
and Technology Department</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif"><b>ESTEC</b></span>
<br><span style=" font-size:10pt;font-family:sans-serif">Keplerlaan 1,
PO Box 299</span>
<br><span style=" font-size:10pt;font-family:sans-serif">NL-2200 AG Noordwijk,
The Netherlands</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Thanassis.Tsiodras@esa.int
| </span><a href=www.esa.int><span style=" font-size:10pt;color:blue;font-family:sans-serif">www.esa.int</span></a>
<br><span style=" font-size:10pt;font-family:sans-serif">T +31 71 565 5332</span>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"Thanassis
Tsiodras (external)" <Thanassis.Tsiodras@esa.int></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Thomas
Doerfler" <Thomas.Doerfler@imd-systems.de></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">users@rtems.org</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">01/05/2020
11:22</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">Re:
RTEMS tasks timesliced instead of running to completion. TIMESLICE flag
is not active!</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">"users"
<users-bounces@rtems.org></span>
<br>
<hr noshade>
<br>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif"><i>> When the
console driver works in interrupt mode and the output ring</i></span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:sans-serif"><i><br>
> buffer between the driver's base context and interrupt context is</i></span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:sans-serif"><i><br>
> filled, the driver's base context (and actually the calling task)
waits</i></span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:sans-serif"><i><br>
> (*******<b>and gets suspended</i></b><i>)*************** until there
is space again in the output buffer.</i></span><span style=" font-size:12pt">
<br>
<br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
I think that is a key observation Thomas - thank you.</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
If I understand you well, you are saying that in BSPs that don't use polling-based
console output, there is a pre-emption point just because of a printf.
<br>
That would indeed explain why the moment Task1 prints "Starting"
the task can get suspended because of this call - and presumably allowing
Task2 to start, thus giving "timeslice" behavior.</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
We can test this with Fernando, by changing the code to avoid printing
- and instead add integer values in a log buffer... and dump all the log
at the end.</span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:sans-serif"><br>
If we see that the values are generated in the proper sequence, then it
is indeed the console output that causes this pre-emption.</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
Does anyone know if the ZynQ's BSP uses a small enough console buffer that
would be filled up with just printing <i>"[TASK 0] Starting..</i>."
- and thus cause a pre-emption?</span><span style=" font-size:12pt"> <br>
</span><span style=" font-size:10pt;color:#000080;font-family:sans-serif"><b><br>
Thanassis Tsiodras</b></span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:sans-serif"><br>
Real-time Embedded Software Engineer <br>
System, Software and Technology Department</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family:sans-serif"><b><br>
ESTEC</b></span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:sans-serif"><br>
Keplerlaan 1, PO Box 299</span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:sans-serif"><br>
NL-2200 AG Noordwijk, The Netherlands</span><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
Thanassis.Tsiodras@esa.int | </span><a href=www.esa.int><span style=" font-size:10pt;color:blue;font-family:sans-serif"><u>www.esa.int</u></span></a><span style=" font-size:12pt">
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
T +31 71 565 5332</span><span style=" font-size:12pt"> <br>
<br>
<br>
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
From: </span><span style=" font-size:9pt;font-family:sans-serif">"Thomas
Doerfler" <Thomas.Doerfler@imd-systems.de></span><span style=" font-size:12pt">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
To: </span><span style=" font-size:9pt;font-family:sans-serif">users@rtems.org</span><span style=" font-size:12pt">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
Date: </span><span style=" font-size:9pt;font-family:sans-serif">01/05/2020
10:54</span><span style=" font-size:12pt"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
Subject: </span><span style=" font-size:9pt;font-family:sans-serif">Re:
RTEMS tasks timesliced instead of running to completion. TIMESLICE flag
is not active!</span><span style=" font-size:12pt"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif"><br>
Sent by: </span><span style=" font-size:9pt;font-family:sans-serif">"users"
<users-bounces@rtems.org></span><span style=" font-size:12pt"> <br>
</span>
<hr noshade><span style=" font-size:12pt"><br>
<br>
</span><tt><span style=" font-size:10pt"><br>
<br>
<br>
Am 01.05.20 um 10:13 schrieb Thanassis Tsiodras (external):<br>
> /> Polled vs interrupt console drivers?/<br>
> <br>
> I don't see how... With tasks spawned with RTEMS_DEFAULT_MODES
and<br>
> CONFIGURE_MAXIMUM_PROCESSORS set to 1, Task 2 should not be allowed
to<br>
> run until Task 1 completes - so the output of "Starting"
( in<br>
> "task_begin" of Task 2) should not be able to precede the
output of<br>
> "Computed" at the end of Task1 - the relevant print should
not have<br>
> happened yet.<br>
<br>
When the console driver works in interrupt mode and the output ring<br>
buffer between the driver's base context and interrupt context is<br>
filled, the driver's base context (and actually the calling task) waits<br>
(and gets suspended) until there is space again in the output buffer.<br>
<br>
So this is a point where the next task may start to execute.<br>
<br>
Remember: doing I/O operations may often preempt a running task,<br>
depending on the driver structure.<br>
<br>
IMHO, relying on "NO_PREEMPT" as a way to avoid other tasks to
run is<br>
dangerous.<br>
<br>
OTOH, I would expect more mingled output if this were the real cause for<br>
the behavior seen. So there me a different cause for this.<br>
<br>
wkr,<br>
<br>
Thomas.<br>
<br>
> <br>
> I can understand how console output can become garbled in tasks that
are<br>
> running concurrently - but in this case, I would expect them to run
in<br>
> sequence.<br>
> The only way for this<br>
> <br>
> [TASK 0] Starting...<br>
> [TASK 0] Computed the correct floating point result.<br>
> [TASK 1] Starting...<br>
> [TASK 1] Computed the correct integer result.<br>
> [TASK 2] Starting...<br>
> [TASK 2] Computed the correct floating point result.<br>
> [TASK 3] Starting...<br>
> [TASK 3] Computed the correct integer result.<br>
> <br>
> to turn into this<br>
> <br>
> The expected result:<br>
> [TASK 0] Starting...<br>
> [TASK 1] Starting...<br>
> [TASK 2] Starting...<br>
> [TASK 3] Starting...<br>
> [TASK 0] Computed the correct floating point result.<br>
> [TASK 1] Computed the correct integer result.<br>
> [TASK 2] Computed the correct floating point result.<br>
> [TASK 3] Computed the correct integer result.<br>
> <br>
> ...is if indeed, the tasks are running concurrently with the ZynQ
BSP.<br>
> <br>
> So the question is:<br>
> <br>
> Given the task spawning parameters ("RTEMS_DEFAULT_MODES")
and<br>
> CONFIGURE_MAXIMUM_PROCESSORS set to 1, is it right to experience<br>
> timeslicing on the ZynQ ZC706?<br>
> <br>
> *Thanassis Tsiodras*<br>
> Real-time Embedded Software Engineer<br>
> System, Software and Technology Department<br>
> <br>
> *ESTEC*<br>
> Keplerlaan 1, PO Box 299<br>
> NL-2200 AG Noordwijk, The Netherlands<br>
> Thanassis.Tsiodras@esa.int | </span></tt><a href=www.esa.int><tt><span style=" font-size:10pt;color:blue"><u>www.esa.int</u></span></tt></a><tt><span style=" font-size:10pt"><br>
> T +31 71 565 5332<br>
> <br>
> <br>
> <br>
> From: "Chris Johns" <chrisj@rtems.org><br>
> To: "Thanassis Tsiodras (external)"
<Thanassis.Tsiodras@esa.int><br>
> Cc: "Gedare Bloom" <gedare@rtems.org>,
"rtems-users@rtems.org"<br>
> <users@rtems.org>, "Fernando Domínguez Pousa" <fdpousa@gmv.com><br>
> Date: 01/05/2020 09:46<br>
> Subject: Re: RTEMS tasks timesliced instead
of running to<br>
> completion. TIMESLICE flag is not active!<br>
> ------------------------------------------------------------------------<br>
> <br>
> <br>
> <br>
> On 1/5/20 5:08 pm, Thanassis Tsiodras (external) wrote:<br>
>> Note that this test (complete code in <br>
>> </span></tt><a href="https://gitrepos.estec.esa.int/ttsiodras/RTEMS-build-workflows/-/tree/master/OAR"><tt><span style=" font-size:10pt;color:blue"><u>https://gitrepos.estec.esa.int/ttsiodras/RTEMS-build-workflows/-/tree/master/OAR</u></span></tt></a><tt><span style=" font-size:10pt">)<br>
> <br>
>> creates the proper - non-interleaved - output when compiled and
executed<br>
>> for the GR712RC and GR740 boards... but creates the interleaved
output<br>
>> in a ZynQ ZC706 board.<br>
> <br>
> Polled vs interrupt console drivers?<br>
> <br>
> Chris<br>
> <br>
> <br>
> <br>
> This message is intended only for the recipient(s) named above. It
may contain proprietary information and/or<br>
> protected content. Any unauthorised disclosure, use, retention or
dissemination is prohibited. If you have received<br>
> this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect<br>
> personal data, in case of data privacy queries, please contact the
ESA Data Protection Officer (dpo@esa.int).<br>
> <br>
> <br>
> _______________________________________________<br>
> users mailing list<br>
> users@rtems.org<br>
> </span></tt><a href=http://lists.rtems.org/mailman/listinfo/users><tt><span style=" font-size:10pt;color:blue"><u>http://lists.rtems.org/mailman/listinfo/users</u></span></tt></a><tt><span style=" font-size:10pt"><br>
> <br>
<br>
-- <br>
IMD Ingenieurbuero fuer Microcomputertechnik<br>
Thomas Doerfler Herbststrasse 8<br>
D-82178 Puchheim Germany<br>
email: Thomas.Doerfler@imd-systems.de<br>
PGP public key available on request<br>
_______________________________________________<br>
users mailing list<br>
users@rtems.org</span></tt><span style=" font-size:12pt;color:blue"><u><br>
</u></span><a href=http://lists.rtems.org/mailman/listinfo/users><tt><span style=" font-size:10pt;color:blue"><u>http://lists.rtems.org/mailman/listinfo/users</u></span></tt></a><span style=" font-size:12pt"><br>
<br>
</span>
<br><tt><span style=" font-size:12pt">This message is intended only for
the recipient(s) named above. It may contain proprietary information and/or<br>
protected content. Any unauthorised disclosure, use, retention or dissemination
is prohibited. If you have received<br>
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect<br>
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (dpo@esa.int).<br>
</span></tt>
<br><tt><span style=" font-size:10pt">_______________________________________________<br>
users mailing list<br>
users@rtems.org<br>
</span></tt><a href=http://lists.rtems.org/mailman/listinfo/users><tt><span style=" font-size:10pt">http://lists.rtems.org/mailman/listinfo/users</span></tt></a>
<br>
<br><PRE>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).
</PRE>