LM3S9B96SAFERTOS介绍

SAFE RTOS™User’s ManualCopyrightCopyright © 2009 Texas Instruments, Inc. All rights reserved. Stellaris and StellarisWare are registered trademarks of Texas Instruments. ARM and Thumb are registered trademarks, and Cortex is a trademark of ARM Limited. SAFE RTOS is a trademark of Wittenstein Aerospace and Simulation Ltd. Other names and brands may be claimed as the property of others.Texas Instruments108 Wild Basin, Suite 350Austin, TX 78746Main: +1-512-279-8800Fax: +1-512-279-8879SAFERTOS™ is a robust, specialized Real-time Operating System which has been independently certified by the TÜV ashaving been developed in compliance with IEC61508 up to Safety Integrity Level (SIL) 3.WITTENSTEIN high integrity systems is a trading name of WITTENSTEIN Aerospace and Simulation Ltd.SafeRTOS™ User’s ManualTable of ContentsPreface: About this Manual (11)Identification (11)Use in Safety-Related Systems (11)Document Overview (12)Scope (12)Contents (12)Chapter 1: System Overview (13)Summary of the SAFE RTOS Scheduler (13)Differences between SAFE RTOS and OPEN RTOS (13)Design Goals (13)Coding Conventions (14)Project Definitions (14)Naming Conventions (15)System Components (15)Tasks (15)Task Priorities (18)The Scheduler (18)Communication between Tasks and Interrupts (25)Interrupts (25)Chapter 2: Installation (27)Source Code and Libraries (27)Hook Functions (27)Configuration (28)Chapter 3: API Reference (29)Task Functions (29)vTaskInitializeScheduler() (30)xTaskCreate() (32)xTaskDelete() (35)xTaskDelay() (37)xTaskDelayUntil() (39)xTaskPriorityGet() (41)xTaskPrioritySet() (43)xTaskSuspend() (45)xTaskResume() (47)Scheduler Control Functions (49)xTaskStartScheduler() (50)vTaskSuspendScheduler() (51)xTaskResumeScheduler() (53)xTaskGetTickCount() (54)taskYIELD() (55)taskYIELD_FROM_ISR() (56)taskENTER_CRITICAL() (57)Table of ContentstaskEXIT_CRITICAL() (59)Queue Functions (61)xQueueCreate() (62)xQueueSend() (64)xQueueReceive() (66)xQueueMessagesWaiting() (68)xQueueSendFromISR() (69)xQueueReceiveFromISR() (71)Chapter 4: Stellaris® ARM® Cortex™-M3 Processor Core Port-Specific Information (73)Installation (73)C Startup Code (73)Vector Table (73)Execution Context (73)Interrupts (75)Interrupt Entry and Exit (75)Interrupt Priorities and Nesting (75)Interrupt Vectors (75)System Tick Timer (SysTick) (75)RAM Usage (76)SafeRTOS™ User’s ManualList of Code ExamplesCode Example1-1.pdTASK_CODE definition (16)Code Example1-2.Typical structure of a task (16)Code Example1-3. A task deleting itself prior to the function terminating (16)Code ing queues to implement binary semaphores (23)Code ing a gatekeeper task to control access to a resource (23)Code Example1-6.Deferring interrupt processing to the task level (25)Code Example2-1.vApplicationErrorHook() Function Prototype (27)Code Example2-2.vApplicationTaskDeleteHook() function prototype (28)Code Example2-3.vApplicationIdleHook() function prototype (28)Code ing the vTaskInitializeScheduler() API function (30)Code ing the xTaskCreate() API function (33)Code ing the xTaskDelete() API function (35)Code ing the xTaskDelay() API function (37)Code ing the xTaskDelayUntil() API function (40)Code ing the xTaskPriorityGet() API function (41)Code ing the xTaskPrioritySet() API function (44)Code ing the xTaskSuspend() API function (45)Code ing the xTaskResume() API function (48)Code ing the vTaskSuspendScheduler() and xTaskResumeScheduler() API functions (51)Code ing the xTaskGetTickCount() API function (54)Code ing the taskYIELD() API function (55)Code ing the taskENTER_CRITICAL() and taskEXIT_CRITICAL() macros (58)Code ing the xQueueCreate() API function (63)Code ing the xQueueSend() API function (65)Code ing the xQueueReceive() API function (67)Code ing the xQueueMessagesWaiting() API function (68)Code ing the xQueueSendFromISR() API function (70)Code ing the xQueueReceiveFromISR() API function (72)Code Example4-1.Definition of the xPORT_INIT_PARAMETERS Structure (73)Code Example4-2.The ISR (75)List of Code ExamplesSafeRTOS™ User’s ManualList of FiguresFigure1-1.Valid Task State Transitions (17)Figure1-2.Valid Scheduler State Transitions (20)List of FiguresSafeRTOS™ User’s ManualList of TablesTable1-1.Project Definitions (14)Table1-2.Port-Dependent Definitions (14)Table1-3.Naming Conventions (15)Table1-4.Task States (17)Table1-5.Scheduler States (19)Table4-1.Example xPORT_INIT_PARAMETERS Initialization Values (74)List of TablesP R E F A C EAbout this ManualIdentificationThis is the user’s manual for SAFE RTOS™ - a low over head, mini, pre-emptive real timescheduler. SAFE RTOS is pre-programmed into the processor ROM, providing a uniqueway to develop high integrity applications quickly and safely.I ncorporating SAFE RTOS in to an embedded software application permits that applicationto be structured as a set of autonomous tasks. The scheduler selects which task toexecute at any point in time in accordance with the state and relative priority of each task.Chapter1, “System Overview”, elaborates on the states in which a task can exist.This SAFE RTOS User’s Manual contains detailed reference information related to usingSAFE RTOS from ROM.SAFE RTOS is based on the FREE RTOS™ and OPEN RTOS™ code base and can beused either as a general purpose real-time operating system or in a mission criticalenvironment.Use in Safety-Related SystemsSAFE RTOS was developed using a formal and rigorous process. The process wascertified by TÜV SÜD to confirm that it was in compliance with that mandated by IEC61508 [Reference 3] parts 1 and 3 for Safety Integrity Level (SIL) 3 projects. The sameprocesses have been used throughout the SAFE RTOS development.Simply using SAFERTOS in an application does not mean developers can make a claimrelated to the conformance of SAFE RTOS to any requirements or process specification(including IEC 61508 [Reference 3]) without first following a recognized system wideconformance verification process. Conformance evidence must then be presented,audited and accepted by a recognized and relevant independent assessmentorganization. Without undergoing this process of due diligence, no claim can be made asto the suitability of SAFE RTOS to be used in any safety or otherwise commercially criticalapplication.In order to facilitate low risk certification, WITTENSTEIN have developed a DesignAssurance Pack which contains full conformance evidence for SAFE RTOS. The DesignAssurance Pack facilitates certification and speeds and de-risks the use of SAFE RTOS inindustrial, medical and other similar critical applications.In order to obtain the Design Assurance Packs for either IEC61508 (SIL3) or FDA510(k)certification, please contact your local WITTENSTEIN sales representative. Informationcan be found at / or by sending an email toinfo@.Preface - About this ManualDocument OverviewScopeEngineers holding a position of responsibility within a safety or commercially criticaldevelopment team must be adequately trained or have adequate prior experience to fulfilltheir responsibilities competently. It is therefore assumed that readers are alreadyfamiliar with the concepts and development of multitasking embedded systems and thesefundamental concepts are omitted from this manual. The eBook “Using the FreeRTOSReal Time Kernel – A Practical Guide” provides a more introductory text that can bereferenced if required.The ‘’ symbol is used to emphasize instruction or information to which compliance isdeemed to be essential for the correct and safe integration of SAFE RTOS into anapplication.ContentsThe SAFE RTOS User’s Manual is organized into the following chapters:Chapter1, “System Overview,” provides an overview of SAFE RTOS and the description of the SAFE RTOS task, queue, semaphore and scheduling mechanisms.Chapter2, “Installation,” describes the installation and setup required to use SAFE RTOS in your application.Chapter3, “API Reference,” provides the SAFE RTOS API reference.Chapter4, “Stellaris® ARM® Cortex™-M3 Processor Core Port-Specific Information,”provides information on using Stellaris® ARM® Cortex™-M3 Processor Core productvariants.E SSENTIAL C OMPLIANCE I NFORMATIONSAFE RTOS users must not call functions within the SAFE RTOS code base that are not documentedin Chapter3, “API Reference.”C H A P T E R1System OverviewThis chapter provides an overview of SAFE RTOS.Summary of the SAFERTOS SchedulerThe SAFE RTOS pre-emptive real time scheduler has the following characteristics:Any number of tasks can be created – the availability of RAM being the only limiting factor.Each task is assigned a priority between zero and ten, zero being the lowest priority. Source code versions of SAFE RTOS (as opposed to ROMed versions) do not impose restrictions onthe number of priorities available.Any number of tasks can share the same priority – allowing for maximum application design flexibility.The highest priority task that is able to execute (that is, not blocked or suspended) will be the task selected by the scheduler to execute.Tasks of equal priority will each get a share of the processing time available to tasks of that priority. A time sliced round robin policy is used (see “The Scheduling Policy” on page18).Tasks can block for a fixed period.Tasks can block to wait for an absolutespecified time.Tasks can block with a specified time-out period to wait for queue events (either data being written to or read from the queue).Queues can be used to send data between tasks, and to send data between tasks and interrupt service routines (ISR).Semaphores can be used to synchronize tasks with other tasks and to synchronize tasks with interrupt service routines.Semaphores can be used to ensure mutually exclusive access to shared resources. Differences between SAFERTOS and OPENRTOS While SAFE RTOS and OPEN RTOS share many attributes, the development process hasnecessitated some notable differences. In partular SAFE RTOS does not perform anydynamic memory allocation, and SAFE RTOS performs numerious parameter and internaldata validity checks.SAFE RTOS is a statically declared subset of OPEN RTOS. OPEN RTOS to SAFE RTOSconversion instructions are provided in a separate technical note.Design GoalsThe design goal of SAFE RTOS is to achieve its stated functionality using a small, simple,and (most importantly) robust implementation.Chapter 1 - System OverviewCoding ConventionsThis section defines the coding conventions used for the SAFE RTOS API.Project DefinitionsEach C file that utilizes the SAFE RTOS API must include the SAFERTOS.h header. TheSAFERTOS.h header file itslef includes the ProjDefs.h header file which contains the definitions shown in Table 1-1 and Table 1-2.Table 1-1.Project Definitions DefinitionValue pdTRUE aa.The ‘pd’ prefix denotes that the constant is defined within the ProjDefs.hheader file. The ProjDefs.h header file also contains error code definitionsthat begin with the ‘err’ prefix.1pdFALSE0pdPASS1pdFAIL 0Table 1-2.Port-Dependent DefinitionsDefinitionValue portCHARchar (type)portLONGlong (type)portSHORTshort (type)portBASE_TYPEPort-dependent a – defined to be the most efficient data type for the architecture a.Port-dependent values are described in Chapter 4, “Stellaris® ARM® Cortex™-M3 Processor Core Port-SpecificInformation” on page 73.portMAX_DELAYPort-dependent portTickType Port-dependentSafeRTOS™ User’s ManualNaming ConventionsThe following conventions are used throughout the code:Parameter names are prefixed with their type as follows:Historically function names were also prefixed with their return type using the sameconvention. The additional validity checking performed by SAFE RTOS has resulted in nearly all API functions returning a value, and for reasons of portability this value is always of type portBASE_TYPE (prefix ‘x’). It is simpler therefore to consider any function that is prefixed ‘x’ as returning either a status code or a value, and any function that is prefixed ‘v’ (void) as returning no value.API functions are also prefixed with the feature to which they relate, either Task or Queue. For example, the prototype for the API function xTaskGetTickCount(), or xQueueSend().Macro names are written in all uppercase other than a lowercase prefix that indicates in whichheader file the macro is defined. The exception to this rule are the error codes which are prefixed with ‘err’ but contained in the ProjDefs.h header file.System ComponentsTasksIncluding SAFERTOS in your application allows the application to be structured as a set ofautonomous tasks. Each task executes within its own context with no coincidental dependency on other tasks within the system or the scheduler itself.Task FunctionsFunctions that implement a task must be of pdTASK_CODE type, where pdTASK_CODE is defined as shown in Code Example 1-1 with an example of such a function shown inCode Example 1-2.Table 1-3.Naming Conventions Parameter NameType Prefix Variables portCHARc portSHORTs portLONGl portBASE_TYPEx structures, and so onx voidv a a.For example, pointers to void and void functions.Pointers—p b b.For example, a pointer to a short will have the prefix ps, apointer to void will have the prefix pv, and so on.Unsigned variables —u cc.For example, an unsigned short will have the prefix us.Chapter 1 - System OverviewA task will typically execute indefinitely and as such be written as an infinite loop, also shown inCode Example1-2.Code Example1-1pdTASK_CODE definitiontypedef void (*pdTASK_CODE)( void * pvParameters );Code Example1-2Typical structure of a taskvoid vATaskFunction( void *pvParameters ){/* The function executes indefinitely so enter an infinite loop. */for( ;; ){/* -- Task application code goes here. -- */}}A task is created using the xTaskCreate() API function.A task is deleted using the xTaskDelete() API function.E SSENTIAL C OMPLIANCE I NFORMATIONA task function must never terminate by attempting to return to its caller (or by calling exit()) as doingso will result in undefined behavior. If required, a task can delete itself prior to reaching the functionend as shown in Code Example1-3.Code Example1-3A task deleting itself prior to the function terminatingvoid vATaskFunction( void *pvParameters ){for( ;; ){/* -- Task application code here. -- */}/* The task deletes itself (indicated by the NULL parameter) before reaching the end of the task function. */xTaskDelete( NULL );}The void* function parameter permits a reference to any type to be passed into the task when thetask is created. Where more than one parameter is required, a pointer to a structure can be used.See the API documentation for the xTaskCreate() function on page32 for further information. Task StatesOnly one task can be executing at a time. The scheduler is responsible for selecting the task toexecute in accordance with each task’s relative priority and state. A task can exist in one of thestates described by Table1-4, with valid transitions between states shown in Figure1-1 on page17.SafeRTOS™ User’s ManualFigure 1-1.Valid Task State TransitionsTable 1-4.Task States Task StateDescription Running When a task is actually executing it is said to be in the Running state. It is the taskselected by the scheduler to execute and is currently utilizing the processor.Only one task can be in the Running state at any given time.Blocked A task is in the Blocked state if it is waiting for an event. The task cannot continue untilthe event occurs and until that time, it cannot be selected by the scheduler as the task toenter the Running state.Tasks in the Blocked state always have a time-out period, after which the task becomesunblocked.Suspended A task enters the Suspended state when it is the subject of a call to the xTaskSuspend() API function, and remains in the Suspended state untilunsuspended by a call to the xTaskResume() API function. A time-out periodcannot be specified.A Suspended state task cannot be selected by the scheduler as the task to enter theRunning state.Ready A task is in the Ready state if it is able to enter the Running state (it is not in the Blockedor Suspended state), but is not currently the task that is selected to execute.The only tasks that are available to the scheduler for selection as the task to enter theRunning state are those that are in the Ready state.Ready is the initial state when a task is created.Chapter 1 - System OverviewEach task executes within its own context. The process of transitioning one task out of theRunning state while transitioning another task into the Running state is called context switching.A call to the xTaskSuspend() API function can cause a task in the Running state, Blockedstate, or Ready state to enter the Suspended state.Calls to the xTaskDelay() and xTaskDelayUntil() API functions can cause a task in theRunning state to enter the Blocked state to wait for a temporal event – the event being theexpiration of the requested delay period.Calls to the xQueueSend() and xQueueReceive() API functions can cause a task in theRunning state to enter the Blocked state to wait for a queue event – the event being either databeing added to or removed from a queue. “Intertask Communication” on page21 provides moreinformation on using queues.Task PrioritiesA priority is assigned to each task when the task is created.The priority of a task can be queried using the xTaskPriorityGet() API function andchanged by using the xTaskPrioritySet() API function.Low numeric values denote low priority tasks. The lowest priority value that can be assigned to atask is 0.High numeric values denote high priority tasks. The maximum priority that can be assigned to atask is 10 (this restriction applies only when executing SafeRTOS out of ROM).The SchedulerThe scheduler has responsibility for:Deciding which task to select to enter the Running statePerforming the applicable context switchingMeasuring the passage of timeTransitioning tasks from the Blocked state into the Ready state upon the expiration of a time-out periodMeasuring TimeA periodic (tick) timer interrupt is used to measure time. The time between two consecutive timerinterrupts is defined as one tick. All times are measured and specified in tick units.The number of milliseconds between each tick is set using the ulTickRateHz member of thestructure passed to the vTaskInitializeScheduler() API function.The core SysTick timer is used to generate the tick interrupt.The Scheduling PolicyThe scheduler selects as the task to be in the Running state the highest priority task that wouldotherwise be in the Ready state. In other words, the task chosen to execute is the highest prioritytask that is able to execute. Tasks in the Blocked or Suspended state are not able to execute.Different tasks can be assigned the same priority. When this is the case, the tasks of equal priorityare selected to enter the Running state in turn. Each task executes for a maximum of one tickperiod before the scheduler selects another task of equal priority to enter the Running state.SafeRTOS™ User’s ManualNOTE:While the scheduler ensures that tasks of equal priority are selected to enter the Running state in turn, it is not guaranteed that each such task will get an equalshare of processing time.Starting the SchedulerThe scheduler is started using the xTaskStartScheduler() API function. SeeCode Example1-5on page23 for an example usage scenario.At least one task must be created prior to the xTaskStartScheduler() function beingcalled.Calling the xTaskStartScheduler() function causes the creation of the Idle task. The Idletask never enters the Blocked or Suspended state. It is created to ensure there is always at leastone task that is able to enter the Running state. The idle task hook (callback) function can be usedto execute application-specific code within the Idle task.YieldingYielding is where a task volunteers to leave the Running state by re-entering the Ready state.When a task yields, the schedule re-evaluates which task should be in the Running state. If notasks of higher or equal priority to the yielding task are in the Ready state, then the yielding taskwill again be selected as the task to enter the Running state.A task can yield by explicitly calling the taskYIELD() macro, or by calling an API function thatchanges the state or priority of another task within the application.Scheduler StatesThe scheduler can exist in one of the states Table1-5, with valid transitions betweenstates shown in Figure1-2 on page 20.Table1-5.Scheduler StatesScheduler State DescriptionInitialization This is the initial state, prior to the scheduler being started.While in the Initialization state the scheduler has no control over theapplication execution.Tasks and queues can be created while the scheduler is in theInitialization state.Active While in the Active state the scheduler controls the applicationexecution by selecting the task that is in the Running state at anygiven time..Suspended The Scheduler does not perform any context switching while in theSuspended state. The task that was in the Running state when thescheduler entered the Suspended state will remain in the Runningstate until the scheduler returns to the Active state.Chapter 1 - System OverviewFigure1-2.Valid Scheduler State TransitionsThe scheduler enters the Suspended state following a call to thexTaskSuspendScheduler() function, and returns to the Active state following a call to thexTaskResumeScheduler() function.A code section that must be executed atomically (without interruption from other tasks orinterrupts) to guarantee data integrity is called a critical region. The traditional method ofimplementing a critical region of code is to disable and then re-enable interrupts as the criticalregion is entered and then exited respectively. The taskENTER_CRITICAL() andtaskEXIT_CRITICAL() macros are provided for this purpose. Critical sections will only disableinterrupts that have a priority up to and including interrupt priority 5 (a basepri value of 191). Theexecution of interrupts with a higher priority (those with priority 4 to 0) will not be effected by criticalsections.Implementing a critical section through the use of the taskENTER_CRITICAL() andtaskEXIT_CRITICAL() macros has the disadvantage of the application being unresponsiveto interrupts of priority 5 and below for the duration of the critical region. The scheduler suspensionmechanism provides an alternative approach that permits interrupts to remain enabled during thecritical region itself.The xTaskSuspendScheduler() API function places the scheduler into the Suspended state. Whilein the Suspended state a switch to another task will never occur. The task executing the criticalregion is guaranteed to remain as the task in the Running state until the xTaskResumeScheduler()function is called.SafeRTOS™ User’s ManualE SSENTIAL C OMPLIANCE I NFORMATION•Interrupts remain enabled while the scheduler is in the Suspended state. Critical regionsimplemented using the scheduler suspension mechanism therefore protect the critical data from access by other tasks, but not by interrupts. It is safe for an interrupt to access a queue or semaphore while the scheduler is in the Suspended state.•The xTaskSuspendScheduler() API function places the scheduler into the Suspended state. While in the Suspended state a switch to another task will never occur. The task executing the critical region is guaranteed to remain as the task in the Running state until the xTaskResumeScheduler() function is called. It is still desirable for the scheduler not to be held in the Suspended state for an extended period as doing so will reduce the responsiveness of high-priority tasks.Intertask CommunicationSAFE RTOS provides a queue implementation that permits data to be transferred safely between tasks. The queue mechanism removes the need for data that is shared between tasks to be declared globally, or for the application writer to concern themselves with mutual exclusion primitives when accessing the data.The queue implementation is flexible and can be used to achieve a number of objectives, including simple data transfer, synchronization, and semaphore-type behavior.Queue CharacteristicsThe queue is implemented as follows:At any time a queue can contain zero or more items.The size of each item and the maximum number of items that the queue can hold are configured when the queue is created.Items are sent to a queue using the xQueueSend() and xQueueSendFromISR() API functions.Items are received from a queue using the xQueueReceive() and xQueueReceiveFromISR() API functions. Queues are FIFO buffers – that is, the first item sent to a queue using the xQueueSend()(or xQueueSendFromISR()) function is the first item retrieved from the queue when using the xQueueReceive() (or xQueueReceiveFromISR()) function.Data transferred through a queue is done so by copy – the data is copied byte for byte into the queue when the data is sent, and then copied byte for byte out of the queue when the data is subsequently received.Queue EventsData being sent to or received from a queue is called a queue event.When calling the xQueueSend() function, a task can specify a period during which it should be held in the Blocked state to wait for space to become available on the queue if the queue is already full. The task is blocking on a queue event and leaves the Blocked state automatically when another task or interrupt removes an item from the queue.When calling the xQueueReceive() function, a task can specify a period during which it should be held in the Blocked state to wait for data to become available from the queue if thequeue is already empty. Again, the task is blocking on a queue event and leaves the Blocked state automatically when another task or interrupt writes data to the queue.Chapter 1 - System OverviewIf more than one task is blocked waiting for the same event, then the task unblocked upon theoccurrence of the event is the task that has the highest priority. Where more than one task of thesame priority are blocked waiting for the same event, then the task unblocked upon the occurrenceof the event will be the task that has been in the Blocked state for the longest time.Data FormattingThe queue sender and receiver must agree on the meaning of the data placed in the queue. Thiscould be a simple data type, such as a char or long, or a compound data type, such as a structurecontaining a number of complex data items. For example, a structure can be used to hold both adata value and the identity of the task sending the data.If the amount of data requiring transfer in each item is large, then it may be preferable to queue apointer to the data rather than the data itself. This is more efficient as only the pointer value needsto be copied rather than each byte of the data itself.E SSENTIAL C OMPLIANCE I NFORMATIONWhen data is sent to a queue by copy, then the queue implementation ensures access is consistentand mutual exclusion primitives are not required when accessing the data. When data is queued byreference (that is, a pointer to the data is queued rather than the data itself), then each task withaccess to the referenced data must agree how consistent and exclusive access is to be achieved.Using Queues as Binary SemaphoresSemaphores can be used for task to task synchronization, interrupt to task synchronization, and asa means for a task to signal that it wants to have exclusive access to data or other resources. Inthe latter case, while the task has the semaphore, other tasks know they are excluded fromaccessing the protected resource.To be permitted access to the resource, the task must first take the semaphore, and when it hasfinished with the resourc, it must give the semaphore back. If it cannot take the semaphore, itknows the resource is already in use by another task and it must wait for the semaphore tobecome available. If a task chooses to enter the Blocked state to wait for a semaphore, it willautomatically be moved back to the Ready state as soon as the semaphore is available.A binary semaphore can be considered to be a queue that can contain, as a maximum, one item.For efficiency, the item size can be zero, thus preventing any data from actually being copied intoand out of the queue. The important information is whether or not the queue is empty or full (theonly two available states as it can only contain one item), not the value of the data it contains.When the resource is available, the queue (representing the semaphore) is full. To take thesemaphore, the task simply receives from the queue which results in the queue being empty. Togive the semaphore, the task simply sends to the queue which results in the queue again beingfull. If, when attempting to receive from the queue, it finds the queue is already empty, a taskknows it cannot access the resource and can choose whether or not it wishes to enter the Blockedstate to wait for the resource to become available again.Code Example1-4 provides an example semaphore function that creates, takes, andgives that uses the SAFE RTOS queue implementation. See Chapter3, “API Reference”on page 29 for more information on the API functions used (xQueueCreate(),xQueueReceive(), and xQueueSend()). Macros are also provided to hide theunderlying mechanism.。