Newbie: Problem with bare bone sample

Kernel
1

akhe wrote on Thursday, April 20, 2006:

I have just started to evaluate FreeRTOS 4.0.0 so please excuse me if this is a dumb question.

I have an AVR ssystem where I have created one task that toggle som bits and one task that send some characters on a serial port.

This works fine if the tasks are created with

xTaskCreate( task1, "led", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 1, NULL );
    xTaskCreate( task2, "uart", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 2, NULL );

or with

xTaskCreate( task1, "led", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 1, NULL );
    xTaskCreate( task2, "uart", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 1, NULL );

but not with

xTaskCreate( task1, "led", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 2, NULL );
    xTaskCreate( task2, "uart", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 1, NULL );

where task1 never get called at all.

I can´t understand why this is.

In the first case the serial task have higher priority. The serial task should get more process time.

In the second case both have the same priority and should get equal processing time.

In the third - non working - case the LED task get more priority then the serial task but now it is never even called.

I’m sure I have missed something basic. Can someone set me on the right track.

Best Regards
/Ake

2

nobody wrote on Thursday, April 20, 2006:

There is nothing basic you have missed from what you describe.  It does not seem to make sense.

Which AVR are you using?  Can you run the demo that comes in the download on it (depends how much RAM you have).

Is there any way your uart code could be causing interrupts to remain disabled, or causing ram corruption?

Could you post a minimal source code that shows the task structures?

3

akhe wrote on Thursday, April 20, 2006:

Thanks for responding.

I use the AT90CAN128, so plenty of resources.

Yes I can run the supplied demo after some modifications.

The UART code can’t me less complex (see below),

The task structure is truly minimal

///////////////////////////////////////////////////////////////////////////////
// task1
//

static void task1( void *pvParameters )
{
    static int i;

    /* The parameters are not used. */
    ( void ) pvParameters;

    /* Cycle for ever, delaying then checking all the other tasks are still
    operating without error. */
    for( ;; ) {
        /* forward march */
        for (i = 0; i < 8; i++)
            LED_On(i);
        /* backward march */
        for (i = 8; i > 0; i–)
            LED_On(i);
        /* skip */
        for (i = 0; i < 8; i += 2)
            LED_On(i);
        for (i = 7; i > 0; i -= 2)
            LED_On(i);
       
    }
}

// http://www.vscp.org

///////////////////////////////////////////////////////////////////////////////
// task2
//

static void task2( void *pvParameters )
{
    /* The parameters are not used. */
    ( void ) pvParameters;

    for( ;; ) {
            uart_putchar(‘A’);
        uart_putchar(‘B’);
        uart_putchar(‘C’);
        uart_putchar(0x0d);
        uart_putchar(0x0a);
        vTaskDelay( 50 );
    }
}

where

///////////////////////////////////////////////////////////////////////////////
// LED_On
//

void LED_On( int i )
{
    PORTB = ~BIT(i);    /* low output to turn LED on */
    vTaskDelay( 500 );
}

and

///////////////////////////////////////////////////////////////////////////////
// uart_putchar
//

void uart_putchar( char ch )
{
    while( !( UCSRA & MSK_UART_DRE ) ) {
        taskYIELD();
    }
    UDR = ch;
}

4

akhe wrote on Thursday, April 20, 2006:

Additional information

I changed the UART code so it is interupt driven instead and after that the problem is gone.

Can’t still figure out why I got the previous behaviour though.

5

nobody wrote on Friday, April 21, 2006:

Your uart routine is busy waiting for the DRE bit to clear, with a yield function being called each loop.  When the uart is the highest priority task the yeild will always return to the uart task which will immediately yield again, tying up the CPU.  When the uart code is not the highest priority it will still always go back to the uart task when the other task is blocked.  This is probably not your intended behavior.

6

akhe wrote on Friday, April 21, 2006:

Hmmm… Just so I aunderstand this right.

How will the following two tasks exceute when I change priorities

task1()
{
     global1++;
}

task2()
{
     global2++;
}

If one of them have higher priority then the other will the other not execute at all then?

I expected the one with less priority to execute more selldom then the other with higher priority.

Cheers
/Ake

7

nobody wrote on Friday, April 21, 2006:

If one has higher priority than the other then it will execute all the time and starve out the other.  A high priority task will always run in favour of a low priority task until it blocks and is therefore unable to continue.

8

akhe wrote on Friday, April 21, 2006:

Thanks a lot now I think I got it.

Cheers
/Ake