Simon

I mean the Makefile approach shown here and in the image below rather than the Single file inclusion approach. I guess the issue I have encountered is that I can create a Makefile project and tell it to use the uGFX makefiles but how do I then incorporate my own code and tell Eclipse to include that in the builds.

Thanks @inmarket I appear to be winning, I've got a clean compile but execution is failing in initialisation. I'll post an update when I've sorted all the problems out.

Hi, In the past I have successfully built uGFX using the single file inclusion approach (notwithstanding issues with the sdram code - see later). I want to use the Makefile approach so it is easier to incorporate bug fixes made to uGFX. I have looked at the CibiStudio wiki post to try to replicate the same in Eclipse. The steps I have taken are: created a new C project for the STM32F746-Discovery board including firmware version 1.9 Made a link to the cloned uGFX repository: Added exclude filters for source files in the following folders: boards/addons boards/base (excluding STM32F746-Discovery folder) demos drivers/gdisp (excluding STM32LTDC folder) drivers/ginput (excluding touch/FT5336) drivers/multiple src/gfile Added the ugfx folder linked to above to the Include path Renamed 'board_STM32LTDC_template.h' to 'board_STM32LTDC.h' Added ugfx/drivers/gdisp/STM32LTDC to the Include path to reolve an inclusion issue Created a userfonts.h file in ugfx/src/gdisp to resolve a missing dependency issue Excluded all .c font files in ugfx/src/gdisp/fonts from the build (I figured I could sort the fonts problem out later) Added ugfx/boards/base/STM32F746-Discovery to the Include path On compiling I now get the error: In file included from /home/simon/uGFX-git/ugfx/drivers/gdisp/STM32LTDC/gdisp_lld_STM32LTDC.c:94:0: /home/simon/uGFX-git/ugfx/drivers/gdisp/STM32LTDC/board_STM32LTDC.h:22:20: error: 'SDRAM_DEVICE_ADDR' undeclared here (not in a function) Finished building: /home/simon/uGFX-git/ugfx/drivers/ginput/touch/FT5336/gmouse_lld_FT5336.c (LLDCOLOR_TYPE *)SDRAM_DEVICE_ADDR, // Frame buffer address My problems with the single file include method as mentioned above is the the file stm32f746g_discovery_sdram.c is duplicated in the uGFX repository but with reference to a header file called stm32f746_discovery_sdram.h but the version of stm32f746g_discovery_sdram.c included in the firmware references a header file called stm32746g_discovery_sdram.h If I proceed to try and resolve this problem it becomes very messy and I didn't document how I have resolved it with the single file inclusion method. So, two simple questions (!): is this the correct way to implement the makefile approach in Eclipse? how to correctly resolve the issues caused by the sdram files? Thanks Simon.

Thanks for confirming my findings @cpu20 I have your demo project running :-)

Of course, some of the functions I added should actually be in a FreeRTOSInit routine to be specified by GFX_OS_PRE_INIT_FUNCTION like the attached file but I get a compile error when I try to include this. stm32f746g_freertos_ugfx.c

Hi @cpu20, as you predicted using HAL_Init and setting up the RCC clock and changing gfxSleepMilliseconds to look like this: void gfxSleepMilliseconds(delaytime_t ms) { HAL_Delay(ms); } ...works as no FreeRTOS commands are used until the OS is initialised. However, using uGFX to initialise FreeRTOS still doesn't work so I have set GFX_OS_NO_INIT to TRUE and initialised it myself. The touchscreen doesn't work but that's a problem for the weekend.

You are correct. I'll try it.

Hi @Joel Bodenmann do you mean this wiki article? It is quite likely that my configuration is at fault so my next step is to take a working FreeRTOS demo and add uGFX to it.

Not for FreeRTOS it doesn't. vTaskStartScheduler is called from function _gosPostInit (in gos_freertos.c) right at the end of gfxInit. I notice that in gos_chibios.c and gos_cmsis.c the OS is initialised at the start of gfxInit so I presume this is a simple mis-placement of code. I'll look at it tonight or tomorrow and see if moving the initialisation of the OS to _gosInit resolves the issue.

