Joel Bodenmann

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

That looks very strange - nothing comes to mind right now. Have you tried making a clean build? You can do that in Keil µVision by clicking Project -> Clean Targets. Then make a new compile. It should restart from the very beginning this time. Can you attach a text file (like you did before, great!) with that clean build output log?

Hello @Ivan_Kuzz and welcome to the µGFX community! We'll have a look at this as soon as possible but that might take a couple of days. In general µGFX works very well together with Keil µVision and we use Keil µVision ourselves a lot in customer projects. From our point of view there is no need to switch. Please don't hesitate to ask if you have any other questions.

All widgets have the possibility to submit functions that handle toggle inputs: #if GINPUT_NEED_TOGGLE struct { 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) */ }; #endif This means that each widget itself decides what it does with a toggle input. For example, the list widget allows to scroll through the list and to select an item in the list: #if GINPUT_NEED_TOGGLE { 2, // two toggle roles ListToggleAssign, // Assign toggles ListToggleGet, // Get toggles 0, ListToggleOn, // Process toggle on event }, #endif You use the gwinAttachToggle() function in your application to attach a toggle input to a widget. Note that you can re-assign those at any time. I hope that helps.

Can you please tell us what doesn't work? If you have compile time errors, please attach a text file containing the entire output of the build process to your next forum post. Also, please do not use colored fonts, larger fonts or similar things in your forum posts.

Have you tried displaying the characters "manually"? Eg. by calling something like this: gdispDrawString(..., "Löwen, Bären, Vögel und Käfer sind Tiere", ...)

Hello @yaoyutaoTom, There's currently just one example and that's the one that you mentioned/showed. We'd be happy to include your code as an example once you have it working This is to simply invert the input. Imagine you want to have a hardware button to select an item in a list widget. You want the item to be selected whenever you press the button. You don't want to bother how the button is connected to the input pin of your microcontroller (active-low or active-high). Using the "invert", both cases can be used with the same high-level user code. I hope that makes it more clear. Please don't hesitate to ask if you didn't understand. We're happy to elaborate. These all come from the ChibiOS/HAL. That is something you don't have. All you have to do in those two functions is initializing the GPIO so it becomes a digital input and then reading the digital input (whether it's low or high). That depends what underlying system you're using. For example, if you're using the CubeHAL for the STM32 you'd simply call HAL_GPIO_Init() and HAL_GPIO_ReadPin() instead of palSetGroupMode() and palReadBus().

Did you enable UTF-8 Support? Did you ensure that your source file is properly encoded? Certain IDEs like to change the encoding of the source files.

Let us know about the results

Hello and welcome to the µGFX community! The way to do this is by creating a custom widget. You can find the corresponding documentation here. Judging from the fact that you already linked the matrix operations API documentation I assume that you know that you need to draw a needle polygon and then transform it, is that correct? In order for us to help you efficiently it would be helpful if you could tell us what you already know/understand and what exactly your questions/problems are. Otherwise we have to write down a complete guide here ^^ You might want to have a look at this custom widget that you can download from the downloads section that does more or less exactly that. It's a lot uglier than yours but the logic behind is the same. You might be able to just take and modify that. Note that we are using a PNG image as a background / dial / scale. The one you show in your photo can be drawn manually using arcs and lines. That will require way less memory than rendering a PNG image. Please don't hesitate to ask if you have any other questions. We're happy to help! Edit: This is the real API documentation for the matrix operations: http://api.ugfx.io/group___g_m_i_s_c.html

We just checked and it works well. I assume you didn't see that the first field is filled with a space. You can only enter one character in the filter range input fields. You have to delete the space that is in the first field before you can enter a new one You might want to use the offline font converter if you want to have the ability to use multiple filter ranges.

Glad to hear that you got it working!

@inmarket: note that @ronan_rt wrote his own touch driver. Our RA8875 driver currently only supports the display, not the touchscreen (the RA8875 is both a display and a touchscreen controller, but we only have a GDISP driver for it at the moment).

The GINPUT module performs all the fancy filtering and calibration required to get consistent readings. But it can't do that job well if the coordinates it gets as an input are incorrect. Please follow the advice you were given.

That's strange. We'll look into this. I put it on the ToDo list. But it might take several days / weeks until we get to it.