Joel Bodenmann

As we mentioned in your previous topic to this problem, the author of the driver told us that it's possible to that there is a small bug in the buffer block allocation/management code. We can't debug this because we don't have the required hardware/setup. The driver has been contributed by a community member. All we can do for you is assuring that it is an issue in the driver itself because the high-level part of the code is very well tested and no known issues exist. You will have to fire up your debugger and dive into this, sorry. At least you know where the problem is. We are very sure that the problem is solely in the driver code (gdisp_lld_ED060SC4.c). Link to previous topic:

µGFX doesn't use a global "update" timer. It only redraws content (and only the parts of it) when it really has to. This saves a lot of resources. Therefore, there's no setting where you can set a fixed or minimal frame update rate. If you need to periodically update a certain element or area, you can use a GTIMER and manually issue a redraw. However, when you need that (eg. when updating a counter or similar) we recommend using the GWIN system which automatically handles redrawing itself. You usually If you give us some more information about what you archive we'll be able to give you better/proper advice.

The built-in font engine doesn't support RTL languages (right-to-left) but only LTR (left-to-right). Neither any of us nor the original font engine author knows/speaks any RTL language and therefore we won't be able to implement it ourselves. The chances of getting it right are just way too small. However, our community member @vahid4134 needed support for RTL languages himself and he ported a 3rdparty font engine which appears to work very well for him. You can find more information here: Please let us know whether it worked or not, we are very interesting to see some results on this.

Yes, that's correct. The display panels you connect to the STM32 microcontroller (when using the LTDC) use a standard RGB interface. If the physical connection is the same (they are usually 40 pin FPC cables) you can plug in any panel that has an RGB interface - no matter what size and what resolution (note that the maximum resolution that the LTDC can handle is something like 1024x768 if I remember correctly). Those RGB interfaces are VERY common and the only trouble you will have is deciding which one you want to pick of all the thousands available I have a friend who used an STM32F429i-Discovery board and replace the 2.4" display on there by a 5" display with a much larger resolution. It works very well. Same would apply to the STM32F746G-Discovery board: If the physical connections match, it's just a matter of plugging the new display panel in. Otherwise you'll just have to do some soldering magic or purchase an adapter board as these connections are almost always some kind of standard. There are also other standards out there like MIPI or LVDS which would allow you changing the actual display panel itself at any time. However, they are less common among these "smaller" systems.

Changing from one screen to another is done by using containers and then switching their visibility. You might want to use the µGFX-Studio for this, it allows you create display pages in the left "Display Pages" pane and it will generate the high-level code to change between them (namely guiShowPage()). If you need a real-life example you might want to have a look at the code of this example project which uses a button to change between two different display pages: As µGFX applications are fully portable you should be able to take the application code and run it on your own hardware or compiling it on Windows/Linux/OS X to give it a try. When it comes to transitions: Currently µGFX doesn't provide a framework to handle animations. You'd have to code them yourself. I hope that helps. Please don't hesitate to ask if you have any other questions.

µGFX has been supported to run on any platform. No matter what you choose, you will be able to use µGFX with it. The question is how much effort you have to put into it (eg. when you use something with existing ports and drivers that will save you a lot of time). To give you better / more precise advice it would be helpful if you could tell us a bit more about what you want to do. For example: Will it just be a regular industrial grade static GUI or are you expecting to work with animations? Is the system only going to handle the GUI or will it have other jobs too? Assuming that we are talking about a regular control device you might want to consider the very popular STM32 microcontroller family. The STM32F4 and STM32F7 microcontrollers are the most used ones by the µGFX community and this is what we mainly use ourselves for development. They have an integrated display controller (LTDC) which removes the need to mess around with a dedicated display controller. Furthermore, they provide hardware acceleration (DMA2D, ChromART) which allows doing fancy animations and stuff without killing the CPU. Another nice benefit is that you can use different LCD panels without changing the hardware: You can connect any RGB panel directly to the microcontroller. This means that you can start developing with a regular 4" or 5" display from an easy-to-purchase development board (eg. STM32F746G-Discovery) and simply plug in a larger panel once you feel the need. I hope that helps. As mentioned there are many different things to consider.

Glad to hear that you got it working!

