Jump to content

HTML2COLOR compile error on STM32F769 Discovery Board in SW4STM32

Andrew W

By Andrew W
in Support

 Share

Recommended Posts

Andrew W

Andrew W

Posted
Posted (edited)

Hello,

I am new to uGFX and evaluating the library for commercial use for a new product. I have reached a stumbling block with getting the library to run on on the STM32F769 demo board utilizing the internal STM32LTDC driver and an on-board SDRAM chip. We are utilizing the STM32F769 board as this is the same chip we intend to use on our finished board layout and developing the project in System Workbench based on Eclipse. I have downloaded the stable build of the uGFX library version 2.7. For my project, we are only concerned about utilizing the display module; no sound or touch input needed.

I have a working project setup that will initialize all the hardware and clear the display to a given color without uGFX. I then went to add in the uGFX library to the project using the very helpful guide on the wiki <https://wiki.ugfx.io/index.php/Using_Eclipse#Importing_the_.C2.B5GFX_library> and everything went smoothly right up until the last step

 

The project will compile without complaint if the GDISP module is disabled. After I added the board configuration file for the STM32LTDC driver, I then enabled the GDISP component in gfxconf.h and went to compile. I get back one error message that is repeated 6 times in the console, pertaining to gdisp_colors.h. 

<Censored_File_Path>/stm32 workspace/Discovery_LCD_uGFX/uGFX/src/gdisp/gdisp_colors.h:313:28: error: expected declaration specifiers or '...' before '(' token
   #define HTML2COLOR_R(h)  (((h) & ((0xFFL & ~((1<<(8-COLOR_BITS_R))-1))<<16)) >> (24-(COLOR_BITS_R+COLOR_SHIFT_R)))
                            ^

This makes the gdisp_lld_STM32LTDC.o object fail to build.

Why is this the case? This macro is just used to convert the red component of an HTML color to the specific board color, right? To try to troubleshoot, I replaced the macro with a constant to see if the project would build as follows: 

	#else // COLOR_BITS_R + COLOR_SHIFT_R < 24
//		#define HTML2COLOR_R(h)		(((h) & ((0xFFL & ~((1<<(8-COLOR_BITS_R))-1))<<16)) >> (24-(COLOR_BITS_R+COLOR_SHIFT_R)))
		#define	HTML2COLOR_R(h)		0
	#endif

However, the end result was an identical error. Commenting out the macro entirely just moves the error to the HTML2COLOR_G(h) macro.

I found this thread. It mentioned something near the end about manually editing the inclusions? Could this possibly be related or is there another cause?

 

Any help would be very greatly appreciated. I'd like to show our customer a simple demo sometime next week so we can pull the trigger and get a commercial license for the software. I can send you a ZIP of the project file I am working with if that would help.

 

Thanks,

 

Andrew W.

 

Edit: I just saw that yesterday support was added for utilizing both layers of the LTDC hardware and the Alpha values. Is this new feature possibly related to this issue?

Edited by Andrew W
Link to comment
Share on other sites
Joel Bodenmann

Joel Bodenmann

Posted
Posted

Hello Andrew and welcome to the µGFX community!

I'm currently siting in the train so I don't have all resources (and notes) available. However, I remember that there was a bug fix of the STM32LTDC driver after the v2.7 release (about 6 months ago). I'm not talking about the stuff that you mentioned that got pushed yesterday.

I'd like to encourage you to use the latest master branch of the git repository. If you included everything properly into your project you should be able to just replace the uGFX library directory.

If that doesn't help I'll try to dig into the notes - This can't be anything serious. We just created a demo project for another uses for the STM32F429i-Discovery and ChibiOS last week and everything worked out of the box. That is using the exact same STM32LTDC driver (although we used the latest master branch).
If you're not into the git version control system you can always just download the latest master branch as a ZIP file from the corresponding git website: https://git.ugfx.io/uGFX/uGFX 

Maybe @cpu20 has something to say to this too as he's somewhat of our community's IDE integration expert ;)

Link to comment
Share on other sites
Andrew W

Andrew W

Posted
  • Author
Posted

Ok, I pulled in the master branch instead, and got the same result. Its just on a different line number now :D. I'll come back and look at it some more tomorrow. 

<Censored_File_Path>/stm32 workspace/Discovery_LCD_uGFX/uGFX/src/gdisp/gdisp_colors.h:309:28: error: expected declaration specifiers or '...' before '(' token
   #define HTML2COLOR_R(h)  ((h) & ((0xFFL & ~((1<<(8-COLOR_BITS_R))-1))<<16))
                            ^

Also, I should have mentioned earlier that this project is running RAW32 with no OS in the middle. I do have gfxMillisecondsToTicks() and gfxSystemTicks() defined in my main file.

Let me know if you guys think of anything else to look into. Thanks!

 

Andrew W.

Link to comment
Share on other sites
Andrew W

Andrew W

Posted
  • Author
Posted (edited)

Aha! I found something.

At the top of gdisp_colors.h, some common colors are defined in terms of this macro. 

// gdisp_colors.h

/**
 * @name   Some basic colors
 * @{
 */
