David Roethig <droethig@cipher.com> writes:
I am using (as of recently) the generic serial driver
package (16x5x compatible serial device drivers).
The application was sending data to the port using the
file i/o interface:
/* output string to serial port */
err = cyg_io_write( serHandle, writeBuffer, length );
Nothing came out the serial port! That is, until, the app
output a 'diag_printf()'. That was a head-scratcher until
looking at the pc_serial_start_xmit() routine, I noticed
that the trasmitter wasn't being 'kicked' with a character
to the transmit register.
// Enable the transmitter on the device
static void
pc_serial_start_xmit(serial_channel *chan)
{
pc_serial_info *ser_chan = (pc_serial_info *)chan->dev_priv;
cyg_addrword_t base = ser_chan->base;
cyg_uint8 _ier;
HAL_READ_UINT8(base+REG_ier, _ier);
_ier |= IER_XMT; // Enable xmit interrupt
HAL_WRITE_UINT8(base+REG_ier, _ier);
/* kick transmitter */ // **!! added !!**
(chan->callbacks->xmt_char)(chan); // **!! added !!**
}
My questions:
1) is the generic serial package still being used?
2) is this a bug or are things configured incorrectly?
This driver is being used on lots of targets, any that have 16x5x
compatible serial devices will use it. However, not all devices that
claim to be 16x5x compatible actually are. Some are missing features,
some have extra features.
Under normal circumstances the XMT interrupt occurs whenever the
transmit buffer (or FIFO) is empty. That's why we have to enable and
disable it, since we would otherwise be flooded with interrupts when
we had nothing to transmit.
It looks like your 16x5x clone either has this wrong, or, more likely,
has a "transmit interrupt holdoff" feature in an attempt to solve the
interrupt flood problem. Another example of hardware designers trying
to be helpful but actually just making the software more complicated.
Your fix is the correct thing to do, and is benign even for correctly
functioning 16x5xs.
Out of interest, what is the target you are working on?