Direct task notification to a task not of higher/est priority

Hi,
I have a number of tasks all set at priority 1.
One of them (InkJetting Task) increases its priority to 2 while controlling some ink jetting nozzles to avoid being interrupted.
A second task (ShutDownPump) is always at priority 1.

ShutDownPump is at some point locking in a xTaskNotifyWait() waiting for a notification from a ISR callback.

There are times when the ISR is called while the InkJetting Task is set as higher priority (priority level 2).

How can I make sure that the ISR sends the notification to the ShutDownPump (at priority level 1) and it does the following in the following order:
a) wake up ShutDownPump (at level 1) while the InkJetting task is currently at level 2
b) carry out some crucial instructions inside ShutDownPump following the xTaskNotifyWait()
c) control goes back to InkJetting task which is still at level 2

What is the best way to do that? Do I have to play with the priorities perhaps?

Thank you as always :slight_smile:

If your priority 2 task never blocks, which is what it sounds like, or your other tasks would get some time, then your best option would seem to be to make this task be a higher priority so it can interrupt the priority2 task.

Thank you Richard,
then, to avoid the other tasks interrupting neither ShutDownPump nor InkJetting I would add another level like this:

  • ShutDownPump Level 3
  • InkJetting Level 2
  • all other tasks Level 1

correct?

Thank you

Yes, give higher priority to tasks that need to interrupt lower priority tasks.

This can’t be achieved due to the conflicting requirement that the ShutDownPump task SHOULD preempt/interrupt any other task including InkJetting task if it get’s notified.

Thank you Richard and Hartmut

To avoid the task at priority 3 staying there for the whole tick time (it only has to execute few instructions at that point) do I then use taskYIELD() to switch to the lower level (level 2) task without wasting any more time in ShutDownPump (Level 3)?

Thank you

Yield won’t help, it needs to block for its next notification.
ALL tasks should block on something if they don’t have useful work to do.

Thank you Richard,
Ideally I don’t want to send a notification or do other operations for that task to resume. So apart from NotifyWait(), what other ways are there to block a task (ideally indefinitely)?
I thought about vTaskDelay() with the longest delay possible but perhaps there is a more elegant/correct way to do it with some other function?
I couldn’t notice any in the API.

Thank you

I don’t understand the problem you want to solve… :thinking:
The ShutDownPump task waits for its notification, gets woken up when signaled by the ISR, does whatever it has to do to urgently control the pump and waits for its notification again.
As soon as it gets blocked waiting for the notification the next ready task with the highest priority runs, which is the InkJetting task.

When ShutDownPump is woken up by the notification from the ISR, it has to execute some urgent instructions but then there are some other time consuming instructions that are not urgent. So after the urgent ones and before the time-consuming ones I want to lock the ShutDownPump and it will resume sometime later whenever the scheduler will make it its turn.
Maybe I am complicating things, but looking at the overall structure I currently have in place that is the best way I can think of. That is why I was wondering if there is some other call that locks the task indefinitely other than vTaskNotifyWait() or vTaskDelay(). I guess vTaskDelay() could work with the longest time setting but I thought there might be a more elegant API. :slight_smile:

Maybe you just want it to drop its priority after it does the urgent stuff.
The other option would be to have two task, one for the urgent, and one for the rest.

I fully with Richard. As 3rd alternative you could do the urgent things in the ISR leaving the pump shutdown task at lower prio than the inkjet task. Provided it’s possible to do those instructions in the ISR.
I still don’t get the approach to lock the task indefinitely after the urgent instructions since the task has to execute a certain postamble when shutting down the pump as you described. Also doing so would cause that the task not being able to get notified again.

Thank you Hartmut and Richard