Joel Bodenmann

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.

Have a look at the GDISP driver / GDisplay documentation. It tells you the function signature (the function name is gdisp_lld_fill() or something like that, that the linker will try to link against). If you implemented the hardware filling functionality into your driver correctly then it should just work. Maybe you forgot to set the corresponding define in the driver configuration file. You might want to have a look at some of the other drivers that implement hardware acceleration.

Usually you'd want your event loop to run in its own thread so you'd use TIME_INFINITE as the timeout parameter of geventEventWait(). This solves all your problems. Keep in mind that you have to use gfxSleepMilliseconds() instead of HAL_Delay() in any case as pointed out by @inmarket.

No, we definitely don't suggest to change your hardware. Your hardware is fine. The µGFX code is optimized to always use the best possible method to achieve something. In case of clearing the screen it would use the hardware clearing if you implemented that. If you haven't it will use gdispGFillArea(0, 0, gdispGetWidth(), gdispGetHeight()). That function would then use the area filling hardware acceleration (if you implemented that) or fall back to manually clearing the screen by basically doing setPixel() - which is what you're experiencing currently. Hence we suggest you to simply implement the hardware area filling (rectangle drawing) support into your RA8875 and your problem will be gone. The performance of your entire GUI will increase immensely.

Hello @cotsos and welcome to the µGFX community! That is expected behavior. For various reasons (which all boil down to saving resources), GEVENT doesn't internally buffer or queue up events. Each listener provides its own buffer with the size of one event. Therefore, if you're not listening you'll miss it. This is a design choice that was made to vastly simplify code complexity and decrease resource usage because the event system is only used for GUI interactions with a user which are always very slow. You get the press but not the release because the press event fits into the one-event sized buffer. Then the release event happens but it can't be stored anyway. The proper way of doing this is using the second parameter of the geventEventWait() function which is the timeout parameter. In a usual application where the event loop runs in its own thread you'd leave this to TIME_INFINITE. Using a timeout of 0 is definitely a bad approach because you're almost guaranteed to miss the event(s). I hope that helps. By the way: Can you share with us what kind of performance you get out of that STM32F469i-Discovery driver from the other thread? Just the overall user experience, not actual measurements. Is it so slow that you see the image being rendered or is everything blazingly fast?

Do not attempt to change anything internal like that. Those things are not like that just because for no reasons. The mechanisms used by the GWIN module (and anything else in the µGFX library) are a result of years of experience and many complex pieces that fit together nicely. When not having the big picture you don't see all the things that go on in the background, what simplifications have been assumed to save memory and so on. Changing something like this is the wrong approach for fixing symptoms rather than problems and you will end up with many other problems instead. Implement the area filling in your RA8875 driver and you'll get a huge performance boost already. After that, apply other mechanisms that have been discussed in this forum many times. Any changes inside of the core code, even if it's just so little of a change, will have many side effects and will imply many more problems.

http://api.ugfx.io/group___keyboard.html#gab49f100ac33eed532c18ca8529ab1bfb

Are you absolutely sure that you set the range of the font converter correctly to include those umlauts? Did you ensure that you have your file encoded as UTF8 and that that UTF8 support has been enabled in your config file? If you keep having problems after checking those things above, please attach your converted font file as well as your source font file to your next forum post.

No problem. Glad to hear that you manged to get it working

The new position (value) is part of the event that you receive: typedef struct GEventGWinSlider { GEventType type; // The type of this event (GEVENT_GWIN_SLIDER) GHandle gwin; // The slider that is returning results #if GWIN_WIDGET_TAGS WidgetTag tag; // The slider tag #endif int position; uint8_t action; #define GSLIDER_EVENT_SET 4 /* Slider position is set. This is the only event returned by default */ #define GSLIDER_EVENT_CANCEL 3 /* Slider position changing has been cancelled */ #define GSLIDER_EVENT_START 2 /* Slider position has started changing */ #define GSLIDER_EVENT_MOVE 1 /* Slider position has been moved */ } GEventGWinSlider; Have a look at the slider demo, it shows exactly how to do that. Here's a simplified section of that (untested): const char* sAction; GEvent* event; GEventGWinSliderEvent* sliderEvent; event = geventEventWait(&gl, TIME_INFINITE); switch(event->type) { // Handle slider events case GEVENT_GWIN_SLIDER: { // Cast to slider event sliderEvent = (GEventGWinSlider*)event; switch(sliderEvent->action) { case GSLIDER_EVENT_SET: sAction = "SET"; break; case GSLIDER_EVENT_CANCEL: sAction = "CANCEL"; break; case GSLIDER_EVENT_MOVE: sAction = "MOVE"; break; case GSLIDER_EVENT_START: sAction = "START"; break; } printf("Slider position = %d %s\n", sliderEvent->position, sAction); break; } default: break; }

Do the same thing that you're doing now but read the value that comes as part of the event that you receive as @inmarket suggested. Then, everything will work exactly the way you want it without any dirty or complex workarounds.

Yep, there are a couple of users here on the forum who are successfully using µGFX in visual studio projects. I also know of two commercial customers who do that.