Joel Bodenmann

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.

Hello and welcome to the µGFX community! Before we start diving into debugging this - did you try running the unmodified /demos/modules/gwin/button demo? Does that work?

Regarding the build error: Did you perform a clean build? Regarding the linker options: The top-level makefile provided by µGFX that you're using comes with an entire API that is documented in /tools/gmake_scripts/readme.txt. Furthermore, the ChibiOS makefiles that are being included by the top-level one if OPT_OS = chibios feature some more chibios specific options which are also documented: # See readme.txt for the make API # Requirements: # # CHIBIOS The location of the ChibiOS code eg. CHIBIOS = ../chibios # CHIBIOS_PLATFORM The name of the ChibiOS platform eg. CHIBIOS_PLATFORM = AT91SAM7 # CHIBIOS_PORT The name of the ChibiOS port eg. CHIBIOS_PORT = GCC/ARM/AT91SAM7 # # Optional: # # CHIBIOS_LDSCRIPT The name of the loader script eg. CHIBIOS_LDSCRIPT = AT91SAM7X256.ld # CHIBIOS_BOARD The name of the ChibiOS board eg. CHIBIOS_BOARD = OLIMEX_SAM7_EX256 - if not specified you must include equivalent code yourself # CHIBIOS_VERSION Which version of ChibiOS is this (2 or 3) - default is 3 # CHIBIOS_STM32LIB Use the STM32 library source for drivers instead of native drivers (yes or no) - default no # CHIBIOS_PROCESS_STACKSIZE Size of the ChibiOS process stack. Only useful if the link script supports it - default is 0x400 # CHIBIOS_EXCEPTIONS_STACKSIZE Size of the ChibiOS exceptopms stack. Only useful if the link script supports it - default is 0x400 # As you can see, there are makefile variables for the stack sizes. You're adding "plain" variables via the LDFLAGS variable. Without remembering the details I'm pretty sure that they are just being appended which would explain the behavior that you're experiencing. Try using the proper variables documented above.

Hello Alan, Unfortunately, I don't really understand your question. The code you're showing is correct. That is the proper way of doing it. You can't do anything other than that - it's the intended way of handling this.

Glad to hear that you managed to get everything running. Good work!

Yes, the existing layout(s) that you can find under /src/gwin/gwin_keyboard_layout.[ch]. And for styling: Custom rendering routines as always.

Exactly. Of course you could start from scratch but that probably won't be as efficient as all the button placement code will be the same.

As you mentioned yourself what you're after is a custom rendering routine. Every GWIN widget supports that: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine I'd recommend you to simply copy the existing one to your project and modify from there.

Yes, you can completely customize the keyboard layout. Have a look at the existing layout that you can find under /src/gwin/gwin_keyboard_layout.c. It's really just a matter of filling in a struct. You can use gwinKeyboardSetLayout() to set your own layout.

It should be fairly easy as the GWIN module uses the GEVENT module for event handling: bool_t gwinAttachListener(GListener *pl) { return geventAttachSource(pl, GWIDGET_SOURCE, 0); } There is a matching geventDetachSource() function in the GEVENT module. I'm looking at this on my phone and I don't remember all the details but on first glance this really looks quite straightforward. @inmarket might have more details in his memory.

Without thinking too hard about this my first idea is to implement a gwinDetachMouse() which you use to detach the GListener that usually gets attached using gwinAttachMouse() (or gwinAttachListener() in the old days). This will prevent the widgets from receiving mouse/touch events. You can attach it to a dummy listener that will fire up the backlight and then detach itself and attach the old listener again. There might be another / better solution but this sounds quite proper to me.

Another solution was presented by our community member @Steffan some time ago. He extended the implementation of the pixmap to support color keying by exploiting exactly what @inmarket mentioned. This way the blending happens inside the µGFX pixmap implementation and not the driver.

We know of several people and companies that successfully run µGFX on a PIC32 platform. As @inmarket mentioned the library has been designed to work with any system and compiler. You shouldn't encounter any problems.

Hello @Mavro and welcome to the µGFX community! Currently we don't have any ready-to-use board files for the STM32F769i-Eval board. This is due to the fact that we don't have such a board. If you want to contribute one, we wouldn't mind Anyway: Running µGFX on that board will be very easy. The STM32F7 microcontroller is well supported by µGFX already and the driver required to use the STM32 LTDC peripheral already exists and is known to work well too. You should get started by simply copying the /boards/base/STM32F746G-Discovery board directory and name it /boards/base/STM32F769i-Eval. From there, just modify the STM32LTCD board file that is located in that directory. It should be pretty straight forward as usually it's just a matter of changing the pin assignments although not even that might be necessary here. I hope that helps. Don't hesitate to ask if you have any further questions.

Hello Stephen, Please excuse the late reply... quite busy around here... I'm glad to hear that you got it working, good work! Regarding the debugger: This is not something µGFX related. I am talking about your regular program/software debugger which will most likely be GDB.