Joel Bodenmann

Then please check the other thing mentioned.

Do the other widgets show up when you run the preview in the µGFX-Studio? Assuming that your system is not crashing, the most likely issue is that you ran out of stack. When there's not enough memory on the heap, the gwinXxxCreate() functions will return null-pointers. More information about memory management can be found here: http://wiki.ugfx.org/index.php/BareMetal Also note that it is possible to use everything with static memory: http://wiki.ugfx.org/index.php/Widgets#Widget_creation

Thank you very much for this awesome contribution!

Glad to hear that you got it working! Sorry for not being more specific about the SSD1963 driver implementation. There are many drivers in the library which evolve over time and some which we haven't written ourselves. It's sometimes hard to keep stuff separated

Yes, you definitely have to write the entire pixel value! Otherwise you are missing parts of the pixel data which leads to incorrect colors. You specify the pixel format in your driver configuration file (eg. RGB565). From that, the pre-processor determines the correct type to use and puts a typedef on color_t for that. This means, if your pixel format is set to RGB565 the color_t will be a 16-bit type. Your board file must put the entire (pixel) value on the bus according to the pixel data packaging stated in the datasheet (somewhere around page 15 depending on the revision). So to summarize: Yes, you must write the high- and low portions of the received uint16_t in two write cycles if you are using the display in 8-bit mode. Without remembering all the details of the SSD1963: Usually all transitions will be either 16- or 8-bit. As in: When you set your SSD1963 to RGB565 mode (16-bit pixel values) and use an 8-bit bus, then you always have to do two write cycles - at least for the data. All the information specific to the SSD1963 are off the top of my head. Please consult the datasheet for more precise information. I have a feeling that the SSD1963 only works in RGB666 (at least by default) which requires you to do three write cycles with an 8-bit bus. Please just look all that stuff up in the datasheet.

Hello Rafael, The SSD1963 is known to work well in 8-Bit mode. There's really no difference besides that you have to do two write transitions instead of one if you need to write a 16-bit value - everything else stays exactly the same. The only thing that you have to change to use the display in 16-bit instead of 8-bit mode are the write_index() and write_data() implementations in your board file. Please consult the datasheet to figure out how the data has to be packed on the bus. When I remember correctly, the driver initialization code stays exactly the same as the SSD1963 is configured for 8- or 16-bit mode via jumpers. This is a video of an SSD1963 running in 8-bit mode on an ARM-Cortex M3 using µGFX:

As @inmarket mentioned in his post the number of file descriptors is limited. It might be that you need to increase that limit depending on how many files you want to have opened simultaneously. The corresponding setting is GFILE_MAX_GFILES. Other than that it will be most likely a memory issue. Please check the points listed by @inmarket. All of them.

As long as it doesn't compile when executing make in the terminal there's no reason to play around in Eclipse. Can you please show us the file tree of the path C:\Users\TSV\Desktop\NeonWS\new ? Also, I assume that you tried make clean just to be sure? Can you please try to execute make all in the /project directory of the example that you downloaded and unzipped without modifying it at all?

We spoke to the author of the driver and he mentioned that the most likely cause of this problem is a bug in the block buffer allocation & management code which might cause an overflow for certain resolutions. There's not much more we can do for you as we don't have the hardware (display + required circuitry) to try it ourselves. This driver was a contribution - we haven't written it ourselves.

Yes, that is possible too. Every widget is completely customizable. There are two different ways you can customize an existing widget: WidgetStyles and Custom Rendering Routine: In case of you like how the different available rendering routines of a widget look like and you just want to change the colors, you can simply assign a different WidgetStyle to that widget using gwinSetStyle() (or gwinSetDefaultStyle() if you want to use it for all/most widgets). If you'd like to have complete control over how a widget is being rendered you can create your own custom rendering routine in your application code and use gwinSetCustomDraw() to assign it to the widget. There is a complete article on the wiki (linked above) that explains step-by-step how a custom rendering routine can be implemented and used. Also, if you want to get one step further, it's possible to create custom widgets from scratch. That is explained here: http://wiki.ugfx.org/index.php/Creating_a_widget

I am not. That is what the GEVENT module was designed to be used for so everything is okay. What I meant is that it would be wrong if you would use it to drive a ModBus interface or other time & event critical things. To wrap it up: It seems like you are hitting one of the limitations of the current version µGFX. Having an (optional) built-in event queue has been added to the feature requests list already. We decided not to add that feature in the current major version of µGFX because it would require redesigning many things. Instead, this is something we will be looking into for µGFX 3.0 which we started working on already. By the way: As @inmarket all the existing components & features have been designed to work well with this very resource friendly solution that µGFX 2 uses. Having a widget that constantly sends events sounds like something that doesn't match the design philosophy of µGFX.

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?