Re: [ECOS] serial driver questions

[Grant Edwards <grante at visi dot com>]

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

I've added the config key to query the buffer status (it was
pretty trivial).  I'll send patches for that later today or
maybe tomorrow.  I think that will be sufficient for now, but
I'll have to check with the person responsible for the
application.

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

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

OK, that's easy enough.  If flow control is disabled, do we
want the fields in cyg_serial_info_t to go away, or just the
code that supports that functionality.  (For the UARTs I'm
using, it's all done by hardware anyway, so the differences
are pretty tivial).

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

For me that's already been decided.  The application requires
access to the modem control lines that are not being used for
flow control.  Other operating systems (Windows, Unix, etc.)
provide that, and I have to also.

What I do get to decide is how that access is provided.  From
what I know of the application, it looks like adding config
keys to read/write the modem control lines would be the minimum
with which I could get by.  I think that having the option for
an input state change to interrupt a blocked read operation
might also be very valuble -- that would obviate the need for a
task that just sits and periodically polls the inputs watching
for a change.  Adding the task itself isn't that bad, but modem
line state information and receive data both go to the same
"place" in an inter-dependant fasion, and having two different
tasks introduces mutex and synchronization issues that
complicate things.

-- 
Grant Edwards
grante@visi.com