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 devicedriver
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Michael Checky <Michael_Checky at Thermoking dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Tue, 25 Mar 2003 02:39:38 +0000
- Subject: Re: [ECOS] More questions about the eCos high level serial devicedriver
- References: <OFF467545A.05F8796D-ON86256CEE.0003269D@ingerrand.com>
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