Re: [ECOS] More questions about the eCos high level serial device driver

Re: [ECOS] More questions about the eCos high level serial device driver

[Michael Checky]

----- Forwarded by Michael Checky/contractor/tkc/IRCorp on 03/25/2003 10:18
AM -----
|---------+----------------------------------------------->
|         |                              Michael Checky   |
|         |                                               |
|         |                              03/25/2003 10:22 |
|         |                              AM               |
|         |                                               |
|---------+----------------------------------------------->
  >------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                          |
  | To:   Jonathan Larmour <jifl@eCosCentric.com>                                                                                            |
  | cc:                                                                                                                                      |
  | Subject: Re: [ECOS] More questions about the eCos high level serial device driver(Document link: Michael Checky)                         |
  |                                                                                                                                          |
  |                                                                                                                                          |
  |                                                                                                                                          |
  >------------------------------------------------------------------------------------------------------------------------------------------|






|---------+----------------------------------------------->
|         |                              Jonathan Larmour |
|         |                              <jifl@eCosCentric|
|         |                              .com>            |
|         |                                               |
|         |                              03/24/2003 08:39 |
|         |                              PM               |
|         |                                               |
|         |                                               |
|         |                                               |
|---------+----------------------------------------------->
  >------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                          |
  | To:   Michael Checky <Michael_Checky@Thermoking.com>                                                                                     |
  | cc:   ecos-discuss@sources.redhat.com                                                                                                    |
  | Subject: Re: [ECOS] More questions about the eCos high level serial device driver                                                        |
  >------------------------------------------------------------------------------------------------------------------------------------------|




> Michael Checky wrote:
> > It appears that the design of 'serial.c' does not work well for serial
> > ports with FIFOs.  The functionality provided by the low level device
> > driver's 'stop_xmit' routine is overloaded.
> >
> > The 'stop_xmit' routine is called when '
> > CYG_IO_GET_CONFIG_SERIAL_OUTPUT_FLUSH' is requested.  It can be assumed
> > that in this instance both the serial port transmitter should be
disabled
> > and the tx FIFO should be reset.
>
> One could argue in an ideal world, yes. But the paradigm eCos was using
> was that whatever is in the FIFO is as good as sent.
>
> > The 'stop_xmit' routine is also called when a XOFF character has been
> > received.  In this instance, the serial port transmitter should be
disabled
> > and the tx FIFO should be left as it is.
>
> The same applies here...

Let me give you a real world example.  The UART that I'm writing the driver
for has 256 byte FIFOs and it also has DMA to load and unload it's FIFOs.
Now we're talking lots of bytes that eCos "thinks" it has sent, but in
reality they're only queued, ready to be sent.  I still think it's
important to call out these two cases, so the driver can do the right
thing.  In a 16550 like UART driver, 'stop_xmit' is sufficient for both of
these two cases.

> > The 'stop_xmit' routine is also called by 'serial_xmt_char' and '
> > serial_data_xmt_done' immediately after these routines determine that
they
> > have emptied the tx buffer.  In this instance, the serial port
transmitter
> > should NOT be disabled and the tx FIFO should be left to drain, after
which
> > the serial port transmitter can be disabled.
>
> Now this is a little more interesting... the principle eCos had was that
> there was no longer any reason for it to be informed about tx
availability
> in the FIFO - the FIFO can be just be allowed to be sent naturally.
>
> However, I suppose it's possible that some serial hardware could actually

> need to turn off the TX entirely, not just the TX interrupt. Although in
> that case this could still be worked round in the driver by just turning
> off the TX when the FIFO is indeed empty and you know you wanted to stop.

In this case, I admit my analysis was too shallow.  Until I looked at it
more, I didn't realize this case was about just letting eCos know about tx
availability.  We can ignore this case for now.  Although it might come up
if a driver was trying to support RS-485 and needed to tri-state the
transmitter driver once it knew there were no more bytes to be transmitted.

> I would prefer Roland's solution if anything. I'll check in something
> based on his patch just so we can get the "ideal world" I mentioned
above.
> This is on the assumption that down the road a serial driver will
actually
> use it! But it's very low overhead.

I haven't looked at this patch closely enough to have a position on it, so
don't apply it on my account yet.

Michael Checky







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

Re: [ECOS] More questions about the eCos high level serial device driver

[Jonathan Larmour]

Michael Checky wrote:
> It appears that the design of 'serial.c' does not work well for serial
> ports with FIFOs.  The functionality provided by the low level device
> driver's 'stop_xmit' routine is overloaded.
> 
> The 'stop_xmit' routine is called when '
> CYG_IO_GET_CONFIG_SERIAL_OUTPUT_FLUSH' is requested.  It can be assumed
> that in this instance both the serial port transmitter should be disabled
> and the tx FIFO should be reset.

