[ECOS] A "pipe" like object for eCos?

[ECOS] A "pipe" like object for eCos?

[Grant Edwards]

I find myself in need of a "pipe" like object in an eCos
application (one that doesn't have file I/O and Posix support
enabled).  All I need is a simple circular buffer in RAM with
blocking and non-blocking read/write methods.  Am I correct in
my conclusion that eCos doesn't have something like that as
part of it's core functionality?

I haven't found anything like that in the docs, but I thought
I'd double-check before I go off and write something...

-- 
Grant Edwards                   grante             Yow! I'm shaving!!
                                  at               I'M SHAVING!!
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] A "pipe" like object for eCos?

[Andrew Lunn]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Thu, May 29, 2008 at 06:27:30PM +0000, Grant Edwards wrote:
> I find myself in need of a "pipe" like object in an eCos
> application (one that doesn't have file I/O and Posix support
> enabled).  All I need is a simple circular buffer in RAM with
> blocking and non-blocking read/write methods.  Am I correct in
> my conclusion that eCos doesn't have something like that as
> part of it's core functionality?
> 
> I haven't found anything like that in the docs, but I thought
> I'd double-check before I go off and write something...

There was a pipe implementation contributed. I spent some time
cleaning it up a few years ago. Try the attachment.

         Andrew

[-- Attachment #2: pipe.tgz --]
[-- Type: application/x-gtar, Size: 5550 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: A "pipe" like object for eCos?

[Grant Edwards]

On 2008-05-29, Andrew Lunn <andrew@lunn.ch> wrote:
> On Thu, May 29, 2008 at 06:27:30PM +0000, Grant Edwards wrote:
>> I find myself in need of a "pipe" like object in an eCos
>> application (one that doesn't have file I/O and Posix support
>> enabled).  All I need is a simple circular buffer in RAM with
>> blocking and non-blocking read/write methods.  Am I correct in
>> my conclusion that eCos doesn't have something like that as
>> part of it's core functionality?
>> 
>> I haven't found anything like that in the docs, but I thought
>> I'd double-check before I go off and write something...
>
> There was a pipe implementation contributed. I spent some time
> cleaning it up a few years ago. Try the attachment.

That looks pretty close to what I need, except it doesn't
support non-blocking write (AFAICT).

Does anybody else find the BSD select() API extremely clumsy
when one simply wants to do something like a non-blocking write
or a read with a timeout?

It sure seems like a cyg_io_read() or cyg_io_write() with a
timeout value (e.g. negative is blocking, zero is non-blocking,
positive is timeout in system ticks) would be a lot cleaner and
less error-prone than having to configure the fileio package
and then messing about with fdset macros and a timeval struct.
Even then, it seems you don't get non-blocking write semantics
unless you call select for every single byte you want to write.

In the original eCos I/O subsystem design, how was one supposed
to do non-blocking read/write operations or read/write
operations with timeouts?  I ended up added those features to
my serial driver, but it was a bit of a kludge that was done
"behind the curtains" by setting various flags/values with
cyg_io_set_config() before calling cyg_io_read/write().

-- 
Grant Edwards                   grante             Yow! I just went below the
                                  at               poverty line!
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: A "pipe" like object for eCos?

[Grant Edwards]

On 2008-05-29, Andrew Lunn <andrew@lunn.ch> wrote:
> On Thu, May 29, 2008 at 06:27:30PM +0000, Grant Edwards wrote:
>> I find myself in need of a "pipe" like object in an eCos
>> application (one that doesn't have file I/O and Posix support
>> enabled).  All I need is a simple circular buffer in RAM with
>> blocking and non-blocking read/write methods.  Am I correct in
>> my conclusion that eCos doesn't have something like that as
>> part of it's core functionality?
>> 
>> I haven't found anything like that in the docs, but I thought
>> I'd double-check before I go off and write something...
>
> There was a pipe implementation contributed. I spent some time
> cleaning it up a few years ago. Try the attachment.
>
>          Andrew
>
> [begin attachment: pipe.tgz]

The following code looks odd:

   287	// --------------------------------------------------------------------------
   288	// Implement Flush/Drain controls
   289	
   290	static Cyg_ErrNo
   291	pipe_get_config(cyg_io_handle_t handle,
   292	                cyg_uint32 key, void *buf, cyg_uint32 * len)
   293	{
   294	     cyg_devtab_entry_t *devtab = (cyg_devtab_entry_t *) handle;
   295	     PIPE_INFO_S *pipeInfo = (PIPE_INFO_S *) devtab->priv;
   296	     Cyg_ErrNo retVal = ENOERR;
   297	
   298	     switch (key) {
   299	          // clear the buffer and signal any threads waiting.
   300	     case CYG_IO_GET_CONFIG_SERIAL_INPUT_FLUSH:
   301	     case CYG_IO_GET_CONFIG_SERIAL_OUTPUT_FLUSH:
   302	     case CYG_IO_GET_CONFIG_SERIAL_OUTPUT_DRAIN:
   303	          cyg_drv_mutex_lock(&pipeInfo->lock);
   304	          pipeInfo->writeIndex = 0;
   305	          pipeInfo->readIndex = 0;
   306	          pipeInfo->dataLength = 0;
   307	          cyg_drv_cond_broadcast(&pipeInfo->wait);
   308	#ifdef CYG_IO_PIPE_SELECT_SUPPORT
   309	          cyg_selwakeup(&pipeInfo->selinfoTx);
   310	#endif
   311	          cyg_drv_mutex_unlock(&pipeInfo->lock);
   312	          retVal = ENOERR;
   313	          break;
   314	         
   315	     default:
   316	          retVal = -EINVAL;
   317	          break;
   318	     }
   319	    
   320	     return (retVal);
   321	}

It looks like all three of those flush/drain operations do the
same thing: discard all of the data.  I can see why both flush
operations might discard the data, since it's not a
directionless interface, but shouldn't the drain operation just
block until the buffer is empty instead of discarding data?

-- 
Grant Edwards                   grante             Yow! PARDON me, am I
                                  at               speaking ENGLISH?
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss