This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: problem with generic serial driver?

David Roethig <> 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?

Nick Garnett                                     eCos Kernel Architect                The eCos and RedBoot experts

Before posting, please read the FAQ:
and search the list archive:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]