Re: [ECOS] serial driver questions

[Jonathan Larmour <jlarmour at redhat dot co dot uk>]

Grant Edwards wrote:
> 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.

We (Red Hat) are shortly about to start some significant development work,
part of which will include non-blocking I/O. We're a bit short on
implementation details right now, but fully intend to develop this in the
open. We would of course greatly appreciate any input you could give once we
start, but as announced elsewhere, just now we're pushing towards the
upcoming new eCos net release.

I think config keys to interrogate free space in the buffers is a good
approach. Send us a patch for config_keys.h so we ensure our numbers and
your numbers are consistent.

> 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.

That's easily added. Just send us a patch when you're done.

>   BTW, there's a typo in serialio.h: it should be
>   CYGNUM_SERIAL_BAUD_230400 rather than
>   CYGNUM_SERIAL_BAUD_234000

Thanks. I've checked that in.
 
>   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.

cyg_serial_info_t's are just meant to be abstractions. Flow control state
would be a sensible addition to cyg_serial_info_t IMHO - no need for keys
since it's a generic concept. But something like support for flow control
should probably be controlled by a configuration option.
 
> 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.]

I think giving direct access to RTS, CTS, etc. to the application sounds
inappropriate for general use. I think in the main sources we want hardware
flow control via RTS/CTS and DSR/DTR (I believe those are the only forms
really), which would live in the driver and common serial code. Other than
that, any other line magic for CD is probably sufficiently specific that it
should be done directly by the driver with get/set_config. IMHO :-).

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault