Joel Bodenmann

Hello @ErikI and welcome to the µGFX community! Thank you very much for bringing this to our attention. I took a quick look and on first glance it really seems like the gdispPixmapDelete() function is not freeing up the allocated memory. We will look into this ASAP.

Hello @spectre, There is no high-level API to simulate a button click. The button widget itself doesn't contain that function because it would bloat the code size a lot (there would be the need for a GTimer and so on). This would mean that we have to make it become a feature that can be toggled on and off and that makes things become complicated & hard to maintain. We feel like this feature adds a lot of trouble for very little to no gain - hence it's not there. The proper way to handle your issue is by creating a function that generates the button-pressed-event in your own code. You can test your entire GUI that way: Simply create a testbench that doesn't do anything other than pushing events that have the same signature as the ones that are fired by the widgets themselves.

The Textedit widget uses the text attribute provided by the GWidget class. Therefore, gwinGetText() can be used to retrieve the current text of the Textedit as @inmarket mentioned.

Hello there, I'm sorry but unfortunately I don't understand your question. Can you please try to rephrase your question? In case of your question is how to convert the string/characters to actual numeric values: That is something you have to do yourself. That is not part of uGFX. The Textedit widget only provides you with an interface to enter text. Parsing the text into numeric values requires to know what kind of text is expected. Usually you'd use something like sscanf() to convert from text to numeric values. Note that the GFILE module provides implementations of sscanf() called sscang() that you can use. This way you don't have to pull all the libc dependencies into your project. You can find an more information in the corresponding documentation: https://wiki.ugfx.io/index.php/GFILE#String_manipulation_.26_printing

Hello Maytham, I'm glad to hear that you managed to get PNG up and running. Regarding the slowness: That is most likely (like, VERY likely) not related to the PNG images at all. We tested the driver from @inakto back then and we too experienced huge performance issues. This has either something to do with wrong clock setups or with using the wrong mode. The display controller/framebuffer that is on that display (the thing between the DSI and the actual display panel) supports different modes. The ones used by @inakto's driver is the video mode if i recall correctly which is not the best choice in this case. However, I'm really not sure anymore. On a side note, may I please ask you to stop quoting the entire previous post in your replies? Quotes are really just helpful if you refer to a specific piece of text, otherwise they make everything become very cluttered. You can just reply without making a quote at all if your reply is a follow-up on the last post(s). Otherwise, please just use partial quotes.

You never have to include any file other than gfx.h. Please remove the include of the file gdisp.h. Most likely your issue can be resolved by a simple make clean. If that doesn't fix your problem, can you please attach the following files: gfxconf.h main.c Text file containing entire compiler output log

Thank you for your effort on creating the corresponding drivers. I will have a look at your attached files tonight. Ideally we would be able to use the existing STM32LTDC display driver without modifying it. If that is not possible (you mentioned something about modifying the LTDC init functions) we might consider making those functions become part of the board file instead. As this board & display controller combination is using the real LTDC which is the same for all other boards that use the LTDC there really shouldn't be two drivers at the end. I put up @nathan.loretan to the task of creating generic drivers for that board. We'll see whether he can get it up and running in time for the upcoming release of µGFX 2.7 that is scheduled for mid December. Unfortunately neither @inmarket nor I have currently the time to spare for creating those drivers. We appreciate your efforts a lot. Decoding PNG images requires a lot of memory (compared to other formats). I guess in your case it's just a matter of increasing the stack size that you defined via GFX_OS_HEAP_SIZE in the configuration file. Note that in case of you're using an underlying operating system that provides a memory manager you want to set it to 0 instead so µGFX uses that memory manager instead of our own one. You can get very detailed information about the RAM requirements for PNG image decoding here: https://wiki.ugfx.io/index.php/Images#PNG

