> 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.
CONFIRMED.
Did a quick check, commenting out the printfs and changing the code to do
this instead:
void task_begin(int task_no)
{
> When the console driver works in interrupt mode and the output ring
> buffer between the driver's base context and interrupt context is
> filled, the driver's base context (and actually the calling task) waits
> (***and gets suspended)*** until there is space again in
the output
The complete code of the two tasks is here:
https://gitrepos.estec.esa.int/ttsiodras/RTEMS-build-workflows/-/blob/master/OAR/src/task1.c
and here:
https://gitrepos.estec.esa.int/ttsiodras/RTEMS-build-workflows/-/blob/master/OAR/src/task2.c
...so the short answer is that, besides what you alread
Fernando,
a second guess: which systems calls are you doing in your Task1 and
task2? Obviously your are sending events (which is not preempting) and
doing console output (which is questionable regarding preemption), but
which other calls are involved?
wkr,
Thomas.
Am 30.04.20 um 17:14 schrieb F
Am 01.05.20 um 10:13 schrieb Thanassis Tsiodras (external):
> /> Polled vs interrupt console drivers?/
>
> I don't see how... With tasks spawned with RTEMS_DEFAULT_MODES and
> CONFIGURE_MAXIMUM_PROCESSORS set to 1, Task 2 should not be allowed to
> run until Task 1 completes - so the output of
> Polled vs interrupt console drivers?
I don't see how... With tasks spawned with RTEMS_DEFAULT_MODES and
CONFIGURE_MAXIMUM_PROCESSORS set to 1, Task 2 should not be allowed to run
until Task 1 completes - so the output of "Starting" ( in "task_begin" of
Task 2) should not be able to precede t
On 1/5/20 5:08 pm, Thanassis Tsiodras (external) wrote:
Note that this test (complete code in
https://gitrepos.estec.esa.int/ttsiodras/RTEMS-build-workflows/-/tree/master/OAR)
creates the proper - non-interleaved - output when compiled and executed
for the GR712RC and GR740 boards... but create
On 1/5/20 2:13 am, Mario Palomares wrote:
Well, really useful information Chris thanks, no worries about the lack
of documentation completely understandable.
Thanks.
Just let me ask you some more questions
Sure, no problem.
- I´am trying to use it on a raspberry pi 2B, is it currently supp
> Probably, the print statement comes after the event send in your task,
> and the event send is causing the task to self-suspend.
Actually, no:
https://gitrepos.estec.esa.int/ttsiodras/RTEMS-build-workflows/-/blob/master/OAR/src/task1.c#L48
with the task_end doing the event send after a (flus
