Basic concepts: Platform Package
Embedded Wizard provides an environment to develop highly platform independent GUI applications. In practice, based on one and the same project you can run the application on any target system. This abstraction is made possible by our programming language Chora designed to strictly conceal all platform specific constructs and the concept of a Platform Package. The following figure demonstrates the components belonging to a Platform Package (highlighted with gray background):
Code Generator
Code Generator takes care of the right translation of the platform independent Chora code in the code valid for the particular target system. Accordingly, the results of the code generation are files you can integrate directly into your target specific development system. For example, you can add the files to the Keil MDK-ARM environment or simply to a GCC makefile.
Actually, our Code Generators support C and JavaScript as output formats. In case of C the resulting code can be compiled with any C compiler. Eventual architecture or operating system specific aspects are handled individually in the respective version of the Code Generator. In particular, the Code Generator for the Win32 target system optimizes the resulting code for the Microsoft Visual Studio C compiler.
With this concept we are highly flexible to adapt Embedded Wizard to any target system be it running on an operating system or bare-metal. Even future support for new output formats like C++, Java, Swift or C# is possible. The unique requirement is a 32- or 64-bit target system architecture. Please note, in case of 64-bit our C generators support actually the I32LP64 data model only.
Resource Converters
Resource Converters take care of the conversion of bitmap and font resources used in the GUI application in a format or code valid for the target system. Depending on the target this may include color reduction, dithering and compression of resource data. Per default, the resource converter store the bitmap and font information in a format intended to be used without any additional image decoder or TrueType font engine. For example, font glyphs are pre-rasterized.
If your target system supports a PNG image decoder, we can provide you corresponding Resource Converter able to store the bitmap resources directly as PNG files. Similarly, if there a TrueType font engine available in your target system, the appropriate Resource Converter can be used to rasterize the glyphs on the fly during the runtime of the application instead of using the pre-rasterized glyphs. This possibility is particularly interesting for large projects containing many images and large fonts (e.g. for Chinese language).
Graphics Engine
Graphics Engine is a library implementing functions to perform graphical operations, like drawing lines, filling rectangles, copying or 3D transforming images and printing formatted text. All graphical operations support alpha-blending and can be performed with an additionally specified color or opacity gradient. The Graphics Engines are optimized individually for the respective target specific color format. Actually our engines support following formats:
Framebuffer format |
Bitmap resource format |
Description |
---|---|---|
RGBA8888 |
RGBA8888 |
The framebuffer and the bitmap resources are stored with 32-bit per pixel. The order of RGBA channels can be configured flexibly. The RGB (color) channels can optionally be pre-multiplied by the corresponding A (alpha) value. |
RGB888 |
RGBA8888 |
The framebuffer stores the pixel as 24-bit values. The bitmap resources, in turn, are stored with 32-bit per pixel including opacity information. The order of the RGB and RGBA channels can be configured individually. The RGB (color) channels of bitmap resources can optionally be pre-multiplied by the corresponding A (alpha) value. |
RGBA4444 |
RGBA4444 |
The framebuffer and the bitmap resources are stored with 16-bit per pixel. The order of RGBA channels can be configured flexibly. The RGB (color) channels can optionally be pre-multiplied by the corresponding A (alpha) value. |
RGB565 |
RGBA8888 |
The framebuffer stores the pixel as 16-bit values. The bitmap resources, in turn, are stored with 32-bit per pixel including opacity information. The order of the framebuffer RB (G is fixed) and bitmap resource RGBA channels can be configured individually. The RGB (color) channels of bitmap resources can optionally be pre-multiplied by the corresponding A (alpha) value. |
LumA44 |
LumA44 |
This format is intended for monochrome displays. The framebuffer and the bitmap resources are stored with 8-bit per pixel. The order of LumA channels can be configured flexibly. The Lum (luminance) channel can optionally be pre-multiplied by the corresponding A (alpha) value. |
Index8 |
Index8 |
The framebuffer and the bitmap resources are stored with 8-bit per pixel using additional color look-up table (CLUT) to translate the 8-bit value in real RGBA color. When performing alpha-blending operations a sophisticated and unique algorithm ensures to map automatically the resulting RGBA color value to the corresponding CLUT index. Thus you don't need to worry about the CLUT. |
RGB565A8 |
RGB565A8 |
The framebuffer and the bitmap resources are stored with 16-bit per pixel for the RGB (color) information and separately 8-bit for A (alpha) information. The order of RB (G is fixed) channels can be configured flexibly. The RGB (color) channels can optionally be pre-multiplied by the corresponding A (alpha) value. |
RGB555A8 |
RGB555A8 |
The framebuffer and the bitmap resources are stored with 16-bit per pixel for the RGB (color) information and separately 8-bit for A (alpha) information. The remaining bit 15 in the color information can be configured to be either a constant value or to correspond to the most significant bit of A (alpha). The order of RGB channels can be configured flexibly and the color channels can optionally be pre-multiplied by the corresponding A (alpha) value. |
The implementation of the Graphics Engine permits every drawing operations to be delegated individually to the hardware of the respective target system. Drawing operations, which are not supported natively in the target are executed automatically in highly optimized software pixel driver. Accordingly the Graphics Engine can be flexibly scaled between target systems not providing hardware acceleration for any drawing operation and systems containing an OpenGL compatible 3D core and thus being able to execute every drawing operation natively per hardware.
With every Platform Package you get two versions of the Graphics Engine. One version is intended to be used in the target system. The other version is a module, Embedded Wizard Studio uses in order to ensure that what you see during prototyping does in fact correspond to what you will get in the target system.
Depending on your Platform Package license, the Graphics Engine is provided in source code or as compiled library. In particular no source code is contained in the Evaluation edition of the Platform Package. Similar is true if you are working with the Small Business edition. The version provided for Evaluation edition can additionally be watermarked.
Runtime Environment
Runtime Environment is a library providing functions necessary to run applications implemented in the programming language Chora. You can consider the Runtime Environment as an interface between the generated code and the target system. Simplified, the Runtime Environment contains functions to manage Chora objects and to communicate between them.
With every Platform Package you get a version of a Runtime Environment intended to be used in the target system. Depending on your Platform Package license, the Runtime Environment is provided in source code or as compiled library. In particular no source code is contained in the Evaluation edition of the Platform Package. Similar is true if you are working with the Small Business edition. The version provided for Evaluation edition can additionally be watermarked.