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


Cooperative Multitasking and gdb debugging

Posted by https://www.google.com/accounts on October 11, 2011
I'm evaluating the use of FreeRTOS on a small amateur radio satellite.

We are debating whether we should use preemptive or cooperative multitasking.

First, is it practical to do single-step debugging using gdb with FreeRTOS preemptive multitasking? I don't see any indication that gdb is FreeRTOS kernel aware, so I assume the usual multitasking gdb features do not work? Do attempts to break and single-step result in the timer context switching in the middle of the debug?

Second, no online documentation I can find on FreeRTOS.org documents using cooperative multitasking with the configUSE_PREEMPTION compile flag. Only co-routines are discussed. Is use of configUSE_PREEMPTION still encouraged and actively in use? Or has it somehow been deprecated in favor of co-routines?

Braddock Gaskill

RE: Cooperative Multitasking and gdb debugging

Posted by William Davy on October 11, 2011
Hi Braddock,

Firstly, you are correct about GDB and single stepping code. There are things that you can do to mitigate the consequences, such as raising the priority of the Task to maximum, disabling pre-emption, entering critical sections or temporarily suspending the Scheduler. These mitigations aren't perfect in that they require you to modify your code a bit and typically you can't call kernel API functions from inside critical sections.

However, when you are stepping through code, the debugger places the temporary break-point on the next line of C code and as long as no other tasks are executing the same code you should get away with it. Any shared/re-entrant code that is being executed by something else is liable to switch your debug context without you realising which is a pain.

With respect to Pre-emptive vs Co-operative, the configUSE_PREEMPTION flag simply prevents the system tick from performing a task context switch. Therefore, Tasks have to explicitly yield. When you call any of the queue functionality, semaphores, or task delay or specifically taskYIELD(), then your task will yield and the scheduler can select the next task. The system tick continues to fire and count up ticks but it the scheduler doesn't get the opportunity to force the context switch. In some respects, this fixes your gdb single step problem because other tasks will not execute between each step, though the interrupt handlers.

Co-routines are heading towards being deprecated. They only provide the capability of running different functions from within a single task context, the IDLE task, and are intended for very low-memory systems. They are explicitly co-operative and in a system with pre-emption the IDLE task will be pre-empted meaning that the co-routines are pre-empted by other tasks, but not by each other.

I hope that answers your questions satisfactorily.


[ 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