RE: OpenG Serial drivers

[Rolf K. <rol...@ci...>]

Scott Hannahs wrote:

> At 22:26 +0100 1/13/05, Martin Henz wrote:
> >  Scott  Hannahs  has  a  set  of  serial drivers maybe from
> >  Albert  Geven.
>=20
> Yes, these are based on Albert's NLSerial library from phillips.

Just to be sure. I wonder if for the serpdrv (the translation driver
on Windows ultimatively used by this library) might not be a similar
issue with licensing. NI wanted to have runtime fees for LabVIEW
executables at some time and then dropped that as far as you built
executables which used NI hardware or the built-in serial port.
With standard serial ports disappearing from PCs more and more this
can get also an issue.

On Mac Classic the serial port driver was simply a VI library calling
into the Mac OS device driver interface so recreating the VIs would
have been a complete solution as well as calling any other possible
hardware which had a device driver installed.

In the case of the Windows serpdrv driver, this one had quite some
limitations. It is possible to use for simple device communication
but a pain in the ass or impossible to do more complicated things.
=20
> > > What is needed is a CROSS PLATFORM serial interface.
> >
> >So we need developers esp. for Mac OS and Linux.
>=20
> Since OS X and linux use the same ioctl and unix read/write=20
> calls that are posix compatible it should be a single piece=20
> of code that is cross compiled.
>=20
> >The  next  steps  would  be the examination of the collected
> >packages. Then we'll decide what we exactly want to do.
>
> The trick will be deciding how to do a lot of the visa=20
> properties, opening and closing and locking resources.  I=20
> have a VISA imitation framework that I used for my GPIB=20
> driver.  This was sort of VISA looking thing but it worked.=20
> Properties are stored as strings as a key and data as a=20
> variant.  It was kept in an array of visa resource names.
>=20
> That code is all Labview and certainly available as well to=20
> open G.  At the base level it called into the GPIB driver,=20
> but it could call serial port primitives as well.  It would=20
> be nice to keep as much of the code as possible in Labview=20
> and only stubs in platform specific libraries.  There is a=20
> cute trick that Christophe Salzmann has for making fat=20
> libraries with multiple code objects for all platforms in it.

This is an interesting solution but maybe a little heavyweight.
On the posititve side of it is the fact that most LabVIEW
developers could contribute to it in one or the other way.

My own solution where I have a quite finished framework written
in C for at least Windows and Unix, but no hardware specific
drivers yet, is to actually implement a fully VISA compatible
external library with plugin DLLs for the different hardware
interfaces. It is a very modular approach with the main library
implementing the VISA interface, a support library providing
platform independant services such as memory allocation, mutexes,
ini file access, string handling, shared library access etc, and
with each VISA resource type handled in one hardware driver module. =20

The main library could eventually be placed into the application
folder and would be picked up by that application if it wants to
use VISA. Until it is to that point where it really can replace
VISA for some interfaces, its name could be changed to a different
name than the standard VISA library name and a VISA compatible
VI library with with Call Library Nodes could provide access to
it.

I'm willing to provide this code under an LGPL compatible license
into an OpenG project of some sort if there is interest for it.
Since it is a dynamically linked library, this would IMO provide
for all potential users with a good solution.

Rolf Kalbermatter