Joel Bodenmann

It's correct that you receive that warning. It tells you to make sure that you know that you have to initialize the C runtime yourself - our library doesn't do that. You can suppress that warning by setting GFX_OS_INIT_NO_WARNING to TRUE in the configuration file. You can find the corresponding documentation here: http://wiki.ugfx.org/index.php/GOS#Warnings You must copy the board_SSD1963_template.h file to your project and rename it to board_SSD1963.h. Please do not hesitate to ask if the problem persists or if you have any other questions.

Hello and welcome to the community! As the error message tells you, you didn't enable any underlying system abstraction in the configuration file (gfxconf.h). Now that I am writing this I see where the confusion comes from: Even if you don't use an operating system you still have to specify which GOS implementation you want to use. In case of bare metal (no operating system), please enable the RAW32 port by setting GFX_USE_OS_RAW32 to TRUE in the configuration file. You can find more information about how to use the µGFX library on a bare metal system (without any underlying system) here: http://wiki.ugfx.org/index.php/BareMetal

Great work! Thank you for sharing your project!

Thank you very much for reporting this issue (and providing the corresponding patch). We have applied your patch to the repository: https://bitbucket.org/Tectu/ugfx/commits/25802124fb64a949971a89dd2ef34b749d949494

Sorry for the late reply. We were out of office over Easter. We are glad to hear that you got it working! And we are also glad to hear that it was no problem on the uGFX side of things Enjoy your display!

I'm afraid we can't help you with your debugging environment. However, we can try to figure out what the problem your driver is. For this, can you please open the driver configuration file (the file /drivers/gdisp/ILI9341/gdisp_lld_config.h) and change the value of GDISP_HARDWARE_STREAM_WRITE from TRUE to FALSE? This will prevent using the streaming interface and therefore not try to execute the code that is making you problems. However, this is of course just a work-around to track down the problem and not a permanent fix/solution. Have you ever been able to use the display with µGFX? Is this a new issue? Can you draw other things? Does it happen directly or just after a couple of minutes? Also: What underlying system are you using? Are you doing other stuff as well or is this a bare, basic project with nothing else but µGFX in it?

It's correct that the GADC oscilloscope demo doesn't use the graph widget. The oscilloscope is a custom widget. As C is not an object oriented programming language it's not possible to simply inherit from the existing graph widget and adding your own modifications. There are two possible ways: Create a new widget and copy-paste the corresponding code from the existing graph widget and then modify to your needs Create a new widget that uses the existing graph widget internally. This would mean that inside your own widget you'd have a GHandle and you call gwinGraphCreate() in your own widget init routine. Which of the two you take depends a lot on your needs.If you want to add things like touch events and so on then option 2 will be a lot simpler. Also autoscaling and other things are possible to implement this way because you simply manipulate the data in your own widget and then forward to the actual graph widget instance. Your widget would basically be a proxy widget. However, as soon as you have to modify anything in the existing graph widget that cannot be modified using the provided API then you have to choose option 1. I hope that helps. Please do not hesitate to ask if you have any other questions

Hello pjwl and welcome to the community! Each driver defines his own board file. You can find the corresponding board file template in the driver's directory. In your case, copy the following file to your project: /drivers/gdisp/SSD1963/board_SSD1963_template.h and rename it to board_SSD1963.h. Then it's just a matter of filling in the empty functions. You can have a look at all the existing board file implementations to get an idea how to do that. I can recommend you having a look at this one as it uses the FSMC interface of am STM32 which is very similar to the EBI of an AVR32: /boards/base/Marlin/board_RA8875.h. You don't have to include the board file manually anywhere. The driver (inside the µGFX library) automatically includes a file named board_xxx.h where xxx is the driver name. All you have to do is making sure that the place where your board file is located is part of the inclusion path for the compiler/linked. I hope that helps.

Are you using files generated by the µGFX-Studio? If so, can you please tell us which version (make sure that you use the latest one!) and upload a ZIP archive containing your project as well as the generated files. Otherwise, please show us the code that you are trying to compile. Are you using the make build system? Are you using single-file inclusion? Manually added all required files? ... Please provide as many information as possible.

Hello and welcome to the community! Did you check whether the issues was the one discussed in this thread? If the issue remains, please provide additional information such as the compiler that you are using, the compiler version, the compiler output log and so on.

That's correct, you are not supposed to change those settings. Are you experiencing performance issues or are you just asking generally? You can cache images which will store the decoded image in RAM which will vastly reduce image rendering time as there's no more decoding to do. You can find more information about image caching here: http://wiki.ugfx.org/index.php/Images#Caching For generic speed-ups you might consider using Pixmaps. Pixmaps provide dynamic, partial framebuffers that allow you to render anything in RAM first and then blitting everything in one burst write to any location on the display. This usually speeds things up a lot. You can find more information about pixmaps here: http://wiki.ugfx.org/index.php/Pixmaps Note that it's always a trade-off between speed and memory usage.

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!