Quality RTOS & Embedded Software

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




Loading

deleting task on PIC32MX

Posted by becopt on August 5, 2015

FreeRTOS 8.2.1 PIC32MX port + heap_4.c Got some troubles when delete and recreate task. Here is test code:

static void empty_thread(void *param) { for(;;) { vTaskDelay(10); } }

static void ApplicationTaskThread(void *params) { for(;;) { uint32t priority = uxTaskPriorityGet(NULL) + 1; TaskHandlet task = NULL; xTaskCreate(emptythread, "empty", 128, NULL, priority, &task); ASSERTNE(task, NULL);

 vTaskDelay(0);

 vTaskDelete(task);
 vTaskDelay(1);

} }

void vApplicationIdleHook( void ) { for(;;) { taskYIELD(); } }

I can create breakpoint and see that idle hook get processor time. Still task resources are never freed. I am using MPLAB X RTOSviewer plugin for debuging.

Screenshot in attachment.

What am i doing wrong? Thanks in advance.

Update. Cant fomat code somehow readable. Is there any special tag?


deleting task on PIC32MX

Posted by davedoors on August 5, 2015

Last sentense, third paragraph http://www.freertos.org/a00016.html your idle hook never returns.

Attachments

rtowviewer.png (28199 bytes)

deleting task on PIC32MX

Posted by becopt on August 5, 2015

Thanks alot. Still wonder why there is no word about that in vTaskDelete article and example.

Attachments

rtowviewer.png (28199 bytes)

deleting task on PIC32MX

Posted by davedoors on August 5, 2015

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

Attachments

rtowviewer.png (28199 bytes)

deleting task on PIC32MX

Posted by becopt on August 5, 2015

I've read that. Not a word about that IdleHook should return.

Attachments

rtowviewer.png (28199 bytes)

deleting task on PIC32MX

Posted by rtel on August 5, 2015

With respect - if it is stated that the idle task is responsible for freeing memory, then you can assume the idle task contains code that performs the free operations, and also assume that if your hook function prevents anything executing in the idle task other than the hook function, then the free operations will never execute.

Regards.

Attachments

rtowviewer.png (28199 bytes)

deleting task on PIC32MX

Posted by e-christenson on August 9, 2015

To begin with, OP Valentin has two significant mis-understandings here that are hard to see for the experienced, might be worth adding to the documentation somewhere or making checkable by lint or a compiler or adding comments to the prototypes in the header file:

A hook function is not a task function. It is a piece of a system "task"(whether or not it has a TCB) within freeRTOS -- examples being the system idle task and the idle hook and the scheduler and the tick hook. As such, failure of such functions to return means an essential part of the freeRTOS system is rendered inoperable.

With or without lint, an upgraded prototype for a task would be NORETURN( void userTaskd(...); ) and an appropriate prototype for a hook function would be MUST_RETURN( void vXyzHook(void); )

That makes the point both clear to everyone, and automatically checkable.

A second possible misconception is that the idle task is actually completely idle. It actually does something important -- reclaiming memory from deleted tasks.

The third misconception is that taskYIELD is appropriate within the idle task. What lower-priority task would run when the idle task yields? Hint: the idle task itself, exactly where it left off. I don't think that is what the OP had in mind...so I'll speculate that OP has a higher priority something that he wants to run before the current scheduling tick is complete. That something should either be an interrupt or simply called once from the idle task hook.

Attachments

rtowviewer.png (28199 bytes)

deleting task on PIC32MX

Posted by richard_damon on August 9, 2015

taskYIELD is entirely appropriate in the idle task, as it allows switching to another priority level 0 task that might exist. (taskYIELD is only useful because you can have multiple tasks at the same priority level, as (since the task is still marked as "Ready") it will only let another task at the same priority run. I find it not uncommon to create additional priority 0 tasks that will normally execute in a round robin fasion, each performing some low priority 'maintance' operation.

An idle priority task yielding lets the other idle priority tasks get to use more time (as opposed to the idle task just repeatively checking the same flag to see if another task has been deleted to reclaim the space. (The disadvantage is that the task you switch to gets just what is 'left over' of the time slice, so might not get perfectly even time distribution between the various idle tasks.

The idlehook function is good to use when you have some simple idle level processing and don't want the overhead of creating a whole new task to do it. My guideline is something that takes much less than a tick to perform (and doesn't need to block) is a candidate for an idle hook, while longer operations, or operations that might need to block become independent tasks.

Attachments

rtowviewer.png (28199 bytes)

deleting task on PIC32MX

Posted by rtel on August 9, 2015

There is a configIDLESHOULDYIELD constant that can make the Idle task do this automatically but it needs to be used with care with ports that mean using the constant will result in the processor spending most of its time in a yield interrupt.

Regards.

Attachments

rtowviewer.png (28199 bytes)


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




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

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

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

OpenRTOS and SafeRTOS