Skip to main content
Sergei Tuchinski
Associate
December 28, 2017
Question

STM32CubeMx and STemWin

Posted on December 28, 2017 at 11:00

I'm trying to setup the STM32F7 device with the LCD driver using STM32CubeMx. But despite the description, I don't see the STemWin library in the Middleware tools list in the STMCube. What I'm doing wrong? Or what am I supposed to do in this case?

    This topic has been closed for replies.

    4 replies

    ST Technical Moderator
    January 2, 2018
    Posted on January 02, 2018 at 17:21

    Hello

    sergik.home

    ,

    Stemwin package still not supported in the CubeMx code generation.It should be added manually into project, by the user.

    You download the

    http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32-standard-peripheral-library-expansion/stemwin.html

    package from this Link and start with the application note

    http://www.st.com/content/ccc/resource/technical/document/application_note/54/c9/95/42/8c/0b/43/69/DM000896pdf/files/DM000896pdf/jcr:content/translations/en.DM000896pdf

    : 'Getting started with STemwin Library'.

    I recommend you have a look to the working examples under the STM32CubeF7 cube firmware package.

    Best Regards

    Imen

    In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Thanks
    Sergei Tuchinski
    Associate
    January 10, 2018
    Posted on January 10, 2018 at 08:08

    Thanks for your answer, I got it.

    Now unfortunately I've encountered the another unpleasant problem. The IAR compiler since the version 8.11 has changed the size of wchar_t type from 2 to 4 bytes (without the option to revert it, as far as I have understood). All the STemWin libraries (current version is 5.40) come in precompiled state, evidently with the 7.xx version (with the wchar_t size 2), but the STM32Cube generates IAR projects of new version (8.xx), which are not possible to be opened with 7.xx. So, despite my dislike of the new version, I have to use 8. So when I'm trying to link the project along with the STemWin, I predictably get the warning of 'incosistent wchar_t types'. The IAR site unambigously says that in this situation the behavior will be unpredictable, and recommends to rebuild the library. What could you recommend in this situation? Maybe there is any convenient way to convert the 8.xx project into 7.xx?

    I've found similar problem has been described in

    https://community.st.com/thread/40176-stm32-cyptolib-with-iar-811

    aaron.bauch
    Visitor II
    January 24, 2019

    The best solution of course will be when ST or Segger recompile the libraries using the current version of IAR Embedded Workbench.

    However another solution is to use the GCC library files instead of the IAR library files. This works because both tool chains generate ARM EABI standard ELF output modules which are cross-linkable with no problem. And the GCC tools have used 32 bit wchar_t types for some time since they are descended from the Linux/Unix world which has always represented a WCHAR as a 32 bit value, while the Microsoft Windows world has stuck with WCHAR at 16 bits as standard.

    So the GCC built libraries are link-able with your IAR built applications. However they represent wchar_t as 32 bits rather than 16 bits so the warning messages will not be generated.

    And as a final note, there are many people using the old STemWin libraries with current versions of IAR Embedded Workbench with no reported problems. This is likely because the GUI library does not actually ever use wchar_t even though the file header must report what it would use IF it were to use this type, causing the warning.