Re: Babbling serial device

[Marty Kraimer <mrk@aps.anl.gov>]

With asynDriver the same goal can be attained in a more generic fashion.

One solution is as follows:

The code, lets call it thalesDriver would use two portNames. Lets call 
them psuedoPort and actualPort.

For psuedoPort, thalesDriver would call registerPort and 
registerInterface just like an actual serial driver.
It would create an asynUser for actualPort, i. e. it would just be a 
normal asynUser.

The code details could be very similar to what Eric has already done.

Some advantages of using asynDriver rather than gpibCore are:

1) This solution will work on all supported architectures, i.e. vxWorks, 
Linux, RTEMS, win32, solaris, darwin.

2) The asynTrace facility will work on both psuedoPort and actualPort..

3) Connection management will work on both psuedoPort and actualPort.

4) By implementing some of the new register interfaces,  the generic 
register based device support can be used. Thus no special device 
support would be needed.

5) Since gpibCore no longer has anyone to support it, asynDriver will 
have a longer lifetime :-)

NOTE: I was supporting gpibCore. asynDriver is the successor to gpibCore 
plus much more.

Marty Kraimer



Eric Williams wrote:

> I just thought I'd throw this solution out so it would be in the 
> archives if someone else needed it.
>
> We have a RS-232 device we wanted to control with EPICS (a Thales 
> Optem zoom lens control stepping motor drive) that reported its status 
> on a continuous basis.  The IOC was a Linux box running 3.14 with the 
> GpibCore driver used to talk to the serial port.
> Because the device didn't wait for a command but instead sent its 
> status periodically, the serial port's input buffer would fill up and 
> cause GpibCore to get an error and dump EPICS as soon as you tried to 
> process any of the records going to the device's port.  I thought 
> about digging into the driver and making it more tolerant of babbling 
> devices, but abandoned that idea in favor of an easier solution.
>
> I built a filter daemon which would open the serial port to the device 
> and pick up the input stream, decode the status, and store it 
> locally.  The other side of the filter was through a pseudo-tty which 
> emulated the device's command set, passing on commands to the device, 
> but with the addition of a new command to read the local copy of the 
> current status.  This daemon ran in the background, and the GpibCore 
> driver would talk to the pseudo-tty port instead of the serial port.  
> The daemon was auto-started through the standard Linux init mechanisms.
> --
> Eric Williams
> Advance Light Source
> Lawrence Berkeley Lab