Actually, the problem arises before uGFX initialises FreeRTOS. During the board init the BSP_SDRAM_Initialization_sequence routine is called. In the version of stm32f746g_discovery_sdram.c included with uGFX the call to HAL_Delay(1) included in the ST version of this file is replaced with gfxSleepMilliseconds(1), which actually runs the FreeRTOS command vTaskDelay, but because FreeRTOS has not been initialised at this point it eventually fails and goes into default error handler. I'll have a deeper look later today but in the meantime if anyone know a fix please let me know :-)

Hi @inmarket, do you mean something like this: int main(int argc, char* argv[]) { (void)argc; (void)argv; gfxInit(); } void uGFXMain() { /* Create GUI task */ xTaskCreate(GUIThread, "GUI_Thread", 16384, 0, 1, 0); } static void GUIThread(void* pvParameters) { (void)pvParameters; gdispSetBacklight(100); gdispSetContrast(100); vTaskDelay( 200 ); geventListenerInit(&glistener); gwinAttachListener(&glistener); guiCreate(); /* Gui background Task */ while(1) { guiEventLoop(); } } In this instance gfxInit does not try to initialise FreeRTOS and so when it executes the gfxSleepMilliseconds, which expands to the FreeRTOS command of vTaskDelay, it eventually fails and goes into the infinite loop default handler. The first part of my gfxconf.h file contains: #define GFX_USE_OS_FREERTOS TRUE #define GFX_CPU GFX_CPU_CORTEX_M7_FP #define GFX_OS_HEAP_SIZE 16384 #define GFX_OS_CALL_UGFXMAIN TRUE So, I suspect they key question is how do I get gfxInit to initialise FreeRTOS. BTW, I cloned the git repository last night so I am using an up-to-date version. FreeRTOS is v9.0.0 supplied with STM32Cube v 1.8.0 (latest version).

Hi@inmarket As suggested by @Joel Bodenmann I was just completing my stepping through of the program. The issue is caused when the gfxSleepMilliseconds routine is called. FreeRTOS then looks to run other tasks (or the idle task) but never returns to gfxInit when the desired delay is completed. I will try your suggested option 2 now.

I've been trying to get uGFX running with FreeRTOS on an STM32F746-Discovery board. I've got uGFX working and I've got FreeRTOS working, however, I cannot get them to work together. I understand that gfxInit has to be run in a non-looping task that is defined before the scheduler is started. However, gfxInit never returns so the GUI task never gets created. If I define the GUI task before starting the scheduler it doesn't execute either. I have #define GFX_USE_OS_FREERTOS TRUE defined in gfxconf.h and my code is: int main(int argc, char* argv[]) { (void)argc; (void)argv; // Create the initialization task xTaskCreate(uGFXInit, "uGFXInit", 1024, 0, 1, uGFXInitHandle); // Start the scheduler. vTaskStartScheduler(); /* We should never get here as control is now taken by the scheduler */ for(;;); } static void uGFXInit(void* pvParameters) { (void)pvParameters; gfxInit(); /* Create GUI task */ xTaskCreate(GUIThread, "GUI_Thread", 16384, 0, 1, 0); vTaskDelete(uGFXInitHandle); } static void GUIThread(void* pvParameters) { (void)pvParameters; gdispSetBacklight(100); gdispSetContrast(100); vTaskDelay( 200 ); geventListenerInit(&glistener); gwinAttachListener(&glistener); guiCreate(); /* Gui background Task */ while(1) { guiEventLoop(); } } I am thinking that I need to use GFX_OS_CALL_UGFXMAIN but cannot work out how to specifically. The behaviour I am seeing is that gfxInit gets called but never returns and it looks like the FreeRTOS idle task is running continuously after this point. As the FreeRTOS page on the wiki says that the "FreeRTOS port works out of the box without any modifications" I may be way off track here but would appreciate advice on the correct way to get FreeRTOS and uGFX to work together.

Thank you! I'm sure I had already tried that but.... It's working fine now, I have excluded several of the stm32746g_discovery_*.c files from the build, e.g. in addition to not needing the lcd module I don't need the camera module. Now, perhaps, I can start to do something more interesting rather than grapple with compile problems

