Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training


Why are co-routines at lowest priority?

Posted by https://www.google.com/accounts on August 5, 2011
This may be a stupid question, but the stupidest question is the one unasked; so here goes.

I've never used a preemptive system on an embedded controller before, and have been studying the FreeRTOS documentation with interest for most of the day.

I've repeatedly seen it claimed that "preemptive multitasking is rarely the best solution for a given problem on embedded controllers". Which sounds reasonable to me; since preemptive multitasking is a general-purpose solution, it understandably requires additional CPU and memory overhead.

I'm quite familiar with writing code structured as co-routines (or state engines, protothreads, etc.) to support multiple "tasks" on systems without true preemptive tasks. I've already written my own co-routine scheduler that handles priorities, mutexes, blocking, etc. And I think that if written properly and specific to the problem at hand, co-routines can perform more efficiently than preemptive tasks.

However, I'm now facing a complex project on a constrained system (PIC24). It will require many simple, time-critical tasks at various priorities which are best implemented as co-routines for best performance. And it will also require two minimum priority tasks, which are way too complex to restructure as co-routines, but would be easily implemented as preemptable tasks.

But in FreeRTOS, co-routines are at a *lower* priority than preemptable tasks, which is the opposite of what I want. While I'm sure I could, with some effort, solve this by integrating another co-routine scheduler into FreeRTOS by setting it up as a high-priority task, I just can't wrap my head around why FreeRTOS would be set up this way.

Why is FreeRTOS' default implementation of a faster tasking solution (co-routines) seemingly crippled by placing it at a lower priority than a slower tasking solution (preemptive tasks)? I'm sure there's something I'm missing, so any insight would be greatly appreciated.

[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]

Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.

Free TCP/IP and file system demos for the RTOS

Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists