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


On Thu, Feb 28, 2008 at 04:04:37PM -0000, Steven Clugston wrote:
> 
> 
> 
> >mpc555_serial_putc() should return false when the buffer is 
> >full. This tells serial_xmt_char() to stop sending bytes, and 
> >so the DSR should exist.
> 
> It does, but I didn't understand why it should ever need to, the very
> fact that it is being called should mean (in this context) that there is
> space for a byte as this is what caused the interrupt in the first
> place.
> 
> >If i understand you correctly, you are seeing a busy loop 
> >somewhere? Where is this loop?
> >
> >      Andrew
> >
> 
> Ok, I see how it works now, it will only try once to send again and then
> breaks out of the while loop when the last byte hasn't finished sending.

Yes. Some devices have a FIFO and the interrupt is triggered when a
low water mark is reached. You can then write multiple bytes to fill
the FIFO. Hence the loop.

> So that wasn't the problem. I've tried setting the buffer to 1 and the
> delay problem is still there. 
> I'm not sure where to look now.

Maybe an interrupt problem. Is the TX interrupt getting cleared
properly when the DSR exists? If not the interrupt will fire again
once interrupts are reenabled. See how many bytes get send out on
average. It should be 1, but if there are lots of 0s, you have a
problem.

        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]