Joel Bodenmann

In that case we strongly recommend that you start off with a ChibiOS/RT only project. ChibiOS comes with tons of ready-to-run demos. In fact, there is at least one demo that works out-of-the-box on the STM32F401RE Nucleo board. Take that demo, make sure that it works. Then add µGFX to it by following this guide (or alternatively this one if you are using the ChibiStudio IDE). You can have a look at the various examples in the /boards directory of the µGFX library to learn how to write a board file. In your case, most notably these two might be interesting: /boards/base/FireBull-STM32F103-FB: ChibiOS with parallel port display using GPIO bit-banging /boards/addons/gdisp/board_SSD1963_fsmc.h: ChibiOS with parallel port display using FSMC As mentioned in the previous post we strongly recommend hooking the display up to the FSMC peripheral if possible. That is a lost easier and a lot faster at the same time. Back in the old days where µGFX was still a ChibiOS-only library I actually wrote a very extensive guide about using the FSMC interface to interface SRAM and LCDs for ChibiOS which you might want to read: http://wiki.chibios.org/dokuwiki/doku.php?id=chibios:community:plans:external_ram

The ILI9341 itself would offer an SPI interface. However, unfortunately you won't be able to use SPI with this display module that you are showing. You have to use it with the parallel interface. Note that you should be able to use it in 8-bit mode instead of 16-bit mode which would free you from making 8 connections. Usually there is a jumper to select the 8-bit vs. the 16-bit mode. Judging from the picture this could be J1 but please check with the datasheet of the display module to be sure. Worthwhile to note is that the display will be more than twice as fast in 16-bit mode than in 8-bit mode and probably around 10 times faster in 8-bit mode than SPI mode. In order to keep the CPU load low and to increase the overall speed & performance, you should connect the display to the FSMC peripheral of the STM32. We don't have a ready-to-run example for your specific setup (Nucleo401RE + ILI9341 over parallel). This would also depend on what underlying system you'd like to use (bare metal, ChibiOS, FreeRTOS, ...). However, there's a Nucleo401RE example available in the download section which uses ChibiOS/RT and an SSD1306 based display. You should be able to modify that and using the various example board files in /boards you should be able to write the board file for your setup. If you want to use a baremetal system (no underlying operating system) instead we recommend using a working example/demo project from another source and adding uGFX to that. The most important thing is not to get discouraged. These systems are very complex and the fact that the µGFX library runs on virtually any system with tons of different configuration options doesn't make it easier. It can take you a while to see how things plug together. Don't get discouraged if you can't get it working straight away. The platform you are using is very common (STM32F4 + ILI9341) and you will be able to get it working just fine without any problems or modifications. Don't hesitate to ask if you have any questions. We are happy to help where ever we can.

@cheater any news on this? We'd love to see the code behind this lovely meter!

We didn't find the time to test it yet, sorry. These kinds of symptoms often arise from common errors such as not enabling the image format in the configuration file or having GFILE_MAX_FILES set to a number too small. As these things usually cover 95% of the problems we tend to let the user check those before we spend the time setting everything up on our side. The new µGFX-Studio will have a proper "export as ZIP-Archive" feature which will vastly speed up things like this. That is not so easy, but finally I'll do it. That should be a thing very easy to do. Just store the return value in a variable of type gdispImageError and read out that value (either display it, send it over serial or look at it via the debugger, ...) I'm glad to hear that you found the problem. We will have a look at your images to determine the problem, but that will take some time. There are certain features that the µGFX image decoders don't support such as PNG interlacing as that would simply bloat code-size with little to no gain at all. However, the GIF decoder should be pretty complete. So far we never encountered an image that imposed problems. The reason why the µGFX-Studio displays the image is because it doesn't use our image decoders. That is probably the biggest benefit of the new µGFX-Studio: It actually uses the real µGFX library to render everything.

We are happy to help resolving or fixing any issue. But as mentioned in the previous post we require you to provide us with a minimal-test case that allows us to reproduce the problem.

Did you ensure that you actually have enough memory left to open that many images at once? You might want to check the return value of gdispImageOpenFile() (or equivalent of the Imagebox). The value returned is of the type gdispImageError, it will tell you what caused the failure. The possible values are documented in /src/gdisp/gdisp_image.h. The same applies to gdispImageDraw() (or equivalent of the Imagebox). Just to ensure that I understand this the right way: You are able to display all images - just not at the same time?

Most likely the fault is caused by the GFILE_MAX_GFILES setting in the configuration file which is too low. Can you please try increasing that value and retry? The µGFX-Studio is supposed to calculate the correct number required, however, there might be a bug. In case of you need to access files that the µGFX-Studio doesn't know, you can add those in the GFILE tab in the Project Settings.

Okay... I am having a hard time following you on what is working know and what questions you have. If you have questions that are not related to the first post in this topic, please don't hesitate to create a new topic. It is very important to us to keep the forum clean, structured & well organized. It makes it a lot easier for us to reply to your questions and it makes it a lot easier for other people to find answers using the forum search.

It is a file that contains library-internal specific stuff. It can happen that we modify the file contents. Think of the simple example where we add a new module to the µGFX library: We'd have to modify the gfx_mk.c file. The goal is that you can simply replace the µGFX library directory without any modifications to upgrade to a newer version. When copying library files like gfx_mk.c to your own project you prevent that from working. We strongly advice against doing that. Glad to hear that you got everything working. We appreciate any kind of guide, tutorial, example project or similar. This can be helpful to many people. They are not useless. They are used to calculate the timings during compile-time which vary from display panel to display panel. Of course the users can do the calculations manually and enter the result instead but these calculations happen during compile time and therefore have zero run-time impact. The parameters supplied to those macros are the more natural information than supplying the result calculated by hand. In fact, the parameters passed to those macros is what you will find 1:1 in the display panel's datasheet.

