Joel Bodenmann

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.

Definitely unrelated to the GADC module as @inmarket already mentioned. It is likely due to a DMA stream collision (if your ADC peripheral has been set-up to use the DMA as well). It has been a long time, I really can't remember which DMA stream the STM32 LTDC driver uses (or even if at all) but you should be able to check the sources and then use a different DMA stream for your ADC. If you say that "it stops working", does that mean that just the DMA halts or do you experience a hard-fault or some other from of crash? As in: Does the CPU keep working and it's just the DMA that gets stuck?

It is a regular C #define. This means that 1000 is 1'000 decimal. If you want 4k of heap you either write 4096 or 0x1000. Regular C syntax, no magic. #define GFX_OS_HEAP_SIZE 4096 // 4k of heap

GFX_OS_HEAP_SIZE can't be dynamically allocated (as that is the whole point). It takes up exactly that amount of memory in bytes of memory at compile time.

Please keep in mind that the latest version of the µGFX library is always available through the master branch of the git repository: https://git.ugfx.io/uGFX/uGFX/ The master branch is always kept in a state where it can actually be used.

Hi, Can you please tell us more about your system (what hardware, which compiler, which underlying system, ...) and show us your configuration file (attachment!)? Also, did you try to use the debugger to figure out what's happening (hard-fault, hang, ...)?

Often the underlying system (that provides the memory management) provides utilities required to track heap usage. However, there's no real magic to that. For embedded systems it's usually just a matter of filling the entire heap area with a known pattern (eg. 0x55555555) at initialization and then using the debugger to dump the memory area to examine how much was left unused. The Raw32 heap manager doesn't offer this. It's also not that critical because RAM usage of µGFX is deterministic once you know what you're doing / what your requirements are. Towards the rest of your application that's completely uncritical as well because µGFX reserves a block of memory the size of GFX_OS_HEAP_SIZE which is known prior to compilation. It's correct that the "default behavior" of µGFX with the STM32F746G-Discovery board files only uses the external SDRAM for the framebuffer(s).

Hello @dswl and welcome to the µGFX community! The problem is caused by having GFXSRC and GFXINC in your Makefile there. Simply remove them and everything should work. The Makefile you're using there is the high-level Makefile provided by the µGFX library. The $(GFXSRC) and $(GFXINC) variables mentioned in the documentation are already being included internally. I hope that helps!

The diskio stuff from FatFS has nothing to do with µGFX. That's not something we can help you with. Usually the underlying system you're using provides a suitable implementation. All major RTOSs do that and I'm pretty sure that the CubeHAL provides one too. In any case this is completely outside of the scope of µGFX. GFILE just uses the high-level API from FatFS. The diskio stuff is on the other end of FatFS. The best way to get this working is by creating a new basic hello-world project for your platform that doesn't use any other dependency (not even µGFX!). Then add FatFS to it and make it work. Once you have a working FatFS environment you can just put µGFX on top of it and enable FatFS in the configuration file.

As @inmarket mentioned the implementations of things like malloc(), setjmp() and so on are often buggy on standard libraries provided with the toolchains for embedded targets. That's why we provide our own generic implementations that work anywhere. The configuration allows to choose any of the options which means that the user of the µGFX library can always pick what's best for his case.

Here you go. Let me know whether that worked out for you.