This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Timing differences before / after starting scheduler
- From: Tim Jaacks <timjaacks at gmx dot de>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Sun, 22 Aug 2010 15:45:59 +0200
- Subject: [ECOS] Timing differences before / after starting scheduler
Hello everybody,
I have a problem concering the eCos scheduler. Perhaps I just have not
understood all the details of the eCos kernel about scheduling. But I
have tried everything I could imagine, without success, so I hope
someone can help me here and explain me why eCos behaves like it does.
I am using eCos on an LPC2378, running at 72MHz. Some driver I have
implemented reads out eight double words from a CPU FIFO, using eight
equal subsequent lines of C-code.
When I make use of this driver within the cyg_user_start() function,
these eight lines of code need 5 microseconds of time (measured with a
logic analyzer and a toggled GPIO pin). My driver works correctly in
this case.
When I use the driver in a thread context, after cyg_user_start() has
completed and the scheduler has been started, the time for these eight
lines is more than three times longer (17 microseconds). Thus, the FIFO
cannot be read out fast enough and an overrun occurs.
What I thought, was: Right, obiously the FIFO reading thread is
preempted between these eight instructions, that's why it takes longer
now. So I tried disabling the scheduler using cyg_scheduler_lock(). But
nothing changed, still 17 microseconds.
Then I thought: Okay, then there might be an interrupt occuring between
the eight lines, which causes the delay. So I disabled interrupts using
cyg_interrupt_disable(). No change, still 17 microseconds.
The last things I tried were disabling the Real Time Clock of the eCos
kernel, because I though maybe that one disturbs the thread in any way,
and changing the scheduling algorithm from multi-level to bitmap. But
none of the actions brought any change. The eight lines of code still
need 17 microseconds to be executed.
My two questions are:
1. Can anybody explain to me, what eCos is doing within these 12
microseconds, which the instructions take longer now?
2. Has anyone an idea how I can change this behaviour, so that these
instructions take 5 microseconds again like before invoking the scheduler?
Thanks in advanced and best wishes,
Tim
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss