Joel Bodenmann

Yes that's possible. The layout of the virtual keyboard widget is fully customizable. You can create your custom layouts and use that. It's all a matter of properly configuring the layout structs. The easiest way to get this going is by looking at the implementation of the existing layout which you can find in the two files /src/gwin/gwin_keyboard_layout.[ch]. Once you created your own layout you can assign it using gwinKeyboardSetLayout(). Please show us a screenshot, photo, video or similar once you are done. We're very interested to see what you come up with

Hello Victor and welcome too the community! First of all, can you please make sure that the project compiles fine if you just execute 'make' manually in the project directory using a terminal? This way we can be sure that your project (the paths etc.) are setup correctly and that the problem solely lies in the Eclipse configuration. We are not providing official support for Eclipse. However, as Eclipse is able to cope with external makefiles this shouldn't be a problem. I have never used Eclipse myself so I won't be of a big help if the project compiles by manually executing 'make' in a terminal. Hopefully somebody else in this community is able to help you. As far as I remember @inmarket used Eclipse once to build the demos to verify that everything is still working. Maybe he will be able to help. Other than that I can just guess that it's a path issue. Is it possible that Eclipse uses the root of the directory that you downloaded as a path instead of the project directory where the actual Makefile is located in?

The driver doesn't have to implement gdisp_lld_postinit(). It is optional and that is why you can't find it: The ED060SC4 driver doesn't implement it. My first guess would have been that you run out of memory as the ED060SC4 driver allocates frame buffer(s). However, as you mentioned that it works with larger resolutions we can safely assume that this isn't a memory problem. I'd recommend you to further debug the program (eg. single-step through the init function) to find out where the actual problem is. As the driver doesn't implement the postinit() I'm pretty sure that this is not the source of the problem. We didn't write that driver ourselves, it was a contribution by one of our community members. I'll try to reach out to him. Maybe he has an idea. That might save some time

The current implementation of the GEVENT system doesn't feature an event queue. This is one of the consequences of other decisions that were made back then to keep overall system resource requirements low. Usually this shouldn't be a problem because the GEVENT sub-system is only used for managing the GUI. If you're not listening for incoming events using geventEventWait() you will simply miss the event. This is one of the things that will be changed in µGFX 3.0: An optional event queue. The proper solution to this problem depends heavily on your system and your application. If you are using the GEVENT module to handle time critical physical interfaces then you are doing something wrong. Just like the other modules of µGFX (for example GTIMER) the GEVENT module has been designed to be used for managing the GUI. Another solution is, as you mentioned, to build a queue yourself. You can use the existing GQUEUE module which provides extensive implementations of different queues. Just as a short follow-up: When you say that "this is quite fatal for my application", that sounds like you are indeed using the GEVENT module for something it was not designed to. May we ask what you are doing and what the problem is that you're facing?

Hello Rafael and welcome to the community! The "adapter layer" that you imagined is called the GFILE module. The GFILE module provides a uniform high-level API for any kind of file system interaction. Just like other elements of the library the GFILE module provides a porting interface which you can find in /src/gfile/gfile_fs.h. There is no step-by-step guide on how to implement a port for a new file system because these things tend to be very specific. However, the existing ports and documentation should allow you to write a port for the FreeRTOS FAT library without any troubles. If you have any questions we are of course happy to help wherever we can. To get started, we recommend having a look at the existing ports in the /src/gfile/ directory. Like the other driver interfaces of the uGFX library the GFILE driver interface is based on a VMT. If you are unfamiliar with this technique you can have a look at the Creating A Widget article as it is explained there. Once you have the GFILE module up and running you can use the high-level API functions of other modules such as GDISP and GWIN to easily load and display images and other files. I hope that helps. Please don't hesitate to ask if you have any other

Hello and welcome to the community! We recently received such a development board and we are looking forward writing board files and example projects for that board. However, with our current schedule that might a couple weeks until we get to it. If you are interested we can strongly recommend you doing that yourself. As the board uses the LTDC of the STM32F4 you can use the existing STM32LTDC driver which is known to work well with various STM32F4 and STM32F7 targets. If done right all you have to do is implementing the corresponding board file. You can find the board file template under /drivers/gdisp/STM32LTDC/board_STM32LTDC_template.h. If you have questions we are of course happy to help wherever we can.

Very well done! Great work at finding the problem! We just pushed the fixes to the repository. We will have a look at the RGB888 issue with the STM32LTDC driver later. Right now we pushed the workaround as per your suggestion which allows people using RGB888 instead of having a blank screen due to a hardfault.

Good work checking with the ST demo! I guess it's safe to say that the problem lies somewhere in the STM32LTDC driver or the STM32F746-Discovery board file. Let us know when you find something!

