From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bart Veer <bartv@cygnus.co.uk>
To: mansoor@cdotb.ernet.in
Cc: ecos-discuss@sourceware.cygnus.com
Subject: [ECOS] Re: Serial device driver for linux synthetic target!
Date: Tue, 05 Oct 1999 06:16:00 -0000
Message-id: <199910051316.OAA06305@sheesh.cygnus.co.uk>
References: <37F9865C.3496B9C3@cdotb.ernet.in>
X-SW-Source: 1999-10/msg00018.html

>>>>> "Mansoor" == Mohammed Illyas Mansoor <mansoor@cdotb.ernet.in> writes:

    Mansoor> I would like to have serial communications enabled in
    Mansoor> linux synthetic target, is any body planning to write a
    Mansoor> pseudo-serial device driver for linux synthetic target. I
    Mansoor> had some ideas related to this, how about using
    Mansoor> asynchronous i/o for reading and normal non-blocked read
    Mansoor> & write systems calls on the serial ports. I would like
    Mansoor> to discuss more on this in detail, if any body is
    Mansoor> interested in this work can contribute their ideas I
    Mansoor> would like to implement this in eCos.

Within Cygnus we have been thinking along slightly different lines,
but nothing has been implemented yet. The basic idea involved having
the synthetic target application talking over a pipe to an external
multiplexer process (possibly a program, possibly a Tcl script running
in a suitable interpreter, whatever).

    +------+	  +------+<-----> dev1
    |      |	  |    	 |
    | eCos |<---->|  MX	 |<-----> dev2
    |      |	  |    	 |
    +------+	  +------+<-----> dev3


When the eCos application wants to generate output, the device driver
would end up writing a suitable packet down the pipe to the
multiplexer. This could be a serial device driver, an lcd device
driver, whatever. The multiplexer would pass the data on to a
device-specific application, or possibly to a dynamically loaded
script running within the same interpreter. The device-specific
application could operate in a number of different ways. It could
provide functionality like the "expect" program, analysing the
generated data and sending back responses. It could forward the data
to real hardware such as the PC's serial line. For something like an
lcd device it could display the data in a suitable window. Because
everything goes via host software there is plenty of scope for adding
little debugging and tracing facilities.

The device-specific application could also send data back to the eCos
application. This would arrive on the pipe, causing a SIGIO signal to
be raised. The synthetic target's interrupt handling support would be
rewritten around SIGIO.

Obviously there are plenty of details to be resolved, but this would
be a very powerful extension to the synthetic target support.

Bart Veer // eCos net maintainer