Joel Bodenmann

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.

Your custom rendering routine seems fine. That definitely shouldn't be a problem. I can't find any problem in the rest of your code either. Can you please use your debugger to grab a stack trace to figure out what causes the crash? Also, check whether it really is a crash. a "freeze" could also just being stuck in a loop waiting for something. Again, using the debugger will give you more information.

Please take that advice. Everything else is just getting you further down the rabbit hole. You might get it "working" eventually but then you'll have a non-standard version of the µGFX library which means that you can't just update to a newer version in the future that will contain bug fixes and new features. Furthermore, when you proceed with your project and you start adding other peripherals and so on you might end up getting the same lock-up again and that time you can't just modify µGFX sources to bypass the problem.

Those are µGFX library projects. They have nothing to do with the µGFX-Studio. They were written without using the µGFX-Studio.

You talk about icons. Did you write some custom widget? Are you using an existing widget with a custom rendering? Are you using existing widget code completely unmodified? Can you provide a minimum test case that allows us to reproduce the problem? Did you try to reproduce the problem when running your µGFX GUI on Windows, Linux or some other desktop system? Did you even try to debug the problem? Did you check for stack overflows? What kind of crash are you getting?

Hello @Asaliii and welcome to the µGFX community! That really sounds like a bug in your software. That's definitely unexpected behavior. Disabling the touchscreen is a very ugly work around that won't solve your problem in the long run. I'd rather encourage you to fix the problem you're actually having. Can you tell us more about your code?

Hello Fabien & welcome to the µGFX community! The Framebuffer board file prints very verbose error messages to stderr in case of something went wrong. Did you check your stderr for any output?

@inmarket is correct. The gwinImageOpenGFile() function takes a pointer to a GFILE. You can find the corresponding API reference here: http://api.ugfx.io/group___image_box.html#gab097ccfd4e1bcb9000ad5e563ff59ef3

We are happy to help wherever we can but you have to tell us what questions you have. Get started by getting µGFX running and then playing around with the various demos in the /demos directory before you start implementing your custom widgets.

I'm not sure what you mean by "write this". If you don't use external SDRAM then you don't need that code.

Hi Alan, No, that just means that you use some state of the library after the official 2.7 release. Please just do as I told you and grab the latest master branch from the git repository here: https://git.ugfx.io/uGFX/uGFX If you never worked with git or you don't want to get into it, you can always just download a ZIP archive of the latest state: https://git.ugfx.io/uGFX/uGFX/archive/master.zip

Hi, Copying the existing SSD1306 driver is definitely the right thing to do. Maybe it would also be a good idea to ask @Andrey_13 to share his working SSD1322 driver. Explanation of the files in the driver directory: SSD1306.h: A file containing helper macros to access registers board_SSD1306_template.h: A template for the board file. The user of the driver needs to copy this file to his project (or board directory) and implement the functions inside. This is documented in the µGFX documentation. driver.mk: The makefile that includes the necessary files and paths in the main µGFX Makefile (it appends to the GFXINC and GFXSRC variables). gdisp_lld_ssd1306.c: The file with the actual driver implementation. gdisp_lld_config.h: Driver specific configuration options readme.txt: A readme file. Don't hesitate to ask if you have any specific questions.

Yes, you can do all of that with the µGFX library. Of course things like that circular process circle doesn't exist yet but you can easily create a custom widget. Everything you need to do that already exists. Things like texts, images and buttons and so on are already there out of the box. Is this a hobby project or a commercial project? Already that would have a big impact on what you'd use. My personal recommendation (at this point, without knowing more information about your project and your goal) is to take the latest ChibiStudio and start playing with the STM32F746G-Discovery demo. Once you feel comfortable working with ChibiOS you can add µGFX. There's a guide in our wiki that explains how to add µGFX to an existing ChibiStudio project. It's straight forward.

In my post I wrote that the gwinDetachToggle() function is not in the current release. Please use the latest master branch of the µGFX repository:

Don't hesitate to ask if you have any questions. We're happy to help wherever we can!