Joel Bodenmann

This must be incredibly slow! As @inmarket mentioned, filled arcs are extremely complex and slow. Wrapping it in for() loops is no good here Images will be vastly faster than this. It of course depends on your system and the available resource but it's pretty safe to say that almost any system will be vastly faster with images than this. Of course, you don't want to re-decode a PNG every time you have to render your button. So either cache the image or use an image format that is extremely fast to decode (such as BMP or even better: NATIVE).

Hi, There's currently no existing rendering function for that. Depending on your needs (and your platform / available resources) you might want to consider using images.

Hello Alan, The gwidgetVMT allows you to register functions for the following toggle events (copied from the documentation): uint16_t toggleroles; /**< The roles supported for toggles (0->toggleroles-1) */ void (*ToggleAssign) (GWidgetObject *gw, uint16_t role, uint16_t instance); /**< Assign a toggle to a role (optional) */ uint16_t (*ToggleGet) (GWidgetObject *gw, uint16_t role); /**< Return the instance for a particular role (optional) */ void (*ToggleOff) (GWidgetObject *gw, uint16_t role); /**< Process toggle off events (optional) */ void (*ToggleOn) (GWidgetObject *gw, uint16_t role); /**< Process toggle on events (optional) */ The toggle status is not saved in gw->g.flags. A toggle can have two states: on and off (true or false, 1 or 0, ...). You get a call to ToggleOn() and ToggleOff() accordingly. It's up to you as a developer to decide what to do with that information afterwards. In case of the existing pushbutton widget we just change the internal flag of the pushbutton that keeps track of the pressed/unpressed state. But in your widget you do whatever you think is best. ToggleOn() and ToggleOff() just inform you that the state of the toggle (the hardware button) changed. The rest is up to you.

Hello and welcome to the µGFX community! From the µGFX perspective you have done everything right so far. It appears that the only compilation errors you're getting are from ChibiOS. The errors you're getting indicate that you didn't enable some of the peripheral drivers and peripherals themselves. Make sure that you enable everything you need in the ChibiOS's configuration file halconf.h and mcuconf.h. There should be examples for these files in the corresponding board file directory /boards/base/Embest-STM32-DMSTF4BB/example_chibios_3.x/. I hope that helps. Don't hesitate to ask if you have any other questions. We're happy to help wherever we can!

Hello Alan, Yes, that is exactly correct! You use gwinAttachToggle() to attach your hardware button to the widget and inside your custom widget you can add the functions to handle the toggle input in the VMT as described in the wiki.

Great work at getting it working! Thank you for sharing your findings with us! The reason your memory requirement is so high is because the SSD1306 driver has to maintain an internal framebuffer. That's simply due to the fact that the SSD1306 driver requires you to write entire chunks of pixels each time - so that's a limitation given by the display controller you're using µGFX is capable of using external memory. That's no problem at all. You can locate your framebuffer anywhere you want. In fact, some driver, such as the STM32LTDC almost always use external memory for that.

Hello @marcwolf and welcome to the µGFX-community! As you have most likely realized there is currently no driver for the ST7789V display controller that comes with µGFX. However, writing a new driver is very easy and there's an entire guide on this in the wiki: https://wiki.ugfx.io/index.php/Display_Driver_Model There are already plenty of existing display drivers that can be used as examples & references as well. Alternatively, we can implement the driver for. Please don't hesitate to contact us via e-mail for a quotation. No matter what kind of interface the ST7789 provides, µGFX will definitely be able to use it - including pixel streaming.

Hello Deon and welcome to the µGFX-Community! Thank you for bringing this to our attention. We'll look into this!

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.