This page presents the FreeRTOS demo for the NEC V850ES 32bit microcontroller.
The demo project contains configurations for:
The V850ES/Fx3 Application Board includes line drivers for numerous serial interfaces along with a limited set of buttons inputs and LED outputs.
The V850ES target boards allow for easy evaluation of the microcontroller by including the microcontroller itself along with the necessary reset, clock, power and debug circuitry on a board that routes all the microcontroller pins to connector mounting points along the edge of the PCB. The target boards themselves have very limited IO capabilities.
See also the FAQ My application does not run, what could be wrong?
The IAR Embedded Workbench workspace for the NEC V850ES demo is called RTOSDemo.eww and can be located within the FreeRTOS\Demo\NEC_V850ES_IAR directory.
| Pin on connector CN24 | Pin on connector CN50/CN51 | |
| 1 | links to | CN51 pin 2 |
| 3 | links to | CN51 pin 4 |
| 5 | links to | CN50 pin 2 |
| 7 | links to | CN50 pin 4 |
The demo application includes an interrupt driven UART test where one task transmits characters that are then received by another task. For correct operation of this functionality a loopback connector must be fitted to the lower 9 way plug on CN 63 (pins 2 and 3 must be connected together on the 9Way connector). Also the low CN63 plug must be linked to microcontroller using jumpers as described in the Application Board User Manual (NEC document number EASE-UM-0019-2.1).
The full demo project creates 32 tasks before starting the scheduler. Most of these tasks consist of the 'standard demo' tasks - the purpose of these tasks is to both demonstrate the RTOS API and test the RTOS port. They do not in themselves perform any other useful function.
In addition to the standard demo tasks the demo creates two 'register test' tasks. These fill the microcontroller registers with known values, then continuously check that each register still contains its expected value - each task using different values. As the tasks run with very low priority they will get pre-empted regularly. A register test task finding an unexpected value in one of its registers is indicative of an error in the pre-emption context switching mechanism.
Finally, a 'check' task is used to give visible feedback of the system status. It only executes every three seconds but has a high priority so is guaranteed to get processing time. Each time it executes it inspects the status of all the other tasks in the system to see if any of them are reporting an error. The check task will toggle an LED every 3 seconds provided all the other tasks are running as expected. The toggle rate will change to 500ms if an error is discovered in any task.
When executing correctly the demo will behave as follows:
The configDATA_MODE configuration constant is specific to the V850ES port. If the compiler options are set to use either the small or large memory model then configDATA_MODE must be set to 0. If the compiler options are set to use the tiny data model then configDATA_MODE must be set to 1.
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.
Often you will require an interrupt service routine to cause a context switch. For example a serial port character being received may unblock a high priority task that was blocked waiting for the character to arrive. If the unblocked task has a higher priority than the current task then the ISR should return directly to the unblocked task. Limitations in the IAR inline assembler necessitate such interrupt service routines use an assembly file wrapper. The UART driver is included in this demo to demonstrate the mechanism. The receive handler is replicated below.
First the assembly file wrapper.
; ISR_Support.h defines the portSAVE_CONTEXT and portRESTORE_CONTEXT
; macros.
#include "ISR_Support.h"
PUBLIC vUARTRxISRWrapper
EXTERN vUARTRxISRHandler
RSEG CODE:CODE
; The wrapper is the interrupt entry point.
vUARTRxISRWrapper:
; The ISR must start with a call to the portSAVE_CONTEXT() macro to save
; the context of the currently running task.
portSAVE_CONTEXT
; Once the context is saved the C portion of the handler can be called.
; This is where the interrupting peripheral is actually serviced.
jarl vUARTRxISRHandler, lp
; Finally the ISR must end with a call to portRESTORE_CONTEXT() to restore
; the context of which ever task is selected to run - which may be
; different to the task that was running before the interrupt started.
portRESTORE_CONTEXT
The C portion of the interrupt handler is just a standard C function.
/* This standard C function is called from the assembly wrapper above. */
void vUARTRxISRHandler( void )
{
portCHAR cChar;
long lHigherPriorityTaskWoken = pdFALSE;
/* Send the received character to the Rx queue. */
cChar = UD0RX;
xQueueSendFromISR( xRxedChars, &cChar, &lHigherPriorityTaskWoken );
/* If sending a character to the Rx queue caused a task to unblock, and
the unblocked task has a priority higher than the currently running task,
then lHigherPriorityTaskWoken will have been set to true and a context
switch should occur now. */
portYIELD_FROM_ISR( lHigherPriorityTaskWoken );
}
The kernel also requires exclusive use of the TRAP 0 instruction.