|
|||||||||||||||
ColdFire V2 RTOS and TCP/IP Demo
|
|||||||||||||||
|
The FEC driver is implemented using an efficient 'no copy' mechanism, meaning the data remains in a single buffer all the way up the TCP/IP stack, and back down again.
The top of each served web page includes a menu containing a link to every other page.
 The IO page
|
The task stats page
Building and executing the demo application
A 'standard make' Eclipse project is used. This means the files to build and the build options are detailed within a standard makefile which can be viewed and edited using the Eclipse IDE. The optimisation level is set by the OPTIM definition at the very top of the makefile.
- To build the demo application:
- Ensure you have the CodeSourcery compiler correctly installed, and that the compilers bin directory is included within your host systems PATH environment variable.
- Ensure you have installed and configured Eclipse exactly as described in these instructions.
-
Start the Eclipse workbench IDE - at which point you will be prompted for a workspace location.
The Eclipse workspace for the ColdFire MCF52233 Eclipse demo is contained in the FreeRTOS/Demo/ColdFire_MCF52233_Eclipse directory. This is therefore the directory that should be selected when Eclipse asks you for a workspace location, as depicted below.
Opening the Eclipse workspace - obviously use the path that is correct for your installation, which might not be the same as that shown here - Make sure you set the "FreeRTOS_ROOT" variable to point to your FreeRTOS installation (again, this is described here).
- Select "Build All" from the Eclipse "Project" menu item. The demo should build with no errors, although the const structures that define the web page content within httpd-fsdata.c will generate 4 or 5 identical warnings - this is unfortunately unavoidable.
- To program the Coldfire Flash memory:
- Ensure the P&E Micro USB connector on the M52233DEMO hardware is correctly connected to your host computer.
- Start the CF Flasher utility.
- Click the "Target Configuration" button, then ensure the configuration is set as per the image below.
The required CF Flasher target configuration settings - Next click the "Program" button in the CF Flasher utility to reveal the Program window. Select the file FreeRTOS/Demo/ColdFire_MCF52233_Eclipse/RTOSDemo/bin/RTOSDemo.s19, then click the "Program" button within the Program window.
- Wait until the flash programming has completed, then close the CF Flasher utility. The utility must be closed for the debugger to function correctly.
- To run the demo application (with the M52233DEMO hardware still connected to your host computer, and the flash memory already programmed):
-
Press the down arrow next to the speed button that shows a little bug, then select RTOSDemo from the menu.
Launching the RTOSDemo debug sessionYou should be taken to the Eclipse Debug perspective, if you were not already there.
Once loaded the program should break on entry to main(). The Eclipse IDE can then be used to step through the code, view variables, view memory, etc, just as any other debug IDE.
Manually remove the breakpoint at main() as a new break point will be added each time a debug session is started.
-
Press the down arrow next to the speed button that shows a little bug, then select RTOSDemo from the menu.
The WITTENSTEIN provided FreeRTOS Eclipse Plug-in can be used to view task and queue state information:
Using the FreeRTOS Eclipse plug-in viewer
Configuration and Usage Details
RTOS port specific configuration
Configuration items specific to this demo are contained in FreeRTOS/Demo/ColdFire_MCF52233_Eclipse/RTOSDemo/FreeRTOSConfig.h. The constants defined in this file can be edited to suit your application. In particular -- configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY
See the interrupt configuration section of the RTOS kernel configuration documentation for full information on these options.
configKERNEL_INTERRUPT_PRIORITY sets the interrupt priority used by the RTOS kernel itself. configMAX_SYSCALL_INTERRUPT_PRIORITY sets the highest interrupt priority from which queue and semaphore API functions can be called (note that only API functions that end in FromISR() can be called from within an ISR).
configKERNEL_INTERRUPT_PRIORITY should be set to the lowest priority.
Interrupts above configMAX_SYSCALL_INTERRUPT_PRIORITY will not be masked out by RTOS kernel critical sections and will therefore be unaffected by RTOS kernel activity - within the limitations imposed by the hardware itself.
By way of demonstration, the demo application defines configMAX_SYSCALL_INTERRUPT_PRIORITY to be 4 and configKERNEL_INTERRUPT_PRIORITY to be 1.
Each port #defines 'BaseType_t' to equal the most efficient data type for that processor. This port defines BaseType_t to be of type long.
Note that vPortEndScheduler() has not been implemented.
Writing interrupt service routines
The CodeSourcery libraries populate the interrupt vector table with default handlers - each of which is called __cs3_isr_interrupt_xx(), where 'xx' is the vector number. You can override the default handler by simply providing your own definition of the handler function. For example, the UART1 peripheral uses vector number 78 - to provide your own UART1 handler simply provide your own definition of a function called __cs3_isr_interrupt_78().Interrupt service routines have no special requirements and can be written as per the compiler documentation. The macro portEND_SWITCHING_ISR() can be used to ensure an interrupt always returns to the highest priority ready state task - tasks can be unblocked by an ISR so the highest priority ready task at the end of an ISR might be different to the highest priority ready/running task when the ISR was entered.
The FEC interrupt within the MCF52233 demo can be used as an example. Listing 1 below provides another example:
/* The function prototype must use the 'interrupt' attribute.*/
void __attribute__( ( interrupt ) ) __cs3_isr_interrupt_78( void );
Next provide the ISR function, with the correct vector number in the name.
NOTE: This is NOT intended to be an example of an efficient ISR. It is provided
only to demonstrate using queues from within interrupts. Great efficiency
improvements would be gained by simply placing received characters in a RAM
buffer, then using a single write to a semaphore to unblock a task if required.
void __cs3_isr_interrupt_78( void )
{
unsigned char ucChar;
BaseType_t xHigherPriorityTaskWoken = pdFALSE, xDoneSomething = pdTRUE;
while( xDoneSomething != pdFALSE )
{
xDoneSomething = pdFALSE;
/* Does the tx buffer contain space? */
if( ( MCF_UART1_USR & MCF_UART_USR_TXRDY ) != 0x00 )
{
/* Are there any characters queued to be sent? */
if( xQueueReceiveFromISR( xCharsForTx, &ucChar, &xHigherPriorityTaskWoken )
== pdTRUE )
{
/* Send the next char. */
MCF_UART1_UTB = ucChar;
xDoneSomething = pdTRUE;
}
else
{
/* Turn off the Tx interrupt until such time as another character
is being transmitted. */
MCF_UART1_UIMR = serRX_INT;
xTxHasEnded = pdTRUE;
}
}
/* Any characters in the receive buffer? */
if( MCF_UART1_USR & MCF_UART_USR_RXRDY )
{
/* Queue the character for processing by a task? */
ucChar = MCF_UART1_URB;
xQueueSendFromISR( xRxedChars, &ucChar, &xHigherPriorityTaskWoken );
xDoneSomething = pdTRUE;
}
}
/* Finally we call portEND_SWITCHING_ISR(). This ensures that the interrupt
returns to the highest priority ready task - which may not be the currently running
task if reading from or writing to a queue causes a task of higher priority to
unblock. */
portEND_SWITCHING_ISR( xHigherPriorityTaskWoken );
}
Resources used by the RTOS kernel
The RTOS kernel uses the PIT0 timer to generate the RTOS tick. The function vApplicationSetupInterrupts() can be altered to use any convenient timer source.In RTOS addition the RTOS kernel requires one additional interrupt vector. As delivered vector 16 on interrupt controller 0 is used as on the MCF52233 vector 16 is not used by any peripherals and is therefore spare. The RTOS kernel uses this vector in conjunction with the Interrupt Force Register 0 (INTFRCL0). For reasons of efficiency the RTOS kernel assumes it has exclusive access to this register and therefore does not attempt to maintain its state - although this behaviour can be easily altered by using bitwise sets and clears on the register rather than writing to the register in its entirety.
To allow users the flexibility to change vector assignments both the PIT0 and vector 16 configuration is performed in a file called FreeRTOS_tick_setup.c which is included as part of the user application, rather than part of the fixed RTOS kernel code.
Critical sections
Exiting a critical section will always set the interrupt priority such that all interrupts are enabled, no matter what its level when the critical section was entered. FreeRTOS API functions themselves will use critical sections.Execution context
For reasons of efficiency, tasks run with Supervisor privileges.Switching between the pre-emptive and co-operative RTOS kernels
Set the definition configUSE_PREEMPTION within FreeRTOS/Demo/ColdFire_MCF52233_Eclipse/RTOSDemo/FreeRTOSConfig.h to 1 to use pre-emption or 0 to use co-operative. The demo application will only execute correctly with configUSE_PREEMPTION set to 0 if configIDLE_SHOULD_YIELD is set to 1.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_2.c is included in the ColdFire 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.
NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.
Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019
Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.
View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.
FreeRTOS and other embedded software careers at AWS.
