Objectifying the FreeRTOS timers

After my last two posts I thought it could be a good idea to extend the objectification process, this time for the FreeRTOS timers (I would objectify myself if I could). FreeRTOS has included timers since the 9.0 release, and for many situations these are a better option than the regular tasks. For example, periodic tasks that must run until completion.

I should mention that I was two days away from giving up this approach. I knew what I wanted, but a piece was missing from the puzzle. So I started from scratch and then I realized the trick.

Base class

The solution is given, again, by the static trampolin member function, task() (line 82), as shown:

Captura de pantalla de 2018-05-28 20-31-12

So, what is different from my last two posts? Just one very important thing to note: the xCreateTask() function receives a function who has an argument for the user’s arguments; xTimerCreate() function doesn’t have such facility. When I reached this point I didn’t see any light, so I wanted to give up. Hopefully I’m kind of obsessive. As mentioned earlier, I started over from scratch and then I saw the light: the fourth parameter, pvTimerID, could do the trick:

Captura de pantalla de 2018-05-28 21-02-53

As you can see, pvTimerID is a pointer to void! And according to the documentation, the programmer can do whatever he/she needs with it. So my attempt was to pass on the this pointer in this argument, as seen in line 78. In line 84 I recover the this pointer through pvTimerGetID() function.

Are we miss out on the timer’s ID capability?

Of course not, although it might not clear why. Actually we get a better ID capability, something like the ID 2.0 release. Let’s explain. The idea behind the original pvTimerID is to discriminate a specific timer when the callback is shared among several timers (you might want to see the official example). In C++ when we create two or more instances from a class the function members are shared among those instances, doesn’t it ring you as a bell? Our timer ID is the object itself! I guess Richard Barry never consider this scenario for the ID field. In your face Richard! (Just kidding, I admire this man. I got his autograph in Embedded World 2014, in Nuremberg, Germany.)

However, if you really need an ID descriptor, then you can add a data member for such feature, as in line 89 and its corresponding getter member function (line 66).

Inherited classes

We write our classes that inherit from Timer as usual:

Captura de pantalla de 2018-05-28 20-31-50

Constructor (line 95) is split in two lines for the sake of clearity: in line 95 we have the parameters for the MyTimer class itself, while the parameters for the base class Timer are written down in line 96. Line 97 calls the base class constructor, while line 98 initializes the MyTimer data members.

Client’s code

Let’s see the beauty of object oriented programming:

Captura de pantalla de 2018-05-28 20-32-22

Resources used

While this approach (base class plus inherited classes) uses a very low amount of FLASH/RAM resources, the FreeRTOS timer feature itself does use large amount.

What’s next

  • The static version of this approach (using the CRTP pattern, as usual).
  • To complete the whole timer functionality.

Source code

As soon as I git the code, I’ll update this section. Meanwhile you can download the example shown from here.










Una respuesta para “Objectifying the FreeRTOS timers”


Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s