Hello Spectre, The table from the datasheet tells you that you cannot use RGB565 mode with an 8-Bit interface. The very first column is named "Interface" and refers to the actual interface that you are using. In your case you are using the 8-Bit interface which means that you are forced to write three bytes per pixel as shown in the table. Theoretically this is RGB666 but because the two least significant bits are ignored (the 'X' in the table) means that you can successfully use RGB888. Unfortunately that table tells you that you are not able to use RGB565 with an 8-Bit interface. To do that, you'd have to use a 16-bit interface and that is why the 16-bit one that you tried works fine. This information might also be interesting to @cheater as he didn't seem to have understood why only RGB888 with three writes work for him.

Hello @spectre and welcome to the µGFX community! The datasheet of the SSD1963 display controller shows the following table:

These are known to work exceptionally well: eBay SSD1289 3.2" TFT module. There are a couple of different variations from dozens of different suppliers. The important thing is that you pick a module that uses the SSD1289 display controller, a 16-bit parallel interface and has touch.

Yep, I can only repeat my recommendation to use 16-bits instead Can you tell us roughly what size (in inches) you'd like to use?

There are plenty to choose from, of course. However, one of my personal favorites is this one. The same module is available with lower resolutions and other configuration options. I could link a dozen more display modules like that but at the end it also depends on factors like how many you need (eg. is this a hobby project?), whether price is an issue, whether it's used in daylight or not and so on. Another display driver that is very well supported by µGFX is the SSD1963. The same manufacturer/supplier from my first link also has display modules with that display controller. One very important thing I'd like to tell you is that you definitely must connect that display controller via the FSMC peripheral to your microcontroller. Otherwise you have to bit-bang the interface which is a HUGE performance drop both in terms of frame rate and CPU. I would furthermore also recommend you to rethink whether you really want to go with an 8-bit parallel interface. Almost certainly you will be using an RGB565 color format which means that every pixel is two bytes large. This means for every pixel you have to push 16-bits. When using an 8-bit parallel interface this means that you have to perform two write cycles for just one pixel. Due to timing constrains such as bus setup times, hold times and so on you are not only two times faster with a 16-bit interface but actually more than two times. My personal recommendation: RA8875 or SSD1963 display controller 16-Bit parallel interface connected to F(S)MC of STM32 Capacitive touchscreen if you can afford it

