alibava-gui is written in C++. The amount of classes and source files can be a little bit confusing for a beginner that wants to know where and how should a change, improvement or patch be applied. In order to facilitate that, a short description of the code organization will be given here.
There three main groups of objects in alibava-gui. In the first group we have the objects in charge of talking to the USB port of Alibava, we then have the objects in charge of handling the configuration and, finally the objects in charge of the data acquisition. The main object arbitrating all the interactions with Alibava is AlibavaGUI, which also controls the graphical user interface (GUI) of alibava-gui
The Alibava module can be read and configured via an USB port. alibava-gui has decoupled the raw USB communication from the Alibava command generation and readout. This can be seen on Figure 18. The main class, AlibavaGUI, has an object, Alibava, which is the responsible of generating the commands for the hardware an of reading out the data. It does so with the help of yet another object interface, USBport, which defines the protocol to interact with the USB port. The different implementations of an USBport object have to do with the kernel driver one uses to access the USB data. There are, currently, four of those incarnations of USBport which are USBd2xx, USBserial, USBFifo and USBemulator.
USBserial makes used of the usbserial driver in Linux. USBd2xx uses the FTDI library provided by the USB chip vendor. Finally, USBFifo creates a memory Fifo for the USB input from which the user reads. All the raw operations with the USB device are delegated in a USBport object given at the instantiation. The default for alibava-gui is USBFifo using USBserial. There is still a fourth one, USBemulator, that contacts a software daemon that emulates the behavior of the Alibava board. With USBemulator one can exercise the program without the need of having any hardware connected to the computer.
AlibavaGUI handles the acquisition process by communicating with a RunManager. Such an object has a number of methods that are called a very precise stages of the acquisition. The role of the RunManager is to impliment the differences of the different among the different run modes and make them invisible to the DAQ manager which is AlibavaGUI.
Figure Figure 19 shows the different RunManager objects defined in the program. Each of them will handle one of the different run modes.
The DAQ loop is sketched in Figure 20. There we can see the main players of the acquisition loop. AlibavaGUI calls the open method which opens the device, sends a reset command and configures the beetle and the trigger. Then, new_file and start_of_run methods of the Plugin are called. At this stage the initialization is over and the program enters the acquisition loop by calling the acquire method in AlibavaGUI. In Figure 20 we have illustrated a calibration run, but the behaviour is the same for other run modes of alibava-gui.
Most of the alibava-gui parameters can be configured. The values can be saved to a configuration file or restored from a previously saved configuration file. Each of the parts that can be configured store the data in a class that derives from ConfigFile. Figure 21 shows all those classes. For each of them, there is a class (same name with a GUI suffix) that allows to see, set and modifiy on dialog windows the current values of the parameters.