On 2008-01-28, Laurie Gellatly <[EMAIL PROTECTED]> wrote: > Hi Grant, >> >>At 117Kbps with no fifo, you have to service a receive >> >>interrupt at a 11.7KHz or you lose bytes. That means you've >> >>got to have an interrupt latency less than 85us. >> > >> > So I modified ser_16X5X.c to read FIFO threshold (1,4,8 or 14) >> > characters worth when an RDA interrupt occurs. >> >> What was it doing? The correct thing to do is to read all the >> available characters each time an rx interrupt occurs. > > In the switch statement the (RDA)ISR_Rx case simply fell through > to the (CTI) ISR_RxTO case and a single character was read from RHR.
That's wrong. It should continue to read bytes from RHR as long as the status register says there is receive data available. What you describe isn't what's in my snapthost snapshot of ser_16x5x.c. The code I'm looking at is right: in the Rx/RxTO case, there's a loop that reads all of the data from the receive fifo. My snapshot is proably a couple years old, and it's doing the right thing. Where did you get the broken file? >> If there aren't any receive overrun errors, then interrupt >> latency isn't the problem. There weren't any rx errors of any >> sort (parity, framing, etc.)? > > Yeah, I thought this was strange as well. After I slept on it > I found that the Rx Line Status Interrupt was not enabled.... > Now I see I'm getting OE. It sounds like you've somehow gotten ahold of a broken serial driver code. I checked CVS, and it's got the right code in it. I've checked all the versions back for 4 years, and they all have a loop that will read all available rx data whenever there's an interrupt. Are you sure you have driver code that only reads a single byte? You shouldn't have had to do anything other than enble the fifo. The code that's in CVS is correct. -- Grant -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
