Joel Bodenmann

Thank you for your feedback. We tested the built-in search feature of doxygen once and it's really bad in our opinion. It doesn't help unless you type in a word that exists exactly like that (eg. the proper function name or similar). Other than that, using Google and restricting the search results to api.ugfx.io is the proper & most helpful way.

Assuming that you're using the built-in image button rendering function of the button widget you just pass a different gdispImage* pointer via the custom parameter to the rendering function. The button widget doesn't store the pointer to your image at all, it just takes the custom parameter of the rendering function and casts it to (gdispImage*) that's all. Therefore, changing the image works like this: gwinSetCustomDraw(ghMyButton, gwinButtonDraw_Image, &myNewImage); With the images of the list box widget it's a different story because the image is actually being stored as part of the list item object. Changing the image is simply a matter of using the corresponding high-level API that has been added exactly for this: gwinListItemSetImage(ghMyImage, 0, &myNewListItemImage);

Actually, thinking about this, the proper solution is to create a custom gdisp_lld_control() command implementation that allows re-calling the driver initialization through gdispControl(). You can have a look at other existing drivers that use custom control commands such as the SSD1306 and the AlteraFramereader drivers.

Well, the proper solution is to add proper shielding and taking other measures required to pass the EMC test without the device becoming unusable Yes, gfxDeinit() will call the deinit() function of all modules, sub-modules and similar. It's the same thing as gfxInit() but in reverse. It can only clean-up the mess it created itself, so all the objects you allocated memory for yourself are not managed and you have to take care of those manually (you need an application wide deinit()). Deinitialization is not very well tested because it's not really needed in situations where µGFX is being used in the first place. The need for deinitialization usually shows a bad design (again, not in general but in systems where µGFX is being used in the first place). You can manually re-call the initialization function of the display driver but that's not supported from our side and vastly discouraged.

We implemented the palette support for BMP as part of a commercial product development (paid support). Initially the project called for both BMP and GIF support but at the end everything was realized with just BMP images so there's nothing done on GIF so far and there's nothing on the schedule / ToDo list for that. As we're currently building a huge pile of things we have to do here on the forum I wouldn't expect anything like that to happen any time soon. But please don't hesitate to contact us if you want us to get it done ASAP as part of paid support.

Hi, Can you please explain your question a bit? What do you mean by "monitor data"?

We had no time to dive into this yet, I'm afraid. I can't promise that we'll find time for that this week. If this is of importance due to a deadline of a commercial project or something like that please contact us if you want to get priority support (paid support).

When making a hard-reset of the display controller you have to re-initialize display controller which means that the internal initialization and post-initialization functions of the GDISP module need to be called (as well as the board_init()). This can only be done by calling gfxInit(). Therefore, you'd have to call gfxDeinit() first and then gfxInit() again. There's no way of buffering the existing GUI in between those operations. This doesn't make much sense in general (none at all). Can you please explain your use case or why you think that you need that so we can try to help you finding the proper solution? This sounds like a very bad design.

One solution is to render the image into a pixmap and then access and modify the pixel data through high-level API that is actually available for that. But that would obviously require you to have enough memory to create a pixmap of the required size.

Hi, What information would you like to get? There were a few different things mentioned in this topic. Please don't hesitate to ask specific questions.

font_t myFont; ... gdispGetFontMetric(myFont, fontHeight);

Hi, The built-in rendering function of the text edit doesn't offer that, no. But you can simply create your own custom rendering function that does that. Basically you can just copy the existing one and modify the justification parameter. Theoretically, you could create a custom rendering function that takes the justification via the parameter. The existing label drawing function does that too.

Yes indeed. Otherwise it's just not a wrapper. A C++ wrapper wouldn't do anything other than calling the equivalent C functions.

Note that you can actually use the GINPUT module without the need of having a touchscreen.

