Joel Bodenmann

We've never heard of such behavior before. I'm not really sure what to tell you... There's nothing obviously wrong in your configuration file. A couple of questions that might help to track down this issue: Is this "new" behavior or did you experience this issue since the first time you used µGFX? Are you getting that behavior only on that specific platform or can you reproduce the same issue running your µGFX application in a Windows / Linux / OS X environment? Are you updating the label/image contents in a loop or does this only happen when the user clicks something? Is it worse when the user is clicking around more? Is the time interval consistent? Is it really just that widget area that gets blacked out or the entire screen / other portions too? Is it a solid black? Does the color change if you use a different widget style (different background color)? Is it possible to reproduce the problem by creating a new, minimal test-case project? Are there other things that stop working during that time? I'm sorry that we can't tell you exactly what the issue is right now. We've never experienced this before.

Information that might be valuable to track down the problem: Does this happen every time you start the program (eg. do you always need to launch it twice)? Does this only happen once after you rebooted and then never again? Do you see any debug message on the terminal? What happens if you call the driver initialization code a second time manually (within the same program)? Anything else that would help to establish a pattern...

Depending on the platform, that might actually be slower. If you have the RAM to spare you might want to consider rendering into a pixmap and then blitting the finished pixmap on the display instead. But again, it depends on the system whether that would actually be faster. For example, on an STM32 using the LTDC that might actually be slower depending on where the pixmap will be located in (eg. if it's in the same memory as the framebuffer then you would slow things down compared to simply drawing multiple times over the same framebuffer).

Hello @paxx and welcome to the µGFX community! We have not been involved into the development of the amazing EMF2016 badge. It's @mbrej who developed the microPython wrapper fro µGFX. We don't have any badges that we could hand out or anything. In fact, we are still waiting for the two that we were promised If somebody (or the entire community) would be interested in developing a similar device, we would definitely be in for the ride. I guess the easiest way to achieve this is to pick a platform supported by microPython (eg. STM32) and build up from there. @mbrej mentioned that he's looking forward pushing the uGFX wrapper upstream to the microPython repository. I'm not sure what the progress on that is - but he's currently definitely very busy.

In that case there is not much you can do other than simply ignoring or turning them off as per the explanation in my previous post. I'm glad to hear that you got it working though! We would love to hear & see more about your project in the User Projects section It's always interesting to see what people build with µGFX.

Thank you very much for your good words, we appreciate it a lot! µGFX has definitely grown far behind of what I ever imagined back when I published it first on the ChibiOS forum as a ChibiOS-only extension. Working together with @inmarket who joined the project later on has been nothing but a real pleasure. Seeing an active community building around the project is one of the main sources of motivations for us. Judging from the screenshot it doesn't compile. You get a lot of errors. Are you sure that the compilation succeeds? One thing to note is that you shouldn't trust the syntax highlighter of IDEs once you start working with uGFX. The build system of uGFX is very complex. We haven't seen a single IDE so far that was able to handle everything correctly. Due to trying to optimize everything as good as possible we rely heavily on pre-processor magic and conditional compilation/linking. Many macros/defines get modified by the pre-processor during compilation - which makes it impossible for the IDE to show you the correct highlighting and error reporting. That was the case at least over a year ago when we first build the support for the STM32F746G-Discovery board. Most certainly ChibiOS will have support for the F7 by now. However, due to the heavy workload we are experiencing at the moment we didn't have time to check ourselves. If you could give it a go that would be nice. Ideally we would add a ChibiOS + µGFX demo for the STM32F746G-Discovery to the example projects download section. When I remember correctly that was possible back with ChibiOS 2.x. I guess it is even a lot easier now where ChibiOS got split up into the OS and the HAL modules. I'd recommend you to check with the people on the ChibiOS forum.

As @inmarket mentioned, using containers is the recommended, easiest & most optimized way of achieving what you want to do. Depending on your use case, this might be interesting too:

Thank you for sharing your experience on getting uGFX working in Kinetis Desing Studio! I am sure other people will appreciate this in the future. Ideally we would write a detailed step-by-step guide for the "Using µGFX with..." section in the wiki.

You are getting that error message because no keyboard driver was linked while GINPUT_NEED_KEYBOARD was set to TRUE. The /boards/base/multiple/Linux-Framebuffer board files don't include a keyboard input driver, neither does /boards/base/multiple/Linux-Framebuffer-Touch. Right now only the Linux board files for SDL (recommended) include the keyboard input drivers. That is due to the fact that SDL provides a common high-level API interface for interfacing keyboards. The Linux framebuffer itself has nothing to do with keyboards and hence doesn't know how to interface them. The most proper solution is writing a generic Linux event input system driver for keyboards, similar (or exactly the same) as the one for the mouse/touchscreen:

Hello @arnonh and welcome to the community! As @chrisjn52 mentioned it would be useful to see some compiler output log and/or screenshots of your setup. There is a step-by-step guide on how to using the µGFX library with ChibiStudio which is Eclipse based. That guide uses the makefile system as well. Did you have a look at that? ---> https://wiki.ugfx.io/index.php/Using_ChibiStudio

This is looking very nice and helpful! Thank you very much for sharing your work! We will have a closer look at this next week. We're sorry for the unexpected delays this week but we got somewhat busy with lots of stuff.

Yes, the GINPUT module has a keyboard input driver. Various drivers can be found in the /drivers directory. You can find a demo for using the GINPUT keyboard interface under /demos/ginput/keyboard. This is somewhat related:

Hello Mano, You can get a single support ticket for the price of (currently) 25 USD. You can access the support system by clicking on "Support" in the top bar on this site. Those single one-time support tickets are there to get any kind of question(s) answered as quickly and as extensively as possible. All questions will be answered within 24 hours guaranteed on week days. If you are interested in more extensive support (for example: writing code, reviewing code, fixing mission critical bugs, adding new features, ...) we offer a per-hour support which you can either purchase as individual hours or blocks (eg. a pack of 10 hours worth of support). Please don't hesitate to contact us directly to get a quote on a support package that fits your needs. The initial response time on any support inquiries is guaranteed to be less than 24 hours on business days. It's needles to say that everything will be handled with the highest priority and as extensively as possible. Support is available through either the support ticket system on this website, e-mail or Skype & Phone calls (scheduled). The technical support is for answering questions and so on as explained above. The license is a commercial license that allows you to use the µGFX library for a commercial application/device/product. µGFX is only free for home, hobby & educational purposes as well as open source projects. You can either purchase a per-device license or an unlimited license which doesn't put any restrictions on the quantity of devices.

If it helps anybody, the display panel of the STM32F746G-Discovery board is a Rocktech RK043FN48H.

You can use the GINPUT Toggle driver interface for that. Once you implemented you board file, you can use gwinAttachToggle() to attach a physical button to a toggle input role of a widget. Similarly you can use the GINPUT Dial interface for analog inputs (rotary encoders, potentiometers, ...).

Hello and welcome to the community! I'm afraid there is currently no ready-to-print version of the µGFX library documentation available. Thank you for the suggestion. However, it is possible to save/print/convert the wiki pages to PDF files. It's also possible to tell Doxygen (the API reference documentation tool) to output LaTeX/PDF files.

Very nice, thank you for sharing this! Could you post a picture of the bare PCB once you removed the display? Would be nice to have a reference for the "connectors" that area required to hook up a different display panel. It seems like the touchscreen has a dedicated connection to the PCB that his hidden behind the flat flex cable of the display panel.

I guess you have to dive into the reference manual then to figure out how to set up the DMA streams to avoid the collisions. You definitely want to use DMA2D. It gives a huge performance boost. Without it you will waste a lot of CPU time for simple tasks such as drawing rectangles.

Yes. That way you can be sure that that part works. I don't know out of the top of my head whether the DMA2D might collide with certain DMA streams. You might want to check that in the reference manual of the STM32F746 microcontroller. To give it a quick try, you can disable DMA2D by setting LTDC_USE_DMA2D to FALSE in the display driver configuration file (/drivers/gdisp/STM32LTDC/gdisp_lld_config.h).

Hi, Can you please give some more information about the problem that you're facing? For example: Are you getting any compiler or linker errors? Is µGFX running on your Keil RTX project without all the ADC stuff? Can you get the proper values from your ADC with Keil RTX but without having µGFX enabled at all? Any kind of information is helpful to track down the problem. At the moment we don't have any information to work with. All we can tell you at the moment is that Keil RTX has been tested well with µGFX.

Hello and welcome to the community! I used a diff tool to ensure that the only difference really is declaring that variable, and indeed it is. Getting a nullpointer back from gwinXxxCreate() usually indicates insufficient heap space. However, you are using a static GGraphObject so this can't be the issue. Adding that variable doesn't do anything but increasing the stack size of the main() function. Therefore, I suspect this to be an issue with hitting the max. stack size. However, that would be a very rare case. I assume that you did the standard debugging steps already (like doing a clean build, trying adding other variables of different sizes and so on...)? I'd strongly recommend you to try running your uGFX application on a desktop such as Windows, Linux or Mac OS X which are all support out of the box. If you can provide us with a full, yet minimal test case that allows us to reproduce the problem we can further investigate.

Happy to hear that!

As listed in the corresponding documentation the PushButton widget already comes with a rounded-rectangles and ellipse (along with others) rendering routines. Just have a look at their implementation that you can find in /src/gwin/gwin_button.c to get some inspirations.

Please use the latest master of the official µGFX library repository. We fixed exactly that issue about two weeks ago: I strongly recommend you to hit the "Follow" button on the µGFX Development blog to stay up-to-date about ongoing changes and fixes:

Using a pixmap that spans the entire display area is a very bad idea in this particular case because you have to use gdispGBlitArea() to copy the contents from the pixmap to the frame buffer. Although you have DMA2D that can take care of this to free CPU resources you still pay A LOT of resources for doing that. The LTDC of the STM32 that you are using is able to handle two layers (framebuffers) natively. Unlike with the pixmap solution you will never have to copy anything around. All you do is swapping a pointer somewhere in one of the LTDC configuration registers. That is a very fast operation. You can even blend the layers, not just hard-swap them. To use this feature you will have to modify the STM32LTDC driver that can be found in /drivers/gdisp/STM32LTDC and your board file. In your board file you will find that the ltdcConfig struct only initializes one layer, it keeps the second layer uninitialized by using LTDC_UNUSED_LAYER_CONFIG. The recommended way of adding support for multiple LTDC layers is by using the multiple displays support of uGFX. After all the two LTDC layers are nothing but two displays as they are complete, fully features framebuffers. All you do is telling the LTDC which of the two you want to show on the actual display. You can use the gdisp_lld_control() and gdisp_lld_query() driver API to retrieve the GDisplay* pointer(s) to the additional layer(s). This means that after calling gfxInit() in your code you simply use two gdispQuery() function calls to retrieve the two GDisplay* pointers that then allow you to draw to each frame buffer independently. You can then use a gdispControl() function call to swap the currently active layer. As you can see you would proceed exactly the same as you would with your current pixmap solution: You draw to the pixmap using the GDisplay* pointer returned by gdispPixmapCreate() and you swap/copy the framebuffers using gdispGBlitArea(). With the new solution you would still proceed exactly the same, just that you use the hardware support of the LTDC to do all that which will really save you tons of resources. I assume that this was quite a bit of dense information. Please feel free to open a new topic to further discuss this if you are interested in implementing this. We are happy to help wherever we can. We definitely strongly recommend not using a full-size pixmap in your case, it's a waste of a lot of resources. Use the LTDC which has been designed to take care of this.