Platform Integration
Within Embedded Wizard Studio, every GUI application is developed in an platform independent manner. By using a dedicated Platform Package, every GUI application can be generated for a dedicated hardware (target system). The selection and the configuration of a Platform Package is done by using the profile settings within an Embedded Wizard UI project.
In most cases, the following software components have to be compiled and linked together to get a binary for a certain target system:
★Generated code - the generated source code of your Embedded Wizard UI project.
★Graphics Engine - the interface to the underlying graphics system. The Graphics Engine is responsible for displaying Embedded Wizard GUI applications on the target platform using the correspondent color format. The Graphics Engine is provided as source code or as library (depending on your license).
★RunTime Environment - the bridge to the underlying operating system (if applicable) and the environment to manage memory, resources, events and Chora objects. The RunTime Environment is provided as source code or as library (depending on your license).
★Main Loop - The main module that drives the UI application and that provide events to the UI application.
★System infrastructure, device drivers, middleware, control logic, BSP, HAL, etc.
The article Main Loop explains the necessary steps to integrate a generated UI application into your main.c file: It covers the necessary details about the system initialization and de-initialization, the insertion of keyboard and touch events, the update of the display and the main loop to keep the UI application running.
The article Framebuffer Concepts describes the different framebuffer concepts and display integration scenarios, that are used to bring an Embedded Wizard based GUI application on the display.
The article Device Class and Device Driver is focused on the interfaces between an UI application and the underlying system: What steps are necessary to get data of a "real" target? How to control a certain device? How to get access to an underlying software API? What are the basic rules to create an interface to a dedicated hardware driver?
Build Environments
In order to simplify the bring-up of your Embedded Wizard GUI application on a dedicated hardware, we provide a couple of so called Build Environments.
Typically, a Build Environment contains a couple of simple UI projects and the necessary sources, libraries, scripts and makefiles to get the UI sample applications up and running on the target system.
Please note, that the provide Build Environments are prepared and tested for a couple of popular development boards or evaluation boards. If you are using your own hardware with different memory layout, different peripherals or different display, you can use the Build Environments just as a template. Please feel free to adapt them according your needs.
Each Build Environment is described by a 'Getting Started' article that explains the ingredients and the recommended workflow.
The following table provides an overview of all available Build Environments and Getting Started articles:
STM32 Discovery and Evalboards |
||
NXP LPCXpresso54608 |
||
NXP MIMXRT1050-EVK |
Getting started with NXP i.MX RT1050 Evaluation Kit (MIMXRT1050-EVK). |
|
Raspberry Pi |
||
JavaScript/WebGL |