 |
 |
 |
 |
 |
 |
 |
 |
 |
14.1 What modules are good for
Modules allow to extend the set of commands that can be used in an
EDL script. This is especially important if a new device needs
to be integrated into fsc2. You don't have to change
fsc2 itself but just write a new module for the device. To do
so you don't have to understand in all the details of how fsc2
works. You only must have a working knowledge of the C
programming language and understand a few basics about fsc2's
variables (and, of course, you must know how your device works and how
to communicate with it). But modules may also be used for other
purposes beside handling devices, one could also write modules that
supply new mathematical functions or other functionalities (as for
example the module for FFT functions demonstrates). The following
discussion will concentrate on modules for new devices, writing other
kinds of modules is even simpler.
I want to start with a short summary of what a module usually consists
of and how to make fsc2 aware of its existence. The most
important things are, of course, the functions that are going to be
invoked from EDL script. Their names (in the C code) are
identical to the ones that are used as EDL function names.
Thus, while you are in principle free to chose whatever names you
fancy, it is probably reasonable to use names that fit the convention
used throughout the rest of the package to pick names that start with
the type of the device (not its name), followed by an underscore and a
descriptive name of what the function does. If there are already
devices similar to the one you're writing the module for it's best to
use names identical to the ones in these other modules and also to try
to use the same arguments if possible. This reduces the problems for
users that have to switch devices, they simply can exchange the device
name in the DEVICES section and don't have to worry about each
and every function call for the device. So, if you're writing a driver
for a lock-in amplifier stick for example with the name
lockin_get_data() and don't make up new ones like
lockin_fetch_data() when the functionality is the same.
Of course, a module will usually also contain other utility functions.
Here you're free to use whatever name you like. To avoid trouble I
always prepend the name of the device to the names of all function not
exported by the module and define them, as far as possible, as static.
Moreover, I use so-called version scripts (see the files with the exension
`.map') for complete control over which symbols get exported from a
module.
There usually are a few functions in a module beside the ones that are
going to be invoked from EDL scripts and that get called from
fsc2 if they exist. These are the so-called hook functions that
(if they exist) get invoked at certain stages of the execution of an
EDL script, i.e. after loading the module, before and after
the test run, at the start and the end of an experiment and, finally,
just before the module is unloaded. From within these functions you
can initialize the internal data of the module, initialize the device
you're controlling and finally bring it back into a well defined state
when the experiment is done.
Once you have written the module you must make fsc2 aware of
the new device it's supposed to control and inform it of the
additional EDL functions that can be used with the device. For
this purpose there are two files in the `config' directory,
called `Devices' and `Functions' where you have to enter the
name of the device and append the new functions to the list of the
already known functions. (Both these files get copied to the
same directory as the modules on installation, typically to
`/usr/local/lib/fsc2/'.
All these subjects are discussed in detail in the following. But
before we continue I want to start with an explanation of the special
type of variables used within fsc2.
|
|
|
|
|
This document was generated by Jens Thoms Toerring on September 6, 2017 using texi2html 1.82.