Hello Victor, Mixing C++ and C code is not always as trivial as it looks. There are always some nasty things to keep in mind like not including C headers after C++ headers and similar things. Inclusion order matters here. You indeed have to create a C++ file for your FreeRTOS port. In that, you can declare your C functions (the ones required by GOS) and the linker will be able to link them properly. There are other things you have to keep in mind like encapsulating your function prototypes in the extern "C" blocks: #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif I can't have a closer look at your files right now (and I can't try it) but I've attached a GOS port that I wrote some time ago that allows using µGFX inside of a Qt application. The Qt stuff is all C++ as well just like your FreeRTOS C++ wrapper. Have a look at those files. Maybe that helps: gos_qt.h gos_qt.cpp Note that I wrote a simple wrapper class around the QThread class because the QThread class doesn't offer certain things that are required. I assume that the FreeRTOS C++ wrapper won't require that workaround. Please don't hesitate to ask if you have any other questions. We're happy to help where ever we can. Just currently on the road so not much I can do right now.

Hello Victor, If it's a true C++ wrapper then that means that the C interface should still be accessible. Therefore, the current FreeRTOS support should still work perfectly fine for you and you'd probably just encounter a build issue. If the C functions are not accessible then the easiest way would be to create a new GOS port for FreeRTOS C++ (so you'd create gos_freertos_cpp.h/c) and use the FreeRTOS C++ interface in there. Optionally you could keep using the existing gos_freertos.h/c file and just add a macro to the configuration file which is something like GFX_FREERTOS_USE_CPP and in the existing port you'd use #if and #else to add your new FreeRTOS C++ wrapper code along the existing C one. I hope that helps.

Sounds good! Keep in mind that you can develop your entire µGFX application on a desktop computer as you can compile native Windows, Linux, Mac OS X and BSD applications. Those are native applications that only use the µGFX library. We don't use simulators or emulators. This means that every single pixel that you see on your desktop will be exactly the same on your hardware target afterwards.

Thanks for sharing your results. Exactly as expected

There's absolutely no reason to feel dump. You cannot possibly know everything. Please don't hesitate to ask if you have any questions, we're always happy to help. You might consider using GIF instead then. It's a lot easier on the CPU and requires about one fourth of the memory that you need to decode a PNG. Our GIF decoder supports transparency. Other than that the common (and strongly recommended) approach is to use bitmaps (regular BMP formats). The bitmaps that have less than or exactly 8 bits per pixel have color palettes. This way you can simply exchange the background color in the BMP before drawing it to the screen. That is how most GUIs are implemented and that is how we implement the GUIs for our customers whenever possible. BMPs come with almost no overhead at all. They are stored uncompressed but as you're talking about icons the size shouldn't be a problem. We also use the same technique for GUIs where you can change the theme (the color scheme) and when the user can click/press the icon as you can simply adjust the background color again to give it a "pressed" effect. Modifying the palette is a very fast operation as well. In the example here, we use the same bitmap (the same BMP image is only one time in the memory) and we render it with 7 different color schemes. Note that you can use bitmaps with more than just one color as well - You can do the same with "colored" icons:

We'll have a look at this, but that might take a few days. Stay tuned! If you have any questions in the meantime please don't hesitate to ask. We're happy to help wherever we can.

Hello @Grobatt and welcome to the µGFX community! Running µGFX on a CC3200 is no problem at all. After all it's a Cortex-M4 processor and µGFX runs very well on those (probably the best supported platform). You definitely won't have any issues running µGFX on it. When it comes to PNG: Just as with everything else we wrote our PNG decoder completely from scratch ourselves to ensure that everything uses as little resources as anyhow possible. However, due to how the PNG format works you require 32 kB of RAM just for the sliding window for decoding the PNG. In addition to that there's a few more kilobytes requires for the deflation buffer and similar things so all in all you need about 37 kB or RAM to display a PNG image of any size. You can find a very detailed description on the memory requirements for rendering a PNG image here: https://wiki.ugfx.io/index.php/Images#PNG In general you definitely don't want to use PNG images on any smaller embedded platform. Is there a particular reason why you'd like to use PNG images? There are plenty of other options. If you explain your use case we might be able to give you a bit more guidance. Yes, you can just use the GDISP module. The configuration file allows to individually enable and disable every single module, feature and sub-feature. You can just enable the GDISP module and it doesn't have any dependencies at all. The µGFX library is very modular. It is possible to use just the GDISP module with no other dependencies for displaying your PNG image. You have to provide the corresponding gdispImage object (struct instance) and then GDISP can display it - it doesn't bother where it comes from. However, as you mentioned µGFX provides certain mechanisms to vastly simplify this. The GFILE module provides a generic, high-level file system abstraction API. The GFILE module itself is very small and does't do anything besides providing wrapper functions. Once you enabled the GFILE module in your configuration file you can choose which file system(s) you want to be using. We do offer a FatFS wrapper that allows you to display a picture by using just two lines of code: gdispImage myImage; gdispImageOpenFile(&myImage, "/path/to/myImage.png"); gdispImageDraw(&myImage, 0, 0, swidth, sheight, 0, 0); If you prefer using something more lightweight you can have a look at ROMFS. It's a file system we wrote ourselves that allows loading any file from your ROM (eg. your micrcontrollers flash). We provide the corresponding tool called file2c that allows converting any file into a C array so you can easily include it in your microcontroller's flash image by just #including the file instead of screwing around with linker scripts. To answer your question: Yes, you can use just the GDISP module to display your PNG image. You can optionally use the GFILE module if you want to make your life easier (you can either use our built-in FatFS implementation or your own one). The GWIN module optionally offers you a window manager with widgets. There's an imagebox widget that would allow you rendering your PNG image as part of the widgets system maintained by the window manager so you don't have to manually take care of redrawing it but the GWIN system will pull in more dependencies such as the GQUEUE module (and the GINPUT, GEVENT and GTIMER module if you have touch/mouse input). But not to worry: If you really need those features then go for it. The µGFX library has been written to be as modular and as lightweight as possible. Every unused feature (and sub-feature and sub-sub-feature and ...) are excluded before compilation by means of the pre-processor. I hope that answers your questions. Please don't hesitate to ask if you have any further questions. We're happy to help!

Can you please attach your Keil project as a ZIP or RAR archive so we can have a look? Please don't forget to clean the project first (Project -> Clean all targets) to keep unnecessary large binaries out of it.

Hi, I think you misunderstood with the text files: Only attach text file containing large, generated things like your compiler output. Don't keep your actual explanations, what you did and questions in there. These things belong directly in your forum post. So to summarize: Stuff you want to say/ask -> Forum post Larger text files that are relative (like compiler outputs, configuration files and similar) -> attach a text file to the same forum post. That is very important, please re-read it carefully. I'll quote your text file: You cannot use the NativeFS in your case. NativeFS is just a file system wrapper that allows using the native file system of the underlying system (if any). For example, when you're running your application on Windows or Linux, you can use NativeFS to directly access files on your computer's hard disk through GFILE. You are not using an underlying operating system that offers a native file system and hence you can't use NativeFS. If you want to use files (eg. if your µGFX application wants to load images and other resources from files) then use ROMFS. It's the best option you have. It's super small & efficient and very easy to use. Otherwise you have to use FatFS or something else that is way more complex and way more resource intensive. So, to summarize: If your µGFX application doesn't need access to files, simply turn the GFILE module off in your configuration file. If your µGFX application needs access to files, then simply use ROMFS in your case. Follow the documentation linked above, create your romfs_files.h files, add it to the project, convert all the files you need to access through ROMFS with file2c.exe, include the generated header files in romfs_files.h and you're done.

So, what is your question? Please ask specific questions that we can answer. Just saying that you don't know something doesn't help anybody.

So far you are only getting one error: ..\ugfx\src\gfile/gfile_fs_rom.c(36): error: #5: cannot open source input file "romfs_files.h": No such file or directory This error means that the file romfs_files.h couldn't be found by the compiler. The romfs_files.h file is required when you are using ROMFS (if GFILE_NEED_ROMFS is set to TRUE). If you don't actually use ROMFS then simply set it to FALSE. If you need ROMFS then create a file named romfs_files.h where you include all the converted ROMFS files (the files converted with file2c.exe). You can find the corresponding documentation here: https://wiki.ugfx.io/index.php/ROMFS