This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: More questions about the eCos high level serial devicedriver


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]