C++ integration and inverted dependencies

Question

Hi Wizards,

I have some legacy code lying here in front of me that I am trying to integrate with a refactored firmware architecture. The new firmware is FreeRTOS and C++ based running on a STM32L4.

Looking at the BSP interface of the legacy code I can see that the current implementation relies on a globally available display API. Code looks something like this:

#include "display.h"

...

void EwBspDisplayCommitBuffer( void* aAddress, int aX, int aY, int aWidth, int aHeight )
{
   ...
   drawOnDisplay(...)
   ...
} 

So my question is: 

1. Do I have to make my hardware API available on a global scope or is there another way that is more in line with an OOP approach?

2. The legacy code seems to be driven through EmbeddedWizard in the sense that its' main loop is responsible for processing I/O and other things that are not strictly related to the GUI (e.g. through the DeviceDriver). Is that the intended/only way to use EW, or can I trigger EW behaviour from my firmware threads. Ideally I'd like to call functions to update the internal state of the EW gui (e.g. push a key event into a queue) and then call another function to trigger a rendering. Is something like this possible?

Thanks and best regards

Moritz

Answer 1

Hello Moritz,

concerning (1): What kind of API do you mean? The display API in case of STM32L4 is typically the STM HAL driver for LTDC/DSI. The file ew_bsp_display.c is just the glue layer between the HAL driver and the Embedded Wizard Graphics Engine. The adaptation of this module is is the recommended way to integrate a customer specific display.

concerning (2): Let me recommend to have a look into the chapters Integrating with the device, Implementing a Device Interface and Main Loop that you will find in our knowledge base. Furthermore, within the Build Environment for the STM32L4R9-Discovery (or other targets) you will find an example called DeviceIntegration - it shows the different aspects of integration directly on your selected platform - e.g. providing data from another thread.

I hope that helps....

Best regards,

Manfred.