firmware

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
DEN-14175 addressed the code review comments

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED IN CODE WALKTHROUGH

RESOLVED IN CODE WALKTHROUGH

Remove test code.

Remove test code.

RESOLVED IN CODE WALKTHROUGH

RESOLVED IN CODE WALKTHROUGH

Remove test code.

Remove test code.

RESOLVED IN CODE WLAKTHROUGH

RESOLVED IN CODE WLAKTHROUGH

Looks like blank line is still there.

Looks like blank line is still there.

DEN-14150: Update DialInFlow.c

Done.

Done.

Done.

Done.

Done.

Done.

I know all the FW code is written in this style but it is always interesting to me, 1 - why don't just say if ( isSyringePumpPreLoaded() ) the function is a boolean why compare to TRUE to get a bo...

I know all the FW code is written in this style but it is always interesting to me,
1 - why don't just say

if ( isSyringePumpPreLoaded() )

the function is a boolean why compare to TRUE to get a bool expression?
if it was returning an int it made sense to have something like this:

if ( isSyringePumpPreLoaded() != 0 )

Which is still unnecessary in some cases.
2 - even if we want to use TRUE, why to put it at the beginning of the expression and don't put it at the end, like

if ( isSyringePumpPreLoaded() == TRUE )

So the first thing developer sees would be the important part which is the function not always a TRUE or FALSE.

RESOLVED IN CODE WALKTHROUGH

RESOLVED IN CODE WALKTHROUGH

If we want to do that for consistency, that's fine but let's handle that as a bulk update and going forward kind of thing rather than keep commenting individually on code reviews.

If we want to do that for consistency, that's fine but let's handle that as a bulk update and going forward kind of thing rather than keep commenting individually on code reviews.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

I think the else can end right after ramp. Ok to do checks I would think.

I think the else can end right after ramp. Ok to do checks I would think.

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

Bamboo Commit: Updated HDCommon.h with build versions from Bamboo

RESOLVED in CODE WALKTHROUGH.

RESOLVED in CODE WALKTHROUGH.

Merge branch 'DEN-14150-hd-dialysate-flow-estimation' into develop

Merge branch 'develop' of ssh://dvm-linux02:7999/hd/hdfirmware into develop

DEN-14150: Update DialInFlow.c

Done.

Done.

Not what I meant. I mean when we're determining whether the measured flow is within 50% of estimated flow, we should use the get function (that allows override to be considered) instead of using fi...

Not what I meant. I mean when we're determining whether the measured flow is within 50% of estimated flow, we should use the get function (that allows override to be considered) instead of using filteredDialinFlowMeterReading.

DEN-14170 Updated for code review comments.

Per Sean - "No harm in adding "F" suffix, but not necessary for assignment to a float variable". Will leave as is for float vars.

Per Sean - "No harm in adding "F" suffix, but not necessary for assignment to a float variable". Will leave as is for float vars.

Per Sean - "No harm in adding "F" suffix, but not necessary for assignment to a float variable". Will leave as is for float vars.

Per Sean - "No harm in adding "F" suffix, but not necessary for assignment to a float variable". Will leave as is for float vars.