Design SCA tool for monitoring/future
Summary
As has started as a discussion in #12 (closed), SCA monitoring has been moved into functions in this file, and thankfully, a lot of functionality is available in the form of getter functions:
- readSCAADCTemperatureSensors
- readSCAADCVoltageSensors
- readSCAADCSignalStrengthSensors
- readAllSCAADCSensors
Since these variables are one we would be interested in using the monitoring suite, it makes sense to review this to make sure it meets all our the requirements we have for the monitoring code.
- Compatible with GE2/1. Talking with @evka, this is as easy as replacing the GE1/1 enums that specify the channels with GE2/1 enums, but this is currently not implemented in the code.
- Possibly centralizing naming scheme of SCA channels: currently in the channel enums, there are many aliased channels which were added (I think) to stay compatible with old RPC register names (eg, FPGA_CORE and INT_V1P0 are same channel, but different register calls in the old code), but this could be cleaned up to avoid confusion of channel naming
- Make the return types of the read functions a
map<std::string, uint32_t>
instead of the currentvector<uint32_t>
form. All current calls indaq_monitor.cpp
return as a map making it easy to use the data, but as a vector, the ordering matters heavily which could be problematic for any code change. I'm not sure if the vector version is absolutely needed. If so, the "map" version could possibly be written for thedaq_monitor.cpp
file alone.
It would behoove us to make special attention to this in documentation as well. The way the SCA data is retrieved is by selecting a channel and a DATA
register is filled with the channel data. Because of these extra steps, getting this information is not as easy as accessing a simple register and should be drawn notice in the documentation somewhere.
There are probably more points to consider, but these were things I was thinking (with @lpetre thanks!), and could be expanded