Joel Bodenmann

Glad to hear that you got it working! Each image decoder defines its own buffer size internal. That's a setting that is not available for configuration to the user of the µGFX library. You can find those definitions at the top of the source file of each image decoder.

The proper way of doing this is by implementing a custom rendering routine for the button widget. In µGFX the widgets are specified by their behavior, not by their appearance. When you need something that is clickable, you take a button and change how it looks. If you need something that takes a range of values, you take a slider and make it look like you want. This is the core philosophy of the µGFX library. This article explains how you can implement your own custom rendering routine. In fact, the guide is prefect for you because it shows how to create a custom rendering routine for a button that has a label and an image - exactly what you want: http://wiki.ugfx.org/index.php/Creating_a_custom_rendering_routine If you have more advanced needs, you can even implement your own widget from scratch. Please do not hesitate to ask if you have any other questions.

Glad to hear that you found the error! I put that on the ToDo list for the µGFX-Studio. Would be nice if you could contribute your driver back to the community once it's fully working.

That IS NOT the recommended method of handling this and it is strongly recommended not to do that. Doing that will not work in all cases and will cause problems. That's just a work-around from somebody who didn't want to listen to the explanations and the advice of the µGFX developers

Containers don't generate any click events. If you explain to us what you want to do / what you are trying to archive we can tell you how it should be done the right way.

Hello Julian and welcome to the community! What touchscreen controller (the chip) are you using? It looks like you are trying to write your own touchscreen driver but most likely your touchscreen controller is already supported and µGFX comes with a built-in driver for that! In that case you would just have to write the board file as you did with the display. You can find a list of all existing drivers here: http://ugfx.org/platforms.html To verify that the systick functions that you implemented for RAW32 are working correctly, you can write a small test program like this: #include "gfx.h" int main(void) { gfxInit(); while (TRUE) { ledToggle(); gfxSleepMilliseconds(500); } } You can then either use a scope to check whether the 500ms delay is exactly correct or just eye-ball it. The reason to do this is that when the GINPUT module polls the touchscreen only once it's possible that the delay is just way too long which can be a result of a fault in the systick conversion function implementations. The next thing you want to do is making sure that the GTIMER thread still runs. Take the program that you already have (the one that only polls the touchscreen once) and add a new GTIMER job yourself. You can just add a function that toggles an LED and tell GTIMER to call that function periodically. If the LED doesn't flash, it means that the GTIMER thread crashed. You can find example code for GTIMER in either the /demos/moduls/gtimer directory or on the corresponding wiki page: http://wiki.ugfx.org/index.php/GTIMER Just a side note: there are two (well three) little programs available that help tracking down touchscreen issues. You can find them in /demos/tools.

The files ch.h and hal.h are part of ChibiOS and have nothing to do with uGFX. ChibiOS is an RTOS like FreeRTOS. It seems like you are trying to compile the board files that have been written for ChibiOS although you are using FreeRTOS and the ST HAL instead. Then you can't use those ChibiOS board files.

Glad to hear that you got it working!

You can always learn how to write Makefiles Compared to writing actual firmware it's very easy. Also, there are thousands of existing Makefile based FreeRTOS projects on the web that you can easily find using Google.

That makefile is not great either. This makefile simply scans your directory recursively and automatically adds all *.c files to a list and then compiles all files in that list. That is bad practice and can lead to issues. To give you an example: There are many *.c files in the uGFX library that you don't want to compile/link. Take all the demos for example. This will simply not work. The same applies to drivers and board files. A proper makefile has a list (a variable) of all sources that need to be compiled where you add your own files and then simply add $(GFXSRC) to that variable.

Hello Carlos, We took a look at the project and the Makefile is indeed not written to use the Makefile that comes with uGFX. That is very bad practice as this leads to several issues one of which is that you won't be able to just update to a newer uGFX version. We strongly advice you not to use that project as a starting point. We can create an example project for you as part of a commercial support package. Please do not hesitate to contact us directly (by sending a direct message). Otherwise we are happy to answer any of your questions here on the forum.

Hello Carlos and welcome to the community! I am trying to download the project / Makefile from the link that you mentioned. But I can only find links to FreeRTOS, ST and uGFX itself. Can you tell us where we can find the actual project so we can have a look at it? Anyway: The project was created with an old version of uGFX. We changed many things internally ever since. However, this is usually no issue for as long as people simply include the uGFX Makefile. This way we can make internal changes (change file names and add new files) without them having to alter their build system. We suspect that the project you are referring too added all the uGFX sources manually instead of including our Makefile. If you have a working FreeRTOS project that uses the make build system you can simply add uGFX by adding our makefile: http://wiki.ugfx.org/index.php/Getting_Started#Makefiles