Hi, I'm got the uGFX demos working and I also have the STM32F746-disco project working. This is the project that was posted to show the fix for the problem caused by the ST HAL and the duplication of colour names Red/Green/Blue between the ST HAL DMA2D component and uGFX. However, I am now trying to go one step further and get the LED blinking on the board (small steps!). To do this I have copied the STM32F746-disco project and added an include to the main.c (stm32746g_discovery.h) and a statement to init the LED as below: #include "gui.h" #include "gfx.h" #include "stm32f7xx.h" #include "stm32f7xx_hal.h" #include "stm32746g_discovery.h" int main(int argc, char* argv[]) { (void)argc; (void)argv; BSP_LED_Init(LED1); gfxInit(); I have also added the directory with the STM32F746 modules into the build: However, this causes compile errors which are solved by defining the appropriate defs in the stm32f7xx_hal_conf.h file. These are for UART, I2C, SAI, TIM, DCMI and DMA2D. As has been reported before the DMA2D module has defines included for Red/Green/Blue and thus the HTML2COLOR macro causes the compile to fail: arm-none-eabi-gcc -mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv5-sp-d16 -DSTM32F746G_DISCO -DSTM32F746NGHx -DSTM32F7 -DSTM32 -DDEBUG -DUSE_HAL_DRIVER -DSTM32F746xx -I"/home/simon/ARM-radio/test-uGFX/inc" -I"/home/simon/ARM-radio/test-uGFX/HAL_Driver/Inc" -I"/home/simon/ARM-radio/test-uGFX/CMSIS/core" -I"/home/simon/ARM-radio/test-uGFX/CMSIS/device" -I"/home/simon/ARM-radio/test-uGFX/uGFX" -I"/home/simon/ARM-radio/test-uGFX/uGFX/drivers/gdisp/STM32LTDC" -I"/home/simon/ARM-radio/test-uGFX/uGFX/drivers/ginput/touch/FT5336" -I"/home/simon/ARM-radio/test-uGFX/uGFX/src/gdisp/mcufont" -I"/home/simon/ARM-radio/test-uGFX/rsc" -I"/home/simon/ARM-radio/test-uGFX/Utilities/STM32746G-Discovery" -O0 -g3 -Wall -fmessage-length=0 -ffunction-sections -c -MMD -MP -MF"uGFX/drivers/ginput/touch/FT5336/gmouse_lld_FT5336.d" -MT"uGFX/drivers/ginput/touch/FT5336/gmouse_lld_FT5336.o" -o "uGFX/drivers/ginput/touch/FT5336/gmouse_lld_FT5336.o" "../uGFX/drivers/ginput/touch/FT5336/gmouse_lld_FT5336.c" In file included from /home/simon/ARM-radio/test-uGFX/uGFX/src/gdisp/gdisp.h:221:0, from /home/simon/ARM-radio/test-uGFX/uGFX/gfx.h:214, from ../uGFX/drivers/ginput/touch/FT5336/gmouse_lld_FT5336.c:8: /home/simon/ARM-radio/test-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)) ^ /home/simon/ARM-radio/test-uGFX/uGFX/src/gdisp/gdisp_colors.h:329:39: note: in expansion of macro 'HTML2COLOR_R' #define HTML2COLOR(h) ((COLOR_TYPE)(HTML2COLOR_R(h) | HTML2COLOR_G(h) | HTML2COLOR_B(h))) ^ /home/simon/ARM-radio/test-uGFX/uGFX/src/gdisp/gdisp_colors.h:87:16: note: in expansion of macro 'HTML2COLOR' #define Blue HTML2COLOR(0x0000FF) ^ /home/simon/ARM-radio/test-uGFX/HAL_Driver/Inc/stm32f7xx_hal_dma2d.h:69:12: note: in expansion of macro 'Blue' uint32_t Blue; /*!< Configures the blue value. ^ The undef's that have been included in uGFX files don't appear to resolve this problem. My feeling is that there is a step that I have missed but I have spent quite a lot of the last three days trying to get my head around this and can't see what to do. Any help would be appreciated :-) Thanks Simon.