CodeWarrior project window showing the RTOSDemo source files
Thanks to Uri Kogan for providing the original MC9S12DP256B port.
From FreeRTOS V3.1.1 the HCS12 port supports both the small and banked memory models. This page demonstrates the usage of the banked memory model on an MC9S12DP256B processor. See the MC9S12C32 RTOS port page for an example that uses the small memory model.
The port was developed on a M68KIT912DP256 development kit from Freescale (instructions are provided should you wish to use an alternative development board). It uses the CodeWarrior HC12 Development Tools from Metrowerks and a P&E Multilink USB BDM interface - both of which are included in the development kit.
As downloaded this demo application does not demonstrate the use of co-routines. See the co-routine documentation page for information on how co-routine functionality can be quickly added to this demonstration.
See also the FAQ My application does not run, what could be wrong?
The HCS12 CodeWarrior banked memory model demo application project file is located in the FreeRTOS/Demo/HCS12_CodeWarrior_banked directory and is called RTOSDemo.mcp.
The demo application utilises the LEDs built onto the prototyping board.
When executing correctly the demo application will behave as follows:
LED D7 is under control of the 'Check' task. Every three seconds the 'Check' task examines all the tasks in the system to ensure they are executing without error. It then toggles LED D7. If LED D7 is toggling every three seconds then no errors have ever been detected. The toggle rate increasing to 500ms indicates that the 'Check' task has discovered at least one error.
The project was originally created using the UNIS Processor Expert configuration utility - resulting in a lot of automatically generated files and folders being included in the project. The FreeRTOS real time kernel source files are contained in the 'Source->Kernel Source' project folder, highlighted in red in the diagram below. The demo application source files are contained in the 'Source->RTOS Demo' project folder highlighted in green in the diagram below.
The demo application project contains two build configurations:
To simulate the RTOSDemo project first select the 'Simulator' configuration from the drop down list highlighted in blue within the diagram above. Following a successful build selecting Debug from the Project menu will automatically open the simulator and start a debug session.
The project can be executed and debugged directly on the HCS12 microcontroller using the USB BDM interface. To start a remote debugging session first select 'P&E ICD' from the drop down list highlighted in blue within the diagram above. Following a successful build selecting Debug from the Project menu will automatically load the program into the microcontroller flash memory and start a debug session (assuming you have the target board powered and connected using the provided USB cable!).
To use the banked memory model:
Please note: The RTOSDemo.mcp project defines most memory banks as being only 256 bytes long. This is done solely to force code to reside in different banks, and therefore test the kernel bank switching code. Users should modify this memory map as necessary for their applications.
Each port #defines 'portBASE_TYPE' to equal the most efficient data type for that processor. This port defines portBASE_TYPE to be of type char.
Note that vPortEndScheduler() has not been implemented.
An interrupt service routine that does not cause a context switch has no special requirements and can be written as per the normal CodeWarrior syntax.
Often you will require an interrupt service routine to cause a context switch. For example a serial port character being received may wake a high priority task that was blocked waiting for the character. If the ISR interrupted a lower priority task then it should return immediately to the woken task. A macro portTASK_SWITCH_FROM_ISR() is provided to permit this functionality. Note that portTASK_SWITCH_FROM_ISR() should only ever be used at the very end of an ISR and only when the ISR does not declare any non static local variables. If the ISR does use local variables then a call to portYIELD() can be used in place of the portTASK_SWITCH_FROM_ISR() macro.
As an
example here is the function vButtonPush() from the demo application:
/* ISR connected to PP0 button input. */
void interrupt vButtonPush( void )
{
static unsigned portBASE_TYPE uxValToSend = 0;
/* Send an incrementing value to the button push
task each time the button is pushed. */
uxValToSend++;
/* Clear the interrupt flag. */
PIFP = 1;
/* Send the incremented value down the queue. The
button push task is blocked waiting for the data.
As the button push task is high priority it will
wake and a context switch should be performed before
leaving the ISR. */
if( xQueueSendFromISR( xButtonQueue, &uxValToSend, pdFALSE ) )
{
/* Posting the message caused a higher priority
task to unblock. This is the end of the ISR so
we can perform the task switch here. This can be
used as the only local variable is static. */
portTASK_SWITCH_FROM_ISR();
}
}
See the interrupt function vCOM0_ISR() within FreeRTOS/Demo/HCS12_CodeWarrior_banked/serial/serial.c for a full example that uses local stack variables.
FreeRTOS/Source/Portable/MemMang/heap_2.c is included in the HCS12 demo application project to provide the memory allocation required by the real time kernel. Please refer to the Memory Management section of the API documentation for full information.
Copyright (C) 2010 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOS.org 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..