Joel Bodenmann

The makefile is complete. There's the OPT_OS variable in there which will be used to include the proper operating system specific makefile at the bottom: include $(GFXLIB)/tools/gmake_scripts/os_$(OPT_OS).mk All you have to do is downloading the appropriate version of ChibiOS adjusting the GFXLIB and CHIBIOS paths in the makefile and you should be able to build a demo for that board using µGFX + ChibiOS. If you don't want to use our own high-level makefiles you can just add the necessary things to the ChibiOS makefile which is explained here: https://wiki.ugfx.io/index.php/Using_ChibiOS/RT Note that you're not forced to use ChibiOS at all. µGFX runs with any underlying system or none at all (baremetal). It's just what the example uses you're referring too. Another thing: Please don't always quote the entire previous forum post you're replying to unless you're referring to just a specific bit or an older forum post. It's very difficult to read the topic otherwise. You can just reply without any quote.

That problem is not related to µGFX at all but is a problem with your c library as @inmarket mentioned. Your linker can't find the definition of the assert() function which is part of the c library - not of the µGFX library. There's not much we can do here as it's completely out of our hands.

What do you mean by "what library I should use"? There's a guide that shows how to add the µGFX library to any existing Keil µVision project that you can find here: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM Additionally there are a hand full of ready-to-run Keil µVision projects that you can find in the downloads section: https://community.ugfx.io/files/category/2-example-projects/

Glad to hear that you could find it. Please don't hesitate to ask if you have any other questions. We're happy to help.

I assume you're referring to the Tetris demo as you already asked in the comments of that video. You can find the demo in the /demos/games/tetris directory inside the µGFX library directory.

Hello Matthias, The solution is simple: You can keep using our RAW32 scheduler but you only have to implement the two functions in assembly for the context switching: _gfxTaskSwitch() and _gfxStartThread(). This is how it's done for all the Cortex-M processors currently as well in order not to rely on the setjmp() and longjmp() implementations. You can have a look at the file /src/gos/gos_x_threads_cortexm347.h to have a look at how we implemented them. Simply create a new file like that for the LX106 processor and implement the two functions. You can see that we even implemented them twice using different types of assembly (embedded and in-line). One thing that comes to mind: Is it possible that your used library provides setjmp() instead of _setjmp()? We have seen this before which is why we have this code (line 217 of /src/gos/gos_x_threads.c: #if (!defined(setjmp) && !defined(_setjmp)) || GFX_COMPILER == GFX_COMPILER_KEIL || GFX_COMPILER == GFX_COMPILER_MINGW32 || GFX_COMPILER == GFX_COMPILER_MINGW64 #define CXT_SAVE setjmp #else #define CXT_SAVE _setjmp #endif #if (!defined(longjmp) && !defined(_longjmp)) || GFX_COMPILER == GFX_COMPILER_KEIL || GFX_COMPILER == GFX_COMPILER_MINGW32 || GFX_COMPILER == GFX_COMPILER_MINGW64 #define CXT_RESTORE longjmp #else #define CXT_RESTORE _longjmp #endif If you have those, then properly setting your compiler (and probably modifying the lines shown above) might solve your issue as well. These two things are actually the reason why the GFX_CPU and GFX_COMPILER options exist in the configuration file. However, we always try to to provide implementations which work for most cases.

Hello @Mutasim, The µGFX-Studio doesn't care about your hardware. The code it generates is high-level µGFX application code and therefore completely portable. It is correct that you can just copy-paste the generated code into your existing project - that is the intended way of using it. We even support post-generation scripts to automate this step.

Glad to hear that you got it up and running!

Hello Matthias, Yes, there is a way: Set the GFX_CPU in the configuration file to GFX_CPU_CORTEX_M4 (or whatever is the correct one) and you won't rely on setjmp() and longjmp() implementations. You can find the corresponding documentation here: https://wiki.ugfx.io/index.php/GOS#CPU

Hello Renan, That is not easily possible with what the current version of µGFX has to offer. You either have to use your own algorithm to achieve that or you resort back to bitmaps (or full blown images).

Hello @Carsten and welcome to the µGFX community! The GFILE_NEED_USERFS feature has been added after the latest stable release. Just use the latest master branch of the git repository to get that feature (and many more).

