3

I am hung up on how to move forward with FreeRTOS in my application. Let me propose a simple scenario. Assume I have main and a module which has some hardware specific code. This code could be for controlling a specific motor in a system or a sensor... any bit of hardware with a defined role. Within module.c I have a function called ModuleNameTask. In main I create the task using xTaskCreate and I pass ModuleNameTask. Since my ModuleNameTask is defined in module.c and not main.c, I now have to include bits of FreeRTOS within module.c in order to use functions like vTaskDelay. I don't like the fact that I am including these files within module.c as I feel its no longer portable.

So, how do I handle this? Should I remove that ModuleNameTask from module.c and place it in main.c? Or just accept the fact that I have to include bits of FreeRTOS into module.c. Any advice?

user946230
  • 269
  • 1
  • 3
  • 8

2 Answers2

8

What functionality do you require from FreeRTOS for your module to work. Obviously there are some things or you wouldn't need to include the headers and you wouldn't be calling the functions.

Take these functions and put them in a separate header called os/<operating_sys>/freertos.h and wrap them in your own function names (e.g. my_createtask(<args>).). Now to port to a different OS you will need to provide a new file with new wrappers for your own functions.

If you do this poorly you'll notice that your createtask function looks exactly like the FreeRTOS function and can be easily mapped but when you want to use linux/vxWorks/other OS that the function doesn't have the right arguments.

Your createtask function should only contain the parameters that you care about. The others should be hard coded in the wrapper. This will make it easier to port (you'll have different parameters to hard code in other operating systems).

dave
  • 4,812
  • 4
  • 25
  • 38
  • Ok, I think I understand. So, I create these wrapper functions that will be used in module.c (to reference my example). These wrapper functions then make module.c OS agnostic. – user946230 Nov 04 '12 at 10:30
  • Yep, just like you write a module for hardware specific code so that your program can be ported to different hardware easily (just re-write that one module). There should be an OS module which is the only thing that has to change should you wish to port to a different OS. – dave Nov 04 '12 at 10:35
  • So, would you embed the task creation in the module as well? For example, each module I have usually has a `ModuleNameInit()` function. If the create task function becomes OS agnostic, it seems to me that it makes sense to create the task in the module. Now, by simply calling the init function the process is up and running. Follow? – user946230 Nov 04 '12 at 10:37
  • I'd have everything relating to the module inside the module. If the module needs it's own task then set that up inside the module. And as you say once it's OS agnostic it's not a problem. – dave Nov 04 '12 at 10:43
5

Abstract both the RTOS and the device layer.

Define an OS interface of your design (this may only be a subset of FreeRTOS functionality or even include higher level interfaces implemented using RTOS primitives) and implement this interface using FreeRTOS.

You then define your entire application including your device layer using only your RTOS abstraction layer interface. When you port your application to another platform or RTOS, you only need change the abstraction layer implementation, being sure to maintain the same semantics as the original implementation. If the device layer is also suitably abstracted so as to be able to be generic across different hardware you can do the same for hardware dependencies (i.e. abstract them from the physical implementation).

I have successfully used this approach for many years, using an RTOS abstraction in C++ that I have ported to FreeRTOS, VxWorks, Segger embOS and Keil RTX and even Windows and Linux (for test and simulation). You need not of course use C++, but it is well suited to the task.

In your abstraction you need to consider the following:

  • Threading
  • IPC (queues, pipes, event flags, mailboxes etc.)
  • Synchronisation (mutex, semaphores)
  • Timers
  • Interrupt handlers

Your interface might look very different from FreeRTOS itself, and it may be worth looking at a number of other RTOS interfaces to see what kind of features yours may need.

Clifford
  • 88,407
  • 13
  • 85
  • 165