<<< | >>>

ColdFire RTOS Implementation

Phase 4: Preemptive Multitasking

1. Setting up a timer to generate RTOS ticks,
2. Writing an interrupt handler to handle the RTOS tick events, and
3. Modifying context-switching code to work in this new situation.

Timers

The MCF5272 platform supports up to four general-purpose timers. Timers are set up by specifying a reference number which is the number of ticks from the system clock that should be counted before an interrupt from the timer is sent. At this point the count may restart or continue counting. This is determined by the free-run bit (FRR) of the corresponding timer mode register (TMRx).

However, the reference number is a 16-bit number giving a maximum count of 65,635. As the system clock runs at 66MHz, this gives a maximum timer period of approximately 1ms (i.e. frequency 1kHz). This may not be sufficient for some applications and so a clock prescaler is provided. The prescaler divides the clock input by a given value effectively allowing for a longer period. For example, by setting the prescaler value to 2, the clock value would be halved before comparing to our reference value. This would shift our timer frequency range to 500Hz - 33MHz (instead of 1kHz - 66MHz).

We have used the first timer (TMR0) for our RTOS tick and set the prescaler to 131 giving us a tick frequency of approximately 8Hz - 500kHz. The other fields and their values are described below. These figures are based on the MCF5272 datasheet.

Timer Mode Register

The other registers used in setting up the timer are as follows:

TRR0 Timer Reference Register:
This register simply contains the 16-bit reference number to which the (prescaled) clock count should be compared. For example, if a tick frequency of 1kHz was required, this number should be set to 66MHz (system clock frequency) / 1kHz (desired tick frequency) / 128 (prescaler value), i.e. 516.

TCAN0 Timer Capture Register:
This register is used to store the current value of the count when an external capture event occurs (e.g. for timing an external event). As we are not using external capture events this register can be ignored.

TCN0 Timer Counter:
This register stores the 16-bit value of the counter which is compared to the value in the reference register. We do not need to use this register directly, except perhaps to clear it when setting up the timer.

TER0 Timer Event Register:
This register reports recognised events. For example, when the counter reaches the reference value, the REF bit of the TER0 register is set. We do not need to use this register directly, except perhaps to clear it at startup.

Interrupt handling and modifying the context-switching code

Having registered an interrupt handler for the TMR0 interrupt source our task was to write the handler such that when it returned, a different task was resumed as determined by the FreeRTOS� scheduler. This involved putting a different exception stack frame on the top of the stack before issuing the RTE instruction. Accommodating such a change would have implications on the cooperative context-switching code. For example, when generating the initial context for a task we can not know in advance if that context would be loaded in a cooperative context-switch or a preemptive context-switch. Consequently we carefully analysed the situation and revised the cooperative context-switching code.

We decided to use the RTE instruction to return from all context switches and therefore to generate an exception stack frame both for the initial stack and for cooperative context-switches. The changes to the initial stack and restore context code are shown in Table 2.

There are two basic changes in this diagram. The first change is the inclusion of the extra value on the stack 0x41142000. This is the first longword of the exception stack frame as shown in Figure 3.

Figure 3 - Exception stack frame form.

The value 0x41142000 corresponds to an exception generated by the TMR0 interrupt where the status register indicates the interrupts are enabled and the supervisor mode is set (also Format is set to 4 and FS is set to 0).

The other change shown in Table 2 is that the status register is no longer on the stack. This is because it is included in the exception stack frame. This is fine for preemptive context-switches because the MCF5272 will automatically generate an exception stack frame with the values of the status register (thereby addressing the problem we identified earlier where the status register might not be saved correctly if we shuffle it in and out of a data register first) however for cooperative context-switches we need to generate our own exception stack frame. To achieve this, the yield function was modified as shown in Table 3.

portSAVE_CONTEXT();
vTaskSwitchContext();
portRESTORE_CONTEXT();

asm volatile ("rts");

/* Save status register but
 * reenable interrupt.s */
asm volatile ( "move.l %%d1,-8(%%sp) nt" 
  "clr.l %%d1 nt"          
  "move.w %%sr,%%d1 nt"    
  "ori.l %0,%%d1 nt"       
  "andi.l %1,%%d1 nt"      
  "move.l %%d1,%%sp@- nt"  
  "move.l -4(%%sp),%%d1nt" 
  : /* no output */          
  : "n" (EXSF_FORMAT(4) |  EXSF_VECTOR(VECTOR_TMR0)), 
    "n" (~STATUS_I(7)) );

