FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [April 2006 Threads] Newbie: Problem with bare bone samplePosted by Ake Hedman on 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
RE: Newbie: Problem with bare bone samplePosted by Nobody/Anonymous on 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?
RE: Newbie: Problem with bare bone samplePosted by Ake Hedman on 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; }
RE: Newbie: Problem with bare bone samplePosted by Ake Hedman on 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.
RE: Newbie: Problem with bare bone samplePosted by Nobody/Anonymous on 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.
RE: Newbie: Problem with bare bone samplePosted by Ake Hedman on 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
RE: Newbie: Problem with bare bone samplePosted by Nobody/Anonymous on 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.
RE: Newbie: Problem with bare bone samplePosted by Ake Hedman on April 21, 2006 Thanks a lot now I think I got it.
Cheers /Ake
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|