 |
Note: The V4.3.0 version of the IAR Cortex M3 port introduced the 'configKERNEL_INTERRUPT_PRIORITY' configuration parameter. This parameter permits the interrupt priority used by the kernel to be configured such that the kernel activity will never delay a higher priority interrupt. See the Configuration and Usage section of this page for more information.
From FreeRTOS V4.7.1 all IAR projects for ARM devices are saved using the IAR Embedded Workbench V5.x format and will not open from V4.x versions. FreeRTOS V4.7.0 and earlier are still available from SourceForge and can be used with Embedded Workbench V4.x.
Upgrading to FreeRTOS V5.0.3: FreeRTOS V5.0.3 introduced the configMAX_SYSCALL_INTERRUPT_PRIORITY configuration option to the Cortex M3 port. See the kernel configuration documentation for full information on this feature.
Upgrading to FreeRTOS V4.8.0: Prior to V4.8.0 the FreeRTOS kernel did not make use of the SVCall interrupt. From V4.8.0 onwards it does. Therefore, to upgrade an older project to the V4.8.0 standard, a small edit to the startup code is required. To do this, simply install vPortSVCHandler() in the SVCall position within the interrupt vector table (contained in the startup source file). The demo projects included in the FreeRTOS download have already been updated so these can be used as an example.
See also the FAQ My application does not run, what could be wrong?
The IAR workspace file for the STM32F103 demo is called RTOSDemo.eww and is located in the FreeRTOS/Demo/CORTEX_STM32F103_IAR directory.
The demo application uses the LEDs and display built onto the prototyping board so no other hardware setup is required.
A J-Link USB JTAG interface is used to interface the host PC with the target.
The following tasks and tests are created in addition to the standard demo tasks:
A high frequency periodic interrupt is generated using a free running timer to demonstrate the use of the 'configKERNEL_INTERRUPT_PRIORITY' configuration constant. The interrupt service routine measures the number of processor clocks that occur between each interrupt - and in so doing measures the jitter in the interrupt timing. The maximum measured jitter time is latched in the ulMaxJitter variable, and displayed on the LCD display by the 'Check' task as described below. The fast interrupt is configured and handled in the timertest.c source file. This demonstrates how the kernel can be configured so as to have no impact on higher priority interrupt processing.
The Cortex-M3 core has the ability to hasten the entry into an interrupt service routine (and therefore reduce latency) by up to 8 cycles should a high priority interrupt occur while a lower priority interrupt is already being serviced. The measured jitter time should therefore be no more than 8 clock cycles.
The LCD task is a 'gatekeeper' task. It is the only task that is permitted to access the display directly. Other tasks wishing to write a message to the LCD send the message on a queue to the LCD task instead of accessing the LCD themselves. The LCD task just blocks on the queue waiting for messages - waking and displaying the messages as they arrive.
This only executes every five seconds but has the highest priority so is guaranteed to get processor time. Its main function is to check that all the standard demo tasks are still operational. Should any unexpected behaviour within a demo task be discovered the 'check' task will write an error to the LCD (via the LCD task) (this mechanism can be tested by removing the loopback connector on UART0, and in so doing deliberately generating an error). If all the demo tasks are executing with their expected behaviour then the check task writes PASS along with the max jitter time to the LCD (again via the LCD task), as described above.
When executing correctly the demo application will behave as follows:
This sets the frequency of the RTOS tick. The supplied value of 1000Hz is useful for testing the kernel functionality but is faster than most applications require. Lowering this value will improve efficiency.
See the kernel configuration documentation for full information on these configuration constants.
Attention please!: Remember that Cortex M3 cores use numerically low priority numbers to represent HIGH priority interrupts, which can seem counter-intuitive and is easy to forget! If you wish to assign an interrupt a low priority do NOT assign it a priority of 0 (or other low numeric value) as this can result in the interrupt actually having the highest priority in the system - and therefore potentially make your system crash if this priority is above configMAX_SYSCALL_INTERRUPT_PRIORITY.
The lowest priority on a Cortex M3 core is in fact 255 - however different Cortex M3 vendors implement a different number of priority bits and supply library functions that expect priorities to be specified in different ways. For example, on the STM32 the lowest priority you can specify in an ST driver library call is in fact 15 - and the highest priority you can specify is 0. This is defined by the constant configLIBRARY_KERNEL_INTERRUPT_PRIORITY in FreeRTOSConfig.h.
Each port #defines 'portBASE_TYPE' to equal the most efficient data type for that processor. This port defines portBASE_TYPE to be of type long.
Note that vPortEndScheduler() has not been implemented.
Note that portEND_SWITCHING_ISR() will leave interrupts enabled.
