Joel Bodenmann

The easiest, most flexible & best solution for a use case like this is to write a custom rendering routine. That gives you complete control over how your list gets rendered. There's a guide on that: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine However, depending on your needs (if the features provided by the list widget are not exactly what you want), you might want to write a custom widget instead: https://wiki.ugfx.io/index.php/Creating_a_widget Don't hesitate to ask when you have any questions. We are happy to help wherever we can.

The distorted image you see on the first startup, is that always exactly the same?

There are two very likely causes to this: You don't have your FPU enabled. The shown demo is a very floating point intensive demo. Your clocks are not setup correctly (eg. your CPU runs way slower than it could/should). That strongly suggests an out-of-memory situation. I'd recommend you to step through the code to figure out why gfileOpen() fails. All in all you might want to ensure that all things you want to do work independently first. Eg: Try to create a project that doesn't do anything but playing your MP3. Once that works, create a project that doesn't do anything but implementing the GUI. Once that works, add all the other stuff (eg. peripherals and what not) and ensure that that works. At the end throw everything together step-by-step so you know exactly where and when something stops working.

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!