feat: adc scheduling and data reading #15
Conversation
|
|
||
| // Insane temperature ranges that should never be reached. | ||
| // Hitting this is a strong indicator of a bug in the Argus system. | ||
| _ => panic!("T < -270 or T > 1372 celcius") |
There was a problem hiding this comment.
Thoughts on the panic here? Theoretically these temperatures are not attainable for Argus, however we could return some number like -1.0 as it was before my refactoring if you prefer.
There was a problem hiding this comment.
I think this is more of an error than a panic. Yes you are totally correct this rocket should never get that hot 🌶️ but I am strongly against panics that are not in init functions. You can create a thermocouple conversion error type and then add this to hydra error manager so that we can capture it in the error manager and just call xyz.temp_convert()?;
I also am not a fan of returning -1 because it can be really cryptic and we can just throw an error nicely
There was a problem hiding this comment.
I also don't like returning -1, it was just the prior implementation. We can implement an error for this of course, and I pondered that, but was just concerned about potentially complicating the API when hitting this would indicate much larger issues. I guess we can just handle this or whatever, and if it hits an error, we trigger a fault state in the SM and re-calibrate or something?
There was a problem hiding this comment.
Yeah exactly, something like this would be a fault and we could for example take that temperature sensor offline if it persists or we just outright take it offline.
There was a problem hiding this comment.
This way we can reduce the time taken to get back to normal execution compared to a panic
There was a problem hiding this comment.
Fair enough. Do you want to implement that quickly then? I probably won't have time until after the reading break.
No description provided.