This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MPC555 serial driver delay


> I've tried to see how the interrupt gets cleared in the code and it
> doesn't seem to get explicitely cleared.

Sometimes just reading the interrupt status register clears it. The
data sheet should say somewhere.

> I've put separate counters in both sections that return either true or
> false.
> For a 64 byte packet there seems to be a time averaged fixed ratio of
> about 2.06 times successful sends to no room in buffer sends.

This says that the hardware is sending out bytes faster than the CPU
can feed it bytes. Since you only have a one byte buffer, being able
to send two bytes at once means it must of finished sending the first
byte by the time the while loop comes around and tries to send the
second one. Humm, this is probably not 100% correct. I guess the
hardware has a shift register which is used for the actual
transmit. There is also the TX Data register which is what you do the
write to. So your first write goes into the TX register and is then
latches into the shift register. The second byte goes into the TX
register. You then fall out of the loop and the ISR finish.

> Scope4.tif is the same but zoomed in on the timebase. So 300us
> are spent idle and only 100us by the DSR attempting to transfer more
> data for each buffer empty interrupt.

What you don't see here is the overhead actually getting into the DSR.
It could be that your CPU is spending nearly 100% of its time feeding
the serial chip data. You threads never get time to run. The timer DSR
might be running, but since use threads don't get any CPU time, you
don't see this. The timer code also handles not being called fast
enough to some degree. The DSR is passed a parameter which indicates
how many time it should be been called since the last time it was
called. This allows the timer DSR to execute multiple ticks at one go.
So heavy interrupt activity will not cause drift. Time just happens in
bursts.
 
> Looks like I'll have to fall back to using the driver interupt-less mode
> or investigate implementing the 16-byte queue to reduce the magnetude or
> frequency of the delay problem.

Using the FIFO will help a lot. You will reduce your interrupt
overheads by a factor of around 10-16, depending on the low water
mark. Less interrupts means your threads will have more time to do
real work.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]