Joel Bodenmann

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.

@timandr just checking: Do you have all the information you require to proceed? Please don't hesitate to ask if you have any questions. We are happy to help where we can

Thank you for sharing the video. Personally I am pretty sure that what you are getting there is way below the performance that the STM32F469i can deliver. As mentioned previously the DSI setup of the ST demos don't seem to use the optimal settings. Blitting a pixmap on a system like that should not not be a visible operation, it should happen so fast that it appears to be instant. I hope that we will have time to write the proper board files before we release µGFX 2.7 by the end of the month. We are sorry for the delay, there's currently just too much on the ToDo list.

Sadly we are having the same problem: We are engineers, not designers. Both @inmarket and I are not very good when it comes to making visually appealing designs. This is why there is no set of fancy/nicer looking default rendering routines for GWIN that could be used on more powerful systems. @chrisjn52 is currently writing a set of minimal, old-school styled 3D rendering routines. I'm not sure what the progress is on that. You can create gradients by using gdispBlendColors(). You can find an example in the default rendering routine of the pushbutton widget which uses a gradient background/fill unless GWIN_NEED_FLAT has been set to TRUE: // Fill the box blended from variants of the fill color tcol = gdispBlendColor(White, pcol->fill, BTN_TOP_FADE); bcol = gdispBlendColor(Black, pcol->fill, BTN_BOTTOM_FADE); dalpha = FIXED(255)/gw->g.height; for(alpha = 0, i = 0; i < gw->g.height; i++, alpha += dalpha) { gdispGDrawLine(gw->g.display, gw->g.x, gw->g.y+i, gw->g.x+gw->g.width-2, gw->g.y+i, gdispBlendColor(bcol, tcol, NONFIXED(alpha))); }

I guess there is not much left to say for me... Rendering a BMP from flash should definitely be a very fast operation. As mentioned in my previous post, the ST example uses a weird mode for the DSI. That may or may not result in lower performance, I haven't studied the datasheet enough yet to give a certain answer to that question. Unfortunately we are very busy the following two weeks, it might take up to three weeks until we get to finishing the implementation of the official board files for the STM32F469i-Discovery board Please don't hesitate to ask if you have any questions. The limitation(s) imposed by the single-fine-inclusion mechanisms are documented here. You can find more information about the performance & resource requirements of our PNG decoder here (mind the comments!):

We are happy to hear that you are making good progress with your table widget. You definitely seem to put a lot of effort into it. Having a full test protocol is a very professional thing to do. Please keep it up and don't get discouraged, this is definitely not an easy job if you want to get it right!

Hello Maytham and welcome to the community! @inakto sent us his project which is working. However, it is far from a state where we could just copy-paste and include it into the repository. We started working on this and we got the basic display stuff working. We didn't look into the touchscreen stuff yet but that should be rather straight forward because µGFX already has a driver for that touch controller. The main issue is that the official STM32F469i-Discovery demo(s) from ST themselves use the DSI in a the video mode. That is by far the "worst" mode to use. From what we can tell you would only use that mode if you're short on memory which isn't the case on that board. Theoretically we can just take the ST board files and wrap them around the uGFX board files, but the DSI definitely wouldn't be working at its maximum performance.

Hello and welcome to the community! It is definitely possible to run µGFX on an 8-bit AVR microcontroller. I have a friend who successfully ran it on an ATmega with an ILI9341 SPI display. Furthermore, I think that @inmarket also used it on some Arduino system based on an AVR microcontroller. However, while it is certainly possible to run µGFX on such a platform it really isn't recommended. We recommend to use at least a 16-bit platform.

As @inmarket mentioned the issue seems to be a restriction in the compiler used by Keil. Your options are: Using a different underlying system such as Keil RTX, FreeRTOS or ChibiOS which are very well tested with µGFX (or any of the other alternatives) Change your Keil project to use GCC instead of ARMCC Investigate on how to use the "Embedded Assembly" alternative (link: http://www.keil.com/support/man/docs/armcc/armcc_chr1359124253861.htm) which appears to not have these restrictions.

Hello @Sahsuvar and welcome to the community! If memory serves me right it is indeed just a syntax problem. As @inmarket mentioned we currently just lack the man power to take care of everything. If you can get it fixed, we would love to put a version of the code that works with the Keil compiler into the official µGFX library. Note that you can use the GFX_COMPILER_KEIL macro to write Keil specific stuff. One of the reasons why this currently isn't that high on our ToDo list is because most of the people that use Keil (with the µGFX library) are using Keil RTX as the underlying system (RTOS). In that case the Raw32 port is not used.

Sounds good! Can't wait to see it!

The Linux-Framebuffer board files only contain drivers & board files for passive display output. They don't contain anything that handles mouse/touch inputs. If your touchscreen/mouse is accessible through the Linux input event system, you can simply use the Linux-Framebuffer-Touch board files which will automatically include the /drivers/ginput/touch/Linux-Event driver. You can find more information about this here: https://wiki.ugfx.io/index.php/Linux#Touchscreen_.2F_Mouse And a complete tutorial here: https://wiki.ugfx.io/index.php/Raspberry_Pi Also, this new Linux-Framebuffer-Touch board file has been added just a few days ago. You might want to click the "Follow" button on the µGFX-Development blog to stay up-to-date about these kind of new things, updates & bug fixes: I hope that helps. Let us know if you have any other questions.

Hello @Sting, We worked a bit with the Linux framebuffer board ourselves yesterday and we found a bug that prevented using it on some systems. We fixed that bug now. You might want to retry using the framebuffer driver on your embedded Linux device.

Hello @timandr and welcome to the community! That is actually the expected behavior when manually adding files to a project. Judging from your screenshots you are doing the right thing. You always have to tell the compiler/linker which paths it should include. This is "normal" and is nothing special with Eclipse or your particular setup. However, note that in general you could also just use the Makefile(s) that come with the µGFX library. We are currently working on a project that uses an Altera FPGA and the NIOS-II soft CPU. It too comes with an Eclipse environment and generates Makefiles for the project. At least with our project it is possible to just include the µGFX makefiles in that generated makefile. Apparently the Altera tools are smart enough to keep manual changes made by the user. But that's just additional information. You are in no way obligated to include the µGFX library by using the built-in makefiles. You can just include it by manually adding all files an paths. It's just a very tedious job. Don't trust the highlighting of Eclipse. The µGFX build system is way too complex for this. Many of those macros get defined and undefined dynamically during the compilation process. Eclipse only knows about the state of those prior to compilation. Just ignore the Eclipse highlighting. We never worked on the Microblaze architecture itself but as mentioned above we ourselves as well as a few of our customers are running µGFX on FPGAs with soft-CPUs successfully without any problems. Getting this to work should definitely not be a big problem. Usually it's a bit of a pain until it compiles the first time because each SDK of those soft-core/FPGA vendors works a bit differently. All in all, what you are describing is correct. You are definitely approaching this the right way. The compilation error you are getting (the one about gfx.h: No such file or directory) is most likely caused by the fact that you are not adding the path to ugfx/src to your compiler include paths list. Can you please try adding the that path and making a clean build? I hope that helps. Please don't hesitate to ask if you have any other questions.