FPModes

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
LEAHI-DD-FIRMWARE-LDT-2004_Dialysate Composition - DD
LDT-3603 added condition to reset and start sub mode in signal function

LDT-3603 changed code to return false when pause state is requested.

LDT-3603 addressed review comments and added missing code

    • -51
    • +57
    ./ModePreGenPermeateDefeatured.c
That's a question for me, will that be required? Fault has sub modes(3), Standby has 1 sub mode(I am adding code for this as this might be required) Init don't have any and service is not defined yet

That's a question for me, will that be required?

Fault has sub modes(3), Standby has 1 sub mode(I am adding code for this as this might be required)
Init don't have any and service is not defined yet

Updated

Updated

Updated

Updated

Changed and left them as static, as we don't need these outside this unit

Changed and left them as static, as we don't need these outside this unit

You are right, (missed that while duplicating the functions)

You are right, (missed that while duplicating the functions)

if ( TRUE == result )

if ( TRUE == result )

Since both states require no special handling, remove breaks and group with default - all modes.

Since both states require no special handling, remove breaks and group with default - all modes.

Remove comment.

Remove comment.

Add comment that all of these states require no special handling.

Add comment that all of these states require no special handling.

I think these functions (validate and signal) should be "test" functions and moved down to Dialin test functions section below - for all modes.

I think these functions (validate and signal) should be "test" functions and moved down to Dialin test functions section below - for all modes.

Add comment that no action is required for these modes - defaulting to invalid request.

Add comment that no action is required for these modes - defaulting to invalid request.

I think this switch should be on requested mode - we haven't changed modes yet.

I think this switch should be on requested mode - we haven't changed modes yet.

We have 1 param (and probably should have 2 params - requested mode and submode).

We have 1 param (and probably should have 2 params - requested mode and submode).

currentMode is an input.

currentMode is an input.

I think this validate function needs to know the requested mode as well - should have 2 params.

I think this validate function needs to know the requested mode as well - should have 2 params.

Are we not supporting sub mode requests for these modes?

Are we not supporting sub mode requests for these modes?

if ( TRUE == testChangeSubMode )

if ( TRUE == testChangeSubMode )

I think these 2 functions are in support of Dialin only, so should be prefixed with "test" as well.

I think these 2 functions are in support of Dialin only, so should be prefixed with "test" as well.

LDT-3603 fixed typo in comments

LDT-3603 moved declaration to top of the scope

LDT-3603 added validate before making a request call in dialin test handler

  1. … 1 more file in changeset.
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).