* [ECOS] Serial device driver for linux synthetic target! @ 1999-10-05 3:31 Mohammed Illyas Mansoor 1999-10-05 6:16 ` [ECOS] " Bart Veer 0 siblings, 1 reply; 5+ messages in thread From: Mohammed Illyas Mansoor @ 1999-10-05 3:31 UTC (permalink / raw) To: ecos-discuss, rprakash, mansoor Hi all, I would like to have serial communications enabled in linux synthetic target, is any body planning to write a pseudo-serial device driver for linux synthetic target. I had some ideas related to this, how about using asynchronous i/o for reading and normal non-blocked read & write systems calls on the serial ports. I would like to discuss more on this in detail, if any body is interested in this work can contribute their ideas I would like to implement this in eCos. --With Regards, M. I. Mansoor. ^ permalink raw reply [flat|nested] 5+ messages in thread
* [ECOS] Re: Serial device driver for linux synthetic target! 1999-10-05 3:31 [ECOS] Serial device driver for linux synthetic target! Mohammed Illyas Mansoor @ 1999-10-05 6:16 ` Bart Veer 1999-10-05 7:01 ` William Gatliff 1999-10-05 8:10 ` [ECOS] " Mohammed Illyas Mansoor 0 siblings, 2 replies; 5+ messages in thread From: Bart Veer @ 1999-10-05 6:16 UTC (permalink / raw) To: mansoor; +Cc: ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] Re: Serial device driver for linux synthetic target! 1999-10-05 6:16 ` [ECOS] " Bart Veer @ 1999-10-05 7:01 ` William Gatliff 1999-10-05 8:10 ` [ECOS] " Mohammed Illyas Mansoor 1 sibling, 0 replies; 5+ messages in thread From: William Gatliff @ 1999-10-05 7:01 UTC (permalink / raw) To: ecos-discuss > 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). I like this idea a lot. My main mission for the synthetic target is automated testing (well someday, anyway), and your approach would mean less disruption of my code when running in a synthetic environment. It also sounds like what Mansoor wants, albeit with considerably more flexibility. b.g. -- William A. Gatliff Senior Design Engineer Komatsu Mining Systems To teach is to learn. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ECOS] Serial device driver for linux synthetic target! 1999-10-05 6:16 ` [ECOS] " Bart Veer 1999-10-05 7:01 ` William Gatliff @ 1999-10-05 8:10 ` Mohammed Illyas Mansoor 1999-10-05 11:59 ` [ECOS] " Bart Veer 1 sibling, 1 reply; 5+ messages in thread From: Mohammed Illyas Mansoor @ 1999-10-05 8:10 UTC (permalink / raw) To: bartv; +Cc: ecos-discuss 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). This would require a protocol between the pseudo_dev and the multiplexer process as to which actual dev it wants to talk to for eg., lcd, serial-dev or say a socket, also how this device would interact with the eCos applications is also not very clear, as to how it would handle an application requesting to open say /dev/ttyS0, probably it should be a catch all device-driver, all this seems a bit complex to me. What I am aiming is to have an eCos application which was written to talk with the serial-device on the actual-hardware, should be able to run on the linux synthetic target also, without any modification whatsoever, for this a pseudo-serial device driver for linux would be sufficient just like for all other archs. ie., having i386 directory in io/serial/current/src and in that a sub-dir called linux or sim (presently) later when eCos supports actual i386 target, the device driver would be written in i386 directory. The actual aim of this synthetic device driver is to help me test TCP/IP stack which I am planning to port, using the SLIP driver with a linux box attached on the other end running SLIP. > 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. > This is what extactly I was having in my mind also. > > Obviously there are plenty of details to be resolved, but this would > be a very powerful extension to the synthetic target support. > This pseudo-device would really be a nice thing to have in the synthetic target, if the device driver handles all the details with respect to the multiplexer process transparent to the eCos application thread. --With Regards, M. I. Mansoor ^ permalink raw reply [flat|nested] 5+ messages in thread
* [ECOS] Re: Serial device driver for linux synthetic target! 1999-10-05 8:10 ` [ECOS] " Mohammed Illyas Mansoor @ 1999-10-05 11:59 ` Bart Veer 0 siblings, 0 replies; 5+ messages in thread From: Bart Veer @ 1999-10-05 11:59 UTC (permalink / raw) To: mansoor; +Cc: ecos-discuss >>>>> "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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1999-10-05 11:59 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-10-05 3:31 [ECOS] Serial device driver for linux synthetic target! Mohammed Illyas Mansoor 1999-10-05 6:16 ` [ECOS] " Bart Veer 1999-10-05 7:01 ` William Gatliff 1999-10-05 8:10 ` [ECOS] " Mohammed Illyas Mansoor 1999-10-05 11:59 ` [ECOS] " Bart Veer
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).