cpu20

Sorry for the late response. It has been a while that I looked into this. You need to add #include "gfx.h" at the top of your board file "board_ILI9225.h".

Can you post your project again?

This is indeed an IDE feature. It's called the Indexer in Eclipse. The indexer will search through all files you tell it to search through in the settings and tries to warn you when something is missing/might be wrong. You can completely configure the error and warning levels of the indexer. But if the indexer gives an error/warning this does not mean that the project won't build. The compiler and indexer can be configured independently of eachother. You should read this to understand how the compiler and the linker work. In short, the compiler produces object files for each source file you provide (.c, .s, .cpp,...) and the linker puts them all togheter to get the final program. Due to the fact that the compiler compiles every file independently it will not complain if two files contain a function with the same name. However when the linker is putting everything togheter and it finds two different function implementations with the same name, it does not know what to do. If you call the _init() function in this case it does not know which implementation you want to call. The _init() function used here is already implemented in newlib I think (I could be wrong though, it has been a long time since I dug into this) so you should not implement it again in your own code.

Just commenting out the _init() function does the trick for me:

Does the error change after you comment the _init() function in stm32f439i_raw32_ugfx.c? Anyway you should do a clean build to make sure there are no old binary files that get linked in. Can you give the compiler output? I doubt that the IDE is buggy. It's based on Eclipse which is a well known and widely used IDE. It can just be tricky to initially set up the project. If you post your project I can take a look to see if something is wrongly configured.

I should have looked closer.The compiler says exactly where it found the second defenition of the init function. The gnu arm libraries already contain an _init function. Just delete the _init() function from the stm32f439i_raw32_ugfx.c file.

The type name gU32 is defined in "gfx_types.h". You should include this in your build.

Everything you did look OK to me. Could it be that something is wrong in the file stm32l1152RE_raw32_ugfx.c? Can you attach it here?

In the last image you sent inidcates that you haven't correctly included the gdisp configuration file. Adding files to be included in the build is done in the Properties window of your project. Go to: C/C++ General > Paths and Symbols > Includes In that window you need to add all the folders that contain .h files that need to be included in your project for example the folder containing the "gdisp_lld_config.h". Sorry for my late reply. If you have any questions don't hesitate to ask.

With Makefile approach do you mean using the Makefile system provided by uGFX? Because then you need to make a Makefile project in Eclipse. When you create a C project in Eclipse, it will create a Makefile for you depending on how you configured the project. When you create a Makefile project, Eclipse will not generate any makefiles and use the Makefile you provide. What you are currently doing is manually configuring the whole Eclipse project to compile correctly. That is a very difficult process, but I think it is possible.

uGFX is a graphics library that makes abstraction from the hardware that you use. So you can write a prom that uses the uGFX library to draw things on the screen, reads user input etc.. without knowing what hardware you are using (in theorie). To make the program work with your specific hardware setup, a gdisp driver must be written for your hardware setup. All existing drivers can be found in drivers/gdisp (take a look there to get an idea). The display driver file is called gdisp_lld_xxx.c So in order to make uGFX work with your EPaper display you need to write a driver for it. An example of a driver for an EPaper display can be seen here: After writing the display driver, there is also a file needed that implements the interface between your specific MCU and the display. This file is called board_xxx.h The board file includes functions that send data to the display over a certain interface (depending on the display used). In your case the display uses SPI so the board file will contain functions that use SPI to send data to the display. For an example see the post above. To summarize, you will have to write a driver (gdisp_lld_xxx.c) for your EPaper display and a board file (board_xxx.h) that implements the SPI interface between your MCU and the display. If you have any questions don't hesitate to ask. EDIT: I did a quick google and it seems that the 2.9inch and 2.13inch EPapers are quite the same. It might be possible to copy the driver in the post above and just change the resolutions of the display in gdisp_lld_xxx.c

From your screenshots it seems that you included all the sources correctly. Not only the uGFX folder has to be included under "Paths and Sybmols", but also your gdisp driver folder. In your case you need to add the drivers/gdisp/ILI9341 folder to your "Paths and Symbols". This should fix the error.

I would start by increasing the stack size of your intialization thread: osThreadDef(defaultTask, StartDefaultTask, osPriorityNormal, 0, 128); 128bytes might not be enough to initialize everything.

This is most likely caused because you don't have any file that implements the memory system calls. These calls are system dependent and normally the manufacturer of your platform provides these functions. You can also let µGFX handle memory management by setting GFX_OS_HEAP_SIZE to a non zero value.

In your board file, you drive the chip select pin of your display. You should not keep that line constantly low or anything because that can lead to unwanted situations. The chip select line should be lowered and raised in the acquire and release bus functions. Other than that I have no idea if the ST7735 driver is functional. Last time it came up there were some issues with it.

That board file uses the Chibios HAL to drive the display. Make sure you have Chibios set up correctly first.

According to the datasheet of the ST7586 the controller has a built in GRAM. So in theory you should not need a full framebuffer on the MCU. Reading from the displays GRAM is according to the datasheet only possible when using the parallel interface. So when using SPI it won't be possible to do this. Otherwise this would probably be the best solution to use the least resources. Some designers make some very weird decisions... When not using the parallel interface, I don't think it will be possible to omit the framebuffer. I think the easiest approach is to keep the framebuffer but only do partial flushing. The controller supports setting a window for the GRAM. So set the window and only write the data that changed.

Just to be sure: When using the gfxInit routine, does the object still get altered in your main? Maybe the problem is not your GuiLoop.

At first sight it seems that the xQueue you give to the xQueueGenericReceive function is not intialized correctly. Maybe something is going wrong with the heap manager when using µGFX? Could you show us the code where you initialize FreeRTOS and µGFX?

That is normal behaviour as you ask to wait indefinitly for an event that never comes. Biggest chance is that the failure is somwhere in the STMPE811 driver. I will look at your code tomorrow to see if I can catch something.

On embedded systems the increased resolution isn't always a benefit as it will increase your required RAM-size significantly and also the data throughput to your display. Be sure to consider those drawbacks also especially when dealing with animations. As the drivers for both displays are already included in µGFX they are both fully supported. As for the speed, my guess would be that the MCU will be the deciding factor. If you are just starting to experiment which these things and want to experiment more I would recommend the STM32F746G-Discovery board. This board is fully supported by µGFX, is very popular and already has alot of peripherals on board. Also the display is already reasonably large.

After creating a program in SW4STM32 and experimenting a bit, it is clear that the method using the uGFXMain() will never work. As stated here no delays are possible before the scheduler is started. The Init function you were using in your first post and starting the scheduler yourself will be the way to go. While trying to get a project up and running it took me quite some tries to get everything right to work together and I bounced into a problem in the board_stm32ltdc.h The stm32f7xx_hal_rcc.h and stm32f7xx_gpio.h need to be replaced with stm32f7xx_hal.h to work properly with the latest HAL libraries. Anyway here is the result if anyone would be interested. STM32F746-Disco-FreeRTOS.zip

Are the SCB_EnableICache() functions giving errors? I think to use those you also need to add #include "stm32f4xx.h" I have no idea what could still be going wrong. When I got some spare time, I will try to setup a project and see what could be wrong.

An example project is now available in the downloads section!