|
|||||||
 
|
|
FreeRTOS Sponsors
|
|
| Get seen by 1000s of embedded engineers a month | |
|
|
|
|
|
|
|
|
|
Atmel SAM3 RTOS Demo
Using the free Atmel Studio 6 IDE, GCC, and the Atmel Software Framework
[RTOS Ports]
| FreeRTOS is now an integral part of the Atmel ASF driver library for SAM. Click to view the application note. |
Introduction
This page documents the Atmel Studio 6 IDE RTOS demo application that runs on both the SAM3S and SAM3X ARM Cortex-M3 microcontrollers from Atmel. The demo uses the FreeRTOS GCC ARM Cortex-M3 port, and components of the comprehensive Atmel Software Framework (ASF).Two pre-configured projects are provided. One runs on the SAM3S-EK2 evaluation kit, and the other on the SAM3X-EK evaluation kit.
IMPORTANT! Notes on using the FreeRTOS SAM3 demo projects
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
For convenience of distribution, the official FreeRTOS zip file download includes source code files for all the RTOS ports, and all the RTOS demo applications. The projects presented on this page only need a small subset of these files. See the Source Code Organization section for a description of the downloaded files and information on creating a new project.The Atmel Studio 6 Solution file for the ATSAM3S-EK2 demo application is called RTOSDemo.atsln, and is located in the FreeRTOS/Demo/CORTEX_ATSAM3S-EK2_Atmel_Studio directory.
The Atmel Studio 6 Solution file for the ATSAM3X-EK demo application is also called RTOSDemo.atsln, and is located in the FreeRTOS/Demo/CORTEX_ATSAM3X_Atmel_Studio directory.
The Preparing the Project Directory Structure section of this page contains important information on preparing this directory.
The Atmel Studio ARM Cortex-M3 Demo Application
Hardware set up
If mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set to 0 (see the functionality section below), then the demo will include the standard com test tasks. The standard demo com test creates two tasks - a Tx task that sends characters to the USART, and an Rx task that expects to receive every character sent by the Tx task. A loopback connector is required on the USART port for this mechanism to work - simply link pin 2 to pin 3 on the 9 way connector marked "USART" on the SAM3S-EK2 and SAM3X-EK hardware.It should be noted that the com test tasks are included to demonstrate queues being used to communicate between tasks and interrupts, and to demonstrate a context switch being performed from inside an interrupt service routine. The serial driver used is not intended to represent an efficient implementation. Real applications should make use of the USART's peripheral DMA channel (PDC).
Functionality
mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is defined in main.c. The behaviour of the demo depends on its setting.
Functionality with mainCREATE_SIMPLE_BLINKY_DEMO_ONLY set to 1
If mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set to 1 then main() will call main_blinky(). main_blinky() creates a very simple demo as follows:-
The main_blinky() Function:
main_blinky() creates one queue, and two tasks. It then starts the RTOS scheduler.
-
The Queue Send Task:
The queue send task is implemented by the prvQueueSendTask() function in main_blinky.c. It sends the value 100 to the queue every 200 milliseconds.
-
The Queue Receive Task:
The queue receive task is implemented by the prvQueueReceiveTask() function in main_blinky.c. It repeatedly reads from the queue with a block time specified, causing it to enter the Blocked state if the queue is empty. The task toggles the red/orange LED each time the value 100 is received from the queue, therefore, because the queue send task sends to the queue every 200 milliseconds, the queue receive task should exit the Blocked state and toggle the red/orange LED every 200 milliseconds.
Functionality with mainCREATE_SIMPLE_BLINKY_DEMO_ONLY set to 0
If mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set to 0 then main() will call main_full(). main_full() creates a comprehensive test and demo application that demonstrates:- Software timers.
- Queues.
- Mutexes.
- Semaphores.
- A simple interrupt service routine that causes an RTOS task context switch.
main() creates 34 tasks and three software timers before starting the RTOS scheduler. The demo then dynamically and continuously creates and deletes a further two tasks while it is running.
A 'check' software timer is created that periodically inspects the standard demo tasks to ensure all the tasks are functioning as expected. The check software timer's callback function toggles the green LED on the SAM3 development hardware. This gives a visual feedback of the system health. If the green LED is toggling every 3 seconds, then the check software timer has not discovered any problems. If the LED is toggling every 200 milliseconds, then the check software timer has discovered a problem in one or more tasks. This mechanism can be tested by removing the loopback connector, and in so doing, deliberately causing the com test tasks to fail.
Preparing the Project Directory Structure
Atmel Studio requires all the source files built by a project to be located in, or
in subdirectories of, the directory that contains the Atmel Studio project itself.
It is therefore necessary to copy the FreeRTOS
and standard demo source files used by the demo applications from
their locations in the standard FreeRTOS directory structure into the demo
directory. A batch file called CreateProjectDirectoryStructure.bat is provided
for this purpose.
CreateProjectDirectoryStructure.bat is located in the same directory that contains the Atmel Studio 6 solution, and must be executed before the demo application can be built successfully.
Building and executing the demo application
- Ensure the CreateProjectDirectoryStructure.bat batch file has been executed.
- Open either the FreeRTOS/Demo/CORTEX_ATSAM3S-EK2_Atmel_Studio/RTOSDemo.atsln or FreeRTOS/Demo/CORTEX_ATSAM3X_Atmel_Studio/RTOSDemo.atsln (as appropriate) from within the Atmel Studio IDE.
- Open main.c, and set mainCREATE_SIMPLE_BLINKY_DEMO_ONLY to generate either the simply blinky demo, or the full test and demo application, as required.
- Ensure the target hardware is connected to the host computer using a suitable J-Link or SAM-ICE interface. The project was created using a J-Link.
- Select 'Build Solution' from the IDE's 'Build' menu, the RTOSDemo project should build without any errors or warnings.
- After the build completes, select "Start Debug and Break" from the IDE's Debug menu to program the SAM3 microcontroller flash memory, start a debug session, and have the debugger break on entry into the main() function.
RTOS Configuration and Usage Details
ARM Cortex-M3 FreeRTOS port specific configuration
Configuration items specific to this demo are contained in FreeRTOS/Demo/CORTEX_ATSAM3S-EK2_Atmel_Studio/src/FreeRTOSConfig.h or FreeRTOS/Demo/CORTEX_ATSAM3X_Atmel_Studio/src/FreeRTOSConfig.h, depending on the project in use. The constants defined in this file can be edited to suit your application. In particular --
configTICK_RATE_HZ
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 need. Lowering the frequency will improve efficiency.
-
configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY
See the RTOS kernel configuration documentation for full information on these configuration constants.
-
configLIBRARY_LOWEST_INTERRUPT_PRIORITY and configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY
Whereas configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY are full eight bit shifted values, defined to be used as raw numbers directly in the ARM Cortex-M3 NVIC registers, configLIBRARY_LOWEST_INTERRUPT_PRIORITY and configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY are equivalents that are defined using just the 4 priority bits implemented in the SAM3 NVIC. These values are provided because the CMSIS library function NVIC_SetPriority() requires the un-shifted 4 bit format.
Attention please!: See the page dedicated to setting interrupt priorities on ARM Cortex-M devices. Remember that ARM Cortex-M cores use numerically low priority numbers to represent HIGH priority interrupts. This can seem counter-intuitive and is easy to forget! If you wish to assign an interrupt a low priority do NOT assign it a priority of 0 (or other low numeric value) as this will result in the interrupt actually having the highest priority in the system - and therefore potentially make your system crash if this priority is above configMAX_SYSCALL_INTERRUPT_PRIORITY. Also, do not leave interrupt priorities unassigned, as by default they will have a priority of 0 and therefore the highest priority possible.
The lowest priority on a ARM Cortex-M core is in fact 255 - however different ARM Cortex-M microcontroller manufacturers implement a different number of priority bits and supply library functions that expect priorities to be specified in different ways. For example, on Atmel SAM3 ARM Cortex-M3 microcontrollers, the lowest priority you can specify is in fact 15 - this is defined by the constant configLIBRARY_LOWEST_INTERRUPT_PRIORITY in FreeRTOSConfig.h. The highest priority that can be assigned is always zero.
It is also recommended to ensure that all priority bits are assigned as being preemption priority bits, and none as sub priority bits, as they are in the provided demo.
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.
Interrupt service routines
Unlike many FreeRTOS ports, interrupt service routines that cause a context switch have no special requirements, and can be written as per the compiler documentation. The macro portEND_SWITCHING_ISR() can be used to request a context switch from within an interrupt service routine.Note that portEND_SWITCHING_ISR() will leave interrupts enabled.
The following source code snippet is provided as an example. The interrupt uses a semaphore to synchronise with a task (not shown), and calls portEND_SWITCHING_ISR to ensure the interrupt returns directly to the task. See the function USART1_Handler() in the file serial.c included in this demo project for another example.
void Dummy_IRQHandler(void)
{
long lHigherPriorityTaskWoken = pdFALSE;
/* Clear the interrupt if necessary. */
Dummy_ClearITPendingBit();
/* This interrupt does nothing more than demonstrate how to synchronise a
task with an interrupt. A semaphore is used for this purpose. Note
lHigherPriorityTaskWoken is initialised to zero. */
xSemaphoreGiveFromISR( xTestSemaphore, &lHigherPriorityTaskWoken );
/* If there was a task that was blocked on the semaphore, and giving the
semaphore 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 xSemaphoreGiveFromISR(). Passing pdTRUE into the
portEND_SWITCHING_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 portEND_SWITCHING_ISR() has no effect. */
portEND_SWITCHING_ISR( lHigherPriorityTaskWoken );
}
Only FreeRTOS API functions that end in "FromISR" can be called from an interrupt service routine - and then only if the priority of the interrupt is less than or equal to that set by the configMAX_SYSCALL_INTERRUPT_PRIORITY configuration constant (or configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY).
Resources used by FreeRTOS
FreeRTOS requires exclusive use of the SysTick and PendSV interrupts. SVC number #0 is also used.Switching between the pre-emptive and co-operative RTOS kernels
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.Compiler options
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.Memory allocation
Source/Portable/MemMang/heap_4.c is included in the ARM Cortex-M3 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.Miscellaneous
Note that vPortEndScheduler() has not been implemented.
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.