Task scheduling without SysTick

marser wrote on Thursday, February 12, 2015:

This might seem like an odd question for a realtime OS, but is there a way to run realtime tasks in FreeRTOS?

I’ve been looking for a way to create, delete and switch tasks without running the FreeRTOS SysTick interrupt. That is to say, I want co-operative scheduling, with no RTOS task interruption. Plus the ability to pre-emptively switch, or kill, tasks, on external events (non-masked interrupts).

I’ve been looking into the tickless ability, and the different scheduling methods, but can’t find anything that fits the requirements.

Co-operative scheduling appears to do exactly this, but I can’t get it to run without the overhead of xPortSysTickHandler.

For background, I’m running an audio processing task (patch) which requires all available uC cycles to complete on time. I need it to run uninterrupted under normal use, with occasional USB events (processed by high-priority interrupts) that may stop and replace the current patch.

At the moment I have a patch management task which receives events through xTaskNotifyFromISR(). This works quite well, and the management thread is blocked while waiting for events, but it seems the overhead of running FreeRTOS (pre-emptive or cooperative) is still significant compared to bare bones.

rtel wrote on Saturday, February 14, 2015:

Sorry for the delay - all posts made two days ago went into moderation for some reason. That shouldn’t happen.

This might seem like an odd question for a realtime OS, but is there a way to run realtime tasks in FreeRTOS?

That would depend on your definition of realtime, but I think most people would agree the answer is “yes”.

I’ve been looking for a way to create,

http://www.freertos.org/a00125.html

delete

http://www.freertos.org/a00126.html

and switch tasks

…make any blocking call or call taskYIELD().

without running the FreeRTOS SysTick interrupt.

http://www.freertos.org/low-power-tickless-rtos.html

That is to say, I want co-operative scheduling,

(So, not real time then? Note my comments above about your definition)

http://www.freertos.org/a00110.html#configUSE_PREEMPTION

with no RTOS task interruption.

http://www.freertos.org/low-power-tickless-rtos.html

Plus the ability to pre-emptively switch, or kill, tasks, on external events (non-masked interrupts).

Did you read any of the API documentation before posting? I can’t give you a link to every way you can do this.

I’ve been looking into the tickless ability, and the different scheduling methods, but can’t find anything that fits the requirements.

I’m not sure I understand your requirement.

Co-operative scheduling appears to do exactly this, but I can’t get it to run without the overhead of xPortSysTickHandler.

Did you just try disabling the interrupt - but be aware if you do that you will have no time at all, as far as the software is concerned.

For background, I’m running an audio processing task (patch) which requires all available uC cycles to complete on time. I need it to run uninterrupted under normal use,

http://www.freertos.org/a00110.html#kernel_priority

with occasional USB events (processed by high-priority interrupts) that may stop and replace the current patch.

Regards.

edwards3 wrote on Saturday, February 14, 2015:

Your post does not make sense to me.

Using FreeRTOS to make a system event driven can free up lots of cpu cycles that otherwise are just spent calling functions to see if there is anything to do or polling io. It cant make your cpu faster than it is though.

If your cpu cant run your system then you can try restructuring the code, slowing the tick, not using an RTOS, or simply use a faster cpu.

marser wrote on Wednesday, February 25, 2015:

Thanks. It turns out I might have overestimated the actual overhead added by FreeRTOS scheduling, though I still need to do some benchmarking on this with my setup.

To clarify, what I’m doing is loading time-critical code at runtime and executing it in a task. Since the code cpu footprint is not always known beforehand, and because some are very nearly maxing out already without the scheduler, more cpu == better.