I am working at the main ideas for the next version of the framework and I would like to share a quick look.

What's new in eLooM v4

This new version of the framework is focused on incremental improvments in two of the three layers:

• Service layer: consolidation of the PM state machine remapping.
• Low Level API: support for multiple instances of a IDriver subclass integrated within the framework.

Consolidation of the PM state machine remapping

Let’s assume we have two Managed Task from two different applications, and each task has been designed for a specific PM States Machine with different states.



We want to reuse MT1 and MT2 in a new application, App3, that we designed with another state machine.



To do that, we must be able to remap MT1 states and MT2 states to the states of App3. That was the problem we tried to solve in the current version of the framework. We did it by introducing a relation between the the application (App3) states and the AManagedTask::ExecuteStepXXX functions.



We used this feature in some projects and we discovered that, even if it is a workable solution, it is not optimal and not easy to use.
But we learned a lot, and I think to have a better solution.

Support for multiple instances of IDriver subclass integrated within the framework

The OO approach used by the framework, and especially the code encapsulation, allow us to allocate different instances of a class. This is true with one main exception: the IDriver subclasses. Let's try to understand why with an example about the SPIMaster driver.



When we allocate a new instance of the SPIMaster driver for the SPI1 IP, then it will be linked to the SPI1 HAL handler during the object initialization. In this way the object can access the HAL handler and it can operate the IP. But if the HAL driver is used in DMA or interrupt mode, then there is a problem in the ISR callback:



How can we go back to the SPI1lld object? Due to the design of the STM32 HAL we loose the context of the Low Level Driver. There are many way to bypass this limitation like using some static variables like in the above image (spHwResources, line 333) that is used by both STM32 HAL and eLooM. But it is done at application level.

With eLooM v4 I want to generalize this idea and provide an homogeneous support at application level (thanks also to the work done with Fernando).

Other little things

There will be also others little things we are working on. We are checking the framework against the MISRA 2012 rules. We are implementing a timestamp service. All things to allow the development of more components on top of eLooM.