Added

Updated

Updated

Yes, removed

Yes, moved to different place

Yes, updated

Used in handle function

added

Yes added

I thought this was a TEST_CONFIG thing. We aren't doing s/w config status, so maybe we should convert it to a TEST_CONFIG.

Let's hard code for time being with a TODO comment. I don't want alarm to be a problem.

Use OVERRIDE_RESET for .override instead of 0.

We can rename priorState to previousInstallState.
Also, it should be declared as a static variable to be able to retain previousState value when the control goes out of the function.

SW fault here?

Do we need this state if all it's doing is going to IDLE?

Might have to wait for module to not be busy before getting the data.

I think we may need to give a get data command here.

Look for request flag to give measure command and transition to measure state.

Write private handle functions for each state and call them in each case.

Should we also check whether bpMeasurementReady is TRUE?

Same.

Same. Set a request flag to TRUE (for Peds this time) and let the state machine do the rest.

Don't change state from outside signal. We should just set a requestBPMeasurement flag to TRUE in this function (if current state is IDLE) and then when the state machine runs next, the IDLE state should look for this flag to be TRUE and transition to MEASURE state (by doing all of these things you have here in this function).

Change comment to "Number of BP driver states."

Not really, I can change this to private

Add a 5th enum for NUM_OF_BP_DRIVER_STATES.
And, does this need to be public?

align indentation, same for line 338 as well.

Yes.
Otherwise, we will have to hard code the calibration record for the time being.

The function getSoftwareConfigStatus() is also part of NVM module.
Moreover, we are planning to remove this function when NVM will be implemented.
So, we will have to perform a cleanup and remove all similar calls that have been currently commented out in other files as well like AirTrap.c, BloodFlow.c, etc.