You might want to have a look at ChibiOS: http://chibios.org It's a very good and mature RTOS that comes with it's own, complete HAL (optional, of course). µGFX is known to work very well on ChibiOS. Actually, µGFX started out as an official ChibiOS extension called ChibiOS/GFX. Otherwise you can have a look at the the list of the operating systems that are already supported by µGFX: http://ugfx.org/platforms.html

Glad to hear that you got it working!

Do never ever modify anything inside the uGFX library unless you know what you are doing (eg. custom modifications). Our build system is very complex and adapts itself to each configuration in order to provide the most efficient code possible. There are many things that are evaluated during compile time and change how stuff gets glued together. If you are working with eclipse we strongly recommend adding the µGFX library using the built-in makefile system. This is the most reliable and easiest way to add µGFX to an existing project. This way you don't have to worry about making sure that every source file is included and that all inclusion paths are set correctly which can be a very cumbersome and error prone work. Guide: http://wiki.ugfx.org/index.php/Getting_Started#Makefiles In your current situation it seems like the root path to the µGFX library directory has not been added to the search/include path.

You can try running the converter directly on your computer. There are binaries for Windows, Linux and FreeBSD in the uGFX library repository. But we don't provide any warranty nor support for those binaries.

No worries, that's nothing stupid We are here to help you where-ever and when-ever we can. Good luck with your project!

The SPIConfig is a struct from ChibiOS/HAL. It has nothing to do with µGFX itself. This means that you are trying to use a board file that was written to be used with ChibiOS/HAL which you are not using. The solution is to not use that board file but copy the template that you can find in /drivers/gdisp/ILI9341/board_ILI9341_template.h and implement those empty functions using what ever HAL that you are using (eg. STM32CubeF1).

There's also a limit on the maximum duration that the script can take to convert the font (server side timeout). But to prevent this kind of issue that timeout has been set to 3600 seconds. I just verified that that setting is still correct. There's nothing we can do on your browser side.

Hello and welcome to the community! There are a couple of different tools that you can find in the /demos/tools directory that will help you to troubleshoot your touchscreen issues. I'd recommend running them to pin-point the exact problem. Regarding the GTIMER thread: Make sure that the stack size (GTIMER_THREAD_WORKING_SIZE) is big enough. However, the default setting of 2048 bytes should be more than enough unless you are running other GTIMER jobs that require a log of stack. You can find more information about that here: http://wiki.ugfx.org/index.php/GTIMER Also note that you don't have to use any of the GINPUT API functions inside your application code unless you want to manually add some devices. The touchscreen handling is totally automated for you in the GWIN module.

Thank you for sharing this great guide! I am sure that this will help some people to improve their workflow. There's still a lot to do in the uGFX-Studio but it's nice to see that people can actually do some real work with it

You can find that information here: http://wiki.ugfx.org/index.php/Images Currently three formats are supported: BMP, GIF and Native. We have just finished adding support for PNG format. It's working and we only have to do some more testing. The upcoming release of the uGFX library will contain support for PNG images. The studio itself doesn't allow to add images where the uGFX library doesn't have the matching decoders for. The uGFX-Studio will allow you to use PNG images as soon as the next version of the uGFX library has been released.

Yes, it's correct that using DMA with the ILI9341 driver will require some driver code modifications. However, that shouldn't require a lot of modification. Most drivers have been contributed by countless users over the years. We don't have the resources to properly implement each driver on our own. So as soon as we see that there's a working driver that meets our coding standards we make sure that it works on one way or the other and then it goes into the repository. But the list of implemented features is usually a lot smaller than with the drivers that we implemented ourselves. You can have a look at the SSD1289 driver to get an idea on how to add DMA support to an existing driver. To actually talk about your problem: Make sure that streaming is enabled. That way the GDISP module will make burst writes whenever possible.

Did you make sure that you enabled the native image format as well as the MEMFS for the GFILE module? Are you able to run the example I posted?

Yes, you can. Both the custom rendering routine as well as the custom parameter passed to that routine can be set either in the widget init struct or at any time during runtime using gwinSetCustomDraw(). There you go: container_pixmap_example.zip This is what it should look like: