How to disable task yield

Kernel
1

Hello there,

Is it possible to make freertos scheduler to switch only on the next tick.
for example let say that I have a tick each 1 ms.
I have a task A was running for 800 us from last tick and now is blocked.
Now task B is ready so the scheduler will switch to task B immediately before waiting for next tick (200 us).
this is the current behavior, and it happen because of task yield from my understanding.
is it possible to make it wait for next tick(200 us) before switching to task A ?

thanks

1 Like
2

And what should the system do for those 200us?

Why NOT go immediately to Task B?

3

it will be dead time.
it should wait for the next tick before switching to another task.
is this possible ?

4

What do you mean by “Dead Time”, the processor needs to be doing SOMETHING.

And again, why?

5

With dead time I mean do nothing like idle task or a dumb while loop.
why ? I have my reasons but it will be hard to explain without diagrams.
Anyway do you think it possible to do ?

6

Since you are not willing to share why you want to do this, we cannot assess whether it is the best solution for your problem.

Here is one way you could do this (I have not tested it): taskYIELD maps to portYIELD which is defined in portmacro.h: FreeRTOS-Kernel/portmacro.h at main · FreeRTOS/FreeRTOS-Kernel · GitHub. You can define portYIELD to your dumb while loop.

7

Thank you very much.
I will try this solution as soon as possible and I will let you know.

8

I suppose that you call one of the FreeRTOS API’s, which in turn yields? Or do you call yield directly?

If so, another solution would be to issue a SLEEP instruction. That will put the CPU in sleep mode, from which it will wakeup when an interrupt comes in.

EDIT: If you want to know if a clock tick has passed, you can use the vApplicationTickHook() function (note the warnings though), or call xTaskGetTickCount() before and after the sleep.

9

no I don’t call anything to yield. its just freertos that call yield automatically when a task is blocked(this is from my understanding), this is the thing that I want to disable.
aggarg did suggest a good thing to try

10

ok so I tried doing your solution but its not working.
from the debugger it seems to be blocked in portYIELD_WITHIN_API().

11

Do you have a possibility of using notifications ? xTaskNotifyWait( p1,p2,p3, portMAX_DELAY);
Make task A and task B wait forever for notification.
And in ISR, where tick is incremented, just notify task to wake up ? vTaskNotifyGiveFromISR();

12

I’m new to freertos and to rtos in general.
I have to study notification before doing this solution.
but I was hoping to do it in a simpler mode

13

Have you been using other RTOS in the past? If yes which one supports the behavior you ask for? If not, there is a chance that you have a fundamental misunderstanding of an RTOS. As long as you do not tell us why you believe to need this feature, we will not be ahle to help you.

If you need precise timing windows, you are better off looking into timer interrupts than trying to tweak the RTOS do in on the application level. But that is only a wild guess as long as you keep your cards in your hands…

1 Like
14

No this is the first time I’m using rtos so I don’t know if there is any rtos that support this.
I think this feature is not mandatory but its nice to have for a lot of reason.
for example :

  • synchronization on ticks with other external hardware when switch tasks
  • scheduling will be easier to understand and to expect its behavior
    etc etc
15

Not a good idea at all. You do NOT want application software to be tightly coupled with hardware. One of the very reasons for existence of an RTOS is to untangle that. You may want to study device driver architectures to get an understanding of how the control flow from hardware to application code works.

16

Thanks for you suggestion.
I think that I will do like you said.

17

I tried this solution myself and now I see that just doing this is not enough. First you need to ensure that there is something forcing context switch at next tick. That was not the case with me as the timer task was the highest priority task and was always ready. I needed to lower its priority. Next, you need to modify the context switch to realize that you are at this “special infinite loop” and then jump past it. This would be much involved and certainly not sounds like a good solution. As others have said, you need to describe the problem you are trying to solve so that we can help you find the best possible solution.

18

Yeah I think I will change my software design to avoid this
thanks