STM32CubeMx and STemWin

[Sergei Tuchinski]

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?

[Imen.D]

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

[Sergei Tuchinski]

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

[zootroop]

Posted on March 03, 2018 at 12:22

Strange it is not implemented in CubeMX. The following lines in

/external-link.jspa?url=http%3A%2F%2Fwww.st.com%2Fcontent%2Fccc%2Fresource%2Ftechnical%2Fdocument%2Fapplication_note%2F54%2Fc9%2F95%2F42%2F8c%2F0b%2F43%2F69%2FDM000896pdf%2Ffiles%2FDM000896pdf%2Fjcr%3Acontent%2Ftranslations%2Fen.DM000896pdf

on page 1 say: 'This graphic library is fully integrated inside the STM32Cube firmware package (such as STM32CubeF2, STM32CubeF3 and STM32CubeF4

). It can be downloaded free from STMicroelectronics web site (

/external-link.jspa?url=http%3A%2F%2Fwww.st.com%2Fstm32cube

)'.

It is known CubeMX is a total intergration of all STM32CubeF0...F4.

What happened?

The issue here is when people want to implement STemWin in a project where the ARM board and the TFT board are two separate items. As a result they will not assign an evalutation board containing a TFT screen. But what is interesting, not even assigning evaluation boards having a TFT screen embedded does result in STemWin being included in the Middleware section. There's a lot going on however the STemWin library is still not implemented in the generated code destined for the IDE of choice.

[aaron.bauch]

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.