Writing drivers

Writing drivers

openSciLab never asks which kind of device is connected: a driver describes what its device can do (its capabilities and facets - capture, GPIO, monitor, analog inputs and outputs, generator), and the device list, the device card, the data view, flows, the command line and the Python API offer what that allows. This page says where to start; the reference is docs/drivers.md.

Two ways to add a device

	Plugin	Built in
Where	a .py file or package outside openSciLab	openscilab/driver/<device>/, openscilab/ui/devices/<device>.py and openscilab/plugins/<device>.py
Changes to openSciLab	none	a driver, a device backend and a plugin that registers both
For	your own instruments, lab equipment, experiments	devices the project ships
Example	examples/plugins/counter_device.py	the Pico, Arduino, DSLogic and Rigol drivers

A plugin is loaded from the plugins folder of the settings directory (~/Library/Application Support/openSciLab/plugins on macOS, %APPDATA%\openSciLab\plugins on Windows, ~/.config/openSciLab/plugins on Linux), from a folder in the environment variable OPENSCILAB_PLUGINS, or from an installed package with an entry point in the group openscilab.plugins. It registers its kind of address (mydevice:...); from then on the device opens like a built-in one - also in a device process of its own. The built-in devices are plugins as well: those in openscilab/plugins/ register their kinds the same way and load first; Help → Plugins… and openscilab-cli plugins list them as built in.

A plugin can also add node types for the flows, with @node as the own nodes of a project (see Nodes); every flow and project knows them, the palette shows them in a group of their own. Example: examples/plugins/calibration_nodes.py.

What a driver provides

• a subclass of AnalyzerDriverBase (openscilab/driver/base.py, free of Qt): channels, rates, limits, capabilities and the capture (buffer, stream);
• optional facets for what else the device does: GPIO, monitor, analog inputs, analog outputs, a generator, protocol transmitters - each unlocks the matching device card tabs and flow nodes;
• a simulator first: new behaviour is written and tested against a simulated device or a fake transport, before hardware is involved (Simulators, docs/simulator.md).

The capability words and the protocols of the openSciLab firmware are specified in docs/protocols.md. A device that is a computer of its own (a Raspberry Pi, the PC of a DAQ) needs no driver at all: it talks to openSciLab over the network with the openscilab_device package, see Remote devices.

Protocol decoders

Decoders are not drivers: they are sigrok decoders in Python and are added by copying their folder, see Protocol decoders.