Joel Bodenmann

Hi, You can find pre-compiled binaries of the font converter in the /tools directory of the µGFX library. That allows you to run the font converter locally without any restrictions.

That's the µGFX-Studio: We are happy to help with whatever we can. The µGFX developers themselves actually maintain this forum in their spare time. Alternatively, you can purchase a support plan form our website. You usually start off by having a working project for your platform. Once you have everything running, you'll just add the µGFX library to that as you would with any other library. There is a generic documentation that explains how to add the µGFX library to an existing project on the wiki. Additionally, there are many different IDE specific guides out there that you can have a look at. As far as I know, CCS is Eclipse based so the generic Eclipse guide or the IDE specific guides for IDEs that are Eclipse based (eg. ChibiStudio) will help. Along these lines: @cpu20 is the IDE integration specialist of this community We provide µGFX drivers that allow rendering to a QWidget and to retrieve user inputs from that QWidget to the µGFX library. It's basically a driver that makes a QWidget become a virtual display (with touchscreen).

Did you check the return value of the gdispImageCache() function call? An image decoder can refuse to cache the image. An image also won't be cached if there's not enough memory left.

glad to hear that you got it working

You can mix C and C++ without any problems. You just have to make sure that you use the C++ compiler to compile C++ sources and the C compiler to compile C sources. That seems to be the most common mistake. Other than that, you can of course not include C++ code (eg. #include <iostream> or #include <functional>) in code that gets compiled by the C compiler.

You don't need a pixmap in this case. You can simply cache the image using gdispImageCache(). A cached image is stored as a decompressed bitmap just like it would in the pixmap with the simple benefit that in some cases, some really basic RLE will be applied that decreases the image size without having a real impact on the rendering performance. To answer your question anyway: You render to a pixmap like you would to any other display. A pixmap is nothing but a virtual display. You use all the normal GDISP rendering calls. Therefore, you can render an image to a pixmap using the regular gdispGImageDraw() function. The wiki demonstrates rendering to a pixmap: https://wiki.ugfx.io/index.php/Pixmaps

Great! Thank you for sharing that with the community!

You have to enable unicode support in your configuration file. Of course, also make sure that your source file(s) are unicode encoded as well when you hard-code your strings. Furthermore, make sure that the Chinese glyphs are not being filtered-out by the default filter range of the online converter.

You can either use the flashing property provided by GWIN (gwinSetFlashing()) or you can implement a custom widget that uses a GTIMER internally to render if you need more control. Do not simply call gwinHide() and gwinShow() periodically. While that has visually the same effect you'll not get what you want as your button will not receive any events while not being visible (meaning you can't click it).

Can you please show us pictures of both pages (eg. the previous page as well)?

gdispFillString() does only fill the bounding rectangle of the string. The bounding rectangle depends on the string you are rendering - although you use the same font you'll have different rectangles based on the string. gdispFillStringBox() allows you to specify the size of the box. Hence that is the correct one to use in this case.

I'm pretty sure that you're using gdispDrawString() instead of gdispFillString() or gdispFillStringBox(). The gdispDrawString() only renders (changes) the pixel of the actual new string. Everything else remains the same. gdispFillString() and gdispFillStringBox() will clear the pixels not occupied by the string with the corresponding background color. Use those.

I'm sorry, this is not a code::blocks support forum.

Hello and welcome to the µGFX community! You can use the µGFX library with any IDE. There's a generic guide here: https://wiki.ugfx.io/index.php/Getting_Started#Integrate_uGFX and there are more IDE specific guides listed on the front page: https://wiki.ugfx.io/index.php/Main_Page

Can you please provide a ZIP containing your entire ChibiOS project so we can have a go on it ourselves? We haven't had any problems at all with using µGFX with ChibiOS and neither did anybody else - this has to be something very small in the build setup

Hello @Stewels and welcome to the µGFX community! I took a look at your makefile and this is wrong: # GFX files. include $(GFXLIB)/tools/gmake_scripts/library_ugfx.mk include $(GFXLIB)/tools/gmake_scripts/os_chibios_git.mk Please follow this guide to add µGFX to your existing ChibiOS project: https://wiki.ugfx.io/index.php/Using_ChibiOS/RT

Thank you for your feedback, we appreciate it a lot! I'm not really sure what you'd expect. Usually you need to debug your application, not the library you're using. So simply using fprintf() as suggested by @inmarket should get the job done.

@inmarket I already have his project with the corresponding changes in uGFX.

Glad to hear that you got it working! I was somehow under the impression that you don't get anything on the display - this definitely makes sense. I assume the errors you're getting are due to the fact that there's not enough RAM to fit the uGFX heap during linking time.

Did you properly set GFX_CPU, GFX_OS_HEAP_SIZE and GFX_COMPILER? The latter is very important when using Keil. When using the Raw32 (baremetal) port with Keil you want to make sure taht GFX_OS_HEAP_SIZE is a non-zero value. It's the heap size that µGFX will use in bytes. Give it something like 20k or 40k to get started.

Whether that is okay or not is something you need to decide yourself. You have to implement the widget the way you like it The GTimer should definitely only run while you're editing the numbers. I'd add API for that, something like: mywidgetHoursSet(GHandle gh, uint8_t value); mywidgetMinutesSet(GHandle gh, uint8_t value); mywidgetHoursFlash(GHandle gh, bool_t enabled); mywidgetMinutesFlash(GHandle gh, bool_t enabled); So when you want to start changing the hours, you'd do this: // Start flashing the hours digits mywidgetHoursFlash(ghWidget, TRUE); // Some code that allows the user to modify the hours while (...) { // ... mywidgetHoursSet(ghWidget, <newValue>); // ... } // Done changing the hours - stop flashing mywidgetHoursFlash(ghWidget, FALSE);

Hello Fabien, There are no built-in mechanisms for this. However, it's extremely easy to implement this yourself as all of the things you need for that are exposed as high-level API. The most challenging thing will be the handling of overlapping containers but as @Steffan showed that is no biggie either:

Hello Alan, Using a GTimer inside the custom widget to make the digits flash is definitely the (only) right approach. You can either separate the gdispFillStringBox() into multiple ones or (and this should be fast), simply use gdispFillArea() to render a rectangle over the portion of the string you want to hide momentarily (to make it look like it flashes). You can use gdispGetStringWidth() to find the correct width of the rectangle.

Hi @Oshel, There's not really much going on in _gosInit() for RAW32. I'm afraid there's not much that comes to mind. Unfortunately you have to get out the debugger and dive into it One thing though: Did you try this with disabling all modules so that gfxInit() really just invokes the GOS module? Please don't hesitate to ask if you have any specific questions - happy to help wherever we can!

Great! Thanks a lot for sharing this with the community