Joel Bodenmann

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!

Well, both ChibiOS 2.x and µGFX are very well tested. Of course there are bugs in both but the problems you're describing definitely aren't caused by that but simply by faults on you're side. I understand that the ChibiOS people told you to use v3 instead because nobody would want to support old software. I wouldn't want to support any µGFX 1.x question either. It really depends on what you want to achieve. Either get v3 working or find & fix the issue you're having with v2. Moving to v3 is definitely the better idea. However, you seem to be quite inexperienced. That can "annoy" you as well as the people trying to help you. Unless this is some project with a deadline I'd recommend you to grab the STM32F407-Discovery project from the latest ChibiOS and work from there. Adding µGFX to Chibios is very easy as you can just add the µGFX makefiles to the ChibiOS makefile as shown in the documentation. When doing that, make sure that you disable everything (including the GDISP) module in the µGFX configuration file (gfxconf.h). This way you wont have to deal with the display driver and display board file stuff yet. After adding µGFX your basic ChibiOS project should still be working. Once you're there, enable the GDISP module and add the drivers. That will require enabling the I2C1 and PWMD4 peripherals of ChibiOS.

What kind of problems did you run into? Are they µGFX related? I haven't worked a lot with ChibiOS 3.x but back in the days I worked a lot with ChibiOS 2.x. I don't expect 3.x to be any less good. The quality is very good. Actually, the µGFX library started off as a ChibiOS-only extension named ChibiOS/GFX. ChibiOS is probably the best supported underlying system by µGFX.

Then please follow the advice given in my post above and you should be able to succeed. Start by making sure that you have a ChibiOS project that works well without any problems. Then add, µGFX as per the documentation. Once µGFX is working add the display stuff. That last step will require to enable I2C1 and PWMD4 in the ChibiOS mcuconfig.h file.

I meant taking the mcuconf.h (or the entire project) from an existing STM32F407VGT-Discovery project from ChibiOS 3.0 (one that just flashes an LED) and then adding the stuff necessary. Have you ever worked with ChibiOS before? Adding µGFX to an existing ChibiOS project is really straight forward. But you definitely need to know what peripherals are and so on.

Can you please just take the STM32F407VGT-Discovery board file supplied by ChibiOS 3.x and enable the stuff that is used by the µGFX board file? We don't use anything but I2C1 and PWMD4. Everything else is "default" stuff (PAL (GPIO) and FSMC). I created the ChibiOS 2.x project myself. I'm 100% certain that it works. I'm not sure where the ChibiOS 3.x project comes from. But changes on the HAL stuff are minimal. You should definitely be able to get this working by just enabling I2C1 and PWMD4.

I just looked into the repository and I see that (at least) the mcuconfig.h file of the chibios_3.x example is missing some things (as you mentioned). However, I know that the chibios_2.x example is working as I created it myself. Can you please manually go through the /chibios_2.x/mcuconfig.h file and adjust the 3.x one accordingly?

The PWM is implemented using the timer peripheral. The PWM4 module is "deduced" from the Timer4 module: #define STM32_PWM_USE_TIM4 TRUE

The mcuconf.h file from ChibiOS allows to configure the peripherals. Apparently the STM32F4 that you're using doesn't have an SPI5 peripheral, hence enabling that peripheral throws an error. I'm not sure why it would be enabled by default (not sure where the board file comes from anymore). Disabling SPI5 is definitely the intended solution here - especially as the Embest board uses I2C to talk to the touchscreen controller. The error regarding PWM4D is the same deal just the other way around: The board file uses PWM4 (most likely to change the display backlight brightness) but it isn't enabled in the mcuconfig.h file. Enable PWM4D (and PWM in general if that is necessary) and you should be good to go.

Hello @Dilanka and welcome to the µGFX community! The GUI mock-up that you're showing is definitely something that you can implement with the µGFX library. First, you have to decide what underlying system you want to be using. The µGFX library has been designed to work with virtually any operating system or bare metal. The choice of the underlying system often already dictates what IDE (development environment) you'll be using. For example, if you want to work with something like RTX then you'll have to use the Keil µVision IDE. Once you know what underlying system and what development environment you want to be using you can either start by taking an existing "hello world" project (a project that flashes the LED of your board but that doesn't contain any µGFX yet) and then add µGFX to that. Alternatively, you can use one of the existing ready-to-run projects that already come with a µGFX integration. For example, this project created by our community member @cpu20 is a ready-to-run project for the STM32F746G-Discovery board and the free (open source) development environment SW4STM32:

What does "doesn't work" mean? Can you please be more specific.

Hello Alan, The solution to this is simple: Extend your guiShowPage() function to attach the physical button to the corresponding software button of each page (untested code!): void guiShowPage(unsigned pageIndex) { // Detach all toggles gwinDetachToggle(ghButton1, 0); gwinDetachToggle(ghButton2, 0); // Hide all containers gwinHide(ghContainerPage0); gwinHide(ghContainerPage1); switch (pageIndex) { case 0: gwinShow(ghContainerPage0); gwinAttachToggle(ghButton1, 0, 0); break; case 1: gwinShow(ghContainerPage1); gwinAttachToggle(ghButton2, 0, 0); break; default: break; } } Note that you'll have to use the latest master branch state from the µGFX repository as the gwinDetachToggle() function is not part of the v2.7 release yet. I hope that helps.