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

[Roland Caßebohm <roland dot cassebohm at visionsystems dot de>]

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