Sorry for the late reply... It turns out that what my friend did isn't exactly what you need. All he did was hacking an alpha channel into the existing pixmap. This won't help when blitting two pixmaps together which is what you want. LLDSPEC void gdisp_lld_draw_pixel(GDisplay *g) { unsigned pos; color_t color; #if GDISP_NEED_CONTROL switch(g->g.Orientation) { case GDISP_ROTATE_0: default: pos = g->p.y * g->g.Width + g->p.x; break; case GDISP_ROTATE_90: pos = (g->g.Width-g->p.x-1) * g->g.Height + g->p.y; break; case GDISP_ROTATE_180: pos = (g->g.Height-g->p.y-1) * g->g.Width + g->g.Width-g->p.x-1; break; case GDISP_ROTATE_270: pos = g->p.x * g->g.Height + g->g.Height-g->p.y-1; break; } #else pos = g->p.y * g->g.Width + g->p.x; #endif if(g->p.color & 0xFF000000){ color = gdispBlendColor(((pixmap *)(g)->priv)->pixels[pos], g->p.color & 0x00FFFFFF, ((g->p.color & 0xFF000000) >> 24)); } else { color = g->p.color; } ((pixmap *)(g)->priv)->pixels[pos] = color; } Note that this is really a hack as the underlying GDISP module doesn't offer a color format that implements an alpha channel. The code above needs to be adjusted in case of the used color format is not RGB888.

@Maytham I'm glad to hear that you are diving into this as we are currently really drowning in work! It's good to see that you have something up and running. Unfortunately I don't have any idea on top of my head what might cause this issue. I'm not very familiar (not at all) with the new MIPI interface. As @inakto mentioned it might be best if you post some of your work so we and other can have a look at it.

Hello Alex and welcome to the community! FatFS requires you to implement the disk interface. That is a set of functions known to FatFS that it will use to communicate with the actual memory device. FatFS comes with the corresponding template files named diskio.h and diskio.c. You have to copy these files to your project and implement them accordingly to your system. µGFX itself only comes with built-in diskio implementations for ChibiOS/RT.

mbed os is currently not official supported. You have to write a GOS port in order to use µGFX with it. It's actually quite straight forward and not as complicated as it might look on first glance. The forum contains many information about this. Furthermore, there are plenty of porting examples available in the /src/gos directory. Please don't hesitate to open a new forum topic if you have any questions regarding writing an mbed OS port.

Ah yes, that might very well be the problem. It appears that the code generated by the µGFX-Studio is lacking the wrappers for C++ inclusion. The fix is easy though: Open the file gui.h and wrap the function declarations in the corresponding wrapper: #ifdef __cplusplus extern "C" { #endif // Function prototypes ... #ifdef __cplusplus } #endif Don't forget to make a clean build afterwards.

Did you forget to include the gui.h file in main.c? #include "gui.h"

Those functions are part of the files gui.h and gui.c that are generated by the µGFX-Studio. It appears that the compiler/linker is not seeing these files. Please make sure that these files are part of the compilation & linking process. For the source file this means that you have to add it to the project tree in the navigation on the left side of Keil µVision. The folder that contains the header file must be added to the compiler include path.

Please don't hesitate to ask if you have any questions

Hello and welcome to the community, This issue has been reported before but unfortunately we didn't have time to investigate ourselves yet and the person that asked the question didn't bother trying to figure out what the problem is. For now, the easy solution is to call the board initialization function twice in the driver.: We'd appreciate it if you can have a look at this trying to figure out what the problem might be.

Hello @Oguzhan and welcome to the community! Keil µVision is known to work very well with µGFX. We are using it ourselves to develop certain features and projects from time to time. There's a complete step by step guide that explains how you can integrate the µGFX library into an existing Keil µVision project: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM You can use the µGFX-Studio to develop your GUI and compile it with Keil µVision. The code generated by the studio is fully portable. You can simply copy/paste the files generated by the studio to your Keil project. In fact, you can automate the process by using post-generation scripts as explained here: You might also be interested in this post of our community member @king2 which explains how he's working with the µGFX-Studio in a real-world project:

Hello Andrey, I'm glad to hear that you successfully managed to write a driver for the SSD1322 display controller - great work! The reason for this is because the string is vertically centered in the box that you define with the first four parameters. In your code, you set the height of the second box to 60 instead of 30. If the height of the box is 60, the text will be drawn in a fashion that it's vertically centered and that is what you are experiencing. To fix the problem, simply use a height of 30 for the second string box as well: gdispDrawStringBox(0, 0, 250, 30, str, font2, 0x02, justifyLeft); gdispDrawStringBox(0, 30, 250, 30, str, font2, 0x02, justifyLeft); That should definitely fix your problem Basically you want the same box/rectangle for both texts, it's just that one is 30 pixels below the other one. If you clear/refresh the display the old content will be gone. The all the GDISP drawing functions directly modify the content of the framebuffer when you call them, they don't retain any state. Hence, if you clear/refresh the display the content that you wrote previously to the framebuffer will be gone. To have persistent items on the display you need a window manager. That is actually what the GWIN module provides. Theoretically you could simply use the label widget instead and the window manager will take care of redrawing the text when it needs to be redrawn. However, with your display that is way overkill. It's better if you simply write your own update() or refresh() function that redraws the stuff that needs to be redrawn. These parameters change the meaning depending on the function that receives them. Those are only used internally by the GDISP module - you must not touch them at any time. I'm sorry in case of I misunderstood any of your questions. Please feel free to complain if your questions didn't get answered properly

Pixmaps currently don't support alpha blending. However, a friend of mine implemented that feature just a few days ago. It's an actual extension for the existing pixmap. I'll ask him whether he could share his work - stay tuned.

Hello @csteaderman, gdispImageCache() will already improve the drawing speed for the very first draw. One of the nice things of gdispImageCache() is that your image will still be drawn, even if caching it failed (due to lack of memory). However, you will always be aware of this as the return value of gdispImageCache() gives you information of whether the caching was successful.