Fix #1, Update to dev guide, add table, add CRC output

[avan989]

Describe the contribution
Updated to dev. guide, added sample table, added CRC output

Testing performed
Steps taken to test the contribution:

1. Build
2. Send Ground Command
3. Verify Results

EVS Port1 42/1/SAMPLE_APP 3: SAMPLE: NOOP command
EVS Port1 42/1/SAMPLE_APP 4: SAMPLE: RESET command
1980-012-14:03:25.00026 Sample App: Table Value 1: 1  Value 2: 2
1980-012-14:03:25.00161 Sample App: CRC = 0xFFFF9C00

output from tblCRCTool:

Table File Name:            ../../exe/cpu1/cf/sample_table.tbl
Table Size:                 4 Bytes
Expected TS Validation CRC: 0xFFFF9C00

Expected behavior changes
no impact to behavior

System(s) tested on:

• Hardware
• OS: Ubuntu 18.04.03
• Versions CFS 6.7

Contributor Info
Anh Van, NASA Goddard

Community contributors
You must attach a signed CLA (required for acceptance) or reference one already submitted

[avan989]

new updates, fixed dependency on ../src/tbl. Clean up code and tested.
Results are consistence with CRC tools:

EVS Port1 42/1/SAMPLE_APP 3: SAMPLE: NOOP command
EVS Port1 42/1/SAMPLE_APP 4: SAMPLE: RESET command
1980-012-14:04:49.00100 Sample App: Table Value 1: 1  Value 2: 2
1980-012-14:04:49.00102 Sample App: CRC: 0xFFFF9C00

[avan989]

Combine commit for review

[avan989]

Test result:

EVS Port1 42/1/SAMPLE_APP 3: SAMPLE: NOOP command  Version 1.1.0.0
EVS Port1 42/1/SAMPLE_APP 4: SAMPLE: RESET command
1980-012-14:03:28.50036 Sample App: Table Value 1: 1  Value 2: 2
1980-012-14:03:28.50037 Sample App: CRC: 0xFFFF9C00

[jphickey]

I think this is getting closer but still needs some modifications.

1. The message handlers in sample_app do not follow the same pattern as CFE does. These should be modified to be in the same pattern as CFE. For instance, use CFE_ES_TaskPipe() or CFE_EVS_ProcessGroundCommand() as a reference example for the current recommended pattern.

The main differences are:

• All identification, validation, and subsequent cast of the message pointer is done prior to invoking the message handler
• The message handler accepts a single pointer argument of the correct type, qualified as const.

For example, in CFE_ES_TaskPipe:

            CommandCode = CFE_SB_GetCmdCode(Msg);
            switch (CommandCode)
            {
                case CFE_ES_NOOP_CC:
                    if (CFE_ES_VerifyCmdLength(Msg, sizeof(CFE_ES_Noop_t)))
                    {
                        CFE_ES_NoopCmd((CFE_ES_Noop_t*)Msg);
                    }
                    break;

                case CFE_ES_RESET_COUNTERS_CC:
                    if (CFE_ES_VerifyCmdLength(Msg, sizeof(CFE_ES_ResetCounters_t)))
                    {
                        CFE_ES_ResetCountersCmd((CFE_ES_ResetCounters_t*)Msg);
                    }
                    break;

And so on for each command type....

Specifically: the "outer" message processor is performing identification and validation duty, and once validated, actually casts it to the correct real message type. The "inner" message handler then just processes the message, knowing that it is already fully validated. It should not need to do any additional introspection or typecasting.

Why this is a better pattern: In a future CFE version it is intended that a message data dictionary of some sort (be it EDS or something else) will provide message identification and validation services. Keeping this consolidated in one function means an easy transition to future CFE versions.

2. Why was the #ifndef protector changed from sample_app_... to sample_lab_... in a couple files?

3. The commit log needs to be improved before it can be merged.

[avan989]

1. updated to match cfe for command and housekeeping.
2. That was an leftover from an copy and paste. Fixed.
3. Can you clarify about the commit log. The only commit in my log is this current one.

[jphickey]

Looks good now, approve for merge.