diff --git a/docs/README_functionaltest.md b/docs/README_functionaltest.md index f861d3674..1498e0301 100644 --- a/docs/README_functionaltest.md +++ b/docs/README_functionaltest.md @@ -19,10 +19,6 @@ This must be the first library loaded for any functional test. - `cfe_testcase`: a CFE-compatible library implementing test cases for CFE core apps. This must be loaded after `cfe_assert`. -- `cfe_testrunner`: a CFE application that actually executes the tests. This is a very -simple app that waits for CFE startup to complete, then executes all registered test -cases. It also must be loaded after `cfe_assert`. - ## Example startup script entries diff --git a/docs/cFE Application Developers Guide.md b/docs/cFE Application Developers Guide.md index ebf9e6f0c..5d50e602b 100644 --- a/docs/cFE Application Developers Guide.md +++ b/docs/cFE Application Developers Guide.md @@ -16,7 +16,7 @@ Table of Contents * [3. cFE Deployment Environment](#3-cfe-deployment-environment) * [3.1 Assumed On-Board Directory Structure](#31-assumed-on-board-directory-structure) * [4. cFE Application Architecture](#4-cfe-application-architecture) - * [4.1 Application Model](#41application-model) + * [4.1 Application Models](#41-application-models) * [4.1.1 "Software Only" Application](#411-software-only-application) * [4.1.2 "Hardware Servicing" Application](#412-hardware-servicing-application) * [4.1.3 Multi-threaded Applications](#413-multi-threaded-applications) @@ -67,14 +67,14 @@ Table of Contents * [6.3 Software Bus Message Subscription](#63-software-bus-message-subscription) * [6.4 Unsubscribing from Receiving Software Bus Messages](#64-unsubscribing-from-receiving-software-bus-messages) * [6.5 Creating Software Bus Messages](#65-creating-software-bus-messages) - * [6.5.1 Software Bus Message Header Types](#651-software-bus-message-header-types) - * [6.5.2 Modifying Software Bus Message Header Information](#652-modifying-software-bus-message-header-information) - * [6.5.2.1 Modifying SB Command Message Header Information](#6521-modifying-sb-command-message-header-information) - * [6.5.2.2 Modifying SB Telemetry Message Header Information](#6522-modifying-sb-telemetry-message-header-information) - * [6.5.3 Reading Software Bus Message Header Information](#653-reading-software-bus-message-header-information) + * [6.5.1 Software Bus Message Header Types](#651-message-header-types) + * [6.5.2 Modifying Software Bus Message Header Information](#652-setting-message-header-information) + * [6.5.2.1 Modifying SB Command Message Header Information](#6521-modifying-command-message-header-information) + * [6.5.2.2 Modifying SB Telemetry Message Header Information](#6522-modifying-telemetry-message-header-information) + * [6.5.3 Reading Software Bus Message Header Information](#653-reading-message-header-information) * [6.6 Sending Software Bus Messages](#66-sending-software-bus-messages) * [6.7 Receiving Software Bus Messages](#67-receiving-software-bus-messages) - * [6.8 Improving Message Transfer Performance for Large SB Messages](#68-improving-message-transfer-performance-for-large-sb-messages) + * [6.8 Improving Message Transfer Performance for Large SB Messages](#68-improving-message-transfer-performance-for-large-messages) * [6.9 Best Practices for using Software Bus](#69-best-practices-for-using-software-bus) * [7. Event Service Interface](#7-event-service-interface) * [7.1 Event Messages](#71-event-messages) @@ -84,8 +84,7 @@ Table of Contents * [7.4.1 Binary Filtering Scheme](#741-binary-filtering-scheme) * [7.5 Sending an Event Message](#75-sending-an-event-message) * [7.5.1 Event Message Text](#751-event-message-text) - * [7.6 Event Service Un-registration](#76-event-service-un-registration) - * [7.7 Best Practices for using Event Services](#77-best-practices-for-using-event-services) + * [7.6 Best Practices for using Event Services](#76-best-practices-for-using-event-services) * [8. Table Service Interface](#8-table-service-interface) * [8.1 Table Terminology](#81-table-terminology) * [8.1.1 Tables](#811-tables) @@ -161,7 +160,7 @@ available to the application as a library of functions. The cFE also provides a File Service (FS) API that is available to applications (there is no task associated with File Service). -It is important for application developers to realize the long term goal +It is important for application developers to realize the long-term goal of the cFE. With a standard set of services providing a standard API, all applications developed with the cFE have an opportunity to become useful on future missions through code reuse. In order to achieve this @@ -250,7 +249,7 @@ Other documentation can be found in the associated repository's docs directory. | Command | A SB Message defined by the receiving Application. Commands can originate from other onboard Applications or from the ground. | | Core Flight Executive (cFE) | A runtime environment and a set of services for hosting FSW Applications. | | Critical Data Store | A collection of data that is not modified by the OS or cFE following a Processor Reset. | - | Cyclic Redundancy Check | A polynomial based method for checking that a data set has remained unchanged from one time period to another. | + | Cyclic Redundancy Check | A polynomial-based method for checking that a data set has remained unchanged from one time period to another. | | Developer | Anyone who is coding a cFE Application. | | Event Data | Data describing an Event that is supplied to the cFE Event Service. The cFE includes this data in an Event Message. | | Event Filter | A numeric value (bit mask) used to determine how frequently to output an application Event Message defined by its Event ID (see definition of Event ID below). | @@ -312,14 +311,14 @@ directory is described as a note under each folder. |-- osal | |-- Contains a copy of the OSAL component |-- psp - | |-- Contains the Platform Suport Package (PSP) library + | |-- Contains the Platform Support Package (PSP) library | |-- Can customize PSP implementation for each CPU and OS that the project needs |-- build | |-- The flight software is all configured and built under this directory | |-- All mission and platform configuration files are placed here |-- apps | |-- Contains application source code. - | |-- Application source code may be shared amoung multiple build CPUs + | |-- Application source code may be shared among multiple build CPUs |-- libs | |-- Contains Core Flight System (cFS) Sample Library (sample_lib) |-- tools @@ -337,7 +336,6 @@ Module descriptions are provided in the table below. |-- modules | |-- cfe_assert | |-- cfe_testcase - | |-- cfe_testrunner | |-- core_api | |-- core_private | |-- es @@ -425,7 +423,6 @@ complete cFE core executive. These modules are all contained under the `modules |:------------------------|:------------------------------------------------------------------------------------------------------------------ | | `modules/cfe_assert/` | A CFE-compatible library wrapping the basic UT assert library. This is the same library that all other unit tests use, but configured to be dynamically loaded into the CFE environment, and using CFE syslog for its output. This must be the first library loaded for any functional test. | | `modules/cfe_testcase/` | A CFE-compatible library implementing test cases for CFE core apps. This must be loaded after cfe_assert. | -| `modules/cfe_testrunner/` | A CFE application that actually executes the tests. This is a very simple app that waits for CFE startup to complete, then executes all registered test cases. It also must be loaded after cfe_assert. | | `modules/core_api/` | Contains the public interface definition of the complete CFE core - public API/headers only, no implementation | | `modules/core_private/` | Contains the inter-module interface definition of the CFE core - internal API/headers only, no implementation | | `modules/es/` | Implementation of the Executive Services (ES) core module - provides app and task management | @@ -526,13 +523,13 @@ volume table. # 4. cFE Application Architecture -In order to achieve the long term goals of the cFE, the Developer should +In order to achieve the long-term goals of the cFE, the Developer should structure their Applications with one of the following frameworks. Each of the frameworks described below has been designed to minimize code modification when the code is ported to either another platform and/or another mission. -## 4.1 Application Models +## 4.1 Application Models ### 4.1.1 "Software Only" Application @@ -543,7 +540,7 @@ which are either telemetry or commands. Examples of existing "Software Only" Applications include the Stored Command (SC) and Scheduler (SCH) applications. A "Software Only" Application has the most promise of being reusable -because it is insulated from most mission and platform specific +because it is insulated from most mission and platform-specific characteristics. A "Software Only" application should never interface directly with any piece of @@ -554,7 +551,7 @@ the cFE APIs or to the OS Abstraction Layer. ### 4.1.2 "Hardware Servicing" Application A "Hardware Servicing" Application is a cFE Application that communicates -directly with a piece of hardware. This could be mission specific +directly with a piece of hardware. This could be mission-specific hardware, such as an experiment, or more common hardware, such as a receiver or transmitter. "Hardware Servicing" Applications should follow the Device Driver model as shown in the following diagram. @@ -623,7 +620,7 @@ of file names across all flight software packages once imported into a combined files should also be overridable at the mission level; that is, a component only provides a default file (with a `default_` prefix, for distinction) that can be "cloned and owned" by placing a copy, without the `default_` prefix, into the `_defs` directory for the CFE/CFS mission build. Any customized file(s) in the `_defs` directory will be seen by the CMake build system and used -instead of the default version of the file that is provided from the orignal source tree. +instead of the default version of the file that is provided from the original source tree. | **File Name Pattern** | **Scope** | **Content** | |:---------------------------|:---------:|:----------------------------------------------------------------------------------------------------| @@ -649,10 +646,10 @@ inclusion of the `_msgdefs.h` file alone provides the command codes as well as a However, the `_fcncodes.h` header should be strictly limited to defining command/function codes for the command interface and should not contain any other information. -**IMPORANT**: All of the header files above with "INTERFACE" scope control the table/message interface of the component. Changing any of the +**IMPORTANT**: All of the header files above with "INTERFACE" scope control the table/message interface of the component. Changing any of the values or definitions in these files will affect the inter-processor communication - either table files, exported data products, commands, or -telementry messages. Due caution should be exercised when customizing any of these files, as any changes will need to be propagated to all -other CFE instances, ground systems, test software or scripts, or any other tools that interact with the flight softare. +telemetry messages. Due caution should be exercised when customizing any of these files, as any changes will need to be propagated to all +other CFE instances, ground systems, test software or scripts, or any other tools that interact with the flight software. Also note that Electronic Data Sheets (EDS) definitions will supercede the "INTERFACE" header files listed above. These headers are not used by the software when building FSW based on EDS. Instead, the EDS tool will generate these headers based on the content of the EDS file(s) @@ -661,7 +658,7 @@ and the software will be configured to use the generated headers during the buil __Combination Headers__ The header files in this section combine two or more files from the above set for simplicity of usage in source code, as well as backward -compatiblity with traditional file names from older versions of CFS apps. Although these files may also be overridden directly, it is +compatibility with traditional file names from older versions of CFS apps. Although these files may also be overridden directly, it is recommended to only override/modify the more granular headers defined above. | **File Name Pattern** | **Content** | @@ -671,7 +668,7 @@ recommended to only override/modify the more granular headers defined above. | _module_`_msg.h` | Complete message interface: Combination of `msgdefs.h`, `msgstruct.h` and all dependencies | | _module_`_tbl.h` | Complete table interface: Combination of `tbldefs.h`, `tblstruct.h` and all dependencies | -**IMPORANT**: Files from a limited scope may depend on files from a broader scope, but not the other way around. For example, +**IMPORTANT**: Files from a limited scope may depend on files from a broader scope, but not the other way around. For example, the `platform_cfg.h` may depend on items defined in `mission_cfg.h`, but items in `mission_cfg.h` must **not** depend on items defined in `platform_cfg.h`. @@ -779,14 +776,14 @@ function to invoke as was necessary in older versions of cFE. The Executive Services maps Application names to numeric Application IDs. This simplifies the identification of Applications within the processor -(by the numeric) but retains the human readable Application names for +(by the numeric) but retains the human-readable Application names for situations when the information is to be presented to an operator. Translating one reference of an Application to the other is accomplished -with one of the following functions: CFE_ES_GetAppIDByName and -CFE_ES_GetAppName. The first will return the numeric Application ID when +with one of the following functions: `CFE_ES_GetAppIDByName` and +`CFE_ES_GetAppName`. The first will return the numeric Application ID when given an Application name and the latter will give the Application name when given the Application ID. If a Task needs to obtain its own Application -ID if can call CFE_ES_GetAppID. For this function, it is important to remember +ID if can call `CFE_ES_GetAppID`. For this function, it is important to remember that an Application's main task and all of its children tasks are considered to be the same Application. Therefore, no matter whether the call is made from the Main Task or one of the Child Tasks, the Application ID returned is @@ -800,14 +797,14 @@ the Application is loaded and run is referred to as the Main Task. Any additional threads that are spawned by this thread are referred to as Child Tasks. There are a handful of functions provided by the Executive Services for controlling Child Tasks. The first is -CFE_ES_CreateChildTask. This function spawns a Child Task that is +`CFE_ES_CreateChildTask`. This function spawns a Child Task that is "owned" by the Main Task. This child task is automatically registered with ES before invoking the entry point. -The remaining functions, CFE_ES_DeleteChildTask, CFE_ES_SuspendChildTask -and CFE_ES_ResumeChildTask can control the existence and execution of the +The remaining functions, `CFE_ES_DeleteChildTask`, `CFE_ES_SuspendChildTask` +and `CFE_ES_ResumeChildTask` can control the existence and execution of the Child Task. All of these functions require the task ID that is returned -by the CFE_ES_CreateChildTask function in order to identify the Child +by the `CFE_ES_CreateChildTask` function in order to identify the Child Task. Note that Child Tasks can only be created from an Application's Main Task. @@ -815,12 +812,12 @@ Main Task. Upon startup, an Application may need to know which type of restart it is undergoing. As part of its initialization, an Application should call -CFE_ES_GetResetType to determine the type of restart it is undergoing. The +`CFE_ES_GetResetType` to determine the type of restart it is undergoing. The return value of this function can be one of the following values: -1) CFE_PSP_RST_TYPE_POWERON +1) `CFE_PSP_RST_TYPE_POWERON` -2) CFE_PSP_RST_TYPE_PROCESSOR +2) `CFE_PSP_RST_TYPE_PROCESSOR` Reference cFE API documentation for more detail on reset types. @@ -838,11 +835,11 @@ information. A number of these functions are not necessary for the cFE Application Developer. The functions that are the most useful to the Application Developer are the following: -- CFE_PSP_GetSpacecraftId returns an identifier associated with a specific +- `CFE_PSP_GetSpacecraftId` returns an identifier associated with a specific spacecraft. This may be useful when the same software may be executing on multiple spacecraft as part of a multi-spacecraft mission. -- CFE_PSP_GetProcessorId returns an identifier associated with a specific +- `CFE_PSP_GetProcessorId` returns an identifier associated with a specific processor. This may be useful when the same software may be executing on multiple processors on the same spacecraft. @@ -850,7 +847,7 @@ For understanding and compensating for the processor timer on a particular platform, the following function provides important information. -- OS_InfoGetTicks returns the number of microseconds per operating system +- `OS_InfoGetTicks` returns the number of microseconds per operating system clock tick. This can also be used to calculate the appropriate number of system clock ticks for a specific delta time. An example can be seen below: @@ -872,8 +869,8 @@ uint32 ConvertSecs2Ticks(uint32 Seconds) ### 5.7.1 Queues -Developers are discouraged from using the OS_QueueCreate, OS_QueueGet, -OS_QueuePut, and OS_QueueDelete functions. These functions are a lower level +Developers are discouraged from using the `OS_QueueCreate`, `OS_QueueGet`, +`OS_QueuePut`, and `OS_QueueDelete` functions. These functions are a lower level duplication of the Software Bus Services pipes. Their usage limits the visibility into data messages being passed between Applications and they would also impose a requirement that two Applications must reside on the @@ -884,7 +881,7 @@ between a Main Task and its Child Task(s). Binary semaphores can be used for Application synchronization. A binary semaphore is essentially a flag that is available or unavailable. When -an Application *takes* a binary semaphore, using the OS_BinSemTake +an Application *takes* a binary semaphore, using the `OS_BinSemTake` function, the outcome depends on whether the semaphore is available or unavailable at the time of the call. If the semaphore is available, then the semaphore becomes unavailable and the Application continues @@ -892,7 +889,7 @@ executing immediately. If the semaphore is unavailable, the Application is put on a queue of blocked Applications and enters a pending state waiting for the availability of the semaphore. -When an Application *gives* a binary semaphore, using the OS_BinSemGive +When an Application *gives* a binary semaphore, using the `OS_BinSemGive` function, the outcome depends on whether the semaphore is available or unavailable at the time of the call. If the semaphore is already available, giving the semaphore has no effect at all. If the semaphore @@ -903,14 +900,14 @@ Application in the queue of pending Applications is unblocked, and the semaphore is left unavailable. Each semaphore is labeled by an integer ID, which is defined in the -header file osids.h by a macro of the form xxx_SEM_ID. To add a new +header file osids.h by a macro of the form `xxx_SEM_ID`. To add a new semaphore to a processor, one must modify the osids.h file and osobjtab.c file for the processor. ### 5.7.2.1 Binary Semaphore Functions -A binary semaphore can be created using the OS_BinSemCreate function. Upon -success, the OS_BinSemCreate function sets the sem_id parameter to the ID of +A binary semaphore can be created using the `OS_BinSemCreate` function. Upon +success, the `OS_BinSemCreate` function sets the sem_id parameter to the ID of the newly-created resource. This ID is used in all other functions that use the binary semaphore. @@ -956,8 +953,8 @@ implement a kind of handshake between its main task and its child task. ### 5.7.3.1 Counting Semaphore Functions -A counting semaphore can be created using the OS_CountSemCreate function. -Upon success, the OS_CountSemCreate function sets the sem_id parameter to the +A counting semaphore can be created using the `OS_CountSemCreate` function. +Upon success, the `OS_CountSemCreate` function sets the sem_id parameter to the ID of the newly-created resource. This ID is used in all other functions that use the binary semaphore. @@ -999,9 +996,9 @@ A mutex semaphore is similar to a binary semaphore, but is used by Applications in a different way. When any Application needs to use a shared resource, it must follow a specific protocol: -- Take the mutex, using OS_MutSemTake. +- Take the mutex, using `OS_MutSemTake`. - Use the resource. -- Release the mutex, using OS_MutSemGive. +- Release the mutex, using `OS_MutSemGive`. The operating system allows only one Application to hold the mutex at one time. If an Application tries to take a mutex that is not in use, @@ -1145,7 +1142,7 @@ manage a block of memory provided to it by the application; mempool does not create the block itself. Because of this, the application must ensure that sufficient memory is provided to store the mempool management structures in addition to the memory needed by the -application. After initialization, mempool allocates fixed size blocks +application. After initialization, mempool allocates fixed-size blocks as requested from the application memory block. As each block is requested mempool creates a block descriptor with management structures as well as space for the user application data (see Figure @@ -1177,25 +1174,25 @@ type. Figure 5.1 Block Descriptor For example, if the application requests 60 bytes, mempool will return a pointer -to the 64 user accessible bytes with the 12 byte descriptor "hidden" on +to the 64 user-accessible bytes with the 12-byte descriptor "hidden" on the front for a total memory allocation of 72 bytes. All of this memory is allocated from the application pool. Once this memory is allocated it can only be used again for application requests of 64 bytes or less. It cannot be combined with other blocks to create larger memory allocations. -With the call to CFE_ES_PoolCreate, mempool takes the memory block -allocated by the application and creates one 168 byte management data +With the call to `CFE_ES_PoolCreate`, mempool takes the memory block +allocated by the application and creates one 168-byte management data structure as shown in Figure 5.2 starting at the address of the provided block. This memory is not available to user applications. As an initialization check, mempool requires that the provided application -block contain enough space for one 168 byte management structure plus -one 12 byte descriptor plus the smallest fixed size block (8 bytes). +block contain enough space for one 168-byte management structure plus +one 12-byte descriptor plus the smallest fixed-size block (8 bytes). This constraint allows mempool to create at least one user application block. Once this structure is created the application can use the -CFE_ES_GetPoolBuf and CFE_ES_PutPoolBuf calls to allocate and +`CFE_ES_GetPoolBuf` and `CFE_ES_PutPoolBuf` calls to allocate and de-allocate the memory blocks. For additional design and user information related to the memory pool, @@ -1228,14 +1225,14 @@ during a reset. It could be memory located off-board, for example in the bulk memory device, or it may just be an area of memory that is left untouched by the cFE. In order to use the CDS, the Application must request a block of memory large enough to hold the parameters in -question. This is accomplished by calling the CFE_ES_RegisterCDS. If +question. This is accomplished by calling the `CFE_ES_RegisterCDS`. If sufficient memory is present, then the cFE will allocate the block to the calling Application and provide a pointer to the handle associated with the allocated memory. The intention is for an Application to use a working copy of the CDS data during Application execution. Periodically, the Application is then -responsible for calling CFE_ES_CopyToCDS API to copy the working image +responsible for calling `CFE_ES_CopyToCDS` API to copy the working image back into the CDS The cFE then computes a data integrity value for the block of data and stores it in the allocated CDS block. It should be noted that although the cFE will validate the integrity of the contents @@ -1360,7 +1357,7 @@ void SAMPLE_TaskMain(void) } ``` -### 5.10.4 Standard CRC Calculations +### 5.10.4 Standard CRC Calculations There are many Applications that require a validation of received data or of data in memory. This is usually done by a Cyclic Redundancy Check (CRC). There are many different ways to calculate a CRC. To help ensure that the @@ -1372,10 +1369,10 @@ This function looks like the following: uint32 CFE_ES_CalculateCRC(const void *DataPtr, size_t DataLength, uint32 InputCRC, CFE_ES_CrcType_Enum_t TypeCRC); ``` -where DataPtr points to the first byte of an array of bytes that are to have -the CRC calculated on, DataLength specifies the number of sequential bytes to -include in the calculation, InputCRC is the initial value of the CRC and -TypeCRC identifies which of the standard CRC polynomials to be used. Currently, +where `DataPtr` points to the first byte of an array of bytes that are to have +the CRC calculated on, `DataLength` specifies the number of sequential bytes to +include in the calculation, `InputCRC` is the initial value of the CRC and +`TypeCRC` identifies which of the standard CRC polynomials to be used. Currently, there are the following types available: ``` @@ -1387,9 +1384,9 @@ CFE_MISSION_ES_DEFAULT_CRC – the mission specified default CRC calculation (cu ``` Unless there is a specific interface with a specified CRC calculation, applications -must use the CFE_MISSION_ES_DEFAULT_CRC type. +must use the `CFE_MISSION_ES_DEFAULT_CRC` type. -Currently only CFE_ES_CrcType_CRC_16 is supported. CFE_ES_CrcType_CRC_8 and CFE_ES_CrcType_CRC_32 are yet +Currently only `CFE_ES_CrcType_CRC_16` is supported. `CFE_ES_CrcType_CRC_8` and `CFE_ES_CrcType_CRC_32` are yet to be implemented. ## 5.11 File System Functions @@ -1442,9 +1439,9 @@ mechanism of recording Events that cannot be issued as Event Messages because the Event Service is either not running or is untrustworthy. An example of items that fall into this category are Events related to the boot process. Developers should make use of the Event Services -CFE_EVS_SendEvent whenever possible. If, however, there is a -significant Event that cannot be recorded using the CFE_EVS_SendEvent -function, then the Developer can use the CFE_ES_WriteToSysLog +`CFE_EVS_SendEvent` whenever possible. If, however, there is a +significant Event that cannot be recorded using the `CFE_EVS_SendEvent` +function, then the Developer can use the `CFE_ES_WriteToSysLog` function. This function has the following prototype: ```c @@ -1454,22 +1451,22 @@ int32 CFE_ES_WriteToSysLog(const char *pSpecString, ...); The function acts just like a standard 'C' printf function and records the ASCII string to a buffer that is preserved during resets. -At minimum, the CFE_ES_WriteToSysLog function is generally used if the call -to CFE_EVS_Register fails or if the Application is about to exit. +At minimum, the `CFE_ES_WriteToSysLog` function is generally used if the call +to `CFE_EVS_Register` fails or if the Application is about to exit. ## 5.13 Software Performance Analysis cFE provides utilities to track the performance of an application. Two functions are provided to configure regions for performance tracking: -- CFE_ES_PerfLogEntry -- CFE_ES_PerfLogExit +- `CFE_ES_PerfLogEntry` +- `CFE_ES_PerfLogExit` These functions are typically used to track the performance of an application's main execution loop. Applications can track performance of multiple sections of code, but must define a unique "performance id" (or "perfid") for each segment of code to monitor. Applications typically define these perfids in -their xx_mission_cfg.h file. A common pattern for performance monitoring is +their `xx_mission_cfg.h` file. A common pattern for performance monitoring is shown below. ```c @@ -1485,7 +1482,7 @@ void XX_AppMain(void) CFE_ES_PerfLogEntry(XX_APPMAIN_PERF_ID); /* - ** Perform application specific initialization... + ** Perform application-specific initialization... */ if (Result == CFE_SUCCESS) { @@ -1549,7 +1546,7 @@ on which to receive SB Messages. The SB's message-based subscription supports one-to-one, one-to-many, and many-to-one routing configurations. The upper limit of "many-to-one" and -"one-to-many" configurations is dictated by the CFE_PLATFORM_SB_MAX_DEST_PER_PKT +"one-to-many" configurations is dictated by the `CFE_PLATFORM_SB_MAX_DEST_PER_PKT` configuration parameter. Multiple SB Message types can be routed to a single pipe. This is commonly done for applications that need to process ground commands. @@ -1646,14 +1643,14 @@ target pipe(s). Applications call the SB API to request specified SB Message IDs to be routed to their previously created pipes. Note there are two routing implementations provide by the -Software Bus Routing (SBR) module. If the MISSION_MSGMAP_IMPLEMENTATION -is unset (the default) or set to DIRECT, a message map of size -CFE_PLATFORM_SB_HIGHEST_VALID_MSGID is used to relate Message ID to routes. -If set to HASH, a message map of size (4 * CFE_PLATFORM_SB_MAX_MSG_IDS) +Software Bus Routing (SBR) module. If the `MISSION_MSGMAP_IMPLEMENTATION` +is unset (the default) or set to `DIRECT`, a message map of size +`CFE_PLATFORM_SB_HIGHEST_VALID_MSGID` is used to relate Message ID to routes. +If set to `HASH`, a message map of size (4 * `CFE_PLATFORM_SB_MAX_MSG_IDS`) is used and a hash is performed on Message IDs to relate to routes. Note the impact on memory footprint can be significant, since -CFE_PLATFORM_SB_HIGHEST_VALID_MSGID is the maximum number of possible -Message IDs, whereas CFE_PLATFORM_SB_MAX_MSG_IDS is the maximum number of +`CFE_PLATFORM_SB_HIGHEST_VALID_MSGID` is the maximum number of possible +Message IDs, whereas `CFE_PLATFORM_SB_MAX_MSG_IDS` is the maximum number of routes supported (**used** Message IDs). Hash collisions are reported during subscription and can be avoided by predetermining Message IDs that won't collide. Note advanced users can replace SBR with a custom @@ -1685,7 +1682,7 @@ from the pipe, at which point the old SB Message is discarded. During the initialization of an Application, the Application must notify the cFE of pipes that it requires to receive data. The Application -performs this request by calling the CFE_SB_CreatePipe API. The +performs this request by calling the `CFE_SB_CreatePipe` API. The following is a brief example of how this is accomplished: ```c @@ -1724,7 +1721,7 @@ SAMPLE_AppData_t; SAMPLE_AppData; In this example, the Developer has created a Pipe, called `SAMPLE_PIPE_1` with a depth of 10. The Pipe name shall be at least one character and no -more than OS_MAX_API_NAME characters long. Developers should prefix their Pipe +more than `OS_MAX_API_NAME` characters long. Developers should prefix their Pipe names with the Application's abbreviated name, because Pipe names will collide with other Application Pipe names in the cFE. Also the Developer/Operator could become confused if every Application named @@ -1827,7 +1824,7 @@ The third parameter specifies the desired Quality of Service (QoS). The Quality of Service determines the priority and the reliability of the specified SB Message that this particular Application requires. Most Applications will be satisfied with the default QoS, as defined with the -CFE_SB_DEFAULT_QOS macro. Some Applications, such as an attitude +`CFE_SB_DEFAULT_QOS` macro. Some Applications, such as an attitude control Application, may require a higher QoS to ensure receipt of critical sensor data. **The current version of the cFE does NOT implement the QoS feature.** @@ -1842,10 +1839,10 @@ Application to another mission where SB Message IDs may need to be renumbered. Most Applications do not care about QoS nor the Message Limit hence -those Applications can use the CFE_SB_Subscribe function. For those +those Applications can use the `CFE_SB_Subscribe` function. For those Applications that need to specify something other than the default QoS or Messages Limit, the SB API provides an additional function, -CFE_SB_SubscribeEx that allows those parameters to be specified. +`CFE_SB_SubscribeEx` that allows those parameters to be specified. ## 6.4 Unsubscribing from Receiving Software Bus Messages @@ -1934,12 +1931,12 @@ SAMPLE_AppData_t SAMPLE_AppData; /* Instantiate Task Data */ ``` In this example, the Developer has allocated space for the SB Message -header in their structure using the CFE_MSG_TelemetryHeader_t type. If +header in their structure using the `CFE_MSG_TelemetryHeader_t` type. If the SB Message was to be a command message, it would have been important -for the Developer to have used the CFE_MSG_CommandHeader_t macro +for the Developer to have used the `CFE_MSG_CommandHeader_t` macro instead. -The CFE_MSG_Init API call formats the Message Header +The `CFE_MSG_Init` API call formats the Message Header appropriately with the given Message ID, size and clears the rest of the message. Note this call is implementation dependent, in that bits in the Message ID may have additional meaning and may impact @@ -1957,7 +1954,7 @@ headers. In the CCSDS implementation, the command and telemetry headers share the same CCSDS primary header structure but have different secondary header structures. The secondary header structures are shown below. Note that all messages must have a secondary header, a message -containing just a CFE_MSG_Message_t is invalid per the CCSDS standard. +containing just a `CFE_MSG_Message_t` is invalid per the CCSDS standard. ```c typedef struct @@ -1975,12 +1972,12 @@ typedef struct */ typedef struct { - uint8 Time[6]; /**< \brief Time, big endian: 4 byte seconds, 2 byte subseconds */ + uint8 Time[6]; /**< \brief Time, big endian: 4-byte seconds, 2-byte subseconds */ } CFE_MSG_TelemetrySecondaryHeader_t; ``` The sizes of command and telemetry message headers can be calculated using -sizeof(CFE_MSG_CommandHeader_t) and sizeof(CFE_MSG_TelemetryHeader_t) respectively. +sizeof(`CFE_MSG_CommandHeader_t`) and sizeof(`CFE_MSG_TelemetryHeader_t`) respectively. It is important to note that some API calls require the presence of a particular header type and will return an error if the other header type @@ -2009,15 +2006,15 @@ Message Header. The structure of the Message Header may change from one deployment to the next. By using these functions, Applications are guaranteed to work regardless of the structure of the Message Header. -Although CFE_SB_SetUserDataLength APIs is available, +Although `CFE_SB_SetUserDataLength` APIs is available, it is based on assumptions about the definition of "User Data" and is really just a best guess since the packet structure is dependent on implementation. -The preference is to use CFE_MSG_SetSize and actual packet structure +The preference is to use `CFE_MSG_SetSize` and actual packet structure information when available. ### 6.5.2.1 Modifying Command Message Header Information The most common update for command messages is to set the command code. -This is done through the CFE_MSG_SetFcnCode() API call. This code is used +This is done through the `CFE_MSG_SetFcnCode()` API call. This code is used to distinguish between multiple commands that share a Message ID. It is common practice for an application to have a single "CMD_MID" to capture all commands and then to differentiate those commands using a command code. @@ -2025,10 +2022,10 @@ all commands and then to differentiate those commands using a command code. ### 6.5.2.2 Modifying Telemetry Message Header Information The most common update for telemetry messages is to put the current time in the Message. This is accomplished with one of two API functions. The -most commonly used function would be CFE_SB_TimeStampMsg(). This API would -insert the current time, in the mission defined format with the mission +most commonly used function would be `CFE_SB_TimeStampMsg()`. This API would +insert the current time, in the mission-defined format with the mission defined epoch, into the Message Header. The other API that can modify -the Message Header time is CFE_MSG_SetMsgTime(). This API call sets the +the Message Header time is `CFE_MSG_SetMsgTime()`. This API call sets the time in the Message Header to the time specified during the call. This is useful when the Application wishes to time tag a series of Messages with the same time. @@ -2044,7 +2041,7 @@ for extracting that field from the header: | **Message Header Field** | **API for Reading the Header Field** | |:----------------------------|:-------------------------------------| | Message ID | CFE_MSG_GetMsgId | -| Message Time | CFE_MSG_GetTime | +| Message Time | CFE_MSG_GetMsgTime | | Total Message Length | CFE_MSG_GetSize | | Command Code | CFE_MSG_GetFcnCode | @@ -2053,10 +2050,10 @@ available in the user's guide. There is another API that automatically calculates the checksum for the packet and compares it to the checksum in the header. The API is called -CFE_MSG_ValidateChecksum() and it simply returns a success or failure +`CFE_MSG_ValidateChecksum()` and it simply returns a success or failure indication. -Although CFE_SB_GetUserDataLength and CFE_SB_GetUserData APIs are available, +Although `CFE_SB_GetUserDataLength` and `CFE_SB_GetUserData` APIs are available, they are based on assumptions about the definition of "User Data" and are really just a best guess since the packet structure is dependent on implementation. The preference is to use the actual packet structure when available. @@ -2092,7 +2089,7 @@ SAMPLE_AppData_t SAMPLE_AppData; /* Instantiate Task Data */ ## 6.7 Receiving Software Bus Messages -To receive a Message, an application calls CFE_SB_ReceiveBuffer. Since most +To receive a Message, an application calls `CFE_SB_ReceiveBuffer`. Since most applications are message-driven, this typically occurs in an application's main execution loop. An example of this is shown below. @@ -2134,18 +2131,18 @@ FILE: sample_app.c ``` In the above example, the Application will pend on the -SAMPLE_AppData.CmdPipe until a Message arrives. A pointer to the next SB -message in the Pipe will be returned in SBBufPtr. +`SAMPLE_AppData.CmdPipe` until a Message arrives. A pointer to the next SB +message in the Pipe will be returned in `SBBufPtr`. Alternatively, the Application could have chosen to pend with a timeout (by -providing a numerical argument in place of CFE_SB_PEND_FOREVER) or to quickly -poll the pipe to check for a message (by using CFE_SB_POLL in place of -CFE_SB_PEND_FOREVER). +providing a numerical argument in place of `CFE_SB_PEND_FOREVER`) or to quickly +poll the pipe to check for a message (by using `CFE_SB_POLL` in place of +`CFE_SB_PEND_FOREVER`). If a Message fails to arrive within the specified timeout period, the -cFE will return the CFE_SB_TIME_OUT status code. If the Pipe does not have -any data present when the CFE_SB_ReceiveBuffer API is called, the cFE will return -a CFE_SB_NO_MESSAGE status code. +cFE will return the `CFE_SB_TIME_OUT` status code. If the Pipe does not have +any data present when the `CFE_SB_ReceiveBuffer` API is called, the cFE will return +a `CFE_SB_NO_MESSAGE` status code. After a message is received, the Message Header accessor functions (as described in Section 6.5.3) should be used to identify the message so that @@ -2157,7 +2154,7 @@ the application can react to it appropriately. Occasionally, there is a need for large quantities of data to be passed between Applications that are on the same processor (e.g.- Science data analysis and/or compression algorithms along with the science data -acquisition Application). The drawback to using CFE_SB_TransmitMsg +acquisition Application). The drawback to using `CFE_SB_TransmitMsg` is that the message is copied into a SB Buffer. If the copy is too time consuming, the Developer can choose to utilize the "Zero Copy" protocol. @@ -2167,11 +2164,11 @@ The application can request a buffer from SB utilizing buffer that can be sent directly (without a copy) by SB. Once an Application has formatted and filled the SB buffer with the -appropriate data, transmit the buffer using CFE_SB_TransmitBuffer. +appropriate data, transmit the buffer using `CFE_SB_TransmitBuffer`. The SB then identifies the Application(s) that have subscribed to this data and places a pointer to the SB Buffer in their Pipe(s). **The pointer to the SB Buffer is no longer valid once the Application -calls the CFE_SB_TransmitBuffer API.** Applications should not +calls the `CFE_SB_TransmitBuffer` API.** Applications should not assume the SB Buffer pointer is accessible once the buffer has been sent. @@ -2290,23 +2287,23 @@ configured to downlink event messages if they need to be sent as telemetry. Event Messages are classified within the cFE and on the ground by an Event Type. Event Types defined within the cFE are: -- CFE_EVS_DEBUG -- Events of this type are primarily for the +- `CFE_EVS_DEBUG` -- Events of this type are primarily for the Developer. The messages contain specific references to code and are of limited use to spacecraft operations personnel. By default, these types of event messages are disabled. -- CFE_EVS_INFORMATION -- Events of this type are normal events that +- `CFE_EVS_INFORMATION` -- Events of this type are normal events that confirm expected behavior of the flight software. Examples would be notification of the processing of a received command, nominal mode changes, entering/exiting orbit day/night, etc. -- CFE_EVS_ERROR -- Events of this type are notifications of abnormal +- `CFE_EVS_ERROR` -- Events of this type are notifications of abnormal behavior. However, they represent error conditions that have been identified and corrected for by the flight software. These typically represent things like erroneous commands, illegal mode change attempts, switching to redundant hardware, etc. -- CFE_EVS_CRITICAL -- Events of this type are notifications of error +- `CFE_EVS_CRITICAL` -- Events of this type are notifications of error conditions that the flight software is unable to correct or compensate for. These might be uncorrectable memory errors, hardware failures etc. @@ -2334,7 +2331,7 @@ should consider these filter options when categorizing their events. ## 7.3 Event Format Event services provides two formats for event messages: long and short. The -format is selected with the CFE_PLATFORM_EVS_DEFAULT_MSG_FORMAT_MODE +format is selected with the `CFE_PLATFORM_EVS_DEFAULT_MSG_FORMAT_MODE` configuration parameter. The only difference between the formats is that the short format does not include the text string portion of the message. Because of this, it is very important that Event Messages IDs be unique @@ -2351,13 +2348,13 @@ libraries however are not able to register for EVS or send Event Messages. Event services include the sending and filtering of event -messages. EVS registration is performed using the CFE_EVS_Register +messages. EVS registration is performed using the `CFE_EVS_Register` function. This function takes as its input parameters a pointer to an array of event message filters, or NULL if no filtering is desired, the number of filters in the input array, and the event filtering scheme the application desires to use. The array structure containing the event message filters depends on the filtering scheme selected. If the -CFE_EVS_Register function is called more than once by the same +`CFE_EVS_Register` function is called more than once by the same application, the application will first be unregistered from the EVS and then reregistered with the EVS. This implies that all current filtering and the filter states will be lost. After an application has registered @@ -2379,7 +2376,7 @@ where a filter mask is logically "anded" with a counter value in order to generate a filter value. When the filter value is greater than zero the message is filtered. When the filter value is equal to zero the message is sent. This filtering scheme is specified during Application -registration with the CFE_EVS_BINARY_FILTER parameter. +registration with the `CFE_EVS_BINARY_FILTER` parameter. The EVS binary filter structure type, shown below, contains an Event ID along with a hexadecimal bit mask. The Event ID is a numeric literal @@ -2397,20 +2394,20 @@ typedef struct Several common bit masks are defined within the EVS. These include: -- CFE_EVS_NO_FILTER -- CFE_EVS_FIRST_ONE_STOP -- CFE_EVS_FIRST_TWO_STOP -- CFE_EVS_EVERY_OTHER_ONE -- CFE_EVS_EVERY_OTHER_TWO +- `CFE_EVS_NO_FILTER` +- `CFE_EVS_FIRST_ONE_STOP` +- `CFE_EVS_FIRST_TWO_STOP` +- `CFE_EVS_EVERY_OTHER_ONE` +- `CFE_EVS_EVERY_OTHER_TWO` Applications may also create and use their own hexadecimal bit masks. When applications register event filters with the -CFE_EVS_BINARY_FILTER scheme a filter counter is created for each +`CFE_EVS_BINARY_FILTER` scheme a filter counter is created for each Event ID contained in the binary filter structure. The binary event filtering is accomplished by "anding" the hexadecimal bit mask with the current value of the event filter counter. When the result is zero the message is sent. Otherwise it is discarded. The filter counter is -incremented on each call to the CFE_EVS_SendEvent function (See +incremented on each call to the `CFE_EVS_SendEvent` function (See section 7.4) regardless of whether the message was sent. An example of an Application registering with Event Services and @@ -2483,8 +2480,8 @@ SAMPLE_AppData_t SAMPLE_AppData; /* Instantiate Task Data */ Once an application has registered its binary event filters the application may reset its filters by clearing the event filter counters to zero. Two functions are available within the EVS for clearing an -application's filter counters: CFE_EVS_ResetFilter and -CFE_EVS_ResetAllFilters. The first of these allows the Application to +application's filter counters: `CFE_EVS_ResetFilter` and +`CFE_EVS_ResetAllFilters`. The first of these allows the Application to reset the filter counter for a specified Event ID. The latter function resets all event filter counters for the Application. An example of resetting a specific Event ID filter counter is shown below: @@ -2503,9 +2500,9 @@ FILE: sample_app.c ## 7.5 Sending an Event Message -Event messages are sent using either the CFE_EVS_SendEvent() function -or the CFE_EVS_SendTimedEvent() function, which are both analogous to -the C printf() function in how strings are formatted. An example of each +Event messages are sent using either the `CFE_EVS_SendEvent()` function +or the `CFE_EVS_SendTimedEvent()` function, which are both analogous to +the C `printf()` function in how strings are formatted. An example of each function call is shown below: ```c @@ -2532,8 +2529,8 @@ CFE_EVS_SendTimedEvent(PktTime, EventID, EventType, "CSS Data Bad: In this case, the first parameter is a time tag that the Application wishes to have associated with the message. Normally, the current time, -as retrieved by the CFE_TIME_GetTime function is automatically -associated with the message when CFE_EVS_SendEvent is called. This +as retrieved by the `CFE_TIME_GetTime` function is automatically +associated with the message when `CFE_EVS_SendEvent` is called. This latter function allows the Application to override this with another time. In this example, it is associating the time tag from the packet that contained the CSS data. @@ -2541,7 +2538,7 @@ that contained the CSS data. The EVS will not send events for applications that have not registered with the EVS. The EVS will ignore all function calls from unregistered applications. If an application fails to register with the EVS, a call -to the CFE_EVS_SendEvent function will have no effect. +to the `CFE_EVS_SendEvent` function will have no effect. ### 7.5.1 Event Message Text @@ -2558,7 +2555,7 @@ conventions in order to be useful and understandable: - It should always be clear what radix a numerical value is expressed in. By default, numbers should be in decimal. A hexadecimal number - should be indicated by prefixing 0x to the digits. Binary should + should be indicated by prefixing `0x` to the digits. Binary should use a "B" suffix. - Floating-point numbers of unknown magnitude should be expressed in a @@ -2657,7 +2654,7 @@ A Double Buffered Table has the disadvantage of requiring a dedicated Inactive Table Buffer that is the same size as the Active Table Buffer. The advantage to a Double Buffered Table is that the switch from Inactive to Active is deterministic, quick and never blocking. This -makes Double Buffered Tables ideal for providing data to time critical +makes Double Buffered Tables ideal for providing data to time-critical operations and Interrupt Service Routines. ### 8.1.4 Loading/Activating a Table @@ -2679,7 +2676,7 @@ replaced by the contents of the Inactive Table Image. An Operator has the ability to command Table Services to make a Table Dump File. The current contents of the Active Table Image are written to -an onboard filesystem with a command specified filename. This provides a +an onboard filesystem with a command-specified filename. This provides a mechanism for Operators to obtain the current settings of Application parameters. The dump file is in the same format as a Table Load file and can be used later as a Load Image. Note that Applications can define a @@ -2705,7 +2702,7 @@ the ground in the Table Services Housekeeping Telemetry Packet. In order for an Application to make use of the features of a Table, it must first request that a Table Image be created. This is done through -the CFE_TBL_Register API. An Application calls the API for each Table +the `CFE_TBL_Register` API. An Application calls the API for each Table they wish to have created and the cFE responds with an Application unique Table Handle. An example of this process is shown in Section 8.5.1. @@ -2714,7 +2711,7 @@ processor specific by prepending the Application name to the given table name. Therefore, after the above example is executed, Table Services would have added a table with the name “SAMPLE.MyTableName” to the Table Registry. If an Application is sharing a Table that is created by another Application, -it should use the CFE_TBL_Share API instead. The CFE_TBL_Share API will locate +it should use the `CFE_TBL_Share` API instead. The `CFE_TBL_Share` API will locate the specified Table by name and return a Table Handle to the calling Application. An example of Table sharing is shown below: @@ -2748,9 +2745,9 @@ should only be done when necessary. ### 8.3.1 Acquiring Table Data Once an Application has acquired the Table Handle for a particular Table -(either via the CFE_TBL_Register API or the CFE_TBL_Share API), the +(either via the `CFE_TBL_Register` API or the `CFE_TBL_Share` API), the Application can obtain a pointer to the start of the data within the -Table using the CFE_TBL_GetAddress or CFE_TBL_GetAddresses APIs. An example +Table using the `CFE_TBL_GetAddress` or `CFE_TBL_GetAddresses` APIs. An example of this is shown in Section 8.5.1. ```c @@ -2780,23 +2777,23 @@ of this is shown in Section 8.5.1. } ``` -The CFE_TBL_GetAddress call can also return the -CFE_TBL_ERR_NEVER_LOADED indicating that an attempt is being made at +The `CFE_TBL_GetAddress` call can also return the +`CFE_TBL_ERR_NEVER_LOADED` indicating that an attempt is being made at accessing table data when the table has never been loaded with a default set of values. -The CFE_TBL_GetAddresses call can simplify this process for a +The `CFE_TBL_GetAddresses` call can simplify this process for a collection of tables by filling an array of pointers using an array of Table Handles as an input. The disadvantage of the -CFE_TBL_GetAddresses call is that an error in any one table will +`CFE_TBL_GetAddresses` call is that an error in any one table will return an error code that will be difficult to associate with a particular table. ### 8.3.2 Releasing Table Data Once an Application is done accessing its Table Data, it must release -the pointers it obtained with the CFE_TBL_ReleaseAddress or -CFE_TBL_ReleaseAddresses APIs. It is imperative that an Application +the pointers it obtained with the `CFE_TBL_ReleaseAddress` or +`CFE_TBL_ReleaseAddresses` APIs. It is imperative that an Application release the pointers it obtains on a periodic basis. The cFE Table Services will be unable to manipulate the Table contents if the Application does not release its allocated pointers. For an example of @@ -2809,8 +2806,8 @@ Each Application is required to perform some activities to allow the operators an opportunity to validate the table's contents and to change the contents of a table. The Table Service API has a set of calls that are used by an Application to perform these management duties. These -APIs are CFE_TBL_GetStatus, CFE_TBL_Validate, CFE_TBL_Update and -CFE_TBL_Manage. +APIs are `CFE_TBL_GetStatus`, `CFE_TBL_Validate`, `CFE_TBL_Update` and +`CFE_TBL_Manage`. ### 8.4.1 Validating Table Data @@ -2827,9 +2824,9 @@ validation function with the table at the time of table registration (see Section 8.2). An Application is made aware that a Validation Request has been made by -examining the return code of the CFE_TBL_GetStatus API. When the -return status is CFE_TBL_INFO_VALIDATION_PENDING, the Application -should call CFE_TBL_Validate with the appropriate Table Handle to +examining the return code of the `CFE_TBL_GetStatus` API. When the +return status is `CFE_TBL_INFO_VALIDATION_PENDING`, the Application +should call `CFE_TBL_Validate` with the appropriate Table Handle to perform the necessary validation activities. This process ensures that the table validation occurs within the context of the Application that created the table thus allowing the Application to generate its own @@ -2890,7 +2887,7 @@ Table Validation Request has been made as shown below: An Application has control of when the contents of the Table are updated within its execution cycle. If an Application wishes to change the contents of a Table with a known file or block of memory, it can use the -CFE_TBL_Load API. This is useful when an Application wishes to load +`CFE_TBL_Load` API. This is useful when an Application wishes to load the Table with default values or when the Application is changing modes and wishes to use a different parameter set. An example of this can be seen below: @@ -2941,27 +2938,27 @@ An Application also has control of when an Update occurs when the Inactive Table Image has been modified by an external party (i.e. -- ground operations or stored command processor). When Operations has requested that a table be activated, for example, the request is passed -on to the Application when the Application makes the CFE_TBL_GetStatus +on to the Application when the Application makes the `CFE_TBL_GetStatus` API call as shown in the example in Section 8.4.1. A return code of -CFE_TBL_INFO_UPDATE_PENDING is returned when there is an Inactive +`CFE_TBL_INFO_UPDATE_PENDING` is returned when there is an Inactive Table Image waiting to be activated. The Application performs this -update when it feels the time is right by calling the CFE_TBL_Update +update when it feels the time is right by calling the `CFE_TBL_Update` API. ### 8.4.3 Simplifying Table Management The example shown in Section 8.4.1 can be tedious to implement for every table an Application has created. Therefore, the Table Services API has -created an additional API called CFE_TBL_Manage. This API performs all +created an additional API called `CFE_TBL_Manage`. This API performs all of the steps mentioned in the example of Section 8.4.1 and simply -returns an error code when there is a programming error, a CFE_SUCCESS +returns an error code when there is a programming error, a `CFE_SUCCESS` code when either no activity is required or a table validation has been -successfully handled, or CFE_TBL_INFO_UPDATED when the table has been +successfully handled, or `CFE_TBL_INFO_UPDATED` when the table has been successfully updated from an Inactive Table Image. It is recommended that Applications that do not require a special handling of their tables -should use the CFE_TBL_Manage API to help ensure a consistent approach +should use the `CFE_TBL_Manage` API to help ensure a consistent approach to table management throughout the flight system. An Application may -wish to make the call to CFE_TBL_Manage during each Housekeeping +wish to make the call to `CFE_TBL_Manage` during each Housekeeping Telemetry Request cycle, for example, to keep the management at a reasonable level with a reasonable amount of lag in its response to Operation requests for table validations and activations. @@ -3058,7 +3055,7 @@ int32 XX_TableInit(void) ** Register my table with Table Services */ Status = CFE_TBL_Register(&XX_AppData.MyTableHandle, /* Table Handle (to be returned) */ - "MyTableName", /* Application specific Table Name */ + "MyTableName", /* Application-specific Table Name */ sizeof(XX_MyTable_t), /* Size of Table being Registered */ CFE_TBL_OPT_DEFAULT, /* Deflt: Single Buff. and Loadable */ &XX_ValidateTable); /* Ptr to table validation function */ @@ -3143,7 +3140,7 @@ FILE: xx_platform_cfg.h ## 8.6 Building Tables In order to build application tables with the CMake build system, the -"add_cfe_tables" command needs to be added to the CMakeLists.txt file. If the +"add_cfe_tables" command needs to be added to the `CMakeLists.txt` file. If the application is structured with a "Tables" directory, another "aux_source_directory" may need to be added as well. @@ -3163,7 +3160,7 @@ services. 1. Applications should consider using tables for configuration parameters that that may need to be updated or modified in flight. 2. Table validation functions should validate every entry in a table. -3. Applications with tables should call the CFE_TBL_Manage function at a +3. Applications with tables should call the `CFE_TBL_Manage` function at a regular interval to ensure that tables can be updated. This is often done during the housekeeping cycle. @@ -3199,61 +3196,61 @@ typedef struct } CFE_FS_Header_t; ``` -The ContentType element is a magic number that identifies this file as +The `ContentType` element is a magic number that identifies this file as conforming to the cFE standard header type. At the release of this -document, the magic number on all cFE compliant files is 0x63464531 +document, the magic number on all cFE-compliant files is `0x63464531` which appears as 'cFE1' when seen in ASCII. -The SubType is an indication of the contents/format of the file. There -are some SubType values that are dedicated to the cFE itself. -Application developers should examine the cfe_fs.h file to determine -what SubType values are allowed for them to use to prevent a type +The `SubType` is an indication of the contents/format of the file. There +are some `SubType` values that are dedicated to the cFE itself. +Application developers should examine the `cfe_fs.h` file to determine +what `SubType` values are allowed for them to use to prevent a type collision in the future. When reading a file, an Application should -verify the SubType is of the appropriate value before processing data. +verify the `SubType` is of the appropriate value before processing data. This will help avoid situations where an operator specifies the wrong filename when sending a command to an Application. -The Length specifies the size of the CFE_FS_Header_t and can be used +The `Length` specifies the size of the `CFE_FS_Header_t` and can be used to determine the version of the header type as well as where the user data is relative to the beginning of the file. -The SpacecraftID, ProcessorID and ApplicationID are all automatically -filled by cFE File Services routines when creating a cFE compliant file. +The `SpacecraftID`, `ProcessorID` and `ApplicationID` are all automatically +filled by cFE File Services routines when creating a cFE-compliant file. These fields help identify where and how the file was created. -The TimeSeconds and TimeSubSeconds elements contain the Spacecraft Time +The `TimeSeconds` and `TimeSubSeconds` elements contain the Spacecraft Time when the header was created. -The Description field provides a brief ASCII description of the contents +The `Description` field provides a brief ASCII description of the contents of the file. ## 9.2 Accessing and Modifying the Standard File Header File Services provides a few functions for accessing and modifying the contents of the standard file header. The first of these is the -CFE_FS_ReadHeader function. This function reads the contents of the +`CFE_FS_ReadHeader` function. This function reads the contents of the header of a specified file and returns it into a given data structure. An example of this function is shown below: -The opposite version of this file API is the CFE_FS_WriteHeader +The opposite version of this file API is the `CFE_FS_WriteHeader` function. This function populates the given header data structure with -the SpacecraftID, ProcessorID, ApplicationID, TimeSeconds and -TimeSubsecs as obtained from the Executive and Time Services. The -Developer only needs to specify the SubType and Description fields. +the `SpacecraftID`, `ProcessorID`, `ApplicationID`, `TimeSeconds` and +`TimeSubsecs` as obtained from the Executive and Time Services. The +Developer only needs to specify the `SubType` and `Description` fields. After the function successfully writes the standard header to the file, the given header data structure contains all of the information and the file pointer associated with the specified file is pointing to the first byte past the standard header. In addition to the functions for obtaining and writing the entire -header, there are two functions for manipulating the TimeSeconds and -TimeSubseconds fields of the header. The first of these is the -CFE_FS_UpdateHeaderTime function. This function takes the specified -file and sets the TimeSeconds and TimeSubsecs fields equal to the -current time as obtained from CFE_TIME_GetTime. The second function, -CFE_FS_SetHeaderTime, allows the Developer to set the create time in +header, there are two functions for manipulating the `TimeSeconds` and +`TimeSubseconds` fields of the header. The first of these is the +`CFE_FS_UpdateHeaderTime` function. This function takes the specified +file and sets the `TimeSeconds` and `TimeSubsecs` fields equal to the +current time as obtained from `CFE_TIME_GetTime`. The second function, +`CFE_FS_SetHeaderTime,` allows the Developer to set the create time in the standard header equal to a time specified using the -CFE_TIME_SysTime_t data format. This function may be useful when time +`CFE_TIME_SysTime_t` data format. This function may be useful when time tagging experiment data with the time the data was acquired rather than the time the file was created. @@ -3262,7 +3259,7 @@ the time the file was created. The File Service provides a utility function that can move the file pointer associated with a specified file to the first byte of data following the standard header. This function is called -CFE_FS_SeekFileDataStart and an example of its use can be found below: +`CFE_FS_SeekFileDataStart` and an example of its use can be found below: | **File Service Function** | **Purpose** | |:-------------------------------|:-------------------------------------------------------------------------------| @@ -3281,7 +3278,7 @@ CFE_FS_SeekFileDataStart and an example of its use can be found below: Time is maintained and accessed through the cFE Time Service (TIME) API. The cFE Time Service is an API that allows Applications the ability to access, convert and manipulate the current time. The definitions for -the TIME API are found in cfe_time.h. +the TIME API are found in `cfe_time.h`. ## 10.1 Time Formats @@ -3297,8 +3294,8 @@ typedef struct { } CFE_TIME_SysTime_t; ``` -Examples of the subseconds time field would be 0x80000000 equals a half -second, 0x40000000 equals a quarter second, etc. Because time is not +Examples of the subseconds time field would be `0x80000000` equals a half +second, `0x40000000` equals a quarter second, etc. Because time is not simply a single integer or floating point number, the Time Service provides a collection of functions for converting and manipulating time in these formats. These functions are described in the sections below. @@ -3372,15 +3369,15 @@ Service time values are summarized below. The following Time Service API functions are available for obtaining time information. Most Developer's will only need one time function, -CFE_TIME_GetTime. This function provides the caller with the current -spacecraft time relative to the mission specific epoch time and may be +`CFE_TIME_GetTime`. This function provides the caller with the current +spacecraft time relative to the mission-specific epoch time and may be either TAI or UTC. Developers should attempt to use this function in all cases to ensure portability of their software to future missions. Two additional time functions are provided for exceptions. The first of -these, CFE_TIME_GetUTC, provides the spacecraft time relative to the +these, `CFE_TIME_GetUTC`, provides the spacecraft time relative to the Mission Epoch with the inclusion of Leap Seconds. Developers may need to use this function when their Application requirements insist on the use -of UTC. The second function, CFE_TIME_GetTAI, provides the spacecraft +of UTC. The second function, `CFE_TIME_GetTAI`, provides the spacecraft time since the Mission Epoch and always excludes any Leap Seconds. Developer's may need to use this function when their Application requirements insist on using a time that cannot be subject to the @@ -3388,24 +3385,24 @@ occasional one second jump that occurs when Leap Seconds are updated. On even more rare occasions, an Application may need to know the Mission Elapsed Time. The Time Service provides three functions for obtaining -the MET. The first, CFE_TIME_GetMET, returns the MET time in the -CFE_Time_SysTime_t format. The other two, CFE_TIME_GetMETSeconds -and CFE_TIME_GetMETSubsecs, return just the appropriate 32-bit integer +the MET. The first, `CFE_TIME_GetMET`, returns the MET time in the +`CFE_Time_SysTime_t` format. The other two, `CFE_TIME_GetMETSeconds` +and `CFE_TIME_GetMETSubsecs`, return just the appropriate 32-bit integer representing that portion of the time. If an Application needs to obtain the current Spacecraft Time -Correlation Factor (STCF), the function CFE_TIME_GetSTCF returns the +Correlation Factor (STCF), the function `CFE_TIME_GetSTCF` returns the value in the cFE standard time format described above. The STCF does not typically, unless the mission operations' personnel decide to do so, incorporate the number of Leap Seconds required to convert the onboard TAI time with UTC. To obtain the number of Leap Seconds, the Application -must call CFE_TIME_GetLeapSeconds. +must call `CFE_TIME_GetLeapSeconds`. -The final time information function is the CFE_TIME_GetClockState +The final time information function is the `CFE_TIME_GetClockState` function. To understand the return values of this function, a brief description of how time is managed on the spacecraft is necessary. From the Application's perspective, the time obtained through any of the -CFE_TIME_Get... functions is directly obtained from the spacecraft's +`CFE_TIME_Get...` functions is directly obtained from the spacecraft's primary onboard time base. However, on a spacecraft with multiple processors, only one processor typically has access to the primary onboard time base. The cFE implements a Time Server / Time Client @@ -3418,27 +3415,27 @@ disconnected from one another, they each do their best to maintain the current time with what information they have available. If an Application requires accurate time knowledge for its processing, -it may require using the CFE_TIME_GetClockState function. When this -function returns CFE_TIME_VALID, then the Application can feel -comfortable that the time obtained through any of the CFE_TIME_Get... +it may require using the `CFE_TIME_GetClockState` function. When this +function returns `CFE_TIME_ClockState_VALID`, then the Application can feel +comfortable that the time obtained through any of the `CFE_TIME_Get...` functions is synchronized with the primary onboard time base. If the -function returns CFE_TIME_FLYWHEEL, then the Application knows that -the time obtained from any of the CFE_TIME_Get... functions was +function returns `CFE_TIME_ClockState_FLYWHEEL`, then the Application knows that +the time obtained from any of the `CFE_TIME_Get...` functions was synchronized at some point in the past but it is now nothing more than a "best guess" based upon a non-optimal time base. When the return value -is CFE_TIME_INVALID, then the Application knows that the -CFE_TIME_Get... functions are returning a local time that has never +is `CFE_TIME_ClockState_INVALID`, then the Application knows that the +`CFE_TIME_Get...` functions are returning a local time that has never been synchronized to the primary onboard time base. ## 10.4 Time Conversion Functions Since working with subseconds as an integer of 2^-32 seconds is sometimes cumbersome, the cFE Time Services provides two functions to -alleviate this problem. The first, CFE_TIME_Sub2MicroSecs, converts +alleviate this problem. The first, `CFE_TIME_Sub2MicroSecs`, converts the 32-bit integer subseconds value to an integral number of microseconds in the range of 0 to 999,999. -The second function, CFE_TIME_Micro2SubSecs, reverses this process and +The second function, `CFE_TIME_Micro2SubSecs`, reverses this process and can convert an integer within the range of 0 to 999,999 into the appropriate number of 2^-32 seconds. @@ -3452,13 +3449,13 @@ seconds since some arbitrary epoch time. ![](.//media/cFE_Application_Developers_Guide_image19.png) -If the counter rolls over (i.e. -- goes from 0xFFFFFFFF to 0x00000000), +If the counter rolls over (i.e. -- goes from `0xFFFFFFFF` to `0x00000000`), it is not considered an error just like when an analog wall clock goes from 11:59 to 12:00. This feature is necessary because a mission specific epoch time could be some time in the future. By allowing rollovers, the time format can be interpreted by ground software as -either a signed integer, so that 0xFFFFFFFF is one second before the -epoch time, or as an unsigned integer, where 0xFFFFFFFF is 4,294,967,295 +either a signed integer, so that `0xFFFFFFFF` is one second before the +epoch time, or as an unsigned integer, where `0xFFFFFFFF` is 4,294,967,295 seconds past the epoch time. The drawback to allowing rollovers is that this adds an interesting @@ -3470,13 +3467,13 @@ hours later. ![](.//media/cFE_Application_Developers_Guide_image20.png) -The rule that is used by the CFE_TIME_Compare function is that if the +The rule that is used by the `CFE_TIME_Compare` function is that if the smaller delta time is found going in a counter-clockwise direction, then the first time is considered greater than the second and the comparison -function would return CFE_TIME_A_GT_B. Likewise, if the smaller +function would return `CFE_TIME_A_GT_B`. Likewise, if the smaller delta time is found going in a clockwise direction, as demonstrated in the example above, then the first time is less than the second and the -comparison function would return CFE_TIME_A_LT_B. This rule was +comparison function would return `CFE_TIME_A_LT_B`. This rule was chosen because it seemed unlikely that someone would require the ability to compare two times whose delta time was greater than or equal to 2,147,483,647 seconds (approximately 68 years). If a mission does @@ -3486,11 +3483,11 @@ their own delta time calculation function(s). In addition to the rollover phenomenon, the Developer should be aware that comparing an absolute time with a delta time is meaningless. -The CFE_TIME_Subtract function will compute the delta between two +The `CFE_TIME_Subtract` function will compute the delta between two given times. The Developer is responsible for determining the appropriate order of two absolute times given to the function to obtain the desired delta time. It may be necessary to call the -CFE_TIME_Compare function to determine which absolute time should be +`CFE_TIME_Compare` function to determine which absolute time should be the first time in the subtraction. Otherwise, as shown above, the delta time between two absolute times could either be 5 hours or 7 hours. An example of a delta time computation function is shown below: @@ -3522,13 +3519,13 @@ absolute time, a delta time or garbage as shown below: - DeltaTime -- DeltaTime = DeltaTime - DeltaTime -- AbsoluteTime = garbage -The CFE_TIME_Add function should be used because it can properly +The `CFE_TIME_Add` function should be used because it can properly handle the subseconds term and rollovers. The Developer should remember, however, that adding two absolute times together does not make any sense. One of the two times must be a delta time. -The cFE Time Services also provide a function called CFE_TIME_Print. -This function allows for a time given in the CFE_TIME_SysTime_t data +The cFE Time Services also provide a function called `CFE_TIME_Print`. +This function allows for a time given in the `CFE_TIME_SysTime_t` data format to be printed to a string. The resulting string will always be 24 characters long, including the null terminator, and will be of the following format: diff --git a/docs/src/cfe_evs.dox b/docs/src/cfe_evs.dox index dbdce7248..78fe18d05 100644 --- a/docs/src/cfe_evs.dox +++ b/docs/src/cfe_evs.dox @@ -163,7 +163,7 @@ \ref cfeevsugmsgfilter (only the Binary Filtering Scheme exists currently). Note that applications are limited in the number of events that they can register for filtering (see #CFE_PLATFORM_EVS_MAX_EVENT_FILTERS in cfe_platform_cfg.h - for the mission defined limit). The filtering method uses a mask to determine if the + for the mission-defined limit). The filtering method uses a mask to determine if the message is forwarded to the software bus, making it available in telemetry (see \ref cfeevsugmsgfilter for a description on filtering). Commands are available to \link #CFE_EVS_SET_FILTER_CC modify the filter mask \endlink for any registered event. diff --git a/docs/src/cfe_frontpage.dox b/docs/src/cfe_frontpage.dox index d25c48d58..650967918 100644 --- a/docs/src/cfe_frontpage.dox +++ b/docs/src/cfe_frontpage.dox @@ -106,10 +106,10 @@ \section cfebackground_s1 Core Flight Executive (cFE) Goals - The main long term goal of the cFE is to form the basis for a platform and project + The main long-term goal of the cFE is to form the basis for a platform and project independent reusable software framework. The cFE with the OSAL allow the development of portable embedded system software that is independent of a particular Real Time - Operating System and hardware platform. A secondary long term goal is to create a + Operating System and hardware platform. A secondary long-term goal is to create a standardized, product-line approach for development of embedded aerospace flight software.
@@ -121,7 +121,7 @@ promoting the growth of the application and library layers where new applications, libraries, tools, and lessons learned can be contributed and shared.
- It is important for application developers to realize the long term and functional + It is important for application developers to realize the long-term and functional goals of the cFE. With a standard set of services providing a standard API, all applications developed with the cFE have an opportunity to become useful on future missions through code reuse. In order to achieve this goal, diff --git a/docs/src/cfe_glossary.dox b/docs/src/cfe_glossary.dox index c0f8067b4..2092cc46f 100644 --- a/docs/src/cfe_glossary.dox +++ b/docs/src/cfe_glossary.dox @@ -44,7 +44,7 @@ cFE following a Processor Reset. \anchor cfeadg_crc Cyclic Redundancy Check - A polynomial based method for checking that a data set + A polynomial-based method for checking that a data set has remained unchanged from one time period to another. \anchor cfeadg_developer Developer diff --git a/docs/src/cfe_tbl.dox b/docs/src/cfe_tbl.dox index c8a9d86cd..887e88009 100644 --- a/docs/src/cfe_tbl.dox +++ b/docs/src/cfe_tbl.dox @@ -116,7 +116,7 @@ The default table type for a cFE Application to use is a single buffered table. The principle advantage of a single buffered table is that it can share one of several shared table buffers for uploaded and pending table images. Since many cFE Applications have relatively small tables - that are not changed at time critical moments or are not changed very often during a mission, + that are not changed at time-critical moments or are not changed very often during a mission, single buffered tables represent the most memory resource efficient method of being managed. The number of single buffered tables that can have inactive table images being manipulated at one diff --git a/docs/src/cfe_time.dox b/docs/src/cfe_time.dox index 1f16a05cb..3653ea103 100644 --- a/docs/src/cfe_time.dox +++ b/docs/src/cfe_time.dox @@ -68,7 +68,7 @@ easily be manipulated and utilized. These components include: The Ground Epoch is an arbitrary date and time that establishes the zero point - for spacecraft time calculations. The selection of the epoch is mission specific, + for spacecraft time calculations. The selection of the epoch is mission-specific, although in the past, it was common to select the same epoch as defined for the Operating System used by the computers hosting the ground system software. Recent mission epoch selections have also included using zero seconds after midnight, @@ -247,7 +247,7 @@ #define CFE_MISSION_TIME_CFG_DEFAULT_UTC TRUE \endverbatim - The choice of time format is a mission specific decision and is not directly + The choice of time format is a mission-specific decision and is not directly affected by the hardware configuration. \sa #CFE_MISSION_TIME_CFG_DEFAULT_TAI, #CFE_MISSION_TIME_CFG_DEFAULT_UTC
@@ -659,7 +659,7 @@ to the current STCF. In addition there is a 1Hz adjustment (#CFE_TIME_ADD_1HZ_ADJUSTMENT_CC and #CFE_TIME_SUB_1HZ_ADJUSTMENT_CC) that can be made to the STCF to compensate for oscillator drift. - Mission specific ground correlation should be used to assist in + Mission-specific ground correlation should be used to assist in determining the proper values to use. The Leap Seconds should be set to the current TAI-UTC. Note that the International Earth Rotation and Reference Systems Service Bulletin C, which defines diff --git a/docs/src/mnem_maps/cfe_es_cmd_mnem_map b/docs/src/mnem_maps/cfe_es_cmd_mnem_map index 8aabd2ac3..e5cf87633 100644 --- a/docs/src/mnem_maps/cfe_es_cmd_mnem_map +++ b/docs/src/mnem_maps/cfe_es_cmd_mnem_map @@ -1,6 +1,6 @@ #--------------------------------------------------------------------------- # Each of the following assignment statements should have the documentation -# mnemonic on the left followed by the mission specific command mnemonic +# mnemonic on the left followed by the mission-specific command mnemonic # on the right of the equals operator. # # FORMATTING DETAILS TO REMEMBER! diff --git a/docs/src/mnem_maps/cfe_es_tlm_mnem_map b/docs/src/mnem_maps/cfe_es_tlm_mnem_map index e76b8701d..b2fbdc405 100644 --- a/docs/src/mnem_maps/cfe_es_tlm_mnem_map +++ b/docs/src/mnem_maps/cfe_es_tlm_mnem_map @@ -1,6 +1,6 @@ #--------------------------------------------------------------------------- # Each of the following assignment statements should have the documentation -# mnemonic on the left followed by the mission specific telemetry mnemonic +# mnemonic on the left followed by the mission-specific telemetry mnemonic # on the right of the equals operator. # # FORMATTING DETAILS TO REMEMBER! diff --git a/docs/src/mnem_maps/cfe_evs_cmd_mnem_map b/docs/src/mnem_maps/cfe_evs_cmd_mnem_map index 3c4ef8d37..a96764b3d 100644 --- a/docs/src/mnem_maps/cfe_evs_cmd_mnem_map +++ b/docs/src/mnem_maps/cfe_evs_cmd_mnem_map @@ -1,6 +1,6 @@ #--------------------------------------------------------------------------- # Each of the following assignment statements should have the documentation -# mnemonic on the left followed by the mission specific command mnemonic +# mnemonic on the left followed by the mission-specific command mnemonic # on the right of the equals operator. # # FORMATTING DETAILS TO REMEMBER! diff --git a/docs/src/mnem_maps/cfe_evs_tlm_mnem_map b/docs/src/mnem_maps/cfe_evs_tlm_mnem_map index 1752b9182..5ae6cbad9 100644 --- a/docs/src/mnem_maps/cfe_evs_tlm_mnem_map +++ b/docs/src/mnem_maps/cfe_evs_tlm_mnem_map @@ -1,6 +1,6 @@ #--------------------------------------------------------------------------- # Each of the following assignment statements should have the documentation -# mnemonic on the left followed by the mission specific telemetry mnemonic +# mnemonic on the left followed by the mission-specific telemetry mnemonic # on the right of the equals operator. # # FORMATTING DETAILS TO REMEMBER! diff --git a/docs/src/mnem_maps/cfe_sb_cmd_mnem_map b/docs/src/mnem_maps/cfe_sb_cmd_mnem_map index 2db61efec..dde5f7866 100644 --- a/docs/src/mnem_maps/cfe_sb_cmd_mnem_map +++ b/docs/src/mnem_maps/cfe_sb_cmd_mnem_map @@ -1,6 +1,6 @@ #--------------------------------------------------------------------------- # Each of the following assignment statements should have the documentation -# mnemonic on the left followed by the mission specific command mnemonic +# mnemonic on the left followed by the mission-specific command mnemonic # on the right of the equals operator. # # FORMATTING DETAILS TO REMEMBER! diff --git a/docs/src/mnem_maps/cfe_sb_tlm_mnem_map b/docs/src/mnem_maps/cfe_sb_tlm_mnem_map index b8192ffb1..30625baf8 100644 --- a/docs/src/mnem_maps/cfe_sb_tlm_mnem_map +++ b/docs/src/mnem_maps/cfe_sb_tlm_mnem_map @@ -1,6 +1,6 @@ #--------------------------------------------------------------------------- # Each of the following assignment statements should have the documentation -# mnemonic on the left followed by the mission specific telemetry mnemonic +# mnemonic on the left followed by the mission-specific telemetry mnemonic # on the right of the equals operator. # # FORMATTING DETAILS TO REMEMBER! diff --git a/docs/src/mnem_maps/cfe_tbl_cmd_mnem_map b/docs/src/mnem_maps/cfe_tbl_cmd_mnem_map index 87889cec9..aa7510067 100644 --- a/docs/src/mnem_maps/cfe_tbl_cmd_mnem_map +++ b/docs/src/mnem_maps/cfe_tbl_cmd_mnem_map @@ -1,6 +1,6 @@ #--------------------------------------------------------------------------- # Each of the following assignment statements should have the documentation -# mnemonic on the left followed by the mission specific command mnemonic +# mnemonic on the left followed by the mission-specific command mnemonic # on the right of the equals operator. # # FORMATTING DETAILS TO REMEMBER! diff --git a/docs/src/mnem_maps/cfe_tbl_tlm_mnem_map b/docs/src/mnem_maps/cfe_tbl_tlm_mnem_map index a2eb427cb..78a33fc69 100644 --- a/docs/src/mnem_maps/cfe_tbl_tlm_mnem_map +++ b/docs/src/mnem_maps/cfe_tbl_tlm_mnem_map @@ -1,6 +1,6 @@ #--------------------------------------------------------------------------- # Each of the following assignment statements should have the documentation -# mnemonic on the left followed by the mission specific telemetry mnemonic +# mnemonic on the left followed by the mission-specific telemetry mnemonic # on the right of the equals operator. # # FORMATTING DETAILS TO REMEMBER! diff --git a/docs/src/mnem_maps/cfe_time_cmd_mnem_map b/docs/src/mnem_maps/cfe_time_cmd_mnem_map index fc8f2cfbc..40a222f04 100644 --- a/docs/src/mnem_maps/cfe_time_cmd_mnem_map +++ b/docs/src/mnem_maps/cfe_time_cmd_mnem_map @@ -1,6 +1,6 @@ #--------------------------------------------------------------------------- # Each of the following assignment statements should have the documentation -# mnemonic on the left followed by the mission specific command mnemonic +# mnemonic on the left followed by the mission-specific command mnemonic # on the right of the equals operator. # # FORMATTING DETAILS TO REMEMBER! diff --git a/docs/src/mnem_maps/cfe_time_tlm_mnem_map b/docs/src/mnem_maps/cfe_time_tlm_mnem_map index dcfe19ffc..e162daa5c 100644 --- a/docs/src/mnem_maps/cfe_time_tlm_mnem_map +++ b/docs/src/mnem_maps/cfe_time_tlm_mnem_map @@ -1,6 +1,6 @@ #--------------------------------------------------------------------------- # Each of the following assignment statements should have the documentation -# mnemonic on the left followed by the mission specific telemetry mnemonic +# mnemonic on the left followed by the mission-specific telemetry mnemonic # on the right of the equals operator. # # FORMATTING DETAILS TO REMEMBER! diff --git a/modules/core_api/eds/config.xml b/modules/core_api/eds/config.xml index 236a5b6f3..ebcf7eba5 100644 --- a/modules/core_api/eds/config.xml +++ b/modules/core_api/eds/config.xml @@ -39,7 +39,7 @@ - + diff --git a/modules/core_api/fsw/inc/cfe_error.h b/modules/core_api/fsw/inc/cfe_error.h index bd7138478..981b0054d 100644 --- a/modules/core_api/fsw/inc/cfe_error.h +++ b/modules/core_api/fsw/inc/cfe_error.h @@ -104,7 +104,7 @@ char *CFE_ES_StatusToString(CFE_Status_t status, CFE_StatusString_t *status_stri ** Mission Defined - These bits are available for Mission ** specific coding standards. They can ** be used to classify error codes related -** to mission specific library function calls, etc. +** to mission-specific library function calls, etc. ** ** Code - is the status code */ diff --git a/modules/core_api/fsw/inc/cfe_tbl.h b/modules/core_api/fsw/inc/cfe_tbl.h index d379b5f1f..a45f74d0e 100644 --- a/modules/core_api/fsw/inc/cfe_tbl.h +++ b/modules/core_api/fsw/inc/cfe_tbl.h @@ -70,7 +70,7 @@ ** ** \param[in] Name The raw table name. This name will be combined with the name of the ** application to produce a name of the form "AppName.RawTableName". -** This application specific name will be used in commands +** This application-specific name will be used in commands ** for modifying or viewing the contents of the table. ** ** \param[in] Size The size, in bytes, of the table to be created @nonzero. This is the size that will @@ -105,7 +105,7 @@ ** the pointer to the "active" table is changed to ** point to the "inactive" buffer thus making it ** the new "active" buffer. This feature is most -** useful for time critical applications (ie - +** useful for time-critical applications (ie - ** interrupt service routines, etc). This option is ** mutually exclusive with the ** #CFE_TBL_OPT_SNGL_BUFFER and #CFE_TBL_OPT_DEFAULT @@ -209,7 +209,7 @@ CFE_Status_t CFE_TBL_Register(CFE_TBL_Handle_t *TblHandlePtr, const char *Name, ** identify table to cFE when performing Table operations. ** This value is returned at the address specified by TblHandlePtr. ** -** \param[in] TblName The application specific name of the table of the form "AppName.RawTableName", +** \param[in] TblName The application-specific name of the table of the form "AppName.RawTableName", ** where RawTableName is the name specified in the #CFE_TBL_Register API call. ** Example: "ACS.TamParams" for a table called "TamParams" ** that was registered by the application called "ACS". @@ -688,7 +688,7 @@ CFE_Status_t CFE_TBL_GetStatus(CFE_TBL_Handle_t TblHandle); ** with table characteristics and information. *TblInfoPtr is the description of the tables ** characteristics and registry information stored in the #CFE_TBL_Info_t data structure ** format. -** \param[in] TblName The application specific name @nonnull of the table of the form "AppName.RawTableName", +** \param[in] TblName The application-specific name @nonnull of the table of the form "AppName.RawTableName", ** where RawTableName is the name specified in the #CFE_TBL_Register API call. ** Example: "ACS.TamParams" for a table called "TamParams" ** that was registered by the application called "ACS". diff --git a/modules/core_private/eds/config.xml b/modules/core_private/eds/config.xml index 236a5b6f3..ebcf7eba5 100644 --- a/modules/core_private/eds/config.xml +++ b/modules/core_private/eds/config.xml @@ -39,7 +39,7 @@ - + diff --git a/modules/es/config/default_cfe_es_fcncodes.h b/modules/es/config/default_cfe_es_fcncodes.h index e02b4d347..a557413e0 100644 --- a/modules/es/config/default_cfe_es_fcncodes.h +++ b/modules/es/config/default_cfe_es_fcncodes.h @@ -303,12 +303,12 @@ */ #define CFE_ES_RESTART_APP_CC 6 -/** \cfeescmd Stops, Unloads, Loads from the command specified File and Restarts an Application +/** \cfeescmd Stops, Unloads, Loads from the command-specified File and Restarts an Application ** ** \par Description ** This command halts and removes the specified Application ** from the system. Then it immediately loads the Application from -** the command specified file and restarts it. This command is +** the command-specified file and restarts it. This command is ** especially useful for restarting a Command Ingest Application ** since once it has been stopped, no further commands can come in ** to restart it. @@ -845,7 +845,7 @@ ** - \b \c \ES_CMDPC - command execution counter will ** increment ** - \b \c \ES_MAXPROCRESETS - Current maximum number of processor resets -** before an automatic power-on reset will go to the command specified value. +** before an automatic power-on reset will go to the command-specified value. ** - The #CFE_ES_SET_MAX_PR_COUNT_EID informational event message will be ** generated. ** diff --git a/modules/es/config/default_cfe_es_internal_cfg.h b/modules/es/config/default_cfe_es_internal_cfg.h index cb9bbee28..b9a3b9e0e 100644 --- a/modules/es/config/default_cfe_es_internal_cfg.h +++ b/modules/es/config/default_cfe_es_internal_cfg.h @@ -238,7 +238,7 @@ ** Defines the ram disk sector size. The ram disk is 1 of 4 memory areas that ** are preserved on a processor reset. ** NOTE: Changing this value changes memory allocation, and may -** require changes to platform specific values (in CFE_PSP) such as +** require changes to platform-specific values (in CFE_PSP) such as ** USER_RESERVED_MEM in VxWorks depending on the memory areas ** being used for preserved data and on OS specific behavior. ** @@ -256,7 +256,7 @@ ** Defines the ram disk number of sectors. The ram disk is one of four memory ** areas that are preserved on a processor reset. ** NOTE: Changing this value changes memory allocation, and may -** require changes to platform specific values (in CFE_PSP) such as +** require changes to platform-specific values (in CFE_PSP) such as ** USER_RESERVED_MEM in VxWorks depending on the memory areas ** being used for preserved data and on OS specific behavior. ** @@ -298,7 +298,7 @@ ** Defines the Critical Data Store (CDS) area size in bytes size. The CDS is ** one of four memory areas that are preserved during a processor reset. ** NOTE: Changing this value changes memory allocation, and may -** require changes to platform specific values (in CFE_PSP) such as +** require changes to platform-specific values (in CFE_PSP) such as ** USER_RESERVED_MEM in VxWorks depending on the memory areas ** being used for preserved data and on OS specific behavior. ** @@ -318,7 +318,7 @@ ** #CFE_PSP_GetUserReservedArea. The User Reserved Memory is one of four memory ** areas that are preserved during a processor reset. ** NOTE: Changing this value changes memory allocation, and may -** require changes to platform specific values (in CFE_PSP) such as +** require changes to platform-specific values (in CFE_PSP) such as ** USER_RESERVED_MEM in VxWorks depending on the memory areas ** being used for preserved data and on OS specific behavior. ** diff --git a/modules/es/fsw/src/cfe_es_cds.c b/modules/es/fsw/src/cfe_es_cds.c index e8326efb3..6cefc9a64 100644 --- a/modules/es/fsw/src/cfe_es_cds.c +++ b/modules/es/fsw/src/cfe_es_cds.c @@ -80,7 +80,7 @@ int32 CFE_ES_CDS_EarlyInit(void) return CFE_STATUS_EXTERNAL_RESOURCE_FAIL; } - /* Always truncate the size to the nearest 4 byte boundary */ + /* Always truncate the size to the nearest 4-byte boundary */ CDS->TotalSize = PlatformSize & 0xfffffffc; /* Compute the minimum size required for the CDS with the current configuration of the cFE */ diff --git a/modules/evs/config/default_cfe_evs_fcncodes.h b/modules/evs/config/default_cfe_evs_fcncodes.h index 7f639081e..6d6fc8321 100644 --- a/modules/evs/config/default_cfe_evs_fcncodes.h +++ b/modules/evs/config/default_cfe_evs_fcncodes.h @@ -106,7 +106,7 @@ /** \cfeevscmd Enable Event Type ** ** \par Description -** This command enables the command specified Event Type allowing event +** This command enables the command-specified Event Type allowing event ** messages of this type to be sent through Event Service. An Event Type ** is defined to be a classification of an Event Message such as debug, ** informational, error and critical. This command is a global enable of a @@ -154,7 +154,7 @@ /** \cfeevscmd Disable Event Type ** ** \par Description -** This command disables the command specified Event Type preventing event +** This command disables the command-specified Event Type preventing event ** messages of this type to be sent through Event Service. An Event Type ** is defined to be a classification of an Event Message such as debug, ** informational, error and critical. This command is a global disable of a @@ -203,7 +203,7 @@ /** \cfeevscmd Set Event Format Mode ** ** \par Description -** This command sets the event format mode to the command specified value. +** This command sets the event format mode to the command-specified value. ** The event format mode may be either short or long. A short event format ** detaches the Event Data from the event message and only includes the ** following information in the event packet: Processor ID, Application ID, @@ -250,9 +250,9 @@ /** \cfeevscmd Enable Application Event Type ** ** \par Description -** This command enables the command specified event type for the command +** This command enables the command-specified event type for the command ** specified application, allowing the application to send event messages -** of the command specified event type through Event Service. An Event +** of the command-specified event type through Event Service. An Event ** Type is defined to be a classification of an Event Message such as ** debug, informational, critical, and error. ** Note: In order for this command to take effect, applications must be @@ -302,9 +302,9 @@ /** \cfeevscmd Disable Application Event Type ** ** \par Description -** This command disables the command specified event type for the command +** This command disables the command-specified event type for the command ** specified application, preventing the application from sending event -** messages of the command specified event type through Event Service. +** messages of the command-specified event type through Event Service. ** An Event Type is defined to be a classification of an Event Message such ** as debug, informational, critical, and error. Note: In order for this ** command to take effect, applications must be registered for Event Service. @@ -355,7 +355,7 @@ /** \cfeevscmd Enable Event Services for an Application ** ** \par Description -** This command enables the command specified application to send events +** This command enables the command-specified application to send events ** through the Event Service. Note: In order for this command to take ** effect, applications must be registered for Event Service. ** @@ -394,7 +394,7 @@ /** \cfeevscmd Disable Event Services for an Application ** ** \par Description -** This command disables the command specified application from sending +** This command disables the command-specified application from sending ** events through Event Service. Note: In order for this command to take ** effect, applications must be registered for Event Service. ** @@ -433,7 +433,7 @@ /** \cfeevscmd Reset Application Event Counters ** ** \par Description -** This command sets the command specified application's event counter to zero. +** This command sets the command-specified application's event counter to zero. ** Note: In order for this command to take effect, applications must be registered ** for Event Service. ** @@ -469,8 +469,8 @@ /** \cfeevscmd Set Application Event Filter ** ** \par Description -** This command sets the command specified application's event filter mask -** to the command specified value for the command specified event. Note: +** This command sets the command-specified application's event filter mask +** to the command-specified value for the command-specified event. Note: ** In order for this command to take effect, applications must be ** registered for Event Service. ** @@ -511,7 +511,7 @@ /** \cfeevscmd Enable Event Services Output Ports ** ** \par Description -** This command enables the command specified port to output event messages +** This command enables the command-specified port to output event messages ** ** \cfecmdmnemonic \EVS_ENAPORT ** @@ -589,8 +589,8 @@ /** \cfeevscmd Reset an Event Filter for an Application ** ** \par Description -** This command resets the command specified application's event filter for -** the command specified event ID. Note: In order for this command to take +** This command resets the command-specified application's event filter for +** the command-specified event ID. Note: In order for this command to take ** effect, applications must be registered for Event Service. ** ** \cfecmdmnemonic \EVS_RSTBINFLTRCTR @@ -625,7 +625,7 @@ /** \cfeevscmd Reset All Event Filters for an Application ** ** \par Description -** This command resets all of the command specified applications event +** This command resets all of the command-specified applications event ** filters. Note: In order for this command to take effect, applications ** must be registered for Event Service. ** @@ -804,7 +804,7 @@ /** \cfeevscmd Set Logging Mode ** ** \par Description -** This command sets the logging mode to the command specified value. +** This command sets the logging mode to the command-specified value. ** ** \cfecmdmnemonic \EVS_SETLOGMODE ** diff --git a/modules/fs/config/default_cfe_fs_interface_cfg.h b/modules/fs/config/default_cfe_fs_interface_cfg.h index 3f02853d3..312889fa3 100644 --- a/modules/fs/config/default_cfe_fs_interface_cfg.h +++ b/modules/fs/config/default_cfe_fs_interface_cfg.h @@ -36,6 +36,6 @@ #define CFE_FS_HDR_DESC_MAX_LEN 32 /**< \brief Max length of description field in a standard cFE File Header */ -#define CFE_FS_FILE_CONTENT_ID 0x63464531 /**< \brief Magic Number for cFE compliant files (= 'cFE1') */ +#define CFE_FS_FILE_CONTENT_ID 0x63464531 /**< \brief Magic Number for cFE-compliant files (= 'cFE1') */ #endif /* CFE_FS_INTERFACE_CFG_H */ diff --git a/modules/msg/option_inc/default_cfe_msg_sechdr.h b/modules/msg/option_inc/default_cfe_msg_sechdr.h index 567299be4..4891112d1 100644 --- a/modules/msg/option_inc/default_cfe_msg_sechdr.h +++ b/modules/msg/option_inc/default_cfe_msg_sechdr.h @@ -72,7 +72,7 @@ typedef struct */ typedef struct { - uint8 Time[6]; /**< \brief Time, big endian: 4 byte seconds, 2 byte subseconds */ + uint8 Time[6]; /**< \brief Time, big endian: 4-byte seconds, 2-byte subseconds */ } CFE_MSG_TelemetrySecondaryHeader_t; #endif /* DEFAULT_CFE_MSG_SECHDR_H */ diff --git a/modules/sb/fsw/src/cfe_sb_api.c b/modules/sb/fsw/src/cfe_sb_api.c index 1b9574260..182fb72b7 100644 --- a/modules/sb/fsw/src/cfe_sb_api.c +++ b/modules/sb/fsw/src/cfe_sb_api.c @@ -44,7 +44,7 @@ ** ** MsgIdkey - This is a unique numeric key within a mission namespace that is used with ** cFS software bus internal structures. -** It is algorithmically created in a mission defined way from the MsgId to support +** It is algorithmically created in a mission-defined way from the MsgId to support ** efficient lookup and mapping implementations ** It is NOT exposed to user applications. ** @@ -1426,7 +1426,7 @@ int32 CFE_SB_TransmitMsgValidate(const CFE_MSG_Message_t *MsgPtr, CFE_SB_MsgId_t { CFE_MSG_GetSize(MsgPtr, SizePtr); - /* Verify the size of the pkt is < or = the mission defined max */ + /* Verify the size of the pkt is < or = the mission-defined max */ if (*SizePtr > CFE_MISSION_SB_MAX_SB_MSG_SIZE) { PendingEventID = CFE_SB_MSG_TOO_BIG_EID; diff --git a/modules/sb/fsw/src/cfe_sb_priv.c b/modules/sb/fsw/src/cfe_sb_priv.c index a48f77481..e1e4812b7 100644 --- a/modules/sb/fsw/src/cfe_sb_priv.c +++ b/modules/sb/fsw/src/cfe_sb_priv.c @@ -49,7 +49,7 @@ ** ** MsgIdkey - This is a unique numeric key within a mission namespace that is used with ** cFS software bus internal structures. -** It is algorithmically created in a mission defined way from the MsgId to support +** It is algorithmically created in a mission-defined way from the MsgId to support ** efficient lookup and mapping implementations ** It is NOT exposed to user applications. ** diff --git a/modules/tbl/config/default_cfe_tbl_fcncodes.h b/modules/tbl/config/default_cfe_tbl_fcncodes.h index e5da0e13c..c7e387017 100644 --- a/modules/tbl/config/default_cfe_tbl_fcncodes.h +++ b/modules/tbl/config/default_cfe_tbl_fcncodes.h @@ -162,7 +162,7 @@ ** ** \par Description ** This command will cause the Table Services to put the contents -** of the specified table buffer into the command specified file. +** of the specified table buffer into the command-specified file. ** ** \cfecmdmnemonic \TBL_DUMP ** @@ -302,7 +302,7 @@ ** ** \par Description ** This command will cause Table Services to write some of the -** contents of the Table Registry to the command specified file. +** contents of the Table Registry to the command-specified file. ** This allows the operator to see the current state and configuration ** of all tables that have been registered with the cFE. ** @@ -346,7 +346,7 @@ ** ** \par Description ** This command will cause Table Services to telemeter the contents -** of the Table Registry for the command specified table. +** of the Table Registry for the command-specified table. ** ** \cfecmdmnemonic \TBL_TLMREG ** diff --git a/modules/tbl/fsw/src/cfe_tbl_api.c b/modules/tbl/fsw/src/cfe_tbl_api.c index 729bef4d2..991f9c2cf 100644 --- a/modules/tbl/fsw/src/cfe_tbl_api.c +++ b/modules/tbl/fsw/src/cfe_tbl_api.c @@ -85,7 +85,7 @@ CFE_Status_t CFE_TBL_Register(CFE_TBL_Handle_t *TblHandlePtr, const char *Name, } else { - /* Generate application specific table name */ + /* Generate application-specific table name */ CFE_TBL_FormTableName(TblName, Name, ThisAppId); /* Make sure the specified size is acceptable */ diff --git a/modules/tbl/fsw/src/cfe_tbl_internal.c b/modules/tbl/fsw/src/cfe_tbl_internal.c index b127c0189..80348d098 100644 --- a/modules/tbl/fsw/src/cfe_tbl_internal.c +++ b/modules/tbl/fsw/src/cfe_tbl_internal.c @@ -576,7 +576,7 @@ void CFE_TBL_FormTableName(char *FullTblName, const char *TblName, CFE_ES_AppId_ /* Ensure that AppName is null terminated */ AppName[OS_MAX_API_NAME - 1] = '\0'; - /* Complete formation of application specific table name */ + /* Complete formation of application-specific table name */ sprintf(FullTblName, "%s.%s", AppName, TblName); } diff --git a/modules/tbl/fsw/src/cfe_tbl_internal.h b/modules/tbl/fsw/src/cfe_tbl_internal.h index 556394ffa..16a0af8f5 100644 --- a/modules/tbl/fsw/src/cfe_tbl_internal.h +++ b/modules/tbl/fsw/src/cfe_tbl_internal.h @@ -243,14 +243,14 @@ CFE_TBL_Handle_t CFE_TBL_FindFreeHandle(void); ** ** \par Description ** Takes a given raw table name and combines it with the calling -** Application's name to make the application specific name of the +** Application's name to make the application-specific name of the ** form: "AppName.RawTableName" ** ** \par Assumptions, External Events, and Notes: ** AppName portion will be truncated to OS_MAX_API_NAME. ** ** \param[in, out] FullTblName Pointer to character buffer of #CFE_TBL_MAX_FULL_NAME_LEN -** size that will be filled with the application specific name +** size that will be filled with the application-specific name ** of the form "AppName.RawTableName" ** \param[in] TblName Pointer to character string containing the raw table name. ** \param[in] ThisAppId Application ID of the Application making the call. diff --git a/modules/time/config/default_cfe_time_fcncodes.h b/modules/time/config/default_cfe_time_fcncodes.h index 6fe06e1f8..fd636bed4 100644 --- a/modules/time/config/default_cfe_time_fcncodes.h +++ b/modules/time/config/default_cfe_time_fcncodes.h @@ -148,7 +148,7 @@ ** ** \par Description ** This command selects the Time Service clock source. Although the -** list of potential clock sources is mission specific and defined +** list of potential clock sources is mission-specific and defined ** via configuration parameters, this command provides a common method ** for switching between the local processor clock and an external ** source for time data.

@@ -176,7 +176,7 @@ ** following telemetry: ** - \b \c \TIME_CMDPC - command execution counter will increment ** - \b \c \TIME_SOURCE - Diagnostic Telemetry point will indicate the -** command specified value +** command-specified value ** - The #CFE_TIME_SOURCE_EID informational event message will be generated ** ** \par Error Conditions @@ -227,7 +227,7 @@ ** following telemetry: ** - \b \c \TIME_CMDPC - command execution counter will increment ** - \b \c \TIME_STATEFLG - Housekeeping Telemetry point "may" indicate the -** command specified value (see above) +** command-specified value (see above) ** - The #CFE_TIME_STATE_EID informational event message will be generated ** ** \par Error Conditions @@ -270,7 +270,7 @@ ** Successful execution of this command may be verified with the ** following telemetry: ** - \b \c \TIME_CMDPC - command execution counter will increment -** - \b \c \TIME_LATENTS - Housekeeping Telemetry point indicating command specified values +** - \b \c \TIME_LATENTS - Housekeeping Telemetry point indicating command-specified values ** - \b \c \TIME_LATENTDIR - Diagnostic Telemetry point indicating commanded latency direction ** - The #CFE_TIME_DELAY_EID informational event message will be generated ** @@ -308,7 +308,7 @@ ** Successful execution of this command may be verified with the ** following telemetry: ** - \b \c \TIME_CMDPC - command execution counter will increment -** - \b \c \TIME_LATENTS - Housekeeping Telemetry point indicating command specified values +** - \b \c \TIME_LATENTS - Housekeeping Telemetry point indicating command-specified values ** - \b \c \TIME_LATENTDIR - Diagnostic Telemetry point indicating commanded latency direction ** - The #CFE_TIME_DELAY_EID informational event message will be generated ** @@ -570,7 +570,7 @@ ** There was some debate about whether the maximum 1Hz clock drift correction ** factor would ever need to exceed some small fraction of a second. But, the ** decision was made to provide the capability to make 1Hz adjustments greater -** than one second and leave it to the ground system to provide mission specific +** than one second and leave it to the ground system to provide mission-specific ** limits. ** ** \cfecmdmnemonic \TIME_ADD1HZSTCF @@ -616,7 +616,7 @@ ** There was some debate about whether the maximum 1Hz clock drift correction ** factor would ever need to exceed some small fraction of a second. But, the ** decision was made to provide the capability to make 1Hz adjustments greater -** than one second and leave it to the ground system to provide mission specific +** than one second and leave it to the ground system to provide mission-specific ** limits. ** ** \cfecmdmnemonic \TIME_SUB1HZSTCF @@ -652,7 +652,7 @@ ** ** \par Description ** This command selects the Time Service tone signal source. Although the -** list of potential tone signal sources is mission specific, a common +** list of potential tone signal sources is mission-specific, a common ** choice is the selection of primary or redundant tone signal. The selection ** may be available to both the Time Server and Time Clients, depending on ** hardware configuration.

@@ -671,7 +671,7 @@ ** - \b \c \TIME_CMDPC - command execution counter will ** increment ** - \b \c \TIME_SIGNAL - Diagnostic Telemetry point will indicate the -** command specified value +** command-specified value ** - The #CFE_TIME_SIGNAL_EID informational event message will ** be generated ** diff --git a/modules/time/config/default_cfe_time_interface_cfg.h b/modules/time/config/default_cfe_time_interface_cfg.h index 3e614f154..1bef00e77 100644 --- a/modules/time/config/default_cfe_time_interface_cfg.h +++ b/modules/time/config/default_cfe_time_interface_cfg.h @@ -37,7 +37,7 @@ ** ** \par Description: ** The following definitions select either UTC or TAI as the default -** (mission specific) time format. Although it is possible for an +** (mission-specific) time format. Although it is possible for an ** application to request time in a specific format, most callers ** should use CFE_TIME_GetTime(), which returns time in the default ** format. This avoids having to modify each individual caller