Joel Bodenmann

I hope you found the documentation: https://wiki.ugfx.io/index.php/Creating_a_widget

Using the console widget is definitely a bad choice in any case. The console widget is not really meant for text that changes, labels are more suited for that. The console widget doesn't generate any events (in developer terms it's a window, not a widget). For this kind of thing you usually want to implement a custom widget (unless a label is enough, which it seems to be the case here so far).

Glad to hear that it works! The applications/notepad demo is really old. Do you need it for a certain thing? We should definitely update it but that is really extremely low priority for us.

Hello Fabien, The Notepad demo is quite old - I'd have to check to figure out whether it still works properly. In the meantime, can you please try one of the GWIN demos such as /demos/modules/gwin/sliders?

Hello Ian and welcome to the µGFX community! There is indeed an offline version of the font encoder available in /tools/mcufontencoder. You can either use the pre-build binaries or compile it yourself.

Hi @thexeno, I'm currently reading this with my phone on the train so I can't dive into any details. But to answer your earlier question: Yes, the SSD1306 driver is a well tested driver that is used by a lot of commercial customers and community members. I used it myself both in customer projects as well as hobby projects. I used it successfully with different compilers as well. I know that that information doesn't help you to resolve your problem right now but just to give you some confidence on this.

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.