This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
serial driver questions
- To: ecos-discuss at sourceware dot cygnus dot com
- Subject: [ECOS] serial driver questions
- From: Grant Edwards <grante at visi dot com>
- Date: Fri, 25 Feb 2000 11:39:25 -0600
Hello eCosians,
I'm setting up an eCos system on custom hardware to support
an application that is being ported from a previous design,
and I've some questions about the serial driver:
Non-Blocking I/O
----------------
In order to avoid re-designing the application completely, I
need to provide non-blocking serial I/O.
Additionally, one of the requirements for the application is
that it be able to find out how much space is available in
the tx buffer [there's a lot of existing stuff that depends
on this ability, and not having it would require ton's of
application code to be scrapped.]
I will probably add cyg_io_get_config keys that let the
application find out how much data is waiting to be read
and/or how much space is available in the transmit buffer.
The application could then make sure that it makes read/write
calls that are not going to block.
I could also add a non-blocking mode to the serial driver so
that read/write calls would return immediately after
performing as much of the read or write operation was
possible without blocking.
I rather like the idea of a non-blocking mode, but since I
have to do the first option anyway, it's not really needed.
Serial-Port Configuration
-------------------------
I need more configuration information for my UART than is
provided in the standard cyg_serial_info_t type. For example,
I need to configure Xon/Xoff characters for send and receive
as well as other flow-control and hardware configuration
stuff. I'll also need an additional baud rate of 460800.
BTW, there's a typo in serialio.h: it should be
CYGNUM_SERIAL_BAUD_230400 rather than
CYGNUM_SERIAL_BAUD_234000
Is there a compatible way to extend the cyg_serial_info_t
structure to provide additional data to my serial hardware
interface module without breaking my module's compatibility
with the standard eCos serial driver?
I think it would be sufficient if I could just add stuff on
to the end of the structure that is passed to the
set_config/CYG_IO_SET_CONFIG_SERIAL_INFO) and expect the
serial driver to pass the data along to the interface module
and preserve the data so that it is returned by the
get_config/CYG_IO_GET_CONFIG_SERIAL_INFO call.
Alternatively, is there a way to add a get/set_config key
that is just passed through the serial driver to the hardware
interface module? This would require two additional entries in
the SERIAL_FUNS table -- one for get and one for set.
Modem Status/Control Lines
--------------------------
I don't see any way to either read or set any of the modem
control/status lines (RTS,CD,RI,DSR,DTR). My application
requires control of these lines, so I'll have to add
something to handle this also.
The net result is that I have to add these features.
I'd like to do it in a way that is generally useful and can be
merged into the standard distribution. [For the moment, we'll
assume this is due to my desire to contribute to the greater
good of society and it's not just me trying to offload
maintenance responsibilities and avoid the headache of
maintaining a set of code that parallels the standard eCos
driver.]
Suggestions?
--
Grant Edwards
grante@visi.com