[EMAIL PROTECTED] (Daniel Néri) writes: > Grant Edwards <[EMAIL PROTECTED]> writes: > > > On 2006-01-14, Paul D. DeRocco <[EMAIL PROTECTED]> wrote: > > > >> If the transmitter has a hardware FIFO, and the software > >> transmits one byte per interrupt, > > > > Then the sofware is completely and utterly broken. It doesn't > > deserve to work. > > > >> then presenting a block of data to it after an idle period > >> will invoke the ISR/DSR a slew of times until the FIFO is > >> full. > > > > That's insane. Nobody with a clue would write software like that. > > Actually, the generic 16x5x serial driver in eCos works exactly like > that.
Actually, it doesn't. > > > When you get a TX interrupt you write data to the tx FIFO until it's > > full. > > Yep. I've made a somewhat quick-and-dirty fix that is attached below. This already happens. pc_serial_putc() returns true or false, depending on whether it transmitted the byte. In the 16550 this means that it will only return false when the FIFO fills up. The generic serial code calls the putc() driver routine in a loop to transmit bytes until it returns false. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
