[ECOS] serial driver questions

[ECOS] serial driver questions

[Grant Edwards]

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

Re: [ECOS] serial driver questions

[Jonathan Larmour]

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

Re: [ECOS] serial driver questions

[Kenneth Porter]

On Wed, 01 Mar 2000 12:31:42 +0000, Jonathan Larmour wrote:

> 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'd suggest a "semi-blocking" mode where a configurable timeout
(typically a few character times) would allow a read request to return
when the line remained idle for longer than the timeout. (The better
UARTs with FIFOs have this kind of logic wired to the receive
interrupt.) Making the timeout dynamically configurable is important,
as some protocols (eg. SEMI-E4, AKA SECS-I) require different timeouts
in different parts of a packet. For example, SECS-I specifies one
timeout for the first "wake-up" character in its protocol, but a
smaller timeout for intercharacter time in the data part of a packet.

Kenneth Porter
Kensington Laboratories, Inc.
mailto:kenneth_porter@kensingtonlabs.com
http://www.kensingtonlabs.com

Re: [ECOS] serial driver questions

[Grant Edwards]

> 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

Re: [ECOS] serial driver questions

[Grant Edwards]

> > 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'd suggest a "semi-blocking" mode where a configurable timeout
> (typically a few character times) would allow a read request to
> return when the line remained idle for longer than the timeout.
> (The better UARTs with FIFOs have this kind of logic wired to
> the receive interrupt.)

Most of the buffered UARTs I've looked at only provide you with
an rx-timeout interrupt if there is data in the FIFO.  If the
gap occured just as you empty the FIFO, you get no timeout
interrupt from the UART so you still have to have some sort of
an inter-byte timer in the driver.  What a pain.

> Making the timeout dynamically configurable is important, as
> some protocols (eg. SEMI-E4, AKA SECS-I) require different
> timeouts in different parts of a packet. For example, SECS-I
> specifies one timeout for the first "wake-up" character in its
> protocol, but a smaller timeout for intercharacter time in the
> data part of a packet.

Yup.  Did something using SECS a few years ago, and that type
of thing is quite common for industrial protocols.  For the
protocols I've dealt with, the best solution I've found is to
have two timeouts: first-byte and inter-byte.  In Modbus for
example, when you call read() to get a reply from a slave you
want to be able to wait a configurable time (up to a couple
seconds) for the first byte, but then you want a timeout if
there is a gap between bytes of more than 3 byte times.

All of the protocols I know of are pretty happy with timer
resolutions of 1 byte-time, though the two timeouts are often
spec'ed in different units: the initial byte timeout in
absolute time (i.e. 200 milliseconds), and the inter-byte time
in baud-relative times (i.e. 3 byte-times).

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] serial driver questions

[Grant Edwards]

>   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
[...]
> Serial-Port Configuration
[...]
> Modem Status/Control Lines
[...]

FWIW, I've also noticed that the receive code in the 16550
driver ignores the receive status bits.  I'll have to change my
16850 driver so that it

 a) Throws out bytes with receive errors (parity, framing, etc.).

    Q: If this were going to be a generic driver for use by
       everybody, should I make this

       c) the way it always works.
       
       a) a runtime decision that is configurable via the
          config flags.

       b) a compile-time package configuration option.

    Option c is obviously the easiest, and that's what I'm
    going to do for now.

 b) Keeps running totals (resettable) of each of the types of
    errors.  Counting the errors is simple enough, but getting
    the info through the common serial driver code to the
    application is the tricky part.

-- 
Grant Edwards
grante@visi.com

[ECOS] Getting serial buffer status: patch attached

[Grant Edwards]

>   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've attached a patch that adds a config key and corresponding
codeto get the current rx/tx buffer info for a serial device.
This only returns status on the buffer implimented in the
mid-level serial driver, and doesn't take into account any FIFO
that the UART may have.

(It also fixes the typo in the 230400 baud rate constant.)

The diff was done against the CVS snapshot of 16 Feb or so.

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Getting serial buffer status: patch attached

[Jonathan Larmour]

Grant Edwards wrote:
> 
> I've attached a patch that adds a config key and corresponding
> codeto get the current rx/tx buffer info for a serial device.
> This only returns status on the buffer implimented in the
> mid-level serial driver, and doesn't take into account any FIFO
> that the UART may have.

Hi Grant,

I have (finally) checked this in. Sorry for the delay. The contents of the
rest of the message are why I kept putting it off :-). I do have one
uncertainty though: if the device is polled (i.e. chan->{in,out}_cbuf.len
== 0), then should rx_count/tx_count really be set to 0? Or perhaps it
should actually be 1? I think 0 is probably right, but I want to flag it if
anyone else disagrees.

Robert, here's something extra to add to the eCos device driver
documentation.

This would go in the bit corresponding to 
http://sourceware.cygnus.com/ecos/docs-1.3.1/ref/ecos-ref.11.html

Firstly, at the end of Runtime configuration (after the description of
cyg_serial_info_t has finished) add:

-=-=-=-=-

typedef struct {
  cyg_int32 rx_bufsize;
  cyg_int32 rx_count;
  cyg_int32 tx_bufsize;
  cyg_int32 tx_count;
}
cyg_serial_buf_info_t;                                                                                              

The field 'rx_bufsize' contains the total size of the incoming data buffer.
This is set to 0 on devices that do not support buffering (i.e. polled
devices).

The field 'rx_count' contains the number of bytes currently occupied in the
incoming data buffer. This is set to 0 on devices that do not support
buffering (i.e. polled devices).

The field 'tx_bufsize' contains the total size of the transmit data buffer.
This is set to 0 on devices that do not support buffering (i.e. polled
devices).

The field 'tx_count' contains the number of bytes currently occrupied in
the transmit data buffer. This is set to 0 on devices that do not support
buffering (i.e. polled devices).

-=-=-=-=-


And then later, after the CYG_IO_GET_CONFIG_SERIAL_INFO key, add this new
key:

-=-=-=-=-=-=-=-
Key:
    CYG_IO_GET_CONFIG_SERIAL_BUFFER_INFO

Buf type:
    cyg_serial_buf_info_t

Function:

  This function retrieves the current state of the software buffers in the
serial drivers. For both receive and transmit buffers it returns the total
buffer size and the current number of bytes occupied in the buffer. It does
not take into account any buffering such as FIFOs or holding registers that
the serial device itself may have.

-=-=-=-=-=-=-=-

BTW Robert, this is only relevant for releases after now, not any of the
ones currently in the pipeline.

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

Re: [ECOS] Getting serial buffer status: patch attached

[Robert Erskine]

At 01:37 AM 5/5/00 +0100, Jonathan Larmour wrote:
>Grant Edwards wrote:

>Robert, here's something extra to add to the eCos device driver
>documentation.

Okay, this has been added in addition to Jesper's stuff from yesterday.

>BTW Robert, this is only relevant for releases after now, not any of the
>ones currently in the pipeline.

But at what point does the 'current pipeline' end? 1.3.6?

And at what point should the /n/r in ecos-ref.11. html start to become
/r/n? (apart from in 1.3.3)?

Robert