|
|||||||||||||||
Infineon TriCore Demo
|
|||||||||||||||
|
mainCREATE_SIMPLE_LED_FLASHER_DEMO_ONLY setting
|
Description
|
| Set to 1 | This creates a very simple example that creates three standard demo "flash" tasks. Each of the three tasks toggles an LED at a fixed but different frequency. LEDs P5.0, P5.1 and P5.2 are used. |
| Set to 0 |
This is a very comprehensive demo that creates 42 tasks before
starting the RTOS scheduler, then continuously dynamically creates and
deletes another two tasks as the application executes.
It creates many queues, software timers and different types of semaphore. The tasks consist mainly of the standard demo tasks. The demo also includes application specific "register test" tasks. These are idle priority tasks that start by filling all the generic processor registers with known values, then repeatedly check that each register maintains its expected value, as it gets swapped in and out, for the lifetime of the task. Each of the two register check tasks uses a different set of known values, and a value being unexpectedly changed is symptomatic of an error in the context switching mechanism. Finally, the demo creates an application specific task to check interrupt nesting functionality. The task uses a high priority, high frequency interrupt, to synchronise with a task using a semaphore. Testing has shown that the test generates a nesting depth that is at least three deep, as it nests with the UART interrupt, that itself nests with the RTOS tick interrupt. In theory, as the UART itself uses two interrupts, an extra level of nesting could also occur. A 'check' task is created that periodically inspects the standard demo tasks, register test tasks, and the interrupt nesting test tasks, to ensure they are all operating as expected. The check task toggles LED P5.7 to give visual feedback of the system status. If LED P5.7 toggles every 5 seconds, then the check task has not discovered any potential problems with the execution of the test/demo application. If the rate at which LED P5.7 toggles increases to every 500 milliseconds, then the check task has discovered a potential problem with the behaviour of at least one task. Like the simple flasher demo, the comprehensive demo creates the standard demo flash tasks, which toggle LEDs P5.0, P5.1 and P5.2 at fixed but different frequencies. |
Hardware setup
The demo application includes tasks that send and receive characters through a UART. The characters sent by one task must be received by another. An error condition is flagged if any character is missing, or received out of order. For this reason, the UART is configured to use its internal loopback mode to ensure that every transmitted character is also received. Two things should be noted about the UART configuration:-
The UART has only ever been used in loopback mode. The baud rate calculation
has never been verified by connecting the UART to external equipment.
- FreeRTOS queues are used to pass characters into, and out of, the UART interrupt handlers. This is a very inefficient implementation if the UART is being used to handle streaming data. It is used in this case to deliberately load the system, and test the operation of the FreeRTOS safe API queue functions in an environment that supports interrupt nesting.
The LEDs used by the demo application are hard wired onto the TriBoard main board, so no explicit hardware setup is required.
Importing, building, and debugging the FreeRTOS demo application
-
Ensure the required tools have been downloaded
and installed.
-
Ensure the FreeRTOS/Demo/TriCore_TC1782_TriBoard_GCC/RTOSDemo/
CreateProjectDirectoryStructure.bat batch file has been executed. -
Start the installed Eclipse for TriCore tool, and create a new Workspace
or select an existing workspace as appropriate. If necessary, proceed to
the Eclipse workbench.
-
Select "Import..." from the File menu.
-
Select "Existing projects into Workspace" from the "General"
category, then click Next.
Selecting "Existing projects into Workspace" -
In the next dialogue, select FreeRTOS/Demo/TriCore_TC1782_TriBoard_GCC
as the root directory, then select "FreeRTOS_Demo" as the project.
Selecting the root directory and project -
Click "Finish" to complete the import process.
-
Right click on the project name in the Eclipse Project Explorer window,
then use the "Build Configurations->Set Active" option from the
pop up menu to select between a build configuration that executes
entirely from RAM, and a build configuration that executes from
the TriCore Flash memory. NOTE: The RAM build configuration
is configured to use size optimisation.
-
To actually build the project, simply select
"Build Project" from the Eclipse Workbench Project menu.
-
Finally, to start a debug session, ensure the TriBoard is powered and correctly
connected via USB a cable to the host computer, then click the "debug"
speed button in the Eclipse IDE.
The debug speed button in the TriCore Eclipse IDE
When executing, the full demo application will behave as follows:
-
LEDs P5.0, P5.1 and P5.2 are under the control of the standard 'flash'
tasks. Each will toggle at a fixed but different frequency, with P5.0
using the highest frequency, and P5.2 using the lowest.
-
LED P5.7 is under the control of the 'check' task. It will toggle every
five seconds if all the other tasks are reporting their status as
healthy. It will toggle every 500ms if any task has ever reported an error.
-
LEDs P5.5 and P5.6 are toggled as characters are transmitted and received
by the standard demo ComTest tasks. The toggle rate will be too fast to
perceive, and the LEDs will appear to be on.
RTOS Configuration and Usage Details
FreeRTOS TriCore RTOS port specific configuration
Configuration items specific to this demo are defined in FreeRTOS/Demo/TriCore_TC1782_TriBoard_GCC/RTOSDemo/FreeRTOSConfig.h. The constants can be edited to suit your application. In particular --
configTICK_RATE_HZ
Sets the frequency of the RTOS tick. The supplied value of 1000Hz is useful for testing the RTOS kernel functionality, but is faster than needed by most applications. Lowering this frequency will improve efficiency.
-
configMAX_SYSCALL_INTERRUPT_PRIORITY
Defines the maximum interrupt priority from which FreeRTOS API functions can be called. Interrupts at or below this priority can call FreeRTOS API functions provided that the API function ends in 'FromISR'. Interrupts above this priority cannot call any FreeRTOS API functions, but will not be disabled by the RTOS kernel (over an above the limitations imposed by the architecture mentioned at the top of this file). Interrupts that have a priority above configMAX_SYSCALL_INTERRUPT_PRIORITY are therefore suitable for functionality that requires very high timing accuracy.
TriCore resources used by FreeRTOS
FreeRTOS uses, and requires exclusive use of:- Interrupt priority 1.
- Interrupt priority 2.
- Syscall trap number 0.
- The frequency at which the system timer (STM) executes.
- The system timer (STM) compare match 0 configuration and interrupt.
Trap handlers
Default trap handlers are defined for unused traps in Demo/TriCore_TC1782_TriBoard_GCC/RTOSDemo/FreeRTOS_Source/portable/GCC/TriCore_1782/portrap.c. The trap handlers are declared as weak functions. This allows an application writer to redefine them within their application code, if desired.
The SysCall trap is used by the RTOS kernel, and defined in port.c.
Writing interrupt service routines (ISRs)
Interrupt service routines (ISRs) are written and installed using the standard facilities provided by the compiler libraries. Examples can be found in serial.c and InterruptNestTest.c.The priorities of the interrupts used by the demo are defined in FreeRTOSConfig.h. Note that interrupt priorities 1 and 2 are used by the RTOS kernel, and must not be used or modified.
Often, an ISR wants to cause a context switch, so the task that the ISR returns to when the ISR processing is completed is different from the task that the ISR originally interrupted. This would be the case if the ISR caused a task to unblock, and the task that was unblocked has a priority above the task in the Running state (the task that was interrupted). The macro portYIELD_FROM_ISR() is provided for this purpose. portYIELD_FROM_ISR() takes a single parameter: If the parameter is zero, a context switch is not performed, if the parameter is non-zero, a context switch is performed. A very simple example of this is found in InterruptNestTest.c, and is replicated below:
static void prvPortHighFrequencyTimerHandler( int iArg )
{
static volatile unsigned long ulExecutionCounter = 0UL;
/* Variable used to determine if a context switch is required. This must be
initialised to pdFALSE (0). */
unsigned long ulHigherPriorityTaskWoken = pdFALSE;
/* Clear the interrupt source. */
STM_ISRR.reg = 1UL << 2UL;
/* Reload the Compare Match register for X ticks into the future.*/
STM_CMP1.reg += ulCompareMatchValue;
/* Note how many times this ISR has executed. */
ulExecutionCounter++;
/* Do the number of executions equal the number expected in a 10ms period? */
if( ulExecutionCounter >= ulInterruptsPer10ms )
{
/* Give the semaphore to unblock the task that is synchronising with
this interrupt. Giving this semaphore will unblock the task, and if the
priority of the unblocked task is above that of the task that is currently
in the Running state (the task that this interrupt interrupted), then
ulHigherPriorityTaskWoken will be set to true within this function call
to indicate that a context switch is required. */
xSemaphoreGiveFromISR( xHighFrequencyTimerSemaphore,
&ulHigherPriorityTaskWoken );
/* Start counting again. */
ulExecutionCounter = 0UL;
}
/* Context switch on exit if necessary. See the comment above the call to
xSemaphoreGiveFromISR() just above. */
portYIELD_FROM_ISR( ulHigherPriorityTaskWoken );
}
Memory allocation
Source/Portable/MemMang/heap_2.c is included in the TriCore demo application project to provide the memory allocation required by the RTOS kernel. Please refer to the Memory Management section of the API documentation for full information.Miscellaneous
Note that vPortEndScheduler() has not been implemented.
NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.
Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019
Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.
View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.
FreeRTOS and other embedded software careers at AWS.