Hello and welcome to the community! It is correct that you are supposed to use gwinContainerDraw_Image() for this. The bad news is that the µGFX-Studio doesn't yet support this feature so you have to code it yourself. Once you created the container you can use gwinSetCustomDraw() to change the image pointer and therefore change the image background. This is a working example: #include "gfx.h" static GHandle ghContainer; static gdispImage imgBackground1; static gdispImage imgBackground2; static void createWidgets(void) { GWidgetInit wi; gwinWidgetClearInit(&wi); // Prepare the background images gdispImageOpenFile(&imgBackground1, "background_1.bmp"); gdispImageOpenFile(&imgBackground2, "background_2.bmp"); // Create container wi.g.show = TRUE; wi.g.x = 0; wi.g.y = 0; wi.g.width = 250; wi.g.height = 250; wi.text = "Container"; wi.customDraw = gwinContainerDraw_Image; wi.customParam = (void*)&imgBackground1; ghContainer = gwinContainerCreate(0, &wi, GWIN_CONTAINER_BORDER); gwinRedraw(ghContainer); } int main(int argc, char* argv[]) { (void)argc; (void)argv; gfxInit(); // GWIN settings gwinSetDefaultFont(gdispOpenFont("*")); gwinSetDefaultStyle(&WhiteWidgetStyle, FALSE); // Create the background container createWidgets(); while (1) { gfxSleepMilliseconds(1500); gwinSetCustomDraw(ghContainer, gwinContainerDraw_Image, (void*)&imgBackground2); gfxSleepMilliseconds(1500); gwinSetCustomDraw(ghContainer, gwinContainerDraw_Image, (void*)&imgBackground1); } return 0; } There are of course several optimizations to consider. This is just a minimal example explaining the theory of operation. Please note: The µGFX-Studio is in a very very very early beta stage. While the µGFX library itself is very mature and provides tons and tons of features, the µGFX-Studio is very young and doesn't support many features yet. If you don't find a feature in the µGFX-Studio this doesn't mean that the µGFX library itself doesn't support it. We are happy to hear all your feedback including bug reports, criticism and feature requests about the µGFX-Studio in the corresponding forum section.

Just to clarify: The "GWIN redraw policy" that @inmarket mentioned is explained here: http://wiki.ugfx.org/index.php/GWIN#Redrawing_mode

Glad to hear that everything is working as expected!

Very nice! Can you please open a new topic in the Development & Feedback section of this forum and share your driver once it's finished?

Let's have a look at the gdisp_lld_draw_pixel() implementation of the existing ST7565 driver: LLDSPEC void gdisp_lld_draw_pixel(GDisplay *g) { coord_t x, y; // Calculate pixel position switch(g->g.Orientation) { default: case GDISP_ROTATE_0: x = g->p.x; y = g->p.y; break; case GDISP_ROTATE_90: x = g->p.y; y = GDISP_SCREEN_HEIGHT-1 - g->p.x; break; case GDISP_ROTATE_180: x = GDISP_SCREEN_WIDTH-1 - g->p.x; y = GDISP_SCREEN_HEIGHT-1 - g->p.y; break; case GDISP_ROTATE_270: x = GDISP_SCREEN_HEIGHT-1 - g->p.y; y = g->p.x; break; } // Sore the pixel information in our own framebuffer if (gdispColor2Native(g->p.color) != Black) { RAM(g)[xyaddr(x, y)] |= xybit(y); } else { RAM(g)[xyaddr(x, y)] &= ~xybit(y); } // Framebuffer content changed, need to flush it g->flags |= GDISP_FLG_NEEDFLUSH; } The µGFX rendering engine calls the that function when a pixel value needs to be changed. The pixel coordinates and value are part of the GDisplay struct that is passed as a parameter. The first thing that happens is that we calculate the pixel position depending on the orientation. This is because the µGFX engine itself doesn't handle the orientations, it's up to the driver to handle this. The reason for this is because some display controllers have native orientation support built-in. The ST7565 doesn't - that's why we have to calculate it manually. As previously established the ST7565 doesn't have a built-in frame buffer. This is why the driver maintains a frame buffer itself (the one that is allocated in the first line of gdisp_lld_ini()). We have store the pixel value that was supplied to us through the GDisplay structure in that framebuffer. This is the point where we decide how we want to store the pixel information in the framebuffer. This is where you decide how you put it in the framebuffer. Store the information however it's convenient to you. Does this help?

Yes sure, that's no problem. If the display controller design calls for a framebuffer you can implement it in the µGFX display driver without any issues - as shown in the ST7565 driver. You can store the pixel information however you like. Just to be sure: Does this answer your question or did we leave something open?

