SW4STM32 IDE & uGFX configuration

[blacktronics]

Hey thanks for the help, it doesn't appear to work for me - i am pretty sure this is some weird eclipse thing.

I have attached the project here: STM32F746-Disco-broken.zip

[cpu20]

That's my bad. I forgot to mention that in the "userfonts.h" file I changed the include to:

#include "../rsc/DejaVuSans16.c"

Normally you don't have to do this when you put the rsc folder inside the inc folder. But for some reason Eclipse wasn't including the file correctly then. I have no idea why though...

[blacktronics]

I have the odd impression that I am managing to run into every single issue that i could possibly run into...
I edited the include in userfonts.h

[cpu20]

Did you add the rsc folder to your projects "Source Location"? Because that could be throwing all those errors.

[blacktronics]

yeah it's in there

[cpu20]

9 minutes ago, blacktronics said:

yeah it's in there

So does removing it from the source location solve your problem?

[blacktronics]

Oh i mis-read that initially as needing to be in there, removing it fixed it, it builds now.

However, once flashed the display only shows garbage similar to what is seen during startup of the example project you provided.
Looking at the structure of the garbage, it looks like some horizontal misalignment.

[cpu20]

Oh, I'm just stupid. The board isn't being initialized You can remove the HAL_Init() from your main file and add this to your gfxconf.h:

#define GFX_OS_PRE_INIT_FUNCTION 				 Raw32OSInit

That should do the trick

[blacktronics]

amazing, it works now and displays.
Touchscreen does not seem to work yet though - do i need to handle this separately? is there a guide somewhere?

[cpu20]

In your file gui.c search for the function called guiEventLoop() and there change the event function to:

pe = geventEventWait(&glistener, TIME_INFINITE);

For the rest hop over to the wiki and let's get started

[blacktronics]

Amazing, it works now!

Thanks a lot for the help - one more question though - is it intentional that the sliders snap back to where they were when you release outside of the bounding box of the slider? Is there a way to disable that?

[Joel Bodenmann]

Yes, that is intentional and yes, you can disable that by setting GWIN_SLIDER_NOSNAP to TRUE in your configuration file. 

Here's a copy of all the default values. It's taken from the example config file named gfxconf.example.h that you find in the top-level directory of the µGFX library distribution:

    #define GWIN_NEED_SLIDER                         FALSE
        #define GWIN_SLIDER_NOSNAP                   FALSE
        #define GWIN_SLIDER_DEAD_BAND                5
        #define GWIN_SLIDER_TOGGLE_INC               20

 

[blacktronics]

Setting GWIN_SLIDER_NOSNAP to TRUE does not appear to work, it still does the snapping.

[inmarket]

Don't forget to do a "make clean" and then recompile.

[blacktronics]

I did, it just doesn't seem to change anything on the snapping behaviour.

[cpu20]

Isn't what @blacktronics is referring to the GWIN_BUTTON_LAZY_RELEASE option?

 

[blacktronics]

1 minute ago, cpu20 said:

Isn't what @blacktronics is referring to the GWIN_BUTTON_LAZY_RELEASE option?

 

That did it! Thanks!

[Joel Bodenmann]

Sorry, my bad!

[Dvor_nik]

 

@cpu20 Could you tell me please, what did you exactly fix in includes? I tried update HAL for project's template from site (simple changed it in project to last version), but have compile error with touch and colors macros:

 

Makefile's version compiles OK with last HAL. 

Edited September 11, 2017 by Dvor_nik

[cpu20]

The fix I just uploaded is just setting the event timeout to TIME_INFINITE. Else the event timer gives an immediate timeout which isn't caught.

That however has nothing to do with the color errors you are getting. The problem you see with the colors is due to the fact that both µGFX and the HAL_drivers use the names red, green and blue for their color naming schemes. Thus they conflict when you try to compile the program.
Those conflicts can be fixed by excluding the files in the HAL_driver that use those color names. The conflicting ones, if I remember correctly are the DMA2D driver and the LTDC driver. Normally you'll never need those HAL-drivers when using µGFX so you can simply exclude them from your build.
For more details on which files are excluded from build in the example project check the stm32f7xx_hal_conf.h file. (Note that when overwriting the HAL_driver in the project you also loose this file. But you do need this to make the HAL work!) All included drivers are listed there. You don't need many of them to make your program work, so play it safe and exclude everything you don't use.

I made another mistake in the example project btw. The stm32f7xx_hal_conf.h file should be located in the inc folder of the project. It is very bad practice to put it in the HAL_driver folders. I will fix that as soon as possible.

[Dvor_nik]

Thank you, @cpu20. I got a lot of useful information from you again. I was absolutely sure that hal_conf.h file in inc folder  I successfully updated HAL now to last version 1.2.3 (there are many fixes in release note). 

 

 

[Dvor_nik]

@cpu20 Small issue in gfxconf.h:

#define GFX_CPU                                  GFX_CPU_CORTEX_M7_FP  // correct
#define GFX_CPU                                  GFX_CPU_CORTEX_M7_FPU // wrong

 

[Oshel]

Hello @cpu20,

Could you please tell me what have you done to make your template working? I am trying to follow all the steps with newest ugfx library and FreeRTOS- although FreeRTOS is not a problem here (I guess). I will tell you now what am I doing- step by step:

1. Creating new C project with clear STM32F745 MCU with HAL library and FreeRTOS included.
2. Importing ugfx library.
3. Adding the folder with ugfx to source location in project properties- I exclude every file except gfx_mk.c and gdisp/STM32LTDC folder.
4. I add in Paths and Symbols in project properties paths to ugfx and gdisp/STM32LTDC.
5. I copy files from boards/base/STM32F746-Discovery to src and inc directories.

In this moment, imho, it should work. But I constatly get these errors. Could you please tell me how did you get is running?

Btw, I am trying to run the display only now.

 

Edited September 18, 2017 by Oshel

[Oshel]

Well, I managed to get rid of the HAL errors by including HAL files in order taht you did in your project.

But now I am facing these problems:

Type 'bool_t' could not be resolved	gdisp_lld_STM32LTDC.c
Type 'systemticks_t' could not be resolved	stm32f746g_discovery_sdram.c

And these problems are related with FreeRTOS. These types are present while raw32 is used- but there is no such definitions in gos_freertos.h file.

Edit:

I did remove errors by:

1. In file stm32f746g_discovery_sdram.c in line 261 (_FMC_SDRAM_SendCommand function) I replaced systemticks_t to uint32_t.

2. In file gdisp_driver.h I added "typedef int8_t bool_t;" right after "#if GFX_USE_GDISP".

Funny fact is that bool_t type should be included while using FreeRTOS- it is in gos_freertos.h.

So, although it compiles, I am sure that I did not do this right way...

Edited September 18, 2017 by Oshel

[Oshel]

Well, finally I compiled the code without modifications in the library. I do not know how eclipse is linking the files but it just "started" to work at some point. I dunno wtf.

If any1 would like to use the code or just check, here it is:

https://drive.google.com/file/d/0BzNqKTMmGSjXeUNzbjlxV29CTms/view?usp=sharing