On Tue, 4 Mar 2003, Nikhil Nair wrote: > However, I'm curious: what would happen if I hacked the serial driver to > just send one byte at a time when transmitting (i.e. to pretend that there > isn't an output FIFO)? To do that you'd have to poll the UART's status register until its transmitter is empty. Given the relatively slow nature of serial ports you'd end up wasting a lot of CPU cycles doing that. Alternatively this could be done based on a periodic kernel timer. In In either cases you wouldn't be able to use the transmit interrupt from the UART since this interrupt is asserted when the transmit fifo is half-full or less. In other words this isn't a one liner hack. > > [...] > > There is no irq priority in standard Linux. > > Strangely enough, it did turn out to be something vaguely related: from > what I can gather, the IDE driver was masking other interrupts while it > was processing its own, so some serial interrupts were being ignored and > overruns were occurring. Yeah... By default any irq can interrupt another irq handler. The IDE code mask irqs in its own irq handler because some (hopefully old) IDE drivers and/or hardware used not to be interrupted while in the middle of a data transfer. So the default is to play safe and mask irqs in all cases. > Of course, the underlying problem remains: the CombiBraille's speech > malfunctions badly when used with a FIFO-enabled serial UART. I've no > idea why: it could be flow control (there was no information about that in > the protocol document from Tieman), but I don't understand why this should > be such a big issue with the FIFO on, and no issue at all with it off; but > there you go. You may try configuring the serial port to use 2 stop bits. With the default of only one stop bit the UART might be sending characters back to back on the wire and the CombiBraille might be just too slow to handle them fast enough (note that CPUs in those devices aren't really fast). Using 2 stop bits might be just enough to allow it to cope with the data stream. Nicolas _______________________________________________ Blinux-list@redhat.com https://listman.redhat.com/mailman/listinfo/blinux-list