What's new in ODeV eLooM v3
STMicroelectronics has recently released two new function packs:
They are both based on ODeV… ops! I have to call it eLooM: embedded Light object oriented fraMework for STM32 application.
They are both based on ODeV… ops! I have to call it eLooM: embedded Light object oriented fraMework for STM32 application.
New folder organization
To be a good citizen in the ST ecosystem, I had to resahpe a bit the folder organization. eLooM is now a middleware following STM32 coding rules. This has improved the separation between the target platform code and the framework.
New implementation of the Power Mode State Machine
The PM state machine implementation is more flexible and now offers the possibility to re-map the state function of a managed task, and also it provides more control on the sequence of the tasks during a state transaction.
New IDriver hierarchy
There are now two interfaces in the Low Level API layer to better model the different type of drivers.
New folder organizzation
The folder organization tries to be inline with STMicroelectronics guidelines. For more information see section 4.3 Packaging model of UM2388 - Development guidelines for STM32Cube firmware Packs.
This has improved the separation between the target platform code and the framework.
This has improved the separation between the target platform code and the framework.
New implementation of the Power Mode State Machine
The PM state machine implementation is more flexible and now offers the possibility to re-map the state function of a managed task, and also it provides more control on the sequence of the tasks during a state transaction.
In the previous version of ODeV_f there were two scenarios, regarding the PM state machine, not easy to handle at application level:
During a PM transaction a developer cannot make assumptions about the order in which managed tasks will transact. This was the rule until ODeV v2. The problem with this rule is that sometime there is a relationship between two or more managed tasks: if one managed task (Task1) requires services exported by another managed task (T2), then Task1 has to make its transaction before Task2 otherwise the system is in a deadlock condition because Task2 is suspended.
eLooM v3 solves this problem by introducing the concept of Power Mode Class (or PMClass). The system support three PMClass:
An object of type AManagedTaskEx can belong to one of the three PM Classes, and there are new APIs to set and get the attribute:
This allows a developer to split the managed tasks in three set and, during a PM transaction, the INIT task executes the transaction first for all tasks belonging to E_PM_CLASS_0, then for all tasks belonging to E_PM_CLASS_1 and then for all tasks belonging to E_PM_CLASS_2.
Moreover a new virtual function is called just before the star of the PM transaction:
It can be used by a managed task to execute some code to prepare itself for the transaction. This function should be fast in term of execution time to keep the overall time of the PM transaction short. It is a good place to dynamically set the PMClass od a managed task.
In the previous version of ODeV_f there were two scenarios, regarding the PM state machine, not easy to handle at application level:
- the order in which the managed tasks execute the state transaction.
- reuse a managed task in another application with a different PM state machine
During a PM transaction a developer cannot make assumptions about the order in which managed tasks will transact. This was the rule until ODeV v2. The problem with this rule is that sometime there is a relationship between two or more managed tasks: if one managed task (Task1) requires services exported by another managed task (T2), then Task1 has to make its transaction before Task2 otherwise the system is in a deadlock condition because Task2 is suspended.
eLooM v3 solves this problem by introducing the concept of Power Mode Class (or PMClass). The system support three PMClass:
- E_PM_CLASS_0
- E_PM_CLASS_1
- E_PM_CLASS_2
An object of type AManagedTaskEx can belong to one of the three PM Classes, and there are new APIs to set and get the attribute:
sys_error_code_t AMTExSetPMClass(AManagedTaskEx *_this, EPMClass eNewPMClass);EPMClass AMTExGetPMClass(AManagedTaskEx *_this);This allows a developer to split the managed tasks in three set and, during a PM transaction, the INIT task executes the transaction first for all tasks belonging to E_PM_CLASS_0, then for all tasks belonging to E_PM_CLASS_1 and then for all tasks belonging to E_PM_CLASS_2.
Moreover a new virtual function is called just before the star of the PM transaction:
sys_error_code_t AMTExOnEnterPowerMode(AManagedTaskEx *_this, const EPowerMode eActivePowerMode, const EPowerMode eNewPowerMode);It can be used by a managed task to execute some code to prepare itself for the transaction. This function should be fast in term of execution time to keep the overall time of the PM transaction short. It is a good place to dynamically set the PMClass od a managed task.
New IDriver hierarchy
- IDriver
- IIODriver
The IDriver is the base class, and it force a common behavior and a common API for a generic driver.
IIODriver extend the previous interface and add also the method to manage I/O operations like write and read.
New git repository
This new version of the framework introduces few but significant changes, so I created a new repository in GitHub to have a new fresh start. In the repository you find the framework and the template projects. For more information look at the README.md file in the git repository at this URL.
Last update: 28th November 2021