#define White			HTML2COLOR(0xFFFFFF)
#define Black			HTML2COLOR(0x000000)
#define Gray			HTML2COLOR(0x808080)
#define Grey			Gray
#define Blue			HTML2COLOR(0x0000FF)
#define Red			HTML2COLOR(0xFF0000)
#define Fuchsia			HTML2COLOR(0xFF00FF)
#define Magenta			Fuchsia
#define Green			HTML2COLOR(0x008000)
#define Yellow			HTML2COLOR(0xFFFF00)
#define Aqua			HTML2COLOR(0x00FFFF)
#define Cyan			Aqua
#define Lime			HTML2COLOR(0x00FF00)
#define Maroon			HTML2COLOR(0x800000)
#define Navy			HTML2COLOR(0x000080)
#define Olive			HTML2COLOR(0x808000)
#define Purple			HTML2COLOR(0x800080)
#define Silver			HTML2COLOR(0xC0C0C0)
#define Teal			HTML2COLOR(0x008080)
#define Orange			HTML2COLOR(0xFFA500)
#define Pink			HTML2COLOR(0xFFC0CB)
#define SkyBlue			HTML2COLOR(0x87CEEB)
/** @} */

 

However, there is a naming conflict with the color structure type definition in the HAL library header file for the DMA2D, used to write to the frame buffer. 

//stm32f7xx_hal_dma2d.h

/** 
  * @brief DMA2D color Structure definition
  */
typedef struct
{
  uint32_t Blue;               /*!< Configures the blue value.
                                    This parameter must be a number between Min_Data = 0x00 and Max_Data = 0xFF. */

  uint32_t Green;              /*!< Configures the green value.
                                    This parameter must be a number between Min_Data = 0x00 and Max_Data = 0xFF. */

  uint32_t Red;                /*!< Configures the red value.
                                    This parameter must be a number between Min_Data = 0x00 and Max_Data = 0xFF. */
} DMA2D_ColorTypeDef;

 

If I comment out the Red, Green, and Blue define statements for the colors in gdisp_colors.h, the project builds and runs. My board is showing the uGFX splash screen now :D.

Do the other demo boards, like the 746 and the 429, not have a dma2d and therefore don't have this conflict with HAL? Or perhaps my eclipse project is just setup incorrectly. Either way, that seems to be the root of the problem. I guess for now I will just define these three colors with a different name and reference them as such.

Andrew W.

 

Edit: Also, my colors are all swapped around too. Green is Red, Red is Blue, Blue is Green O.o.

Edited by Andrew W
Additional Information
Link to comment
Share on other sites
Joel Bodenmann

Joel Bodenmann

Posted
Posted

Hello Andrew,

That is a problem known to us. This has been an issue that came with one of the countless completely incompatible CubeHAL updates that ST pushes every so often. This is why all the board file come with the corresponding #undef. Here's ane example from the board file of teh STM32F439i-Eval board: 

// Avoid naming collisions with CubeHAL
#undef Red
#undef Green
#undef Blue

I'm not sure why this is missing in the STM32F746G-Discovery board files now. This definitely was there at some point. I'll go through the git history tomorrow to find the source of that.
In any case: The #undefs shown above are the proper solution. These naming conflicts are something that will be handled better in uGFX v3.0 that should be released in 2018.

Link to comment
Share on other sites
Andrew W

Andrew W

Posted
  • Author
Posted

Thank you Joel,

I shouldn't have made that mistake in the first place. Those undefs are in the 746G board files, but they are hiding in the stm32f746g_raw32_ugfx.c file instead of the board header file. So I missed those when doing my port to the stm32f769 board.

Thanks again,

Andrew W.

Link to comment
Share on other sites
cpu20

cpu20

Posted
Posted

Those undefs have never been in the board file as far as I can remember.
The reason this conflict does not occur in the example projects is because there (almost) all the unused HAL-components have been disabled to save code space. This also excludes the dma2d from the build and thus not giving any conflicts.

Of course the proper way to fix this is to add the undefs to the board file.

Link to comment
Share on other sites
  • 7 months later...
jurc192

jurc192

Posted
Posted

I am working on STM32F746 discovery board and had exactly the same problem! (single file inclusion)
Looking at the STM32F746 board file, I noticed there were no #undefs , so I copied
and pasted the #undef part from another (STM32F469i) board file - no it looks like this:

STM32F746 edited board file: 

/*
 * This file is subject to the terms of the GFX License. If a copy of
 * the license was not distributed with this file, you can obtain one at:
 *
 *              http://ugfx.org/license.html
 */

#ifndef _GDISP_LLD_BOARD_H
#define _GDISP_LLD_BOARD_H

/* Avoid naming collisions with CubeHAL. */
#if GFX_COMPAT_V2 && GFX_COMPAT_OLDCOLORS
	#undef Red
	#undef Green
	#undef Blue
#endif

#include "stm32746g_discovery_sdram.h"

[....and so on....]


There was another problem with inclusion of the _discovery_sdram.h in the same file. I didn't want to use  the BSP files included with uGFX,
but rather point to the downloaded version of stm32cubeF7 - to have everything in one place. I noticed that the official STM32 cube package has
misspelled the folder and file names of the BSP drivers for STM32F746 (missing the "F") - so I renamed the include in the board file to ommit the "f".

With this it compiles well! I would never figured this out without this Forum thread, so thanks! :)

Link to comment
Share on other sites
jurc192

jurc192

Posted
Posted

EDIT: I noticed that if I include the "stm32f7xx_hal.h" to "main.c", for example - the problem with color macro expansion comes back, despite having the undefs in the board file.
I think I will need this hal header file in the future - what should I do?

Link to comment
Share on other sites
jurc192

jurc192

Posted
Posted
On 17/05/2018 at 16:18, jurc192 said:

EDIT: I noticed that if I include the "stm32f7xx_hal.h" to "main.c", for example - the problem with color macro expansion comes back, despite having the undefs in the board file.
I think I will need this hal header file in the future - what should I do?

SOLVED: in your file (main.c, for example) you have to include stm32f7xx_hal.h FIRST and then gfx.h -> it then works okay.

It would be nice to put this into the documentation, since the example (on BareBones guide) has includes the wrong way around and it doesn't work (in my case at least)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...