Joel Bodenmann

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.

Happy to hear that you got it working! The issue with the chip select sounds like the GDISP driver is not properly calling those functions.

Hi, We appreciate your motivation to donate. Once we started selling commercial licenses we decided to take down the donation option. Money is clearly the main hold-back issue here as we can't afford more man-power but donations usually don't result in an amount and steady supply of money that would allow to improve this. We're close to release µGFX v2.9. It's already ready - we just need to do the actual release. µGFX v3.0 is also making progress

Hello & Welcome to the µGFX community! There are many factors to consider such as the resolution and color space you want. The more pixels you have to control the more resources you'll need (memory, CPU, bandwidth, ...). For something of this size the newer STM32F4 families or the STM32F7/STM32H7 microcontrollers are extremely popular. If you're not very experienced I'd stay away from the STM32H7 for the moment as support for it seems to be quite scarce on all levels (including debugger support). The STM32F7 is by now pretty well established but tends to be a lot harder to work with compared to an "old school" STM32F4 due to newly introduced technologies such as the memory cache which can lead to many sleepless nights: http://www.chibios.org/dokuwiki/doku.php?id=chibios:articles:cortexm7_dma_guide The STM32F429/STM32F439/STM32F469 are extremely well supported and will most likely provide enough resources for what you're after. Also, you can get various development boards for those with displays so you can get yourself familiar with all the software components before you have to mess with custom hardware.

The ILIxxxx display controllers are known to suffer from differences across series and revisions. Also, some (chinese) sources love to sell you an ILI9225 as an ILI9220 and so on. Therefore, once you confirmed that the SPI is working correctly, try to grab the initialization code (sequence) from your supplied and plug it into the init() function of the corresponding µGFX driver. Another thing you might want to do is trying to read out the display controllers version register / chip ID. This will tell you exactly what display controller you have and will also confirm that the communication is working well.

Happens to the best of us

You should definitely work against the latest master branch of the official git repository (https://git.ugfx.io/ugfx/ugfx).

> I am working with a recent git version of ugfx and Chibios 18.2. How recent is recent? There has been a text edit fix two months ago: https://git.ugfx.io/uGFX/uGFX/commit/509fc7501e7bd30b1b314fc0d4838d7cdf6ac621 I'm currently on the road so I can't dive into this right now. But can you reproduce it with the most minimal test case? Eg. using gwinSetText() with a simple string parameter (no runtime buffer stuff) and setting the last argument to TRUE? So I guess the response to your "I suppose using dynamic text could provide a workaround, but I thought I would ask before trying too many things." statement is pretty much: That's exactly what I'd recommend you to try to track down the problem.