FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [June 2016 Threads]
I am looking at V9 with the aim of creating task pools for re-use in RAM limited real time systems. The idea is to statically create empty tasks at boot time then have a master task populate them depending on the device operating mode. No malloc-free memory heap is allowed.
My nitial thought is to provide a standard pool interface such as taskpoolrequesttask method and have it allocate a TCB and stack along with a taskpoolreturntask method to hand back the resources once it is no longer required.
There seem to be a number of issues - questions.
a) the request method creates (statically) a task but note that the task handle is NOT unique to the executable code function as it is essentially a pointer to the TCB, which is shared among a number of potential code functions..
b) The TCB contains the link list elements for the task management so the kernel must guarantee that all these items have been removed from the kernel control lists before the TCB resource can be re-used. This is achieved by the task delete function. I am not sure that this can be checked externally in the application. If a task offers itself for deletion it is not deleted immediately but placed on the pending queue to be deleted next time the idle task is run.
So the question is are there any other issues ??? The pseudo code is below ...
taskpoolrequesttask
getfreetaskTCBandSTACK // get one of the RAM blocks allocated at boot time
createtask // standard FreeRTOS static task creation
suspendtask // task will be started by high level mode control task
end
taskpoolreturntask
deletetask // standard FreeRTOS task deletion
returnfreetaskTCBand_STACK // hand back RAM block
end
Any comment or hints would be appreciated.
FYI ... I am developing on Atmel Studio7 for SAM4N uP
I am looking at V9 with the aim of creating task pools for re-use in
RAM limited real time systems.
In my experience, and in the general case, RAM limited real time systems
rarely create and delete many tasks at run time. Rather they create all
the resources during initialisation, then those resources perform a
dedicated task and persist until the system is switched off.
Of course there are some application that fall outside of that
generalised case.
a) the request method creates (statically) a task but note that the
task handle is NOT unique to the executable code function as it is
essentially a pointer to the TCB, which is shared among a number of
potential code functions..
I'm not sure why that is an issue, but perhaps it is because you don't
know if the task has changed between two subsequent reads of the task
handle - because the handle will be the same if the task is using the
same StaticTask_t object from your pool.
This has also been an issue for kernel aware IDE plug-ins. The issue
was solved by also giving each task a unique number. You will see the
uxTaskNumber variable is incremented each time a task is created or
deleted - it is incremented when a task is deleted so the kernel aware
debugger knows it has to re-read the task list. The variable is stored
inside the task's TCB, but [by default] is not accessible - but could be
made accessible.
b) The TCB contains the link list elements for the task management so
the kernel must guarantee that all these items have been removed
from the kernel control lists before the TCB resource can be re-used.
This is achieved by the task delete function. I am not sure that this
can be checked externally in the application. If a task offers itself
for deletion it is not deleted immediately but placed on the pending
queue to be deleted next time the idle task is run.
In version 9 that is only the case if a task deletes itself. If one
task deletes another task then the deletion occurs immediately. In
either case, when the TCB is actually deleted (perhaps conceptually if
you are only using static memory allocation) then the portCLEANUPTCB()
macro will be executed. By default that is empty (I think) so you could
implement it in FreeRTOSConfig.h to return the TCB to the pool. Just be
careful to note that portCLEANUPTCB() is called before the TCB is
access for the last time if dynamic memory allocation is used - but if
you are only using static memory allocation then that should be fine.
Thanks for your input. I dont think the task_handle non uniqueness will be an issue as I will make sure its not persistent beween mode switches. Also its relatively easy to make tasks signal a central task delete task so that no task ever deletes itsself. I was not aware about the debugger issues, so thanks for that.
If I find any wrinkles in implememntation I'll re-post here ...
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.