• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 1516 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/MSP430F5529: Task priorities do not work

Moshe Deutsch
Prodigy 50 points
Part Number: MSP430F5529


Tool/software: TI-RTOS

Hello,

I recently encontered a strange phenomenon: 

I define Tasks in GUI and it doesn't matter whether they have different priorities or have the same priority - they will always run in a "timesharing" fashion -

as if there was a time quantum for each (similar to Threads in in Windows, for example). This is very strange and refute all principles taught....

Can anyone help please?

Many thanks!

Dr. M. Deutsch

  • 0
    TI__Guru* 96960 points
    Why do you think they run in a time-sharing mode? A task only gives up the processor if
    1. A higher priority thread is ready to run (e.g. higher priority task, Swi or Hwi).
    2. It blocks on something (e.g. Task_sleep, driver call that blocks (e.g. UART_read), Semaphore_pend where the semaphore is not available and a non-zero timeout is passed in, etc.)
    3. It calls Task_yield and there is another task of the same priority ready to run. Note: Task_yield does not yield to lower priority tasks.
    4. The task terminates.

    Can you give the number of tasks in the system and their priorities? It might be easiest to simply show a snapshow of Tools->ROV->Tasks->Detailed. Give a brief description of what each task is doing and why you think it is time-sharing.

    Todd
  • 0 in reply to ToddMullanix
    Prodigy 50 points
    Hello Todd and thank you for your answer.

    Two simple examples:
    1) Two Tasks created in GUI Statically, one is priority 1 - running in while(1) blinking LED1 and the other priority 2 - running in while(1) blinking LED2. You would expect only Task 2 to run in this situation and get only LED2 to blink. However, they both run in timesharing and BOTH LEDs blink at the same time.

    2) Same two Tasks run on equal priorities (say both run at priority 1). You would expect only one of them to run (the first one scheduled) - until either: blocked, yield or change priority, right? But yet again - timesharing...!!! They both run in timesharing and BOTH LEDs blink at the same time.

    Debugging also show timesharing scheduling! I know it breaks a major concept here, but believe me I did get very deep into this (and I know 1 or 2 things about systems - having a PhD in Software Engineering). I would really like to understand why I am encountering this, whereas all concepts suggest otherwise.

    I tried to dig into configuration, but did't find anything unusual.

    Running CCS Version: 6.1.2.00015
    TI RTOS Ver: TI-RTOS for MSP43x 2.14.03.28

    Many Thanks!

    Moshe
  • 0 in reply to Moshe Deutsch
    TI__Guru* 96960 points
    Can attach the two task functions?
  • 0 in reply to ToddMullanix
    Prodigy 50 points

    Hello Todd,

    I realised what the mistake was:

    Each Task function was running in while(1). In each iteration, toggle LED (via GPIO function) and then invoking Task_sleep(500) (for having a delay of 1/2 a second).

    Task1 runs this code for LED1, wheras Task2 runs this code for LED2.

    Of course Task_sleep is a blocking call, so while Task is in "Waiting" state, the highest priority Task in the Ready Queue gets to run! Hence the "time sharing" phenomenon I experienced!

    Many thanks for your assistence and prompt response!

    Best wishes!

  • 0 in reply to Moshe Deutsch
    TI__Guru* 96960 points
    Glad you got it resolved.

    Todd