dd-firmware / firmware / App / Modes / FPModes

FPModeStandby.h

Clone Tools

Stats

Commits this week: 1
Total Committers: 3
Last Commit: 12 Mar
Commits this week: 1

Lines of code count not available

Commit Activity

Commits By Day In Week
52 week commits volume
Commits By Day In Week
Commits by day
Commits By Day In Week
Commits by hour
Commits By Hour In Day
Commit calendar
 

Most active committers (90 days)

loading
loading
  • last updated a few seconds ago
All Commits Reviews
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Thursday 12 Mar
4:32 pm

Sean Nash

7:21 am

Raghu Kallala

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

6:37 am

Raghu Kallala

Updated

Updated

6:37 am

Raghu Kallala

Updated

Updated

6:36 am

Raghu Kallala

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

6:27 am

Raghu Kallala

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

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

Wednesday 11 Mar
2:37 pm

Sean Nash

if ( TRUE == result )

if ( TRUE == result )

2:34 pm

Sean Nash

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.

2:34 pm

Sean Nash

Remove comment.

Remove comment.

2:31 pm

Sean Nash

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

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

2:27 pm

Sean Nash

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.

2:25 pm

Sean Nash

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.

2:24 pm

Sean Nash

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.

2:22 pm

Sean Nash

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

2:22 pm

Sean Nash

currentMode is an input.

currentMode is an input.

2:21 pm

Sean Nash

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.

2:18 pm

Sean Nash

Are we not supporting sub mode requests for these modes?

Are we not supporting sub mode requests for these modes?

2:15 pm

Sean Nash

if ( TRUE == testChangeSubMode )

if ( TRUE == testChangeSubMode )

2:13 pm

Sean Nash

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.

Friday 06 Mar
2:48 pm

Sean Nash

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.

2:46 pm

Sean Nash

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.

2:42 pm

Sean Nash

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.

2:38 pm

Sean Nash

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

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

2:37 pm

Sean Nash

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?

2:34 pm

Sean Nash

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?

12:47 pm

Raghu Kallala

Shall I add the SW_Fault as an else case if an invalid submode was requested for an opmode? Sean NashMichael Garthwaite please confirm

Shall I add the SW_Fault as an else case if an invalid submode was requested for an opmode?
Sean NashMichael Garthwaite please confirm

12:37 pm

Raghu Kallala

I was thinking we could return BOOL to check if the request was successful, added it. But as you clarified the dialin response will only confirm the delivery of message successfully, I can change ...

I was thinking we could return BOOL to check if the request was successful, added it.

But as you clarified the dialin response will only confirm the delivery of message successfully, I can change all these signal functions to void
Thanks!

9:58 am

Michael Garthwaite

Yes since you're not using the return value in execOpModes()

Yes since you're not using the return value in execOpModes()

Thursday 05 Mar
7:32 am

Dara Navaei

LEAHI-DD-FIRMWARE-LDT-3603_Ability to set operation sub mode on IOFP sub system
LEAHI-DD-FIRMWARE-LDT-3603_Ability to set operation sub mode on IOFP sub system
Friday 09 Jan
10:07 am

Dara Navaei

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

Options
    • -1
    • +1
    ./FPModeStandby.h
  2. … 121 more files in changeset.