readFloaterLevelStatus is higher level functions that give the data from the FPGA. Reason why we had these get functions here is, based on the FPGA response we translate it to the user understandable enum values (low, medium, high)
Move to the PreTreatmentCreateStack.qml Think of these types of things as modules. If you have the CreateTreatment as a module, the Stack manager file shall take care of screens and their state, and not the main.qml. Is there any reason they are called here and not on the section that has been removed from the Create Stack?
Noe says we can distinguish between beta 1.9 and 2.0 w/ ID (4 and 6). We still need test configs for beta 1.0 stuff and non-fpga differences. We can use DD fpga ID # here in this macro instead of test config. Since this is all temporary, I'm not that concerned about how we do this so long as it works.
This is a reset call, as the default requirement is to be on Beta 1.9 HW The logic is checking if the user is resetting the Beta 2.0 config, if yes, we will have to fall back to the Beta 1.9 FPGA registers
I think Sameer is saying that the monitor should just call one get level function in FPGA and that one function (in FpgaDD.c) would handle all of this beta 1/1.9/2.0 stuff. I agree, but didn't comment on it because it's all temporary anyway.
Why change rank back to 206? If priority is low, rank was probably correct at 711. I think you had correct properties before - it was just in the wrong row.
Why do we need a get function to call another get function? The caller of this function should just call getFPGAGPIOStatus() and then we wouldn't need this.
this seems to fail here because if we enter TREATMENT_DIALYSIS_STATE then the Blood Prime screen is not going to show and thus failing the squish test case
