| Latest: FreeRTOS V7.1.1 was released May 1, 2012. View the change history. |
|
|||||||||||||||||
|
Renesas RX62N Demo using GNURX (GCC) and the HEW IDE
|
||||||||||||||||
| Build configuration | Description |
| Blinky | This is a very simple example that just creates two tasks. The tasks communicate via a queue, with an LED being toggled each time an expected value is received from the queue. The Blinky build configuration includes main-blinky.c, the other two build configurations use main-full.c. |
| Debug | This is a much more comprehensive demo that creates nearly 50 demo tasks. A further two tasks are then repeatedly creates and deleted as the application runs. The tasks consist mainly of the standard demo tasks - which don't perform any particular functionality other than testing the port (including interrupt nesting) and demonstrating how the FreeRTOS API is used. Information on additional tasks that are created is provided immediately below this table. |
| Debug_with_optimisation | This is similar to the 'Debug' configuration, but adds a high frequency timer test and tests that the tasks and tests execute correctly when the optimiser is switched on. |
The Debug and Debug_with_optimisation build configurations create the following tasks and tests in addition to the standard demo tasks:
This only executes every five seconds but has the highest priority to ensure it gets CPU time. Its main function is to check that all the standard demo tasks are still operational. The check function maintains a status string that can be viewed at the very bottom of the "Task Stats" page served by the integrated web server. It also toggles LED5 if using the RSK, or LED9 if using the RDK. If the LED controlled by the check task is toggling once every five seconds then all the demo tasks are executing without ever reporting an error. If the toggle frequency increases to once every 200ms then an error has been detected in at least one task.
Some of the tasks check to ensure their own execution timing remains within fixed limits, and with nearly 50 tasks executing these limits can sometimes be breached causing an error to be reported where none really exists. The timing constraints can be put under even more stress when the 20KHz interrupt is running too. Therefore an error being reported is not necessarily indicative of an error in the FreeRTOS port, but just a symptom of a task not getting the CPU time it requires to remain within its tight (self imposed) timing constraints.
This is the task that runs the TCP/IP stack. All network related processing and communication is performed in this task, making the TCP/IP Flash footprint extremely small when compared to other embedded TCP/IP stacks.
These two tasks fill the microcontroller registers with known values before checking that each register still contains the written and expected value. Each of the two tasks use different known values. The tasks run with very low priority so will get preempted very often. If a register ever contains an unexpected value then an error has occurred - probably in the context switching or interrupt mechanism. The reg test tasks write directly into registers and are therefore written in assembly code.
This test configures a timer to generate an interrupt at 20KHz. The interrupt priority is above configMAX_SYSCALL_INTERRUPT_PRIORITY so should not be effected by anything else the kernel is doing. The jitter measured in the interrupt timing is displayed at the bottom of the "Run Time Stats" page served by the integrated web server.
The IP addresses used by the web browser and the RX62N development board must be compatible. This can be ensured by making the first three octets of both IP addresses the same. For example, if the web browser computer uses IP address 192.168.0.1, then the RX62N development board can be given any address in the range 192.168.0.2 to 192.168.0.254 (other than any addresses that already exist on the same network).
The MAC address assigned to the RX62N must be unique on the network to which it is being attached.
The demo application should behave as follows (LED numbers are correct for the RSK, numbers in brackets are correct for the RDK):


The RTOS stats page served by the RX62N web server
showing status information on each task in the system.

The run time stats page served by the RX62N web
server showing the processor utilisation of each task.

The served IO page
The IO page provides a simple interface to permit various LEDs to be turned on and off from a web browser. The LED number will be correct for the RSK only. Changes are sent to the target board whenever the "Update IO" button is clicked.
Other served pages include TCP/IP statistics and a large JPG image. All the web pages are included in the downloaded binary image - which can make the binary image appear to be quite large (the jpg file by itself is in excess of 36K).
This sets the frequency of the RTOS tick. The supplied value of 1KHz is useful for testing the kernel functionality but is faster than most applications need. Lowering this frequency will improve efficiency.
This defines the interrupt priority used by the kernel for the timer and software interrupts. This should always be set to the lowest interrupt priority, which is 1 for the RX62N. See the configuration pages for more information.
This 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 effected by anything the kernel is doing. This makes them suitable for functionality that requires very high temporal accuracy (motor control for example). The high frequency timer test included in the demo application uses a priority that is above configMAX_SYSCALL_INTERRUPT_PRIORITY. See the configuration pages for more information.
/* Function prototype. */
static void prvTimer2IntHandler( void ) __attribute__((interrupt));
/* Function definition. */
static void prvTimer2IntHandler( void )
{
/* ISR implementation goes here. This is the highest priority interrupt in
the demo, so interrupts are just left disabled. */
}
Often an ISR wants to cause a context switch so the task that is returned to when the ISR completes is different to the task that the ISR originally interrupted. This would be the case if the ISR caused a task to unblock, and the unblocked task had a priority above that of the task that was already in the Running state. This can be achieved by calling portYIELD_FROM_ISR(), which takes a single parameter. The parameter must be 0 if a context switch is not required, or non-zero if a context switch is required. This is demonstrated in the code below - which is a handler for a cascaded 8 bit timer 0 and timer 1 compare match interrupt.
/* Function prototype. */
static void vT0_1_InterruptHandler( void ) __attribute__((interrupt));
/* Function definition. */
void vT0_1_InterruptHandler( void )
{
long lHigherPriorityTaskWoken;
/* Enable interrupts to allow interrupt nesting. */
__asm volatile( "SETPSW I" );
/* xFirstTimerHandler() 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. */
lHigherPriorityTaskWoken = xFirstTimerHandler();
portYIELD_FROM_ISR( lHigherPriorityTaskWoken );
}
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 within this demo application. Vects.c (also within the demo application) then installs vTickISR() in the CMTU0_CMT0 vector (offset 0x70). It is suggested that the provided example implementations are used in most cases.