cpu20

The 2.7 version is the stable release. To have the latest version of µGFX you should use the git repository. You can find more information about this on this wiki page.

@Joel Bodenmann thanks for those recources!!! They are really usefull! The only thing I can't get working is the generation of the .map file using the makefile approach. When I add the flags: -Map=filename.map to the linker flags in my 'single file inclusion mechanism' projects it generates the .map file as expected. But adding -Map=filename.map to the LDFLAGS in the makefile throws me an unrcognized option. Any idea how to solve that?

In your provided screenshots you did everything correctly to include µGFX into your project. The conflicts you are seeing with the colors Red, Green and Blue are probably due to a redefinition in your application. Can this be resolved by renaming them in your application? Are those the only problems you are still having when compiling with IAR? Because you should be really close now to get a successful build.

How do I check if that is the case? I am not that experienced with debugging RTOS program's.

@Joe Stepien : Maybe it's a good idea to start a new project to first get µGFX compiling correctly using the single file inclusion mechanism. Here is what I did to get µGFX working in IAR embedded workbench: - First start with a clean project and include µGFX in the Preprocessor include directories. For this right click on your project, click on options -> C/C++ Compiler -> Preprocessor - Do this for Assembler also - Next you'll need a gfxconf.h file. I made a directory Inc and placed the template found in "uGFX/gfxconf.example.h" into the directory. For this example I only enabled GFX_USE_OS_RAW32 and nothing else just for basic compilation. - Repeat above steps to include the folder where you saved your "gfxconf.h" in the C/C++ Compiler and the Assembler tab - Now add the "gfx_mk.c" to your project. IAR automatically includes it to build. Compilation should now be successful. Now you can edit the "gfxconf.h" to include all the modules you want. Let us know if you have any other problems compiling! (Please attach the full compiler output so we can see what exactly is going wrong while compiling)

So I have been playing around with the µGFX and ChibiOS configurations in a clean new project to see what happens. What I found is that when setting CH_CFG_MEMCORE_SIZE to something like 4096 so that ChibiOS does not manage all of the RAM gfile works as expected. But when setting this to 0 (manage all RAM) things get very very weird. I don't think I can really describe what is happening as it seems partially random. It does open a file and read from it, but the file read from is almost never the one given to the gfileOpen function. You should really test it out for yourself. Just make three files on an SD-card, and read from them one by one, closing the previous one before opening the other. Could it be that when ChibiOS manages all of the RAM, it also manages the SDRAM but doesn't know the LTDC is using that?

When using fatfs directly with chibios (not using gfile) everything works fine. So something is going wrong when using gfile. Have there been other issues with gfile and chibios in the past? Or is this again platform specific (STM32F746-DISCO)?

Something goes wrong when allocating memory for the file object I think. It allocates memory from the heap, but I already experienced problems when chibios creates threads using memory from heap. The threads start acting very weird. I have no idea what could be wrong with this. I'll look into it further tomorrow.

Well if you accidentally select the "src" map when excluding files with the filter it could be that Eclipse excludes your "gfx_mk.c" file again. But looking at your included screenshot everything went well. I can't explain why this would make any difference. Normally the "gfx.h" file is already included by including the uGFX folder in your include paths. You can keep it removed from the filter list as it should not be a problem.

Alright so I started from scratch in Eclipse and just build a project with the single file inclusion system: First go to the paths and symbols and add the root uGFX directory to the include paths in all the languages. (for me this was assembly, GNU, GNU C++) Here you can also include the directory holding the driver files for your specific display. To this again for all languages. Now you need to exclude all sources except the gfx_mk.c: Do this by clicking on edit filter -> add multiple. Now select everything except the gfx_mk.c and do not select the src map! To include your drivers later on you have to delete the "drivers" line out of the filter lines. Then add multiple again and select everything in the driver folder except for your driver file. Copy a fresh gfxconf.h in your include directory and it should compile. At least it does for me.

Yes. Later on you can include the files from the drivers you want to use by editing the filter again.

To add source files/folders to your project, you first go to the properties of your project. Then go to C/C++ General -> Paths and Symbols -> Source location. Here you can add the ugfx folder and use a filter (Edit filter) to only include the gfx_mk.c to the sources of your project.