We ourselves (and a couple of our customers) are using µGFX on the NIOS-II platform. That is a SoC platform (hard- and soft-cores) for Altera FPGAs. They too use a modified Eclipse as an IDE. We have never encountered any issues using µGFX in those projects, it just worked out of the box. It too generates the makefiles automatically because, as you said, those change depending on the systems configuration. All we had to do was including the main µGFX makefile and the driver make files in that generated "main" makefile. We followed 1:1 our own guide on how to integrate µGFX using the makefiles and it works very well out of the box. It seems that the build system recognizes the changes in the makefile that were made manually and keeps them in there. As that will most likely be part of eclipse I assume that this should work for you just as well. So after all it boiled down to adding five lines to the generated makefile and µGFX was complied successfully with the rest of the system. So what keeps you from adding µGFX to your project the way it's explained here? Edit: All we had to do was adding these three lines to the top of the generated makefile: GFXLIB = \path\to\your\ugfx include $(GFXLIB)/gfx.mk include $(GFXLIB)/boards/base/Altera-MAX10-NEEK/board.mk C_SRCS += $(GFXSRC) APP_INCLUDE_DIRS += $(GFXINC) Of course the variables are not the same as you are working on a completely different platform. It's just to show you what we had to do to get it working, and that's really all.

A board file is nothing but a file containing functions that the driver will use to communicate with the piece of hardware. To write a board file, you simply copy the board file template that you find in the drivers directory and implement the empty functions. In your particular case that would mean that you copy the file /drivers/gdisp/STM32LTDC/board_STM32LTDC_template.h to your project and rename it to board_STM32LTDC.h (the driver will automatically include that file). All you have to do is implementing the functions in there using ChibiOS/HAL instead of CubeHAL. With other drivers this is less cumbersome because you usually just need to write to an SPI interface or similar. However, when using LTDC you have to initialize the memory interface, setup the SDRAM timings and so on. Hence writing a board file for the STM32LTDC driver is a bit more cumbersome. However, all the stuff that is "difficult to figure out" (the proper pin configurations, timings, ...) can be copied from the existing board file. You just need to use the ChibiOS/HAL API.

The process is the same as for any other font. Just make sure that you enable unicode support in the configuration file and don't forget to ensure that your source files use an encoding that can hold/represent Chinese characters as well (ideally also utf-8). These two articles contain all the information required: http://wiki.ugfx.org/index.php/Font_rendering http://wiki.ugfx.org/index.php/Cyrillic Let us know if you have any further questions.

We never used µGFX in eclipse with auto-generated makefiles - we always work with manually created Makefiles. We would appreciate it if you guys could write some kind of tutorial/guide on how to use µGFX in Eclipse with auto-makefiles once you got it working. Ideally you would write a new article for the "Using µGFX on..." section in the forum.

Hello and welcome to the community! We fully understand your frustration. Most of us went through the same process. I remember how it took me three days until I had a blinking LED when I first moved to the STM32 platform The problem you are facing is that the board files that you are compiling are not compatible with the ChibiOS/HAL. The board files in /boards/base/STM32F746-Discovery are written for systems that use the CubeHAL (the official STM32F7CubeHAL or whatever the actual name is). ChibiOS doesn't use that CubeHAL but comes with its own HAL (called ChibiOS/HAL). Right now we don't have any board files for the STM32F746G-Discovery board that work with ChibiOS/HAL - you'll have to write those yourself (or use the CubeHAL instead). If you want to tackle writing board files for the ChibiOS/HAL: We are obviously happy to help wherever we can.

Hello Sting and welcome to the community! Assuming that your hardware (drivers, ...) are already supported it doesn't matter which demo you use. However, if you have to implement your own display driver or board files, we recommend using the most basic demo: /demos/modules/gdisp/basic. The recommended way of using µGFX in an Eclipse environment is to just include the µGFX makefile. Therefore, from what you tell you are doing the right thing

Hello David and welcome to the community! We ourselves never have used µGFX in an automake environment. Therefore, we can't provide you with any examples. Using the makefiles is definitely the better approach than the single-file-inclusion due to limitations in the latter. It's definitely good to hear that you got it working! We would appreciate it if you could share your experience to help other users that might hit that challenge. Ideally, you could create a dedicated page for the "Using µGFX on..." page on the wiki.

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.