dd-firmware

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
LDT-3603 moved declaration to top of the scope

    • -2
    • +5
    /firmware/App/Modes/FPModes/FPOperationModes.c
LDT-3603 added validate before making a request call in dialin test handler

    • -53
    • +111
    /firmware/App/Modes/FPModes/FPOperationModes.c
    • -3
    • +1
    /firmware/App/Modes/FPModes/FPOperationModes.h
    • -4
    • +21
    /firmware/App/Modes/FPModes/ModeGenPermeate.c
    • -0
    • +1
    /firmware/App/Modes/FPModes/ModeGenPermeate.h
Bamboo Commit: Updated DDCommon.h with build versions from Bamboo.

Resolved merge conflicts from staging merge

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

Bamboo Commit: Updated the Copyright section and replaced tabs with 4 spaces

Merged LDT-3605

LDT-3103 pressure range check for diff qd for d48 pump

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

Bamboo Commit: Updated the Copyright section and replaced tabs with 4 spaces

Merge branch 'LDT-3372-v1-conductivity-fixes' into staging

LEAHI-DD-FIRMWARE-LDT-3605_(DD) BLD sensor intermittently does not read for B2.0 HW
LEAHI-DD-FIRMWARE-LDT-3605_(DD) BLD sensor intermittently does not read for B2.0 HW
LDT-3605 updated the blood leak driver for the hardware config restart

LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
See my comment above. We should return BOOL so Dialin request can be ACK/NAK'd.

See my comment above. We should return BOOL so Dialin request can be ACK/NAK'd.

No faults from Dialin commands - we never want Dialin to cause system to go to fault because it requested something invalid - we only NAK the invalid request. We should do whatever is needed (if an...

No faults from Dialin commands - we never want Dialin to cause system to go to fault because it requested something invalid - we only NAK the invalid request.
We should do whatever is needed (if anything) to start the mode normally in an else.
And we should return TRUE/FALSE in these signal functions so that when it's called from Dialin msg handler, the msg handler can return ACK/NAK to Dialin if sub mode is invalid.

We shouldn't request op mode until we're sure we're happy with the whole thing. Need to determine whether we are already in the op mode being requested. If so, no need to request it again - just re...

We shouldn't request op mode until we're sure we're happy with the whole thing.
Need to determine whether we are already in the op mode being requested. If so, no need to request it again - just request new sub mode if not already in it. If not, the currentSubMode checked below is not relevant (applies to current mode, not the requested mode) and we need to request new op mode and signal that new op mode that we will want to start in a specific sub mode.

Declarations should be at top of scope (right before memcpy).

Declarations should be at top of scope (right before memcpy).

Do we need this function? Can we do these 2 assignments in the Dialin msg handler function?

Do we need this function? Can we do these 2 assignments in the Dialin msg handler function?

I don't think this code should be here. Should be moved to a function and called - probably not from here though. Can we call function with this code from the Dialin msg handler?

I don't think this code should be here. Should be moved to a function and called - probably not from here though. Can we call function with this code from the Dialin msg handler?

LDT-3372: code review comments

fixed

fixed

fixed

fixed

fixed.

fixed.

LDT-3372: code review comments