I have used gfile and fatfs together with the STM32 HAL libraries and everything worked fine. But now I am trying to use gfile and fatfs together with chibios and strange things happen. First the filesystem mounts correctly and gfile can open a file from the filesystem and read from it. But when closing the file and opening another file, things start to get weird. The gfileOpen function just returns the same GFILE it also gave back when opening the first file instead of the GFILE for the new file. File1 = gfileOpen("/File1", "r"); // Opens file and reads from it correctly gfileRead(File1, &Buf, 4); gfileClose(File1); File2 = gfileOpen("/File2", "r"); // The returned GFILE is the same as the gfileRead(File2, &Buf, 4); // File1 gfileClose(File2); So in this example the first file will be opened, read from and closed again. Now when the second file is opened, the GFILE returned by gfileOpen is exactly the same as the one that was returned for File1. So the same file is read again. Now here is where it starts to get really confusing: File1 = gfileOpen("File1", "r"); // File1 and File2 are opened File2 = gfileOpen("File2", "r"); // and read from correctly gfileRead(File1, &Buf, 4); gfileRead(File2, &Buf, 4); gfileClose(File1); // Opening files after this will return gfileClose(File2); // the File1 GFILE... When doing this it opens the two separate files, reads from them and closes them. And now when trying to open another file after these two have been closed, the same GFILE will be returned as the one that was returned for File1. Any ideas on what I could be doing wrong? Or what could be going wrong? I am using the STM32F746-disco again for this. As opening and reading the first file works I doubt that it has something to do with the SDMMC1 configuration.

If the IDE is eclipse based you should be able to make a "makefile" project. You just choose new -> C/C++ -> Makefile project with existing code. Import your own code into the project and also a template makefile (or a filled in makefile if you already made one). When building your project now it will use your own included makefile to build the project.

If you have written the board_ST7735.h file yourself you should be able to get it working with this µGFX version: https://github.com/cpu20/uGFX-ST7735-fix- Let me know if it compiles for you.

I've tried compiling a project with the st7735 driver and indeed it throws these errors. I tried to fix some of them but now I get linking problems. I'll try to look into it tomorrow.

That is a nice development board! Maybe I'll be buying it in the future to debug on it. But for now I don't have anything I need from Farnell. I read the forum thread about the board, but I could not find any files that were created already. Could you send them to me? I'll try to look into it and see what I can do.

I pulled in the new uGFX repository and a fresh copy of ChibiOS and it works like a charm now! I deleted the Github repo as it is no longer needed. Thanks alot for all the suggestions and hard work!

Great! I'll pull the new version in and test it asap!

I have posted the current problems on there forums. Hopefully they will fix it soon. You can follow the status here: http://www.chibios.com/forum/viewtopic.php?f=35&t=3983

The repo is: https://github.com/cpu20/uGFX-Chibios-STM32F7 It's no problem for me to report back to the ChibiOS people. Should I contact them via mail, forum or report a bug on their GitHub page?

Big morning today because it's fixed!!! In the end there were two problems related to the GPIO why the whole thing did not work. The pins PG8: FMC_SDCLK and PI12: LCD_DISP_PIN were configured incorrectly thus making the whole thing not work. First the DISP pin was the reason the display stayed white. After fixing that it turned black and the LTDC initialized correctly. Second thing was that the framebuffer did not work. This was due to the fact that the FMC_SDCLK pin was not initialized at all. Maybe this should be reported back to the Chibios people as this initialization sequence is done somewhere in there code? After all it was worth the search and the effort You can find the fixed code on my GitHub page if you want to pull it.

@steved Thanks for the suggestion! I tried it out but for the moment it still gives me the same result. (black screen) What I have noticed, is that when initiliazing the LTDC peripheral when using Chibios the frame buffer address (register CFBAR) is set to 0. When using the raw32 project this address is set to 33792(for the background layer). Is there anyone who can tell me where and how the uGFX library determines the framebuffer address?

Yeah I think ST is not a great example of good practices. In the meantime I've forked the uGFX repository and made some changes regarding the incompatibility: https://github.com/cpu20/uGFX-Chibios-STM32F7 I changed the STM32LTDC code to initialize the pins with the Chibios PAL. After some extended testing I'm quite certain the pins are now configured correctly looking at the GPIO registers. Also setting the DISP pin makes the screen go black (when LTDC is initialized) and got white when the DISP pin is cleared. Playing with alot of different clock configurations did not change anything, which makes me think that the problem is not clock related? The only thing I can think of that could be a problem is the FLASH/ART-accelerator... I can not find any Chibios code that initializes the I/D-cache on the STM32F7 while when using raw32 they are enabled. Could this form a problem? As of now I don't really know what to look for. If any ideas let me know and I'll check it out!

Alright, to continue on this topic, I have been looking at te RCC registers and there are some things I don't understand. In the file stm32f746g_raw32_ugfx.c in the comment is stated that the HSE clock is divided by 25 to get a 1MHz clock to send to the other PLL clocks. But in reality it is divided by 12. Also in board_STM32LTDC.c the value of 1MHz is used to calculate a 9.6MHz clock for the LCD. But due to the division of 12 a LCD clock of 20MHz is achieved. I have no idea why this even works because in the LCD datasheet it states that 12MHz is the maximum. Any idea why this was done? I have tried in chibios to set the LCD clock to different values including 9.6MHz and 20MHz but nothing works. Any input on the clock is welcome! I'll keep searching!