Joel Bodenmann

We provide e-mail and phone support as part of a paid support contract. You can find more about paid support (and place orders) on our website: https://ugfx.io/pricing

Nice, glad to hear that you managed to get it working! Thank you for sharing the solution with us.

You do not have to use FatFS to load your NATIVE image. It's correct that the GDISP module provides a function to open an image from a file but you're not forced to use that. You can also use gdispImageOpenMemory() which allows you to open an image from any memory location. However, that won't be as easy if you image is not in your main memory. Note that a gdispImage object is comprised of a pointer to a GFILE object. Using a file system one way or another is therefore a must have. But whether you use something very small such as ROMFS or a custom file system (USERFS) or something big and complex such as FatFS is completely up to you. USERFS allows you to implement your own file system. You can do pretty much anything you want that way and still use the high-level API such as gdispImageOpenFile(). Whether or not that's a good option depends on your goals and experience. Examples exist in form of the already implemented file systems. USERFS really just exposes the existing GFILE abstraction interface. Here's all the information you need: https://wiki.ugfx.io/index.php/USERFS

The flag you're referring to is part of the GDISP driver layer as @inmarket mentioned. High-level flushing behavior gets defined by GDISP_NEED_AUTOFLUSH and GDISP_NEED_TIMERFLUSH. If both are set to false, you shouldn't get any flushing happening without manually calling gdispFlush().

Note that using the proper GDISP image approach by either modifying your SPI flash content format to match the existing NATIVE image format or by implementing your own you get a few benefits such as the fact that you'll be able to display your images within a GWIN imagebox widget and you could optionally implement caching. Manually blitting the pixel contents means that you loose the added value of having a concept of an image object. There are other benefits as well such as the ability to modify the palettes, background colors and so on - all stuff that already exists in GDISP image.

Hello @Hilco and welcome to the µGFX community. The easiest way is to use the NATIVE GDISP image format that already exists. It is a format that we created to support exactly your use case. However, unlike just having the pixel data the image format stores the width and height as well. The overhead is just 8 bytes for the entire header. It's documented here: https://wiki.ugfx.io/index.php/Images#NATIVE So if you use that format to store your images on the external SPI Flash you can easily load and display them using existing GFILE and GDISP API. If that doesn't suite your needs you'll have to implement your own GDISP image handler. The existing one will serve as examples. /* The structure defining the routines for image drawing */ typedef struct gdispImageHandlers { gdispImageError (*open)(gdispImage *img); /* The open function */ void (*close)(gdispImage *img); /* The close function */ gdispImageError (*cache)(gdispImage *img); /* The cache function */ gdispImageError (*draw)(GDisplay *g, gdispImage *img, coord_t x, coord_t y, coord_t cx, coord_t cy, coord_t sx, coord_t sy); /* The draw function */ delaytime_t (*next)(gdispImage *img); /* The next frame function */ uint16_t (*getPaletteSize)(gdispImage *img); /* Retrieve the size of the palette (number of entries) */ color_t (*getPalette)(gdispImage *img, uint16_t index); /* Retrieve a specific color value of the palette */ bool_t (*adjustPalette)(gdispImage *img, uint16_t index, color_t newColor); /* Replace a color value in the palette */ } gdispImageHandlers;

Glad to hear that you managed to get it working!

http://api.ugfx.io/group___image.html#ga0cb760bce6be8c9cb1affc5d568663f1

It appears that your image is simply too small. Make sure that the image is of the same size as the widget itself. The current rendering function of the dial widget that you're using doesn't do a solid-color clear of the area but instead relies on the fact that the image covers the entire widget area.

Hello Andrew, That is a problem known to us. This has been an issue that came with one of the countless completely incompatible CubeHAL updates that ST pushes every so often. This is why all the board file come with the corresponding #undef. Here's ane example from the board file of teh STM32F439i-Eval board: // Avoid naming collisions with CubeHAL #undef Red #undef Green #undef Blue I'm not sure why this is missing in the STM32F746G-Discovery board files now. This definitely was there at some point. I'll go through the git history tomorrow to find the source of that. In any case: The #undefs shown above are the proper solution. These naming conflicts are something that will be handled better in uGFX v3.0 that should be released in 2018.

Hello Andrew and welcome to the µGFX community! I'm currently siting in the train so I don't have all resources (and notes) available. However, I remember that there was a bug fix of the STM32LTDC driver after the v2.7 release (about 6 months ago). I'm not talking about the stuff that you mentioned that got pushed yesterday. I'd like to encourage you to use the latest master branch of the git repository. If you included everything properly into your project you should be able to just replace the uGFX library directory. If that doesn't help I'll try to dig into the notes - This can't be anything serious. We just created a demo project for another uses for the STM32F429i-Discovery and ChibiOS last week and everything worked out of the box. That is using the exact same STM32LTDC driver (although we used the latest master branch). If you're not into the git version control system you can always just download the latest master branch as a ZIP file from the corresponding git website: https://git.ugfx.io/uGFX/uGFX Maybe @cpu20 has something to say to this too as he's somewhat of our community's IDE integration expert

