* [ECOS] A "pipe" like object for eCos?
@ 2008-05-29 18:28 Grant Edwards
2008-05-29 18:32 ` Andrew Lunn
0 siblings, 1 reply; 4+ messages in thread
From: Grant Edwards @ 2008-05-29 18:28 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] A "pipe" like object for eCos?
2008-05-29 18:28 [ECOS] A "pipe" like object for eCos? Grant Edwards
@ 2008-05-29 18:32 ` Andrew Lunn
2008-05-29 22:25 ` [ECOS] " Grant Edwards
2008-05-29 22:52 ` Grant Edwards
0 siblings, 2 replies; 4+ messages in thread
From: Andrew Lunn @ 2008-05-29 18:32 UTC (permalink / raw)
To: Grant Edwards; +Cc: ecos-discuss
[-- 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ECOS] Re: A "pipe" like object for eCos?
2008-05-29 18:32 ` Andrew Lunn
@ 2008-05-29 22:25 ` Grant Edwards
2008-05-29 22:52 ` Grant Edwards
1 sibling, 0 replies; 4+ messages in thread
From: Grant Edwards @ 2008-05-29 22:25 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ECOS] Re: A "pipe" like object for eCos?
2008-05-29 18:32 ` Andrew Lunn
2008-05-29 22:25 ` [ECOS] " Grant Edwards
@ 2008-05-29 22:52 ` Grant Edwards
1 sibling, 0 replies; 4+ messages in thread
From: Grant Edwards @ 2008-05-29 22:52 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-05-29 22:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-05-29 18:28 [ECOS] A "pipe" like object for eCos? Grant Edwards
2008-05-29 18:32 ` Andrew Lunn
2008-05-29 22:25 ` [ECOS] " Grant Edwards
2008-05-29 22:52 ` Grant Edwards
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).