public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jlarmour@redhat.co.uk>
To: Grant Edwards <grante@visi.com>
Cc: ecos-discuss@sourceware.cygnus.com,
	Robert Erskine <roberte@redhat.co.uk>
Subject: Re: [ECOS] Getting serial buffer status: patch attached
Date: Thu, 04 May 2000 17:37:00 -0000	[thread overview]
Message-ID: <391217CD.686122F9@redhat.co.uk> (raw)
In-Reply-To: <20000302151409.A9857@visi.com>

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

  reply	other threads:[~2000-05-04 17:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-02-25  9:39 [ECOS] serial driver questions Grant Edwards
2000-03-01  4:31 ` Jonathan Larmour
2000-03-01  4:49   ` Kenneth Porter
2000-03-02  8:12     ` Grant Edwards
2000-03-02  8:03   ` Grant Edwards
2000-03-02 11:53 ` Grant Edwards
2000-03-02 13:14 ` [ECOS] Getting serial buffer status: patch attached Grant Edwards
2000-05-04 17:37   ` Jonathan Larmour [this message]
2000-05-05  8:18     ` Robert Erskine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=391217CD.686122F9@redhat.co.uk \
    --to=jlarmour@redhat.co.uk \
    --cc=ecos-discuss@sourceware.cygnus.com \
    --cc=grante@visi.com \
    --cc=roberte@redhat.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).