• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 407 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.

TM4C1290NCPDT: TI RTOS Does Task_setPri( task, -1 ) Require a Task_yield?

Bryan Radke
Expert 1313 points
Part Number: TM4C1290NCPDT

I have a task that is setup to interface with a flash memory chip for our design. I have a HW interrupt to detect when our products supply voltage is falling. I was planning to use the Task_setPri( task, -1 ) within the low voltage HW interrupt to inactivate the task that is interfacing to our flash memory, that way I prevent subsequent writes to flash when power is being lost.

I have verified that a pended task will stop when set to a priority of -1. I am wondering if a running task will require a scheduler call to stop work if its priority is set to -1 from a HW interrupt? If so, would using a Task_yield() in the running task satisfy the requirement?

  • 0
    TI__Guru*** 135355 points

    Hello Bryan,

    From what I am reading in the description of Task_yield, you would not need that:

    • Task_yield yields the processor to another task of equal priority.
    • A task switch occurs when you call Task_yield if there is an equal priority task ready to run.
    • Tasks of higher priority preempt the currently running task without the need for a call to Task_yield. If only lower-priority tasks are ready to run when you call Task_yield, the current task continues to run. Control does not pass to a lower-priority task.

    The question for me then becomes if the power is restored and you restore the priority, will you have any issues with restarting that task?

    Though perhaps that is something that can be handled outside of the HWI like when the system is has some idle time if the task priority was set to -1 then kill the task and reconstruct it if/when power is restored. Just musing a bit about the implications of only stopping the running task which may start to run again from who knows what state later on.

  • 0 in reply to Ralph Jacobi
    Expert 1313 points

    Hello Ralph,

    Task_yield should switch to a higher priority or like priority task, which is why I thought this approach may work. If the priority of the running task was set to -1, and then Task_yield was called with no other tasks ready to run, would that cause a switch to the idle task (priority 0)?

    Re-starting the task for sure can have issues that we would have to work through. We might have to stop the task all together, and re-construct if power is restored.

    Regards,

    Bryan

  • 0 in reply to Bryan Radke
    TI__Guru*** 135355 points

    Hello Bryan,

    Task_yield deals with equal priority tasks only. For example, documentation specifically states "If only lower-priority tasks are ready to run when you call Task_yield, the current task continues to run. Control does not pass to a lower-priority task." So the important step for you is setting the priority to -1 as that is what will give you the behavior you want. Task_yield will not add any value for you in this situation.

    The Idle Task at Priority 0 and therefore it is already be higher than your task set to Priority -1. Therefore when the HWI exits, the scheduler would automatically run Idle Task if there are no other higher priority tasks over going back into your Priority -1 task. This is what you are aiming for here and that is how the scheduler will automatically operate.

    Just to explain when you would use Task_yield, if you set your flash memory interface task to be Priority 0 and not -1, then it would be on the same priority level as Idle. At that time, Task_yield could be used to run the idle task first instead of your memory interface task.