Introduction
Code Structure
The software structure is setup to mimic the hardware setup: each class in the software represents a module in the hardware. For example: the D5a_module class and the S4g_module class. The only exception to this is the SPI_rack class. This class handles the communication with the rack. It can be seen as the representation of the controller module (C1/C1b). All modules in a rack communicate via the one controller. This is the same for the software: all the instantiated classes communicate via a SPI_rack instantiation. The image below shows this in a block diagram:
As each SPI Rack can only have one controller, there is also only one SPI_rack object per physical SPI Rack. You can have multiple SPI Racks connected to the same PC using multiple SPI_rack objects. Each SPI Rack can have only one open connection (instantiation) on a PC. So to use the same SPI Rack in multiple measurements it either has to be a shared instance, or it has to be closed and opened again when necessary.
The SPI_rack class is setup to accommodate for threading using the parameter use_locks=True. This allows the user to setup threads using the module classes and not having to worry about simultaneous access to the connection.
Modules
Each module class represents a module type and, as explained above, communicates through a SPI_rack object. This object needs to be passed as an argument to the module at instantiation of the module. The other crucial parameter is the module address. Each physical module has to have a unique module address in the rack. This address can be set by DIP switches inside the module. At initialization this address needs to set as a parameter.
For example: lets say that we want to initialize the SPI Rack at COM Port 4 with a timeout of 1 second and a D5a module at module address 3. We would have to do the following:
spi = SPI_rack("COM4", baud=9600, timeout=1)
spi.unlock()
D5a = D5a_module(spi, module=2)
For an explanation of the SPI_rack parameters (baud, timeout and unlock), check the SPI_rack Class page.
Software Stack
The architecture of the firmware and software of the SPI Rack consists of several layers, as illustrated in the figure below. On the top of the stack is the Python user application and/or QCoDes (a Python-based data acquisition framework). The user interfaces with the SPI Rack library described on this webpage.
On the hardware side there are also multiple layers of firmware: both in the controllers and inside the modules. The controllers contain a microcontroller which facilitates the communication between the PC and the SPI Rack modules. Every module has a CPLD which contains a firmware specifically designed for that module. Certain modules also contain a microcontroller which again have a firmware running module specific code.
