Joel Bodenmann

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

We'd love see your code once it's ready. In fact, there are waiting other people to see it as well It's really a nice demo you made there.

Glad to hear that you managed to locate & resolve the issue. Problems like that are the reason why the new µGFX-Studio will use the µGFX library natively for rendering:

Hi, Can you please create a minimum test case that allows us to reproduce, observe & examine the problem? A minimum test case consists of nothing else but the absolute minimum code to show the problem. In your case that would be the application code with nothing but a label, the configuration file and the corresponding font files. There really shouldn't be anything else in there. This way we can ensure that it has nothing to do with other parts of your application and we can try it on multiple platforms.

Oh wow.... I don't know what to say, that is just amazing! We would love to see more of your project, it really looks very very very very well. Ideally we'd like to put a picture or two of that application in our demos section of the website as nice demos is what we are currently lacking. Would it actually be possible to get the source or is this a closed-source project? Could you at least share how you implemented the gradients & transparency of those very nice looking arcs? That is µGFX. It's just amazing & very impressive to see what people can do with it

Hello Richard and welcome to the community! µGFX provides different simple & well documented interface for creating custom widgets. Examples are available for download as well. However, unfortunately it's mostly industrial/customers that actually implement custom widgets. In fact, most applications only consist of custom rendering functions and custom widgets. The problem is that all of these projects are closed source and if we get the source it's protected by an NDA. Therefore, these types of widgets never make it to the downloads section or into the repository itself. Our community member @Smd implementer a very nice list-based menu widget about three years ago. I'm not sure if that's available now. @Sting created a table widget and mentioned being busy working on a tree widget. Other than that: You are welcomed to post any questions you have on this forum. We are happy to help wherever we can.

No need to delete the topic. If you can leave an answer to your question this might help other people in the future that have the same question Official the answer is: Use gwinSetFont() to set a widget specific font Use the Font property combobox in the µGFX-Studio widget editor on the right side to set a font in the studio

Just an insider information in case of @madhu decides to implement it that way: The list that the built-in window manager uses is a uni-direction list in order to safe resources. Back-Tab is currently not supported/implemented at all. Code needs to be added that overflows the list to find the previous item. That being said, it's also possible to write your own window manager and using that by using gwinSetWindowManager().

What you see there is called Tearing and it is probably one of the most common phenomena with displays. The effect is caused by modifying the framebuffer while the display controller is looping through the framebuffer to refresh the actual display panel. There are two (common?) solutions to this problem: Vertical Synchronization: Display controllers often provide a signal or flag that informs you when the framebuffer sampler finished refreshing the display. Then you have a specific/known amount of time (like a time window) during which you can modify the framebuffer before the sampler starts scanning through it and updating the display again. Double-Buffering: When multiple framebuffers are available, you can write to one framebuffer at any time and once the framebuffer sampler completed a frame you simply swap the buffer so it will loop through the new one while the other one can now be modified. Tearing prevention is something that has to happen on the driver level. The GDISP driver API has been designed to be flexible enough to support these kind of things. For example, a gdispQuery() command can be implemented to check whether the display controller is currently refreshing the display panel. You can have a look at the uGFX microPython wrapper that implements this feature. However, unless it got fixed by now they are not doing it through the gdispQuery() API like they should but instead they implemented a specific function in the ILI9341 driver that they use for that specific project. Although that is the wrong approach (this really has to be done through gdispQuery()) it shows how to deal with tearing prevention. The same goes for using the 2nd layer of the LTDC of the STM32. More information can be found here. Although in case of double-buffer that could be done manually using Pixmaps instead so that the second layer is still available to use the other fancy features. I hope that helps.

Yes, we tried it with your config file. Enabling containers definitely shouldn't lead to a crash or any other unexpected behavior. We'll give it a try and let you know. However, this might have to wait until Monday.

You can change the image of a pushbutton (presuming that you use the built-in image rendering function) at any time by calling gwinSetCustomDraw() passing a pointer to a different image as the custom parameter. However, I assume that you talk about the state of the button (the different images for the three states "enabled", "disabled" and "pressed" which are just one image file). Using a pushbutton widget without GINPUT/GEVENT doesn't make much sense and is actually impossible (it won't even compile!). Can you please be more specific?

Yeah, that's what I did - it appears to work correctly unless we missed something less obvious. As @inmarket mentioned, this might be an platform specific issue. It is usually a good idea to develop the entire application on a desktop system. The entire µGFX application code is completely portable and you can compile native applications for Windows, Linux, Mac OS X and BSD. Developing a µGFX application on a desktop system is a lot faster, less cumbersome & easier to debug.