Joel Bodenmann

Hello Andrew and welcome to the µGFX community! I'm currently siting in the train so I don't have all resources (and notes) available. However, I remember that there was a bug fix of the STM32LTDC driver after the v2.7 release (about 6 months ago). I'm not talking about the stuff that you mentioned that got pushed yesterday. I'd like to encourage you to use the latest master branch of the git repository. If you included everything properly into your project you should be able to just replace the uGFX library directory. If that doesn't help I'll try to dig into the notes - This can't be anything serious. We just created a demo project for another uses for the STM32F429i-Discovery and ChibiOS last week and everything worked out of the box. That is using the exact same STM32LTDC driver (although we used the latest master branch). If you're not into the git version control system you can always just download the latest master branch as a ZIP file from the corresponding git website: https://git.ugfx.io/uGFX/uGFX Maybe @cpu20 has something to say to this too as he's somewhat of our community's IDE integration expert

Hello Rafael, The built-in window manager doesn't support overlapping widgets. There are two ways to tackle this: Implement a custom window manager that handles overlapping/stacked widgets (that's what most customers do that need this, there's an API to do that). Our community member @Steffan dit that as well and he succeeded (see the video below). Call gwinHide() on the console before the keyboard becomes visible to prevent having two widgets on top of each other However, I'm not entirely sure whether your crash is caused by this. Usually you'll just see artifacts when widgets are on top of each other. Here's @Steffan custom window manager in action:

We'd definitely appreciate if you could create another forum topic regarding this bug. Just wondering: Are you using the latest master branch of the µGFX library? There was a major rework of the FreeRTOS port about 6 months ago. I haven't checked but AFAIK that didn't make it into v2.7.

Hello Alan, The gdispFillConvexPoly() function can only operate on integer points because the points represent pixel coordinates. There is no such thing as half a pixel. When rendering a shape to the framebuffer. Of course you can use float matrix operations prior to that - that's no problem. I assume that you enabled the convex polygon support as you wouldn't be able to compile otherwise? Did the /demos/modules/gdisp/polygons demo work on your hardware?

No problem - We're happy to help wherever we can

And that's exactly what I see on the picture. The X-Grid is the divisions in X direction, so the lines that divide the X axis. Those are the lines perpendicular to the X-Axis. Same with the Y-axis but the other way around: The Y-Grid divides the Y-Axis and hence the Y-Grid are the horizontal lines.

Hello Alan, Yes, you can of course use an image for the needle. The example is really just that: An example. It's a custom widget and you can customize it to fit your needs. However, the current version of the µGFX library doesn't provide any high-level API for image rotation so you'd have to handle the image rotation yourself. But looking at your image it doesn't look like this needs to be an image anyway. I see two polygons and a circle

Well, maybe I'm still not understanding the problem here but the picture you show is exactly what you wrote in your code: X-Axis: Red, Solid-Line X-Grid: Red, Dash-Line Y-Axis: Blue, Solid-Line X-Grid: Blue, Dash-Line That's exactly what I'm seeing in the picture.

Hi, I looked into the code and I couldn't find either of the problems you're describing. Could you please create a minimal test case example that allows us to reproduce the problem?

Hi Alan, Those are actually compiler warnings and not errors. I just uploaded a new version of the demo where those are fixed. Thank you for bringing this to our attention!

No, they are not outdated. Please read the description on the download page of the uGFX library. You can find all of this information in the documentation and the countless demos in the /demos directory. gfxInit() automatically initializes everything for you. Once you implemented the board file you can just create high-level widgets such as buttons and listen for events as shown in the demos.

So far this looks good. As the error is explaining: You need to select an underlying operating system in your gfxconf.h. That is a mandatory setting as explained in both the documentation and by that error. Just enable RAW32 and you should be ready to go.

Using an image that rotates constantly for a progressbar sounds like a bad idea. Usually you use pictures for backgrounds and then use the primitive rendering functions to draw on top of that. You can easily rotate shapes like polygons and similar.