Hello Rafael, The built-in window manager doesn't support overlapping widgets. There are two ways to tackle this: Implement a custom window manager that handles overlapping/stacked widgets (that's what most customers do that need this, there's an API to do that). Our community member @Steffan dit that as well and he succeeded (see the video below). Call gwinHide() on the console before the keyboard becomes visible to prevent having two widgets on top of each other However, I'm not entirely sure whether your crash is caused by this. Usually you'll just see artifacts when widgets are on top of each other. Here's @Steffan custom window manager in action:

We'd definitely appreciate if you could create another forum topic regarding this bug. Just wondering: Are you using the latest master branch of the µGFX library? There was a major rework of the FreeRTOS port about 6 months ago. I haven't checked but AFAIK that didn't make it into v2.7.

Hello Alan, The gdispFillConvexPoly() function can only operate on integer points because the points represent pixel coordinates. There is no such thing as half a pixel. When rendering a shape to the framebuffer. Of course you can use float matrix operations prior to that - that's no problem. I assume that you enabled the convex polygon support as you wouldn't be able to compile otherwise? Did the /demos/modules/gdisp/polygons demo work on your hardware?

No problem - We're happy to help wherever we can

And that's exactly what I see on the picture. The X-Grid is the divisions in X direction, so the lines that divide the X axis. Those are the lines perpendicular to the X-Axis. Same with the Y-axis but the other way around: The Y-Grid divides the Y-Axis and hence the Y-Grid are the horizontal lines.

Hello Alan, Yes, you can of course use an image for the needle. The example is really just that: An example. It's a custom widget and you can customize it to fit your needs. However, the current version of the µGFX library doesn't provide any high-level API for image rotation so you'd have to handle the image rotation yourself. But looking at your image it doesn't look like this needs to be an image anyway. I see two polygons and a circle

Well, maybe I'm still not understanding the problem here but the picture you show is exactly what you wrote in your code: X-Axis: Red, Solid-Line X-Grid: Red, Dash-Line Y-Axis: Blue, Solid-Line X-Grid: Blue, Dash-Line That's exactly what I'm seeing in the picture.

Hi, I looked into the code and I couldn't find either of the problems you're describing. Could you please create a minimal test case example that allows us to reproduce the problem?

Hi Alan, Those are actually compiler warnings and not errors. I just uploaded a new version of the demo where those are fixed. Thank you for bringing this to our attention!

No, they are not outdated. Please read the description on the download page of the uGFX library. You can find all of this information in the documentation and the countless demos in the /demos directory. gfxInit() automatically initializes everything for you. Once you implemented the board file you can just create high-level widgets such as buttons and listen for events as shown in the demos.

So far this looks good. As the error is explaining: You need to select an underlying operating system in your gfxconf.h. That is a mandatory setting as explained in both the documentation and by that error. Just enable RAW32 and you should be ready to go.

Using an image that rotates constantly for a progressbar sounds like a bad idea. Usually you use pictures for backgrounds and then use the primitive rendering functions to draw on top of that. You can easily rotate shapes like polygons and similar.

Hello @thexeno and welcome to the µGFX community I'd recommend you to have a look at our step-by-step guide for the Keil µVision IDE. It shows you exactly what you need to add. Of course, the dialogs are different but at the end of the day it's the same: You have lists of source files and inclusion paths. You can have a look at the guide here: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM First of all, I'd recommend you not to enable GDISP until you are able to build your project. Try to take your working AtmelStudio project and just add µGFX as per the guide but do not enable GDISP. You are able to make sure that everything works anyway because the GOS module is always enabled. Therefore, you can build a fully working µGFX application without using the GDISP module. Adding the /src directory is not necessary. All files are being included automatically once you included gfx_mk.c and the path to the top-level directory. Don't do that. The LLD config file is being included by the driver itself automatically. Have a look at the Keil guide I linked above. You only need to add the path of the driver directory to the include path and then add the driver source file to your list of source files. No need to include or modify anything else. But again: Try without the GDISP module first. That will save you a lot of hassle. Enable GDISP once your project builds fine just with GOS. As a general rule: Once you need to modify µGFX library sources you're doing something wrong. If you'd like to write a guide for the Atmel Studio that we can put on the wiki that would be much appreciated.