The STemWin Library is a professional graphical stack library
enabling the building up of graphical user interfaces (GUIs) with any STM32,
LCD/TFT display and LCD/TFT controller, taking advantage of STM32 hardware
acceleration whenever possible.
The STemWin Library is a comprehensive solution with rich features, such as
JPG, GIF and PNG decoding, many widgets (checkboxes, buttons…), and a VNC
server. It allows a local display to be displayed remotely, and also
professional tools (such as GUIBuilder) to create dialog boxes by a drag and
drop font converter. This graphic library is fully integrated inside the
STM32Cube firmware. It can be downloaded free from the STMicroelectronics
web site (http://www.st.com/stm32cube)
Basic Structure
The STemWin supports Arm®(a)-based devices.
STemWin Library is distributed by ST as an object code library locked to
STM32 products. It is compiler-dependent (IAR, Arm, GCC).
The library is compiled for CM0 and CM3 cores with Following Features:
• With and without OS support.
• With Size optimization
• Using ABGR and ARGB format
The library is compiled for CM4 and CM7 cores with Following Features:
• With and without OS support.
• With size and time optimization
• Using ABGR and ARGB format
• The FPU is enabled.
STemWin Library includes two optimized drivers:
• Direct linear access (LIN) driver. This kind of driver is used for
example on STM32F429, STM32F769, STM32H743 and any STM32
based on the LCD TFT Display Controller (LTDC) or LTDC/DSI (Display Serial
Interface) hardware.
• FlexColor (indirect access) driver for serial and parallel bus external LCD controllers.
A STemWin application can be built using or not an OS. On the application architecture presented above it’s a non-OS case.
![]() |
STemWin Structure |
STemWin Feature
Configuration
In addition to
the main application, the user has to configure two essential interface
files:
The configuration is basically divided into two parts: GUI configuration
and LCD configuration.
• LCD configuration file (LCDConf.c/.h)
LCD Display initialization
and configuration – LCD Display driver link and customizing – Additional
hardware capability management. The LCD configuration is more hardware-dependent and enables the user to
define the different graphical parameters, the display driver, the color
conversion routines to be used and the drawing accelerated function if the
STM32 support Chrom-ART.
• GUI configuration file (GUIConf.c/.h) – The GUI configuration covers
the configuration of default colors and fonts and of available memory.
1. GUI initialization
To
initialize the STemWin internal data structures and variables,
GUI_Init() should be used. Note that before initializing the GUI, the
CRC module (in RCC peripheral clock enable register) should be enabled A
simple “Hello world” program illustrates this initialization, as shown
below.
1.
Core functions
-
Image file display
STemWin currently supports the BMP, JPEG, GIF and PNG file formats. The library includes rich APIs for each one of these image format.
-
Bidirectional text
Drawing Arabic or Hebrew text with STemWin is quite easy and is
supported automatically in each text-based function. It only needs to
be enabled once by using the following command:
GUI_UC_EnableBIDI()
- Alpha blending
Alpha blending is a method combining the alpha channel with other
layers in an image in order to create the appearance of
semi-transparency. The user can enable automatic alpha blending
using the following command:
GUI_EnableAlpha()
He can also give an alpha value to determine how much of a pixel
should be visible and how much of the background should show
through: GUI_SetUserAlpha()
- Sprites and cursors
A sprite is an image which can be shown above all other graphics on
the screen. A sprite preserves the screen area it covers. It can be
moved or removed at any time, fully restoring the screen content.
Animation by use of multiple images is also possible. Sprites can be
animated by calling Command : GUI_SPRITE_CreateAnim().
STemWin also includes a system-wide cursor which can also be
animated by using GUI_CURSOR_SetAnim(). Cursors are actually based on
sprites. Although the cursor always exists, it is hidden by default.
It is not visible until a call is made to show it (GUI_CURSOR_Show()),
and may be hidden again at any point (GUI_CURSOR_Hide()).
1.
Memory devices
A memory device is a hardware-independent destination device for drawing operations. If a memory device is created (by calling GUI_MEMDEV_Create()) then validated (by calling GUI_MEMDEV_Select()), all drawing operations are executed in memory. The final result is displayed on the screen only when all operations have been finished. This action is done by calling GUI_MEMDEV_CopyToLCD(). Memory devices can be used:
• to prevent flickering effect (due to direct drawing on the display),
• as containers for decompressed images,
• for rotating (GUI_MEMDEV_Rotate()) and scaling operations (Figure8),
• for fading operations, • for window animations,
• for transparency effects.
Since memory devices need a considerable amount of memory.
it is advised to use an external memory if available.
1.
Antialiasing
Antialiasing
smoothest curves and diagonal lines by “blending” the background color with the
foreground one. This is done by adding intermediate colors between object and
background.
Shape
antialiasing STemWin supports antialiased drawing of:
•
Text (Font Converter is required to create AA fonts)
•
Arcs (GUI_AA_DrawArc())
• Circles (GUI_AA_FillCircle())
• Lines (GUI_AA_DrawLine())
• Polygons (GUI_AA_DrawPolyOutline() and GUI_AA_FillPolygon())
1.
Window Manager
Window
Manager can be described as:
•
A management system for a hierarchic window structure: – Each layer has its own
desktop window. Each desktop window can have its own hierarchic tree of child
windows.
•
A callback mechanism-based system: – Communication is based on an event-driven
callback mechanism. All drawing operations should be done within the WM_PAINT
event.
• The foundation of the widget library: – All
widgets are based on the functions of the Window Manager.
1.
Widget library
Widgets
(Window + Gadget) are windows with object-type properties. They require the
Window Manager. Once a widget is created, it is treated just like any other
window. The Window Manager ensures that it is properly displayed (and redrawn)
whenever necessary.
Widget
creation Creating a widget can be done with one line of code. There are
basically two ways of creating a widget:
•
Direct creation:
Creation
functions exist for each widget:
– <WIDGET>_CreateEx(): creation without
user data.
–
<WIDGET>_CreateUser(): creation with user data.
•
Indirect creation: “Indirect” means here using a dialog box creation function
and a GUI_WIDGET_CREATE_INFO structure which contains a pointer to the indirect
creation routine:
–
<WIDGET>_CreateIndirect(): creation by dialog box creation function.
A
list of all widgets available in STemWin Library can be found at: http://www.segger.com
1.
Fonts
The
most common fonts are included in STemWin Library as a standard font package.
All of them contain the ASCII character set and most of them also the ISO
8859-1 characters.
In
most cases, those fonts are found sufficient. However, if needed, STemWin also
supports several external font formats:
• System Independent Font (SIF) format
•
External Bitmap Font (XBF) format
•
TrueType Font (TTF) format
In
order to be able to use any desired font when building our application, STemWin
provides a tool called “Font Converter”. As a Windows program, it allows a
convenient converting of any PC installed font into a STemWin (bitmap) font
which can be easily integrated into our application.
1.
GUIBuilder
The
GUIBuilder is a tool for easily creating dialogs: instead of writing source
code, the user can place and size widgets by drag and drop. Additional
properties can be added via a pop- up menu. Fine tuning can be done by editing
the properties of the widgets. The GUIBuilder then generates some dialog C code
that can be either customized or integrated as is in the project.
•
Start with the FRAMEWIN or WINDOW widget: only those widgets are able to serve
as parent windows for a dialog.
•
Place the widgets within the parent window: the widgets can be placed and sized
by moving them with the mouse and/or by editing the properties in the property
window.
•
Configure the widgets: the pop-up menu shows the available options.
•
Save the dialog: each dialog is saved in a separate file. The filenames are
generated automatically, based on the name of the parent window.
Creation routine: The file generated using GUIBuilder
contains a creation routine for the dialog. The routine name includes the name
of the parent window: WM_HWIN Create<WindowName>(void); Simply call the
following routine to create the dialog:
hWin
= CreateFramewin();
User-defined code: The generated code contains a couple
of comments to add user code between them. To be able to read back the file
with the GUIBuilder, the code must be between these comments.
Callback routine: The main part of the generated file
is the callback routine. It normally contains the following message handlers: WM_INIT_DIALOG
The
widget initialization is done here immediately after creating all widgets of
the dialog. The user code area can be used to add further initialization. • WM_NOTIFY_PARENT
.It contains (empty) message handlers to be filled with user code. For each
notification of the widget, there is one message handler. Further reactions on
notification messages can be added.
1.
Porting GUI on a different resolution
The
setting of the GUI resolution is completely done on the “LCDConf.c” and it’s
very simple to go from one resolution to another.
The
variables “XSIZE_PHYS” and “YSIZE_PHYS” will be set on the “LCDConf.c” to
mention the physical screen size. Suppose that our screen has the resolution of
(800x480), the “LCDConf.c” have the following content:
/*
Define physical screen sizes */
#define
XSIZE_PHYS 800
#define
YSIZE_PHYS 480
These
variables will be used to initialize the hardware linked to the screen (ex: the
LTDC/DSI). The GUI resolution is then set using two other variables called
“XSIZE_0” and “YSIZE_0”. “0” correspond to layer “0”, so there are also
“XSIZE_1” and “YSIZE_1” if the layer “1” is used. Of course, the GUI resolution
must fit on the physical one.
#define XSIZE_0 XSIZE_PHYS
#define
YSIZE_0 YSIZE_PHYS
If
now the screen (or the GUI resolution) has to be modified, the variables have
to be modified as mentioned above.
Comments
Post a Comment