One could argue in an ideal world, yes. But the paradigm eCos was using 
was that whatever is in the FIFO is as good as sent.

> The 'stop_xmit' routine is also called when a XOFF character has been
> received.  In this instance, the serial port transmitter should be disabled
> and the tx FIFO should be left as it is.

The same applies here...

> The 'stop_xmit' routine is also called by 'serial_xmt_char' and '
> serial_data_xmt_done' immediately after these routines determine that they
> have emptied the tx buffer.  In this instance, the serial port transmitter
> should NOT be disabled and the tx FIFO should be left to drain, after which
> the serial port transmitter can be disabled.

Now this is a little more interesting... the principle eCos had was that 
there was no longer any reason for it to be informed about tx availability 
in the FIFO - the FIFO can be just be allowed to be sent naturally.

However, I suppose it's possible that some serial hardware could actually 
need to turn off the TX entirely, not just the TX interrupt. Although in 
that case this could still be worked round in the driver by just turning 
off the TX when the FIFO is indeed empty and you know you wanted to stop.

But I'd rather not change eCos for a hypothetical piece of hardware; 
unless you are saying you do have hardware that behaves like this.

> I propose that the interface between the high and low level serial device
> drivers be changed to call out these three functions.  The 'stop_xmit'
> routine can be used for these three functions if the serial port doesn't
> have a FIFO.  Changing the 'SERIAL_FUNS' macro to duplicate the 'stop_xmit'
> entry point should work with the current low level device drivers.  A new
> macro should be added to initialize the new entry points.  Call it
> 'SERIAL_FUNS_BLOCK' or 'SERIAL_FUNS_FIFO' or 'SERIAL_FUNS_EXT'.

I would prefer Roland's solution if anything. I'll check in something 
based on his patch just so we can get the "ideal world" I mentioned above. 
This is on the assumption that down the road a serial driver will actually 
use it! But it's very low overhead.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


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

Re: [ECOS] More questions about the eCos high level serial device driver

[Roland Caßebohm]

On Mittwoch, 19. MÀrz 2003 04:48, Gary D. Thomas wrote:
> On Tue, 2003-03-18 at 18:05, Michael Checky wrote:
> > It appears that the design of 'serial.c' does not work well for serial
> > ports with FIFOs.  The functionality provided by the low level device
> > driver's 'stop_xmit' routine is overloaded.
> >
> > The 'stop_xmit' routine is called when '
> > CYG_IO_GET_CONFIG_SERIAL_OUTPUT_FLUSH' is requested.  It can be assumed
> > that in this instance both the serial port transmitter should be disabled
> > and the tx FIFO should be reset.
> >
> > The 'stop_xmit' routine is also called when a XOFF character has been
> > received.  In this instance, the serial port transmitter should be
> > disabled and the tx FIFO should be left as it is.
> >
> > The 'stop_xmit' routine is also called by 'serial_xmt_char' and '
> > serial_data_xmt_done' immediately after these routines determine that
> > they have emptied the tx buffer.  In this instance, the serial port
> > transmitter should NOT be disabled and the tx FIFO should be left to
> > drain, after which the serial port transmitter can be disabled.
> >
> > I propose that the interface between the high and low level serial device
> > drivers be changed to call out these three functions.  The 'stop_xmit'
> > routine can be used for these three functions if the serial port doesn't
> > have a FIFO.  Changing the 'SERIAL_FUNS' macro to duplicate the
> > 'stop_xmit' entry point should work with the current low level device
> > drivers.  A new macro should be added to initialize the new entry points.
> >  Call it 'SERIAL_FUNS_BLOCK' or 'SERIAL_FUNS_FIFO' or 'SERIAL_FUNS_EXT'.
>
> This probably needs some thought, but in the meantime, how
> about proposing a patch which does all of this?  Remember that
> eCos is a *volunteer* project.  Some of us do work on eCos for
> customer needs, but in general changes are made by the user's
> themselves.

What about doing like this?

Index: io/serial/current/src/common/serial.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/io/serial/current/src/common/serial.c,v
retrieving revision 1.17
diff -u -5 -p -r1.17 serial.c
--- io/serial/current/src/common/serial.c       23 May 2002 23:06:27 -0000      
1.17
+++ io/serial/current/src/common/serial.c       19 Mar 2003 09:05:25 -0000
@@ -614,10 +724,17 @@ serial_get_config(cyg_io_handle_t handle
             in_cbuf->abort = true;
             cyg_drv_cond_signal(&in_cbuf->wait);
             in_cbuf->waiting = false;
         }
         in_cbuf->get = in_cbuf->put = in_cbuf->nb = 0;  // Flush buffered 