Hello @Mutasim and welcome to the µGFX community! This really depends a lot on what underlying systems you're using, what IDE you're planning to use and so on. You can find a few step-by-step guides that show how to integrate the µGFX library in existing projects for specific IDEs on our wiki. Additionally, you can find a few ready-to-run example projects in the demo section. Unfortunately, there's just too much variation to cover all the cases. I'd recommend you to ask specific questions if you have any. We're happy to help wherever we can.

You have to write (and read) two bytes here. Currently you're missing out on half of the data. And yes, that is definitely wrong too if you want to use the 8-bit bus.

I agree with @inmarket that it's pretty hard to understand what you want to achieve. The way I understand it you want to connect a computer monitor via a VGA interface to your STM32F746 microcontroller, is that correct? In that case you'll have to write your own display driver which is explained here: https://wiki.ugfx.io/index.php/Display_Driver_Model It would be theoretically possible to use the exiting framebuffer driver and just write a matching board file but because of how the VGA interface works you'll most likely end up having issues with the flushing.

The ILI9481 display controller has a set of pins that control which interface is used. These are called IM0 and IM1 if I remember correctly. You have to set them correctly to select the 8-bit parallel interface.

The current version of the label widget only allows to control horizontal alignment and always vertically centers the text. This behavior is not affected on whether a line gets wrapped or not. The entire text block will be centered vertically no matter how many lines it takes up. There's no solution other than writing a custom rendering routine - which is the intended way of doing this. Regarding text rotation: In addition to what @inmarket said you also have the option to render into a pixmap and blit that in a different orientation.

This is not at all related to your initial problem / the topic of this forum thread. We're happy to help wherever we can but please at least try to figure out what the problem is. Googling the error(s) you're getting would instantly give you results. Furthermore, the demo you're trying to compile even comes with a readme file that explains what to do: In order to run this demo you will have to link against the math libs. You can do this by adding -lm to the LIBS variable in your Makefile: LIBS = -lm

Here: http://api.ugfx.io/group___colors.html You can add your own color format if you need something specialized. Eg. some people on this forum added color formats with an alpha channel.

It's part of the board file of the framebuffer. Have a look at the board file template that you can find in the driver directory (/drivers/gdisp/framebuffer/board_framebuffer_template.h). You might want to get the latest master branch of the µGFX repository to get all the latest framebuffer driver goodness:

Note that this is not about #defines. This is about function definitions (the C functions). There must only ever be one function named main in the entire program/application. The project you're having has two: One in main.c and one in gui.c. Simply remove the one in main.c (because the one in gui.c is the one from the demo that does everything you want) and you can continue to compile. Then you'll hit the next problem as described above.

This is the error when just building the project you attached without any modifications: compiler_output.txt These are the two only errors: .\Objects\Widge_Create_Ugfx.axf: Error: L6200E: Symbol __ARM_use_no_argv multiply defined (by gui.o and main.o). .\Objects\Widge_Create_Ugfx.axf: Error: L6200E: Symbol main multiply defined (by gui.o and main.o). It tells you exactly what your problem is: You have multiple definitions of the main() function. It even tells you where they are. So currently your problem is that you have your own main.c() and the one that comes as part of the demo. Simply commenting out your own main() function allows you to get rid of that problem. Then, you'll hit the next problem: .\Objects\Widge_Create_Ugfx.axf: Error: L6218E: Undefined symbol dialGCreate (referred from gui.o). .\Objects\Widge_Create_Ugfx.axf: Error: L6218E: Undefined symbol dialGetAngle (referred from gui.o). .\Objects\Widge_Create_Ugfx.axf: Error: L6218E: Undefined symbol dialSetAngle (referred from gui.o). .\Objects\Widge_Create_Ugfx.axf: Error: L6218E: Undefined symbol assert (referred from gfx_mk.o). You haven't added the other source files that came as part of the demo/widget to the project (you're missing dial.c and probably dial.h is not in the include path, but I haven't checked that).

This appears to be related to a miss match of the floating point flags.

I just had the time to download and try building the project. Did you even read the error message that you're getting? It tells you exactly what the issue is.

The µGFX library currently doesn't come with a built-in driver for the ILI9327 so you'd have to write your own GDISP driver. This should be very straight forward as everything is well documented and as there are literally dozens of examples (existing drivers). I assume that you can just copy the existing ILI9325 or ILI9320 driver and modify it to work for the ILI9327 display controller.