Factory and Registry for PBv3 Testbenches

A configurable way to create PBv3TB objects that allows to switch between single board test setup, mass tester or (future) module control without recompiling code. It uses the ClassRegistry to create a registry of all PBv3TB implementations. Those can then be configured and created from a hardware configuration file using the PBv3TBConf factory class.

Hardware Configuration

The same hardware configuration file as used for power supply definitions is used. The motivation is to reduce the number of configuration files that need to be passed to the different tools.

The testbench is defined inside the testbenches block. It consists of a dictionary with the keys labeling the setup. The contents are:

• type: Class name for the desired PBv3TB implementation
• Other configurations for the specific testbench. For example, the Bk load device for PBv3TBSingle is stored under bkdev.

The example configuration file under config/equip_testbench.json contains the example configuration for a mass tester and single board setups.

"testbenches": {
    "comment": "Rename massive or single to default for your corresponding setup!"
    "massive": {
        "type"  : "PBv3TBMassive",
        "i2cdev": "/dev/i2c-0"
    },
    "single": {
        "type"  : "PBv3TBSingle",
        "bkdev": "/dev/ttyUSB0"
    }
}

The same hardware configuration file also contains the power supply definitions. There should be at least two channels defined: HVin and Vin. For now, the channel names are hardcoded.

Factory Class

The PBv3TB implementation can be instantiated from the PBv3TBConf factory class using the getPBv3TB method. The method takes the testbench definition name as an argument. All programs currently hardcode this name as "default".

The testbench factory is also responsible for creating the necessary power supply objects that should be located in the same hardware configuration file. It does this via an internal EquipConf instance. The power supplies should be defined in the same hardware configuration file as the testbenches.

If a new testbench object has to be initialized, it is done via the following steps:

1. Instantiate the object.
2. Apply configuration by passing the testbench definition JSON to PBv3TB::setConfiguration.
3. Associate the power supply channels.
4. Initialize the testbench via PBv3TB::init.

Changes to PBv3TB

A few changes were done to the PBv3TB interface to work better with the factory class. They are:

• Initialization of the testbench is no longer performed in the constructor.
• Add PBv3TB::init pure virtual function responsible for initializing all internal objects after configuration is applied. This function should only perform initialization necessary to communicate with the testbench. The state should not be reset to allow reading from an already active testbench.
• Add PBv3TB::setConfiguration virtual function that allows configuration of the testbench via JSON.
• Power supplies are now associated via PBv3TB::setLV/HVPS.

Programs

All programs have been updated to use the PBv3TBConf class to create the PBv3TB object. The general code for this is the following, where equipConfigFile is the optional argument passed via -e.

PBv3TBConf factory_pbv3tb(equipConfigFile);
std::shared_ptr<PBv3TB> tb=factory_pbv3tb.getPBv3TB("default");
if(tb==nullptr)
  return 1;

This includes the endeavour command that has been updated to use the PBv3TB directly instead of manually creating the EndeavourCom object.