See also the FAQ My application does not run, what could be wrong?, noting in particular the recommendation to develop with configASSERT() defined in FreeRTOSConfig.h.
The Xtensa Xplorer project is located in the /FreeRTOS/Demo/Tensilica_Simulator_Xplorer_XCC directory and has the usual Eclipse project name .project.
The RTOS demo project can be configured to build either a simple blinky demo, or a comprehensive test and demo application. The constant mainCREATE_SIMPLE_BLINKY_DEMO_ONLY, which is defined at the top of main.c file, is used to switch between the two.
main_blinky() creates one queue, one software timer, and two tasks. It then starts the RTOS scheduler.
The queue send task is implemented by the prvQueueSendTask() function in main_blinky.c file. It uses vTaskDelayUntil() to send the value 100 to the queue every 200 milliseconds.
The timer is an auto-reload timer with a period of two seconds. The timer's callback function writes the value 200 to the queue. The callback function is implemented by prvQueueSendTimerCallback() within main_blinky.c file.
The queue receive task is implemented by prvQueueReceiveTask() in main_blinky.c file. It waits for data to arrive on the queue. When data is received, the task checks the value of the data, then outputs a message to indicate if the data came from the queue send task or the queue send software timer.
Note this is the only task that outputs a message, so no attempt is made to make the printf function thread safe. Be careful to not use the printf function in more than one tasks.
A 'check' task is created to periodically inspect the standard demo tasks in order to ensure all the tasks are functioning as expected. If no error is detected, the check task periodically outputs "No errors", the current simulated tick time, free heap size and the minimum free heap size so far. If an error is discovered in the execution of a task then the check task will output an appropriate error message.
Note this is the only task that outputs a message, so no attempt is made to make the printf function thread safe. Be careful to not use the printf function in more than one tasks.
Interrupt queue tests (file IntQueue.c) exercise interrupt nesting and are observed to interfere with the proper functioning of other tests on the Simulator. Therefore, the mainENABLE_INT_QUEUE_TESTS macro is provided in the file main_full.c to choose whether to enable interrupt queue tests or all other tests.
void Dummy_IRQHandler( void *arg )
{
long lHigherPriorityTaskWoken = pdFALSE;
( void ) arg; /* Parameter not used. */
/* Clear the interrupt if necessary. */
Dummy_ClearITPendingBit();
/* This interrupt does nothing more than demonstrate how to synchronise a
task with an interrupt. A task notification is used for this purpose. Note
lHigherPriorityTaskWoken is initialised to zero. Only FreeRTOS API functions
that end in "FromISR" can be called from an ISR! */
vTaskNotifyGiveFromISR( xTaskToNotify, &lHigherPriorityTaskWoken );
/* If the task with handle xTaskToNotify was blocked waiting for a notification,
and giving the notification caused the task to unblock, and the unblocked
task has a priority higher than the current Running state task (the task that
this interrupt interrupted), then lHigherPriorityTaskWoken will have been set
to pdTRUE internally within vTaskNotifyGiveFromISR(). Passing pdTRUE into
the portYIELD_FROM_ISR() macro will result in a context switch being pended
to ensure this interrupt returns directly to the unblocked, higher priority,
task. Passing pdFALSE into portYIELD_FROM_ISR() has no effect. */
portYIELD_FROM_ISR( lHigherPriorityTaskWoken );
}
This sets the frequency of the RTOS tick interrupt. The supplied value of 1000Hz is useful for testing the RTOS kernel functionality, but is faster than most applications require. Lowering this value will improve efficiency.
Each port #defines 'BaseType_t' to equal the most efficient data type for that processor. This port defines BaseType_t to be of type int.
Set the definition configUSE_PREEMPTION within 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 selected.
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_4.c is included in the 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 full information.
Note that vPortEndScheduler() has not been implemented.