portSAVE_CONTEXT();
vTaskSwitchContext();
portRESTORE_CONTEXT();

asm volatile ("rte");

Disabling Interrupts

Unlike many microprocessors, the MCF5272 does not have instructions for enabling and disabling interrupts. Instead, interrupts are enabled or disabled by setting the interrupt level bits in the status register (SR). Bits 10-8 of the status register set the interrupt priority mask which determines which interrupt requests are serviced. If the value is set to binary 111, then all interrupts are serviced but if the value is set to binary 000, then all interrupt requests are inhibited, effectively disabling the interrupts.

The SimpleOS disables and enables interrupts with the following instructions:

#define enable_interrupts() asm("move #0x2000,%sr")
#define disable_interrupts() asm("move #0x2700,%sr")

The value 0x2700 corresponds to setting the interrupt to the minimum level and setting the supervisor mode bit.

For simply enabling and disabling interrupts we have used the same approach. For critical sections of code however we have defined a slightly more complicated macro which leaves the remaining bits of the status register untouched as shown in Code Extract 2.

#define portENTER_CRITICAL() asm volatile ( 
  "move.w %%sr,%%d1     nt" 
  "ori.l #0x700,%%d1    nt" 
  "move.w %%d1,%%sr"          
   : : : "d1" );
#define portEXIT_CRITICAL() asm volatile ( 
  "move.w %%sr,%%d1     nt" 
  "andi.l #0xF8FF,%%d1  nt" 
  "move.w %%d1,%%sr"          
  : : : "d1" );

Frame Pointers:
During this phase we decided to address more thoroughly the issue with frame pointers that we had identified in the previous phase. Our solution was to include a define in the makefile which would indicate if frame pointers were included. Based on this we could manually remove the frame pointer from the stack when saving the process context. For example, we have inserted the code in Code Extract 3 at the start of the vPortYield function before the call to save the context.

  /* As the naked attribute is not
   * supported for m68k we need to
   * reverse the effects of the
   * function prologue by removing
   * the frame pointer. */
#ifndef OMIT_FRAME_POINTER
  asm volatile ( "unlk %fp" );
#endif

The compiler also puts a frame pointer on the stack when interrupt handlers are called and so a similar modification was required there. The interrupt handler was also modified so that context saving and restoring was performed directly within the handler function (rather than in a called function). This reduced some of the complexity in removing frame pointers.

Reentrancy in Newlib functions: Preemptive context switches may occur during calls to Newlib functions. Although the Newlib functions are reentrant, some functions require additional support in terms of defining a reentrancy block for each execution thread. This can be performed either by the application or the real time operating system . We investigated implementing this in our port of the FreeRTOS� although it appeared impossible to achieve without changing common FreeRTOS� code because there is no possibility of freeing the reentrancy block when the task is terminated. Hence, it is necessary for the application to provide its own reentrancy block. We suggest that a future enhancement to FreeRTOS� could be to define a port-specific function to be called when a task is terminated.

To test our implementation of preemptive multitasking we developed a simple test program, the body of which is shown in Program 3.

static void vTestTask( void *pvParameters );
static int task1id = 1;
static int task2id = 2;
static int task3id = 3;
static int task4id = 4;
xSemaphoreHandle xSemaphore = NULL;

portSHORT main( void )
{
    xTaskCreate( vTestTask, "Task 1", 1000,
    (void *) &task1id, tskIDLE_PRIORITY + 2, NULL );
    xTaskCreate( vTestTask, "Task 2", 1000,
    (void *) &task2id, tskIDLE_PRIORITY + 2, NULL );
    xTaskCreate( vTestTask, "Task 3", 1000,
    (void *) &task3id, tskIDLE_PRIORITY + 2, NULL );
    xTaskCreate( vTestTask, "Task 4", 1000,
    (void *) &task4id, tskIDLE_PRIORITY + 2, NULL );

    printf("starting scheduler...n");

    vSemaphoreCreateBinary( xSemaphore );
    vTaskStartScheduler( pdTRUE );

    return 0;
}
/*-----------------------------------------*/

static void vTestTask( void *pvParameters )
{
    int taskId = *((int *)pvParameters);
    while(1)
    {
        if ( cSemaphoreTake( xSemaphore, 0 ) )
        {
            printf("Task %d running.n", taskId);
            cSemaphoreGive( xSemaphore );
        }
    }
}

The results of running this program are shown in Figure 4.

Figure 4 - Output from the test program demonstrating cooperative multitasking.

NEXT >>> ColdFire RTOS Port - Phase 5 - Running The Software Tests