Last site update June 02 2015
Renesas RX200 Demo
Using the Renesas Compiler and HEW IDE
Renesas RX210 Starter Kit (RSK)
This page documents the Renesas RX210
FreeRTOS port and demo application that uses the Renesas RX compiler,
and HEW IDE. The project is pre-configured to run on the RSKRX210 starter kit.
This demo application demonstrates:
IMPORTANT! Notes on using the Renesas RX200 port and demo application
Please read all the following points before using this RTOS port.
See also the FAQ My application does not run, what could be wrong?
- Source Code Organisation
- The Demo Application
- RTOS Configuration and Usage Details
Source Code Organisation
The HEW workspaces for the RSK development board is called RTOSDemo.hws and is located in the
The FreeRTOS zip file download contains the implementation of all the FreeRTOS ports, and every single official
demo application project. It therefore contains many more files than used by this demo. See the
Source Code Organization section for a description
of the downloaded files and information on creating a new project.
RX210 Demo Application
The project includes three build configurations:
This is a very simple example that creates two tasks and
one queue. The tasks communicate with each other via the queue,
and an LED is toggled on each successful queue receive. The main()
function used by the Blinky build configuration is defined in
main-blinky.c. The main() function used by the other two
build configurations is defined in main-full.c.
This is a very comprehensive demo that creates nearly 50 tasks before
starting the RTOS scheduler, then continuously dynamically creates and
deletes another two tasks as the application executes. It also creates
many queues and different types of semaphore. The tasks consist
mainly of the standard demo tasks - which don't perform any
particular functionality other than testing the port and demonstrating how the FreeRTOS API can be used.
Information on additional tasks that are created is provided immediately below this table.
The Debug build configuration includes standard demo tasks that demonstrate
interrupt nesting, but does not include the high frequency timer interrupt.
This is similar to the Debug build configuration, but includes the
high frequency timer interrupt. The build configuration also has
compiler optimisation turned up to maximum.
The Debug and Debug_with_optimisation build configurations create the following tasks, timers, and tests, in addition to the standard demo tasks:
Check timer and callback function
The Check timer is an example of a very simple watchdog type timer. It monitors
all the other standard demo tasks, and the register test tasks (described below),
and provides visual feedback of the system status using an LED.
The period of the check timer is initially set to five seconds. The check
timer callback function checks that all the standard demo tasks, and the
register test tasks, are not only still executing, but are executing without
reporting any errors, then toggles an LED.
If the check timer discovers that a task has either stalled, or reported an
error, then it changes its own period from the initial five seconds, to just
200ms. Therefore, if the LED toggles every five seconds, no issues have been
discovered, whereas, if the LED toggles every 200ms, an issue has been
discovered in at least one task.
The check timer uses LED marked LED3 on the RSK silkscreen.
Reg test tasks
These two tasks test the RTOS kernel context switch mechanism by first filling
each RX200 register with a known and unique value, then repeatedly checking
that the value originally written to the register is maintained in the
register, for the lifetime of the task. The tasks execute at the lowest
possible priority (the idle priority), so are preempted frequently. The
nature of these tasks necessitates that they are written in assembly.
High frequency timer test
This test configures a timer to generate an interrupt at 20KHz. The interrupt priority is above
configMAX_SYSCALL_INTERRUPT_PRIORITY, so will never
be disabled by the RTOS kernel. The jitter experienced in the interrupt timing is measured and
stored in a variable that can be inspected using the debugger.
Button input interrupts and LCD demo
This demo defines three IRQ interrupt handlers that are triggered by
button presses, a task that controls the top line of the LCD, a task that
controls the bottom line of the LCD, and a queue that is used to communicate
between the interrupt handlers and one of the tasks.
The task that controls the top line of the LCD simply scrolls a message
back and forth, with the scroll direction changing each time the message
reaches the end of the LCD.
The task that controls the bottom line of the LCD acts just like the one
controlling the top line, until button SW2 is pressed. Pressing button
SW2 causes and interrupt to be generated. The interrupt handler uses
the queue to send a command to the task instructing it to halt or restart
the scrolling motion. While the scrolling
is halted, the interrupts generated by pressing buttons SW3 and SW1 result
in commands being sent to the task, on the same queue, instructing the
task to nudge the message left and right respectively, one character at
When executing, the demo application will behave as follows:
LEDs LED0, LED1 and LED2 are under the control of the standard 'flash' tasks. Each will toggle at a fixed but different frequency, with LED0
using the highest frequency, and LED 2 using the lowest.
LED3 is under the control of the 'check' timer. It will toggle every five seconds if all the other tasks are reporting their status as
healthy. It will toggle every 200ms if any task has ever reported an error.
"http://www.FreeRTOS.org" will continuously scroll left to right, then back right to left, along the top line of the LCD.
A long string that describes the features available on the RX210 will scroll left to right, then back right to left,
along the bottom line of the LCD, until button SW2 is pressed. Pressing button SW2 will cause the scrolling to halt, pressing
button SW2 again will start the string scrolling again. While the string is stationary, pressing button SW3 will nudge the string
to the left, one character at a time, and pressing button SW1 will nudge the string to the right, one character at a time.
Building and executing the demo application
Before opening the project - connect the RX210 RSK to the host computer using an E1 FINE interface,
which is provided in the RSK kit. Once connected, apply power to the development board.
Open the FreeRTOS/Demo/RTOSDemo.hws workspace from within the HEW IDE - following the prompts
to connect to the target interface as the project opens.
Select "Build" from the HEW "Build" menu - the demo application should build without any genuine errors or warnings,
although dependency errors are produced as the pre-processor [inexplicable] looks for header files that omitted
from the build by preprocessor directives - these erroneous errors will not effect the build.
When the build has completed, a dialogue box will appear that asks if you want the produced binary to be downloaded to the
RX210 microcontroller - select "yes" to program the flash, and start a debug session. The debugger will break on entry
to the main() function.
FreeRTOS RX200 RTOS port specific configuration
Configuration items specific to this demo are defined in FreeRTOS/Demo/RX200_RX210-RSK_Renesas/RTOSDemo/FreeRTOSConfig.h. The
constants can be edited to suit your application. In particular -
The RX200 port layer #defines 'BaseType_t' to 'long'.
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.
Defines the interrupt priority used for by the tick and yield interrupts
(the RTOS kernel interrupts). configKERNEL_INTERRUPT_PRIORITY should normally be set to
the lowest interrupt priority, which is 1 on an RX200 core. See
the customisation pages for more information.
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 never be disabled by the RTOS kernel. Interrupts that have a priority
above configMAX_SYSCALL_INTERRUPT_PRIORITY are therefore suitable for
functionality that requires very high timing accuracy. The high
frequency timer test included in this demo uses a priority that is above
the configuration pages for more information.
Writing interrupt service routines (ISRs)
Interrupt service routines can be implemented using the standard Renesas compiler
syntax. For example, the demo application defines the high frequency timer using:
/* The 'enable' in the following line causes the compiler to generate code that
re-enables interrupts on function entry. This will allow interrupts to nest
(although in this case the high frequency timer interrupt is the highest priority
interrupt in the demo). */
#pragma interrupt ( prvTimer2IntHandler( vect = _VECT( _CMT2_CMI2 ), enable ) )
static void prvTimer2IntHandler( void )
/* ISR implementation goes here. */
See the examples provided by Renesas and the compiler documentation for full details.
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. This is demonstrated in the code below - which is
part of the RX210 demo, and implemented in
/* The 'enable' in the following line causes the compiler to generate code that
re-enables interrupts on function entry. This will allow interrupts to nest. */
#pragma interrupt ( prvIRQ1_Handler( vect = 65, enable ) )
static void prvIRQ1_Handler( void )
static TickType_t xTimeLastInterrupt = 0UL;
static const unsigned char ucCommand = lcdSHIFT_BACK_COMMAND;
/* prvSendCommandOnDebouncedInput() returns true or false, depending on
whether the function unblocked a task that has equal or higher priority than the task
that is already in the running state. */
xHigherPriorityTaskWoken = prvSendCommandOnDebouncedInput( &xTimeLastInterrupt,
portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
Resources used by FreeRTOS
FreeRTOS requires exclusive use of the software interrupt.
FreeRTOS also requires exclusive use of a timer that is capable of generating the tick interrupt - but
it is up to the application writer to define which timer is used.
The application must define a function called vApplicationSetupTimerInterrupt() to
configure the tick interrupt, then define configTICK_VECTOR to be the interrupt vector
number associated with the chosen timer source.
It is suggested that a compare match timer is used to generate the tick interrupt, and an example
implementation of vApplicationSetupTimerInterrupt() that uses compare match timer 0 is
included in both main-full.c and main-blinky.c in this demo application.
The demo application defines configTICK_VECTOR within FreeRTOSConfig.h to be _CMT0_CMI0 (the compare
match 0 interrupt vector number). The provided example implementations can be used
in any application that does not itself need to use the compare match 0 timer/interrupt.
Switching between the pre-emptive and co-operative RTOS kernels
Set the definition configUSE_PREEMPTION within RTOSDemo/FreeRTOSConfig.h to 1 to use pre-emption or 0
to use co-operative. The full demo application may not execute correctly when the co-operative RTOS scheduler is
As with all the ports, it is essential that the correct compiler options are used. The best way to ensure this is to base your
application on the provided demo application files.
Source/Portable/MemMang/heap_2.c is included in the RX210 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
Note that vPortEndScheduler() has not been implemented.
Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2015 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd..
See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.