MsgDefs.h

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
LEAHI-TD-FIRMWARE-LDT-3126_Blood Prime - TD
LEAHI-TD-FIRMWARE-LDT-3126_Blood Prime - TD
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.

If we don't think we need this, let's just delete it. If we think it's coming back, let's keep it and just set the max count to something really high (e.g. 1,000,000).

If we don't think we need this, let's just delete it. If we think it's coming back, let's keep it and just set the max count to something really high (e.g. 1,000,000).

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