Glad to hear that you managed to compile the project. In that case the problem really was that the toolchain simply didn't provide support for the Cortex-M7 yet.

We recommend using this toolchain: https://launchpad.net/gcc-arm-embedded You should be able to compile the demo project without any problems using that toolchain. Please don't hesitate to ask if you have any further questions. We are happy to help where ever we can.

Hello Greg, The errors you are getting are related to the floating point units. I am not 100% sure what the problem is, but I am pretty sure that it is either of these two: The STM32F746 uses an ARM Cortex-M7 core. That is a fairly new core and it's possible that the version/distribution of GNU ARM GCC that you are using doesn't have support for that Cortex-M7 yet. In that case, a simple update to a newer version of GCC should help. We are successfully using the STM32F746G-Discovery bare metal make project template available in the downloads section with GNU ARM GCC 5.4.1 from the Launchpad. It is possible that you mixed soft-FPU and hard-FPU software. However, that shouldn't be the case with the example project that you downloaded unless you modified things yourself. Can you confirm that you are trying to compile the example from the downloads section that you just downloaded? Note that you just have to execute the command make in the directory that contains the Makefile. You don't have to modify anything at all. I hope that helps.

Please check the return value of gdispImageOpenFile(), it will tell you what caused a problem. The return value is of the type gdispImageError: https://git.ugfx.io/uGFX/uGFX/src/master/src/gdisp/gdisp_image.h#L37

Hello and welcome to the community! There are generic "Getting Started" guides, platform & IDE specific step-by-step tutorials and tons of demos and ready-to-run projects available. We recommend following through the "Getting Started" guide to get an idea how everything is organized: https://wiki.ugfx.io/index.php/Getting_Started The front page of the wiki/documentation has been organized to provide "entry points" to the different topics: https://wiki.ugfx.io/index.php/Main_Page

Did you ensure that you removed the copy of the gfx_mk.c file that you placed in your project directory before trying to compile with the one that is part of the uGFX library directory?

Thank you for sharing your experience. We can create an official guide like the ones we have for other IDEs. The only object I have is that you copy the gfx_mk.c file. Can't you just include that file into the build while still excluding everything else from the uGFX directory? The problem is that upgrading to a newer version would require you to copy the file again. The same applies for the drivers. The only thing that should be part of the application directory is stuff that is application specific, such as board files and configuration files. Everything else should stay in the uGFX directory so you can easily upgrade to a newer uGFX version by simply replacing the library directory.

Can you please tell us which driver you are using? Most likely that's a fault in the driver's area blitting function.

The Windows binary of the font encoder has been updated a couple of days ago. You can find the latest version of it in the µGFX library repository. It should work without any dependencies or other problems: https://git.ugfx.io/uGFX/uGFX/commit/c9b616014fee75c60824819f78eb8e7ff247439e

Can you please provide us with an archive that contains a minimum-test case example that allows us to reproduce the problem?

You place the graph widget into the container - just as you would with any other widget/container combination: // Create the container wi.g.y = 10; wi.g.x = 10; wi.g.width = 320; wi.g.height = 240; wi.text = "Container"; ghContainer = gwinContainerCreate(0, &wi, GWIN_CONTAINER_BORDER); // Create the graph wi.g.x = 10; wi.g.y = 10; wi.g.width = 300; wi.g.height = 200; wi.g.parent = ghContainer; // Specify the parent container ghGraph = gwinGraphCreate(0, &wi.g);

You are not allowed to do that. Please do never modify the µGFX library sources unless you know what you are doing. The µGFX build system is very delicate because a lot of complex things are happening to ensure maximum portability & compile time optimizations. Modifications like that results in errors like the one your are describing. You are supposed to add the driver file ( "/drivers/gdisp/STM32LTDC/gdisp_lld_STM32LTDC.c" ) to your project but you have to do that as part of the Eclipse configuration. You have to tell eclipse that you want to include that file in the build process. You are also missing the path to "../ugfx/src".

The variables & definitions mentioned by @Victor are only required/recommended if you are working with our built-in Makefile system (eg. when using our own top-level Makefile). If you are using the Makefiles generated by Eclipse or if you are just adding µGFX to Eclipse there is no need to define those - you have to take care of them in your own build settings. The only thing you have to do is to copy the configuration file template gfxconf.example.h to your own project directory and renaming it to gfxconfig.h as @jano mentioned. We don't have a generic Eclipse guide because it depends heavily on many factors (eg. the "Eclipse Distribution") and how the Vendor/Supplier set up the build environment. If somebody would like to publish a step-by-step guide or tutorial, we'd appreciate a lot. So far we have a guide that explains how to use ChibiStudio which is also Eclipse based. Please don't hesitate to ask if you have any other questions.

Hello and welcome to the community! Thank you for bringing this to our attention. We will investigate and get back to you. However, that might take some time.

Hi and welcome to the community! You are compiling the µGFX C sources as C++ sources. That leads to those errors you are getting. You have to ensure that you compile the µGFX sources as C sources.

Those functions are explained here: https://wiki.ugfx.io/index.php/BareMetal