leahi-common

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
signal function will take us out of blood prime, so no reason to change state here. We would not want to go to run state even if we weren't leaving - run state is for when user changes blood flow r...

signal function will take us out of blood prime, so no reason to change state here. We would not want to go to run state even if we weren't leaving - run state is for when user changes blood flow rate which they have not done here.

Raghu is fixing this in his Tx Params branch, but you should fix it too. TUBING_BLOOD_PRIME_VOLUME_ML is not a treatment parameter. See Raghu's fix and duplicate it here.

Raghu is fixing this in his Tx Params branch, but you should fix it too. TUBING_BLOOD_PRIME_VOLUME_ML is not a treatment parameter. See Raghu's fix and duplicate it here.

But now it's not in right position (in this table only). This table should be sorted by rank.

But now it's not in right position (in this table only). This table should be sorted by rank.

the 2nd if statement for beta 1.0 is an ask from systems team to raise fault alarm if user by mistake enable Beta 2.0 config when Beta1.0 is active

the 2nd if statement for beta 1.0 is an ask from systems team to raise fault alarm if user by mistake enable Beta 2.0 config when Beta1.0 is active

LEAHI-TD-FIRMWARE-LDT-3126_Blood Prime - TD
LEAHI-TD-FIRMWARE-LDT-3126_Blood Prime - TD
removed both enums

removed both enums

Updated

Updated

Updated

Updated

This was correct before (assuming 711 was correct rank).

This was correct before (assuming 711 was correct rank).

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 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.

In comment, specify units is % duty cycle (0..100%).

In comment, specify units is % duty cycle (0..100%).

Should we specify that power level is now a duty cycle percentage (0..100%)?

Should we specify that power level is now a duty cycle percentage (0..100%)?

Updated

Updated

Updated

Updated

We have a FRACTION_TO_PERCENT_FACTOR in Common.h that we can use when we need 100.0.

We have a FRACTION_TO_PERCENT_FACTOR in Common.h that we can use when we need 100.0.

We've been using capital F. Let's be consistent.

We've been using capital F. Let's be consistent.

Don't call function in function call. Set local var to scalar, then pass local var as param.

Don't call function in function call. Set local var to scalar, then pass local var as param.

You can use RANGE macro in Common.h for this.

You can use RANGE macro in Common.h for this.

( F32 percentage ) { }

( F32 percentage )
{
}

Add space around () i.e. ..Scalar( F32 percentage );

Add space around () i.e. ..Scalar( F32 percentage );

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 t...

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.

Updated

Updated

Updated

Updated

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 comm...

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 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.

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.

Move this up to public definitions section.

Move this up to public definitions section.

LEAHI-TD-FIRMWARE-LDT-1903_Air Trap Level Control - TD - 04: DEV - Feature Implementation
LEAHI-TD-FIRMWARE-LDT-1903_Air Trap Level Control - TD - 04: DEV - Feature Implementation
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 understandab...

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)