[ECOS] problem with generic serial driver?

[ECOS] problem with generic serial driver?

[David Roethig]

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?



Thanks
Dave






-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] problem with generic serial driver?

[Nick Garnett]

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?



-- 
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

Re: [ECOS] problem with generic serial driver?

[David Roethig]

Nick Garnett wrote:

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

We are working on a Philips LPC2292 custom board.
We started our design before the LPC2xxx port was released. Recently,
the generic serial port driver package was added because we thought
it would be more robust than the code we cobbled together.

Thanks
Dave



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] problem with generic serial driver?

[Nick Garnett]

David Roethig <droethig@cipher.com> writes:

> > Out of interest, what is the target you are working on?
> 
> We are working on a Philips LPC2292 custom board.
> We started our design before the LPC2xxx port was released. Recently,
> the generic serial port driver package was added because we thought
> it would be more robust than the code we cobbled together.

That makes sense, I think it was in the context of the LPC2xxx serial
devices that I came across the same problem.

-- 
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