Joel Bodenmann

Glad to hear that you got it working - Thanks for sharing with the community!

nice. happy to hear that you got it working - good job!

Thank you for your suggestion. If you feel like opening an µGFX channel please feel free to do so. We're happy to promote it here and on our website - I'd also join in personally. However, we're not going to do / maintain this ourselves. We have done this in the past (eg. the #ugfx channel on freenode) but we mainly stopped doing that as we prefer to invest our time into development.

Hi, The best way to get started is by reading the corresponding wiki article: https://wiki.ugfx.io/index.php/Display_Driver_Model You might also want to take a look at the countless examples in for of existing drivers which you can find in the /drivers directory in the library. If you have any specific questions you can always ask here on the forum - we're happy to help where we can.

Hi, The font converter engine supports TTF and BDF font files. I think the font converter should reject other files but maybe that's not the case and it can't process at some point. The online font converter definitely checks for the proper file extension.

Make sure that all your DMA stuff is setup properly (i.e that there are no conflicts). Keep in mind that the DMA stuff is not part of µGFX - it's part of the application. You need to configure all the DMA components in a way that it works for the entire application. You might also find this forum post helpful:

What exactly is "1mg" or "1Mg"? If you also need OpAmps you might want to have a look at the "PSoC" series of Cypress. The PSoC 4, 5 and 6 all feature Cortex-M cores. Those devices come with your regular amount of peripherals (SPI, I2C, ...) but also feature programmable analog components such as OpAmps, comparators and so on. There's a guide on how to use µGFX with the PSoC creator studio (their IDE) in our wiki.

Hello and welcome to the µGFX community! The answer to all your questions is: Yes. µGFX has been written to run on virtually any system/platform. The STM32F103 is very well supported. In fact, when I started writing µGFX the initial development took place on an STM32F103RB6T. However, while still working great the STM32F103 is "quite an old" chip by now. There have been several revisions on even basic things such as the SPI and I2C peripherals ever since then (and they provided huge improvements). If you could better state your requirements (especially in terms of memory & CPU resources) we might be able to recommend a "better" chip to you. But keep in mind that this would just be optimizing: µGFX will definitely run just well within the environment that you described. µGFX also allows you to compile your resources (eg. images) directly as part of the application itself using GFILE's ROMFS so you don't have to fiddle around with linker scripts.

Did you set your GFX_CPU macro to the appropriate value (eg. GFX_CPU_CORTEX_M7_FP in your case)? If you keep using the Raw32 port setting that macro will ensure that the assembly code is understandable by Keil (together with GFX_COMPILER_KEIL). You can find more information in the documentation: https://wiki.ugfx.io/index.php/GOS

I fully agree with @inmarket here. We've yet to come across a C-Compiler that can't handle µGFX. We're running this project for over 7 years now and never encountered any issue on this end of things. As before: We're happy to help where we can - but you need to provide a bit more information.

We've successfully used Keil µVision MDK v5 in multiple projects - including customer projects. You can find the corresponding guide here: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM. Don't forget to set the GFX_COMPILER macro to GFX_COMPILER_KEIL in your configuration file! If you tell us more about the errors you're facing we might be able to help you.

Hello & welcome to the µGFX-Community! The Linux framebuffer driver is meant to directly operate on the framebuffer memory provided by the Linux kernel (if this feature is enabled). It's a device such as /dev/fb0 (or similar) that the Linux kernel provides as a framebuffer. If you do not want to use this framebuffer but render to a different display you'll have to provide a GDISP driver for this. As you mention SPI I assume that you have a dedicated display controller. In that case, check whether your display controller is already supported by the µGFX library. Otherwise you'll have to write your own driver.

The upload issue is fixed - Please excuse that this took so long.

This is most likely a mismatch of the color formats. Check the color format configuration of your GDISP driver (eg. /drivers/gdisp/RA8875/gdisp_lld_conf.h). It defaults to RGB565. You have to ensure that the display controller on the other end is using the same color format as specified in the GDISP driver configuration.

I think you need to read the first few basic articles of our documentation such as this [1] and this [2] to understand things like what a module is and how to enable or disable modules. [1] https://wiki.ugfx.io/index.php/Architecture [2] https://wiki.ugfx.io/index.php/Configuration

Hi, Unfortunately, we never worked with CubeMX enerated Makefiles ourselves. However, there are plenty of community members that did this successfully. As it's Makefile based you should definitely be able to just follow the official Makefile guide that you quoted in your post. Maybe someone like @cpu20 could help here (he's this community's IDE expert).

That sounds an awful lot like an issue in / related to the GDISP driver that you're using. You can use the GDISP TestStub driver to compile & run with that. It's an empty driver that doesn't do anything but allows to pass compilation of the GDISP module. This way you can ensure that the rest of the system is running properly.

You're using an older version of the library. We'd recommend using the latest master branch of the official repository or getting the latest stable v2.9 release from the downloads section.

Hello & welcome to the µGFX community! Did you include the "gfx.h" header in the files where you call the high-level API functions such as gdispDrawPixel() ?

Thank you for sharing your driver We'll look into the forum upload issue that you mentioned.

Have a look at the various GWIN (and widgets) documentation. Especially the /demos directory that comes as part of the library might be a valuable resource. the /demos/modules/gwin and /demos/applications applications will demonstrate the proper use of the event system to dispatch widget events.

Thank you for bringing this to our attention. We've added looking into this to our ToDo list.

There's a list of all supported controllers on the website/homepage. You can also have a look at the /drivers directory. And as @inmarket said: Adding a new driver is very easy. There's documentation and plenty of existing samples including drivers for very similar display controllers.

There's currently no driver for the ST7920 display controller that comes with the µGFX library but µGFX is very agnostic: It will work with virtually anything. There are plenty of existing GDISP drivers (also for monochrome displays) that you can use as examples to implement your ST7920 driver.

The STM32F103 is quite an outdated microcontroller. Any particular reason why you'd be using this model? µGFX will definitely work in all of those configurations. How much RAM you want to have to work with is of course another discussion (and your personal decision). µGFX can work with very little resources. Having more resources available just enables you to do fancier stuff.