Joel Bodenmann

Very nice, great work! Can't wait to see and try the finished implementation of this. When text is being truncated, are you adding some indicator like "..." ?

Thanks for getting this done so quickly! I will have a look at it tomorrow and let you know. If you really hate your life you can enable -pedantic. But the warnings I got I got from regular GCC while compiling on win32. When developing something like a widget you definitely want to use the Windows/Linux/MacOS port, otherwise you have to flash your target each time and debugging is a pain too. Also I got crashes with the spinbox that was supposed to show the days of the week. However, I simply commented it out and didn't investigate due to not having a whole lot of time. I'll try again with the new version tomorrow and let you know how it's looking.

The two most likely issues that cause this error are: Your Linux kernel has not been compiled with framebuffer support or it isn't enabled Your Linux framebuffer is in a non-standard location. Have a look at /boards/base/Linux-Framebuffer/board_framebuffer.h. The board file looks for /dev/fb0 and /dev/fb/0 by default.

I took a closer look at the code. Here are my thoughts: The gtimerInit() function must go into the Create() function. Initialization should only happen once. After that you can use gtimerStart() and gtimerStop() at any time as you are doing now. The callback functions you use with the GTimer don't have the correct signature. They must be of the following signature: void foo(void* param). You are free to cast that void pointer to anything you like inside the function. The drawing function doesn't have the correct signature. It must be the following signature: void foo(GWidgetObject* gw, void* param). Some functions don't use the parameters passed to them. Suppress warnings by using (void)x; the upArrow and downArrow arrays in the drawing function should only be created/declared if GDISP_NEED_CONVEX_POLYGON is set to TRUE. Otherwise you get compiler warnings about unused variables. The configuration macros in the header to set the padding, border width, max. character count etc. should either get a prefix (eg. GSPINBOX_) or should be moved to the C file (recommended!) to avoid naming conflicts. That being said, I'd also like to say that I like your style of commenting things. Well done! If you handle the things listed above we can add your spinbox widget to the library

To further extend what @inmarket said: Until a few days ago, the GWIN module required you to use a mouse (touchscreen). You couldn't just use the toggle inputs alone. This is why you are getting the errors about the missing mouse functions, macros and so on. You need to enable the mouse support by settings GINPUT_NEED_MOUSE to TRUE in your configuration file. However, this limitation has been removed a couple of days ago, it's now possible to use the GWIN module just with the toggle buttons as inputs (without any mouse/touchscreen). To benefit from this behavior you'd have to grab the very latest version of µGFX (newer than the latest stable release 2.5) from the repository. Edit: It wasn't actually the GWIN module that required a mouse input device, it was the widgets module which is a GWIN sub-module. So it has always been possible to use GWIN without a mouse. Just not the widgets.

You are allowed and welcomed to optimize the drawing of your widget

What are you trying to say / ask? @inmarket said exactly that.

Ah, I missed that, sorry. In that case having a row per queue makes sense. Basically this would extend the current list widget with a row option. Sounds good!

Thank you, we appreciate that you want to make something that can be added to the repository at the end. Earlier you mentioned that the number of rows and columns is known/fixed. Why would you mess with using queues then? To me it sounds like you should be using a static array instead. That saves a lot of overhead. If you like you can attach your header file to a post in this topic once you think that it's ready. I can give it a look There are no generic widget design guide lines as there is not much room for customization. The VMT is pretty much gives all the guidelines.

This is entirely possible and a very common technique. If you want to do it like this, we definitely recommend using am STM32F4 or an STM32F7. Note that only the newer models of the F4 have the built-in LCD controller & hardware acceleration.

Yes it's correct that the toggle driver called "Pal" is for the ChibiOS/HAL. Just as with the GDISP module for displays, you will have to write a driver that works with the HAL that you want to use. The driver then uses a board file to interface the actual hardware - exactly the same as with the GDISP module. You basically have to implementing everything in /src/drivers/ginput/toggle/Pal but using the other HAL that you'd like to use. The driver interface can be found in /src/ginput/toggle/ginput_driver_toggle.h. Implementing the palXxx() functions on your platform is definitely not the right way to go. Sorry for the confusion on this. The toggle drivers are not often used and we simply didn't clean up properly after we removed the ChibiOS-only constrain. That's correct. That is up to the driver / board file.

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.