What’s next? Ideas for ODeV v3

17/08/19 05:45

After the first new products powered by STM32 and the ODeV framework are in mass production, it is time again to go back to the design table and start thinking what’s next?

From ODeV to ODeV v2, a quick review
Last year, for ODeV v2 I did a extended code review by introducing the APMH interface with a default implementation for each supported MCU. I split other application specific code from the framework, for example by adding xxx_mx.c files (like sysinit_mx.c). And, most important, I extended the AManagedTask class to fix what looked like a not optimized behavior for a multitasking and event driven system:

ODeV_v1_Trace

Tracealyzer showed, during tests, that the managed tasks need to do micro steps (every 100ms or 150ms) only to prevent a WDG reset, and to respond to the power mode change. With the AManagedTaskEx the AED is aware when a task is suspended (for example blocked in queue waiting for an event), and the INIT task is able to force the step execution of a AManagedTaskEx object. Still the AManagedTask class make senses (in fact it is still available, not only for backward compatibility) because in an embedded application there are many case of task with a periodic frequency. For example the classic LED blinking demo task.

What we learned this year?
During the latest projects we had a couple of situation that got my attention. The first one is about the IDriver hierarchy in the Low Level API layer.

ODeV v3 - Idea - IDriver

The framework provides only one interface. From that interface we build many concrete driver class using basically two design pattern:

The first is as simple as subclass a driver. A typical example is the driver to implement the HID over I2C specification. We extended the I2CMasterDriver, by creating a new subclass, in order to add the code to manage the interrupt line (GPIO) for each slave connected to the bus.

The second is the composition pattern. An example is the driver for an FPGA that has two interface (SPI and I2C), one to program the FPGA and another to use it. We created a composite FPGA driver that include both one I2CSlaveDriver and one SPIMasterDriver.

In this way we designed all the drivers we needed, but there are cases when some virtual function are not used. For example the KeyScannerDriver that controls only the GPIOs of the Key Matrix and a hardware Timer does not need the Read and Write functions.
Moreover we found useful, sometime, to reset the hardware IP. For example this can happen when there are electrical noises injected into the system (EFT, ESD, etc.). This kind of scenario is very application specific. A low level reset can be done using the HAL_PPP_DeInit() and HAL_PPP_Init() functions.
All these considerations gave me some ideas to review the IDriver hierarchy in the next version of the framework like this:

ODeV v3 - Idea - IDriver 2

Note: WriteNB and ReadNB are the Non Blocking version of the write and read operations.

The second thing is at Services Layer and it regards the Managed Task. This year the MCU was in charge to update not only itself, but also the firmware of other devices connected to the MCU. In this scenario reliability and robustness are mandatory because many thing can go wrong during a fw update.
The framework has an intrinsic modularity in its design and we used this to handle this situation. In the SysLoadApplicationContext() function we decide what managed task must be executed, and we know that each task is a gate keeper for a subsystem. So the idea was simple:

When we detect an error during the fw update of an external device, we store this information in the NVM.

At startup we use this information to select what managed task to add into the ApplicationContext.

In this way the system gains a new level of reliability, because combine the capability to detect hardware failure with the one to isolate a subsystem. And it works very well.

In ODeV v3 I want to generalize this idea and bring it inside the framework (not at application level). I this it is possible to implement some thing like the POST (power-on self-test) we have in a PC.
To do this the idea is to extend the Managed Task interface that today look like this:

ODeV v3 - Task