Closed CasperBroekhuizen closed 4 years ago
I agree on most of the points, I do not think we need to monitor the INAs or the TMPs as we have a status bit already in the telemetry for each and every one of them.
But I fully agree on all other points.
HWMonitor initial implementation on https://github.com/DelfiSpace/DelfiPQcore/commits/HWMonitor . The status functionality of the ResetService is moved to this object
The EPS Has a HWMonitor branch to test functionality. https://github.com/DelfiSpace/EPS_FlightSoftware/tree/HWMonitor
HWMonitor looks very good, I think we can merge it in master. It will cost you fixing the DSerial references but it should be minor.
A small code cleanup might be appropriate as the MCU temperature readout has been moved to a separate class but we still have the function commented out.
Is there a way to detect if the clock was initialized (LFTX, for example) and it failed or it was simply not initialized? Not sure it if makes sense to raise an error if we did not even initialize the clock.
We should also look into initializing the Start-count, just to avoid throwing errors. I hate errors that are always there: they might mislead you when there is actually an error and we got used to ignoring something.
But for the rest, this looks great!
I'll close this issue once i merged into master, after that ill create to new issues about the LFTX and the start-counter
I propose a new object that centralized the collection of the status of the hardware.
This way the reset status (https://github.com/DelfiSpace/FlightSoftwareWorkspace/issues/2) and Clock Status (https://github.com/DelfiSpace/DelfiPQcore/issues/18) can be collected in a different place than the 'reset-service' (which is becoming less intuitive).
This new object could also obtain the status of some of the hardware that is always present like the INA226 for board consumption and TMP100 for board temperature and FRAM.
What is your opinion on this @StefanoSperetta ?