Please note: From FreeRTOS.org V5.1.0 the demo presented on this page has switched from using the old (and discontinued) Keil DKARM compiler to instead use the latest Keil/RVDS/ARM compiler.
The port was developed on an MCB2100 development/prototyping board (instructions are provided should you wish to use an alternative development board) using a ULINK USB JTAG adapter. The Keil simulator also proved very useful. A complete development kit can be obtained from Hitex Development Tools.
The MCB2100 is a fully featured and comprehensive prototyping board that allows easy access to the LPC2129 peripherals and includes 8 built in LEDs which are utilised by the FreeRTOS demo application.
The development tools include a compiler, assembler and linker tool chain along with an IDE and excellent device specific simulator. The simulator includes a 'logic analyzer' feature that can be used to monitor the microcontroller IO - providing the same visual feedback in the simulated environment that the LEDs do on the real target hardware. Unfortunately the evaluation version of the tools are limited to a combined ROM and RAM image size of 16KBytes - which is too restrictive to run this demo (because the FreeRTOS.org heap memory is included in the 16KBytes, even if it is not being used).
See also the FAQ My application does not run, what could be wrong?
The uVision project file for this demo is called RTOSDemo.Uv2 and can be located in the Demo/ARM7_LPC2129_Keil_RVDS directory.
The project contains two configurations, one that uses the ARM instruction set and one that uses the THUMB instruction set.
The demo application uses the LEDs built into the prototyping board so no other hardware setup is required.
LED P1.23 is under control of the 'Check' task. Every three seconds the 'Check' task examines all the tasks in the system to ensure they are executing without error. It then toggles LED P1.23. If LED P1.23 is toggling every three seconds then no errors have ever been detected. The toggle rate increasing to 500ms indicates that the 'Check' task has discovered at least one error. This mechanism can be checked by removing the loopback connector from the serial port and in doing so deliberately generating an error.
The red green and blue lines show pins P1.16, P1.17 and P1.18 respectively under control of the 'Flash' tasks. The black line shows pin P1.19 which is toggled each time a character is transmitted. You would need to zoom much closer in to see the line being toggled for each individual transmitted character.
When being simulated the 'Check' task will find an error in the 'ComTest' tasks. This is because the 'ComTest' tasks require a loopback connector as described previously.
The flash must be programmed before the JTAG debugger can be used.
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.
An interrupt service routine that cannot cause a context switch has no special requirements and can be written as per the normal RVDS syntax. Interrupt service routines that can cause a context switch require an assembly file wrapper, as demonstrated below.
;To define an interrupt service routine first we need an assembly file wrapper.
;The wrapper is installed in the interrupt controller as the interrupt entry
;point.
;portmacro.inc must be included within the assembly file as this defines
;the portSAVE_CONTEXT and portRESTORE_CONTEXT macros.
INCLUDE portmacro.inc
;Here the C portion of the handler is imported so it can be called from this
;assembly file. The asm wrapper is exported so it can be installed in the
;interrupt controller.
IMPORT vUART_ISRHandler
EXPORT vUART_ISREntry
;Interrupt entry must always be in ARM mode.
ARM
AREA |.text|, CODE, READONLY
PRESERVE8
;Define the interrupt entry point.
vUART_ISREntry
;portSAVE_CONTEXT must be the first thing called in the wrapper.
portSAVE_CONTEXT
;The rest of the interrupt functionality can be implemented in a standard C
;function. Call the function now.
LDR R0, =vUART_ISRHandler
MOV LR, PC
BX R0
;Finish off by restoring the context of the task that has been chosen to
;run next - which might be a different task to that which was originally
;interrupted.
portRESTORE_CONTEXT
END
See the file Demo/ARM7_LPC2129_Keil_RVDS/serial/serialISR.s within the demo application for a full example.
The assembly file wrapper calls a C function (in the example above the C function is called vUART_ISRHandler()) in which the main interrupt functionality can be implemented. The C function has no special requirements and does not need any special function qualifiers. See the function vUART_ISRHandler() within Demo/ARM7_LPC2129_Keil_RVDS/serial/serial.c for a full example. vUART_ISRHandler() also demonstrates the portEXIT_SWITCHING_ISR() macro, which is used to ensure the correct task is selected to run once the interrupt exits.
NOTE! : The processor MUST be in supervisor mode when the scheduler is started (vTaskStartScheduler is called). The demo applications included in the FreeRTOS.org download switch to supervisor mode prior to main being called. If you are not using one of these demo application projects then ensure Supervisor mode is entered before calling vTaskStartScheduler().
Interrupt service routines always run in ARM mode.
Demo/ARM7_LPC2129_Keil_RVDS/Startup.s configures stacks for system/user, IRQ and SWI modes only.
SWI instructions are used by the real time kernel and can therefore not be used by the application code.
Any and all data, files, source code, html content and documentation included in the FreeRTOS distribution or available on this site are the exclusive property of Richard Barry.
See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Richard Barry.