[ECOS] Re: Serial device driver for linux synthetic target!

[Bart Veer <bartv at cygnus dot co dot uk>]

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

    Mansoor> Bart Veer wrote:
    >> 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).

    Mansoor> This would require a protocol between the pseudo_dev and
    Mansoor> the multiplexer process as to which actual dev it wants
    Mansoor> to talk to for eg., lcd, serial-dev or say a socket, also
    Mansoor> how this device would interact with the eCos applications
    Mansoor> is also not very clear, as to how it would handle an
    Mansoor> application requesting to open say /dev/ttyS0, probably
    Mansoor> it should be a catch all device-driver, all this seems a
    Mansoor> bit complex to me.

A protocol is needed but it can be very simple. All communication
happens over pipes so there is no need to worry about lost or
corrupted data. Something like a fixed-size header containing <packet
size, device id, device opcode> followed by a variable length data
packet would probably do the trick. Initialization, specifically the
way in which the multiplexer loads or starts the various
pseudo-devices, is a bit more interesting - there are various ways of
approaching this, most of them easy enough to implement.

The basic synthetic target code would provide HAL functions for
interacting with the pipe to the multiplexer, both read and write
operations. The former would be tied up with the synthetic target's
implementation of interrupt handling. There would be versions of the
eCos device drivers specific to the synthetic target such that e.g. an
eCos write operation involves constructing a suitable header and
sending it and the actual data down the pipe. Implementing these
device drivers should be straightforward since they do not need to
interact with any actual hardware or make any Linux system calls, they
just call the appropriate HAL routines to access the pipe.

The real power of the system comes with the pseudo devices that get
hooked up to the multiplexor on the host side. A simple implementation
of e.g. a serial pseudo device could just transmit the data down a
PC's serial device. It could also perform logging, effectively giving
you a serial analyzer. Alternatively it need not interact with any
hardware at all, it could use something like expect to examine the
data that eCos is trying to send down the serial line and generate
responses. Later on you can get fancy by providing mechanisms for
fault injection and the like.

Once the multiplexor and the synthetic target support are in place,
the system becomes very easy to extend. For example you could add a
new pseudo-device for an ethernet interface, or a CAN bus, or
whatever. In fact you can have the synthetic target fake up I/O
facilities that are not actually present on the PC, but which will be
present on the final embedded hardware.

    Mansoor> What I am aiming is to have an eCos application which was
    Mansoor> written to talk with the serial-device on the
    Mansoor> actual-hardware, should be able to run on the linux
    Mansoor> synthetic target also, without any modification
    Mansoor> whatsoever, for this a pseudo-serial device driver for
    Mansoor> linux would be sufficient just like for all other archs.
    Mansoor> ie., having i386 directory in io/serial/current/src and
    Mansoor> in that a sub-dir called linux or sim (presently) later
    Mansoor> when eCos supports actual i386 target, the device driver
    Mansoor> would be written in i386 directory.

I understand. This would certainly have its uses, but I can think of a
number of complications.

1) device names. Should the synthetic target open /dev/tty0,
   /dev/tty1, or something else? Currently I do not think there is any
   support in the synthetic target for accessing command-line
   arguments or environment variables, so configuring this information
   dynamically rather than embedding constants in the code would be a
   problem. You could try to read a configuration file via system
   calls, but that seems hard work. Hardwiring a constant name might
   be ok for a specific setup, but is inflexible.

2) constants like baud rate settings. Having an eCos source file
   #include Linux headers could well cause problems. You can cut and
   paste whatever is needed, but that could break when it comes to
   different Linux distributions or different releases. Granted,
   the constants used for baud rates are not all that likely to
   change, but the potential is there.

   By contrast, the pseudo devices are ordinary Linux applications.
   They should be easier to write and debug than trying to do
   real I/O operations inside the synthetic target. It should
   be much easier to configure them, both at compile-time via
   autoconf and at run-time.

3) if you need to access more than one device then your SIGIO handler
   would have to check multiple file descriptors. This could get
   complicated. If all I/O happens over a single pipe then the
   interrupt behaviour would be much closer to what you would end
   up with on a real embedded system.

The multiplexor approach probably would take a bit more effort to get
working, but once the initial work is done it should be much more
flexible. A lot of the nasty code related to SIGIO handling etc. could
actually be the same, irrespective of which approach is taken.

Bart Veer // eCos net maintainer