input
+
+        // up to hardware driver
+        (funs->set_config)(chan,
+                                 CYG_IO_GET_CONFIG_SERIAL_INPUT_FLUSH,
+                                 NULL, NULL);
+
         cyg_drv_dsr_unlock();
         cyg_drv_mutex_unlock(&in_cbuf->lock);
         break;

     case CYG_IO_GET_CONFIG_SERIAL_ABORT:
@@ -640,10 +757,17 @@ serial_get_config(cyg_io_handle_t handle
         cyg_drv_dsr_lock();
         if (out_cbuf->nb > 0) {
             out_cbuf->get = out_cbuf->put = out_cbuf->nb = 0;  // Empties 
queue!
             (funs->stop_xmit)(chan);  // Done with transmit
         }
+
+        // up to hardware driver
+        (funs->set_config)(chan,
+                                 CYG_IO_GET_CONFIG_SERIAL_OUTPUT_FLUSH,
+                                 NULL, NULL);
+
         if (out_cbuf->waiting) {
             out_cbuf->abort = true;
             cyg_drv_cond_signal(&out_cbuf->wait);
             out_cbuf->waiting = false;
         }


But it is a little bit confusing, because the higher level driver function 
get_config() calls the lower level function set_config(), but there isn't 
get_config() in the lower level drivers.

Roland

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

Re: [ECOS] More questions about the eCos high level serial device driver

[Gary D. Thomas]

On Tue, 2003-03-18 at 18:05, Michael Checky wrote:
> It appears that the design of 'serial.c' does not work well for serial
> ports with FIFOs.  The functionality provided by the low level device
> driver's 'stop_xmit' routine is overloaded.
> 
> The 'stop_xmit' routine is called when '
> CYG_IO_GET_CONFIG_SERIAL_OUTPUT_FLUSH' is requested.  It can be assumed
> that in this instance both the serial port transmitter should be disabled
> and the tx FIFO should be reset.
> 
> The 'stop_xmit' routine is also called when a XOFF character has been
> received.  In this instance, the serial port transmitter should be disabled
> and the tx FIFO should be left as it is.
> 
> The 'stop_xmit' routine is also called by 'serial_xmt_char' and '
> serial_data_xmt_done' immediately after these routines determine that they
> have emptied the tx buffer.  In this instance, the serial port transmitter
> should NOT be disabled and the tx FIFO should be left to drain, after which
> the serial port transmitter can be disabled.
> 
> I propose that the interface between the high and low level serial device
> drivers be changed to call out these three functions.  The 'stop_xmit'
> routine can be used for these three functions if the serial port doesn't
> have a FIFO.  Changing the 'SERIAL_FUNS' macro to duplicate the 'stop_xmit'
> entry point should work with the current low level device drivers.  A new
> macro should be added to initialize the new entry points.  Call it
> 'SERIAL_FUNS_BLOCK' or 'SERIAL_FUNS_FIFO' or 'SERIAL_FUNS_EXT'.

This probably needs some thought, but in the meantime, how
about proposing a patch which does all of this?  Remember that
eCos is a *volunteer* project.  Some of us do work on eCos for
customer needs, but in general changes are made by the user's
themselves.

-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'


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

[ECOS] More questions about the eCos high level serial device driver

[Michael Checky]

It appears that the design of 'serial.c' does not work well for serial
ports with FIFOs.  The functionality provided by the low level device
driver's 'stop_xmit' routine is overloaded.

The 'stop_xmit' routine is called when '
CYG_IO_GET_CONFIG_SERIAL_OUTPUT_FLUSH' is requested.  It can be assumed
that in this instance both the serial port transmitter should be disabled
and the tx FIFO should be reset.

The 'stop_xmit' routine is also called when a XOFF character has been
received.  In this instance, the serial port transmitter should be disabled
and the tx FIFO should be left as it is.

The 'stop_xmit' routine is also called by 'serial_xmt_char' and '
serial_data_xmt_done' immediately after these routines determine that they
have emptied the tx buffer.  In this instance, the serial port transmitter
should NOT be disabled and the tx FIFO should be left to drain, after which
the serial port transmitter can be disabled.

I propose that the interface between the high and low level serial device
drivers be changed to call out these three functions.  The 'stop_xmit'
routine can be used for these three functions if the serial port doesn't
have a FIFO.  Changing the 'SERIAL_FUNS' macro to duplicate the 'stop_xmit'
entry point should work with the current low level device drivers.  A new
macro should be added to initialize the new entry points.  Call it
'SERIAL_FUNS_BLOCK' or 'SERIAL_FUNS_FIFO' or 'SERIAL_FUNS_EXT'.

Thanks
Michael Checky




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