<span style=" font-size:10pt;font-family:sans-serif"><i>> When the
console driver works in interrupt mode and the output ring</i></span>
<br><span style=" font-size:10pt;font-family:sans-serif"><i>> buffer
between the driver's base context and interrupt context is</i></span>
<br><span style=" font-size:10pt;font-family:sans-serif"><i>> filled,
the driver's base context (and actually the calling task) waits</i></span>
<br><span style=" font-size:10pt;font-family:sans-serif"><i>> (*******<b>and
gets suspended</i></b><i>)*************** until there is space again in
the output buffer.</i></span>
<br>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I think that is
a key observation Thomas - thank you.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">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>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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>
<br><span style=" font-size:10pt;font-family:sans-serif">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>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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>
<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">"Thomas
Doerfler" <Thomas.Doerfler@imd-systems.de></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</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
10:54</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><tt><span style=" font-size:10pt"><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">www.esa.int</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">https://gitrepos.estec.esa.int/ttsiodras/RTEMS-build-workflows/-/tree/master/OAR</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">http://lists.rtems.org/mailman/listinfo/users</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<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><tt><span style=" font-size:10pt"><br>
</span></tt>
<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>