This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: More questions about the eCos high level serial device driver
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