I am going to use the FreeRTOS on my hardware platform. My plan is to model individual tasks as C structs containing task execution period, task priority, task stack size, task name and maybe another atributes. Then I am going to define public “constructor” function called task accepting values of individual task attributes mentioned above, “abstract” function called taskFun which contains code of the task (each task will have this function but the implementation will differ among all the tasks) and public set/get functions.
My motivation for development of such overhead is improving organization of the source code and data encapsulation. Do you think it is good a idea? What are better approaches in case C language is used? Thanks for any ideas.
C does not readily support struct derivation like you are describing. If you really want that sort of data model, I would suggest switching to C++, which does provide such a model. Yes, you can sort of build something like that in C, but it doesn’t really provide the dynamic linking implied by your description.
What works better for a C encapsulation is to put each unique task/module in its own code file, with a header to provide the ‘API’ for that task/module (some modules might not have a task of their own, for instance a serial driver might run in the context of the calling task and an ISR. Multiple copies of similar tasks (like serial port drivers) would share one implementation file, with the calls containing a pointer to a data block with the details of which port you are working on.
Very few tasks are going to need to deal with the set of ‘all tasks’ in some generic way, that is the job of the OS, if you find you need something wanting to know about all tasks, you are likely doing something wrong. I would say that even most of the system shouldn’t know that the things ARE tasks, except for those things that implements the OS specific parts of the API. You build it on the concept that modules interface to modules with their APIs which is based on module based operations.
Hello richard-damon,
thank you for your reaction. My idea was to use what is described in Polymorphism section in the AN_Simple_OOP_in_C document (I am sorry I am not allowed to upload files as a new user). As far as your suggestion. Do I understand correctly that you model task with .c module and associated .h module? The .c module contains implementation of the functions from my design (without the “constructor”) and task attributes declared as static and the .h module contains public interface of the task i.e. prototypes of taskFun and set/get functions?
If I was designing a system like this in C, yes, that would be largely the organization, but there would be a ‘constructor’ call (I tend to call it xxx_Init) that main() would call before starting FreeRTOS that would allow that module to set itself up (and create its task).
My point is that you shouldn’t need an abstraction about ‘Tasks’ as that is the job of FreeRTOS. IT handles most of those needs, and it uses the TCB as its data structure to control it, so you shouldn’t need to.
I wouldn’t term them separate .c and .h modules, the .c and .h files TOGETHER define a module, the .h declares the API, and the .c defines the actual implementation. You do’t need to create a static structure with the data to setup the task, as those are the parameters of the task creation call and end up in the TCB. The .c file may have some local variables to allow easy configuration of the file from the front of it, but it is unneeded to create an ‘AbstractTask’ block to define that information.
