Is it possible that the speech subsystem is sending back indexing data to the serial port, which it can not handle? On Fri, 28 Feb 2003, Nikhil Nair wrote: > Dear all, > > I'm having some headaches with the serial port hardware (in fact, they've > been nagging away in the background for several years, really): I'm using > a Tieman CombiBraille display on a serial port with a 16550A UART (i.e. a > reasonably modern one with a 16-byte FIFO buffer). The trouble is, I get > one problem when the FIFO is enabled, and another when I disable it to > avoid the first! > > This Braille display has an in-built speech chip, and, for some reason, it > misbehaves horribly when I'm using the FIFO: the speech gets garbled, it > doesn't always speak straight away, some bits get left out etc. Strangely > enough, the Braille output is absolutely fine! This is strange to me, > because (a) BRLTTY does the same thing whether the FIFO is in use or not, > (b) the Kernel and the computer's UART, which are doing different things > when the FIFO is enabled or disabled, don't know or care which bits are > Braille data and which are speech, and (c) the CombiBraille shouldn't be > able to tell whether the computer is using a FIFO, as the data still > arrives one bit at a time! I can only guess that the computer's UART is > doing something subtly different when the FIFO is enabled (perhaps some > delays in transmission) which, for some reason, is upsetting the > CombiBraille. > > My solution to this used to be to turn off the FIFO (with `setserial > /dev/ttyS1 uart 16450'). However, when the system has a lot of interrupts > to handle (e.g. high-speed read or write access on an ATAPI CD-R drive), > there are a lot of overruns in the serial input, leaving the Braille > display virtually unusable: so much for multi-tasking... > > Possible solutions: > > a) Hack the serial driver to use the FIFO for input but ignore it for > output (as if the UART is a cross between a 16550A and a 16450); I don't > understand enough about the low-level stuff to know if this is possible - > it would mean delving deep into drivers/char/serial.c in the kernel, I > would imagine. > > b) Raise the priority of serial interrupts, and leave the FIFO off. I > don't know how to go about doing this, or what the dangers might be... > > Any thoughts, suggestions, advice etc. would be much appreciated! > > Cheers, > > Nikhil. > > > > > _______________________________________________ > > Blinux-list@redhat.com > https://listman.redhat.com/mailman/listinfo/blinux-list > _______________________________________________ Blinux-list@redhat.com https://listman.redhat.com/mailman/listinfo/blinux-list