Hello @thexeno and welcome to the µGFX community I'd recommend you to have a look at our step-by-step guide for the Keil µVision IDE. It shows you exactly what you need to add. Of course, the dialogs are different but at the end of the day it's the same: You have lists of source files and inclusion paths. You can have a look at the guide here: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM First of all, I'd recommend you not to enable GDISP until you are able to build your project. Try to take your working AtmelStudio project and just add µGFX as per the guide but do not enable GDISP. You are able to make sure that everything works anyway because the GOS module is always enabled. Therefore, you can build a fully working µGFX application without using the GDISP module. Adding the /src directory is not necessary. All files are being included automatically once you included gfx_mk.c and the path to the top-level directory. Don't do that. The LLD config file is being included by the driver itself automatically. Have a look at the Keil guide I linked above. You only need to add the path of the driver directory to the include path and then add the driver source file to your list of source files. No need to include or modify anything else. But again: Try without the GDISP module first. That will save you a lot of hassle. Enable GDISP once your project builds fine just with GOS. As a general rule: Once you need to modify µGFX library sources you're doing something wrong. If you'd like to write a guide for the Atmel Studio that we can put on the wiki that would be much appreciated.

Hello and welcome to the µGFX community! This sounds like a mismatch of the ST HAL versions. Unfortunately, ST used to change their HAL a few times breaking compatibility each time. I can't look into this the next couple of days. But I'd recommend you to create an STM32F746G-Discovery project in Keil from scratch and then follow our guide on how to add µGFX to an existing Keil project. It's very straight forward. You can always use the demo you have there as a reference as of where to add files and so on. Here's the guide: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM Don't hesitate to ask if you have any further questions. We're happy to help wherever we can.

The easiest way is to use the existing pushbutton widget and using the existing image rendering routine for it. You pass a pointer to a gdispImage object via the parameter of the custom rendering function. Just use gwinSetCustomDraw() to change the parameter whenever you want to change the random picture. Then just listen to the pushbutton even that gets fired when the button gets pushed. Easy as that. You can simply use gwinHide() and gwinShow() to control the visibility of your screen saver widget (button).

gwinWidgetClearInit() and gwinClearInit()

Thank you for sharing this valuable information with us!

Hello @TheProdigalCat and welcome to the µGFX community! Importing existing projects into the µGFX-Studio is definitely something we'll never support. However, we'll definitely create the new demos with the studio once it gets released in a few days / weeks.

That is a bug that got resolved a very long time ago. Please use the very latest version of the µGFX library (the master branch from the git repository). You can always just download it as a ZIP archive if you don't want to use git. Your change is not a proper fix. Your touchscreen will not be working now.

Hello Alan, First of all I'm glad to hear that you managed to resolve the issue. I completely forgot about the different heap managers that FreeRTOS has to offer. We should add that to our troubleshooting list. Regarding the images: All µGFX image decoders are streaming decoders which means that you never need to have the entire image in memory. Caching the decoded image is optional too so the memory usage is very minimal (but depends on the image format you're using). For example, when you render a BMP that is in your microcontrollers flash (using ROMFS) then you really only need a few dozen bytes for the image header (the gdispImage structure).

Hello Alan, I was referring to the stack size of the uGFX_task task. At some point in your program you have to start that task by either using the FreeRTOS API (such as xTaskCreate()) or by using the µGFX wrapper named gfxThreadCreate(). You either tell those functions how much stack you want to reserve for that task and they allocate it for you or you create the stack yourself and just point to it. In any case, make sure you're not experiencing a stack overflow caused by a stack that is too small. A side note: Keep in mind that FreeRTOS uses numbers of words for the stack size: http://www.freertos.org/FAQMem.html#StackSize

Hello Nathan, This is a very interesting problem. We've never encountered this before. We ran some tests ourselves yesterday with a quite sophisticated µGFX application on an STM32F746G-Discovery board. Unfortunately, we were not able to reproduce the problem. Are you able to reproduce the problem on an STM32F746G-Discovery board? I don't want to point with fingers at someone, but let's start at the things that are easiest to check: Did you have a look at the errata of your microcontroller? I remember that one of the first STM32 that featured the LTDC had a bug that caused some artifacts on higher-resolution displays. Again: I'm not saying this is the case here, it's equally likely that the bug is in the µGFX driver but things like that are just easier to check when getting started to investigate. Also, what version of the µGFX library are you using? There was a datatype fix four months ago: I don't think that this has any impact here but again - let's start with the things that are simple to check The above is just an addition to what @inmarket wrote.

Did you ensure that your thread stack is big enough?

Hello @Linker and welcome to the µGFX community! Can you please tell us what "won't work" means? What exactly are you experiencing? Compiler errors (if so, which ones)? Does it compile but the screen stays blank? Please give us more information.