The reason that there is no documentation about the framebuffer format is because there is no framebuffer in µGFX. One of the strong suits of µGFX compared to similar libraries is that it can work without a framebuffer. I assume that as you are talking about the RAM() macro you are taking the existing ST7565 driver as a template? Upon closer inspection you will see that the framebuffer is entirely handled inside of that driver. µGFX itself doesn't know about it at all. The first line in the gdisp_lld_init() function allocates a framebuffer. Note again that the framebuffer pointer is stored in the driver's private area. There is no call that submits/registers the framebuffer to µGFX itself. All that µGFX will do is calling the gdisp_lld_draw_pixel() function. In that function, the driver stores the pixel information in the framebuffer that he himself is managing. Therefore, it can use any kind of format. All you have to do is storing the pixel information in a way inside the gdisp_lld_draw_pixel() function (and similar) that you can retrieve them once it's time to send that information to the display controller. Note: I haven't checked the datasheet of the ST7586 display controller. However, note that may display controllers provide a frame buffer themselves. In that case, you might want to use a different display driver model. More information can be found here: http://wiki.ugfx.org/index.php/Display_Driver_Model I hope that helps. Please don't hesitate to ask if there's anything unclear

Well, that shouldn't happen... Are you sure that the font is opened correctly? Can you manually draw a text using gdispGDrawString() using that font? Can you supply us with a minimal test case example that allows us reproducing the problem?

Caling gwinSetFont() won't issue a redraw of the widget. You will have to manually issue a redraw using gwinRedraw().

That will be a lot of #ifdefs. But I guess as almost all of them are located inside the specific Windows port we might give it a go...

The file(s) is/are located at /ugfx/boards\base/STM32F746-Discovery/ and are included in the board.mk file that can be found in the same directory. In the main Makefile which is part of the project directory that you downloaded, that board.mk file is included by this line: GFXBOARD = STM32F746-Discovery That GFXBOARD variable is extended in the background to the path stated above. All that makefile magic happens in the /tools/gmake_scripts/compiler_gcc.mk Makefile. Simply remove the main.c file from the SRC variable in the main Makefile (the one in the project directory) and use the GFXDEMO variable (eg. GFXDEMO = modules/gwin/frame). It might be possible that you have to remove/rename the gfxconf.h file in the project directory to avoid file inclusion collision. Please feel free to create a new forum topic for this I hope that helps.

That question can't really be answered. It depends on so many different things: The underlying system that you're using Whenever possible uGFX uses infrastructures from the underlying system Which features you are using (configuration file!) Each module can be enabled/disabled individually Each module has sub-features that can be enabled/disabled individually Each of those configurations pulls a different set of dependencies Images Each image format comes with different memory requirements Fonts You can enable and disable sub-features like kerning, anti-aliasing and unicode. Each of those has an impact on the binary size. Fonts are usually stored in the linked binary. Therefore each font will have an impact on the binary size. Fonts can be filtered, this way unused characters don't end up consuming any memory Styles & Renderings Each widget style and custom rendering routine will have an individual impact on the binary size ... The list could go on and on - The point is that it not only depends on the platform you're working with but also which features you have enabled, what kind of resources you're using and so on. In general you definitely want to disable anything in the configuration file that is not explicitly needed/used. Never the less it's worth while to note that µGFX has been designed to be as small as possible. This is also one of the reasons why the source of µGFX is completely open: Many other competitive products only provide pre-compiled libraries. This is not only a pain in the butt but also means that unused features become part of the linked binary. When you don't enable something in the µGFX configuration file, the linker will never ever see the code as it gets removed by the pre-processor even before compilation. You're not We're happy to answer any question we can.

I guess this has to wait a couple of weeks then, sorry! In the meantime we at least updated the STM32F7-Discovery board files to be compatible with the latest STM32CubeF7 HAL (or what ever the right terminology is...). We will definitely take a look at it. It's on the short-term ToDo list.

Hello Ettore and welcome to the community! Sorry for the late reply. We appreciate this a lot. It's nice that you list everything in such a level of detail, nice work! As you mentioned, these changes are very Visual Studio specific. Sadly we don't see a way (yet) to integrate them in an easy way without breaking support for other compilers or introducing a very ugly #ifdef mess. For the time being, we added a note to the documentation that points to this forum topic: http://wiki.ugfx.org/index.php/Win32 Keep up the good work!

µGFX already has a virtual on-screen keyboard widget that is known to work very well. It's highly customizable as it supports custom layouts (eg. you can arrange the buttons however you like). API-Reference: http://api.ugfx.org/group___virtual_keyboard.html Demo 1: /demos/modules/gwin/keyboard Demo 2: /demos/modules/gwin/textedit_virtual_keyboard

We updated the HAL files that the STM32F746G-Discovery board files are using. Everything is now compatible to the latest version of the STM32F7CubeHAL and CMSIS that is available from the ST website itself. If you are still not able to use the new board files with ChibiOS/RT then it's very likely that ChibiOS/RT is using an older version of the ST files. Check the file headers for versioning information. We uploaded a complete, running out-of-the-box minimal project using RAW32 and makefile. I'm afraid we won't have time to create a similar example for ChibiOS/RT in the following weeks. In case of you're going to try that example, please don't forget to rate it if it's working the way it should