77 views
in GUI Development by
Hi,
the standard EwInit() initialises the device driver after the root object is initialised. This seems to mean that init() for the first UI object runs with an uninitialised device driver. Assuming this is correct, would there be any issue moving the device driver init to be immedaitely before the root object creation?

*edit* I would also need to run DeviceDriver_ProcessData() of course so would that be a potential issue?

1 Answer

0 votes
by

Hello,

concerning your question it would be good to know the version you are using and which target (BuildEnvironment) you are using.

Starting with version 12, we have integrated support for communication between threads and tasks. The example DeviceIntegration that you will find in most of our BuildEnvironments is adapted to use this new technology.

The global functions DeviceDriver_Initialize() and DeviceDriver_Deinitialize() exists for compatibility reasons. Meanwhile, it is recommended to make the initialization of dedicated hardware drivers or middleware APIs in separate functions called by the Init constructor of the device class. The counterpart is the Done destructor of the device class.

This data processing function DeviceDriver_ProcessData() can be used to process data periodically in the context of the main GUI thread/task or in case there is no operating system at all (bare metal). In case you want to feed the GUI application with data and events from a foreign thread/task or an interrupt service routine it will be much easier to use the functions EwInvoke() and EwInvokeCopy().

I hope this answers your question.

Best regards,
Manfred.

by
Thanks Manfred. EW11 running on STM32H7.

I'm running all of the sensor code on the CM4 core and everything is sent to the CM7 on a message queue that the DeviceDriver_ProcessData() reads in the GUI thread. The device driver also interfaces with a config DB to get settings data, again that's initialised in the same thread via it's own init function that DeviceDriver_Init() calls. DeviceDriver_ProcessData() then queries the DB and updates a property. The CM7 is running freertos but is doing everything in one thread.

The first thing my Application class does is display a splash screen. That's been fine, but now I want to pick a splash screen based on a value from the config DB. The problem is that because EwInit() creates the Application class before the Device Driver init and first run of ProcessData, then the property has not been set when the Application::Init() function is called. The same would be true for the sensor values but in practice they are fully populated by the time the UI gets to the stage where they are needed.

I did try another approach yesterday, which was to have the device driver include an 'Iniitalised' property that it sets to true at the end of ProcessData(). The Applicaiton class then observes that property and waits for it to be true before displaying the splash screen. That seems to work quite well, but interested to know which approach you'd recommend.

thanks, ...rob
by
Hi Rob,

of course, a flag can be used to indicate the completed initialization in order to access only valid data.

The recommendation would be to make the initialization within the Init constructor of the device class. As soon as you access the device class from somewhere in your GUI application, an object of the device class will be created and the initialization code is executed.

Best regards,
Manfred.

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...