Joel Bodenmann

Hello @topsecret9x and welcome to the µGFX community! @inmarket pretty much said everything there is to say. However, just for completeness I'd like to point you towards this solution which uses a slightly modified pixmap to work with alpha: Whether or not that is useful depends a lot on your application & platform.

Please don't hesitate to ask if you have any further questions. We are happy to help wherever we can. We have just been exceptionally busy the past two weeks due to Christmas vacation and moving to a new office.

Hello @nquantum and welcome to the community! Sorry for the long response time. We're currently on Christmas vacation and we used that time window to move to a new office which took a lot of our time. I'm on the run to catch a train to get to a meeting right now but I'll get back to you in a few hours.

For completeness: It's gdispAddFont() that was added recently (it's already part of µGFX 2.7).

Hi there, We are currently both on vacation & currently moving to a new office. Sorry for the longer-than-expected delay on this. We should be fully operational by next week.

I took a look at your configuration file and there's nothing wrong with it. GFX_OS_EXTRA_INIT_FUNCTION is documented here. All it does is allowing you to register a function that will be called before all the other things of the µGFX library get initialized when calling gfxInit(). Raw32OSInit() is a function defined in the board files for the STM32F746G-Discovery board that initializes the SDRAM and all other things required to run µGFX on that board without depending on any other things such as CubeHAL or similar. You don't need to use that if you have your own initialization functions. The function is there so we can run any demo on the STM32F746G-Discovery board without modifying the application code.

We have solved this problem. It's working well in our test projects. Putting together an official demo that we can provide as ready-to-run project from the download section is a different matter - it takes time to do that. We appreciate it that you brought this to our attention.

As mentioned a couple of times we will put together an official demo within the following days. If this is urgent for you due to a project deadline, please consider contacting us for priority support. This is a free support forum that the µGFX developers maintain in their spare-time.

1. Please don't modify the µGFX library source files. The moment you modify one of the source files from the µGFX library that is not part of your own project directory/code you are doing something horribly wrong. The µGFX library direction is created and maintained in a fashion that allows using the same directory on any system and upgrading at any time by simply replacing the directory. Changing the code if gfx.c or any other µGFX library directory file is completely destroying all of these things. Keep your project specific stuff in your project. Do never ever modify µGFX code unless you know what you're doing. You will face issues in the future otherwise and every time you ask something we will loose a lot of time because you are not using the version of the library that we provide. Seriously, I cannot stress this enough: Never ever modify µGFX library files. Everything inside the /ugfx directory is off-limits. The Raw32 implementation code for the systicks is totally application/platform/target specific - hence you want to put that code somewhere in your own project scope. 2. Please use code-boxes if you want to paste code as part of your forum post (like I will below). That helps not only to keep everything nice, clean & easy to read but also allows optimizing search engine results. 3. The primary goal of you right now is to get your display up and running. Trying to directly run a full blown GUI, complex demo or µGFX-Studio project is simply a bad idea if you don't know that your display is working already. Build up from simple things. There's absolutely no reason why you would want to try rendering texts, images, widgets and other things if you can even change the color of the entire display. Just run something like this to make sure that your display stuff is working properly: #include "gfx.h" void main(void) { gfxInit(); while (1) { gfxClear(Blue); gfxSleepMilliseconds(500); gfxClear(Red); gfxSleepMilliseconds(500); } } Alternatively you can run any of the demos in the /demos directory. Again, start with the simple stuff. In that case we'd recommend getting /demos/modules/gdisp/basics up and running first. Please don't hesitate to ask if you have any other questions.

@inmarket just pushed a fix to the master branch of the repository. Can you please grab that, try it and let us know whether everything is working as expected now?

We'll put together an official ready-to-run project for the STM32F746G-Discovery project using the SW4STM32 / AC6 IDE. It should be ready for download within a week.

Please show us your configuration file (attach it as a text file!). There's a known bug with the latest version of the task scheduling code of the Raw32 port when using ARMCC (the compiler that Keil µVision uses by default). @inmarket is currently working on resolving this issue. You might get past it by setting GFX_CPU to GFX_CPU_UNKNOWN in the configuration file. Other common issues are insufficient heap and stack sizes. We'd strongly recommend you not adding your GUI straight away but making sure that your display is working first. Disable every module except for GDISP, call gfxInit() and then just gfxClear() to change the color of the display, nothing else. Build up from there. There's simply no point in adding everything at the first time directly - too much that can go wrong - too hard to debug.

CMSIS is not an underlying system / operating system. CMSIS is the Cortex Microcontroller Software Interface Standard and it's basically a library that contains functions to use the processor in your STM32 microcontroller. You definitely do want to use CMSIS. Without CMSIS there's not much going to happen. So even if you want to use µGFX without an underlying operating system you still want to use CMSIS. I guess it's fair to say that 99.99% of every Cortex-M related thing you will ever come across uses CMSIS. Have you read the guide which explains how to run µGFX on a bare-metal platform (without any underlying operating system)? The port that allows running µGFX bare-metal on a 32-bit platform is called RAW32. You have to set GFX_USE_OS_RAW32 to TRUE in your configuration file.

You can have a look at the many existing board files that you find under /board to get an idea how to use the CubeHAL to communicate over SPI. Personally I can recommend having a look at ugfx/boards/addons/ginput/touch/ADS7843/stm32f4cube_hal.h as that's the most recent one I added myself a couple of days ago. It's made for a touchscreen controller but the concept is the same. At the end it's always the same. One can't really reinvent the HAL API. There are a few different concepts but it all boils down to the same thing. You use whatever OS you want. Usually it's the application/project specifications (the requirements) that dictate what underlying system will be used. µGFX has been designed to run on any underlying system. Baremetal, ChibiOS/RT and FreeRTOS are definitely the most used ones though. If you're working with Keil and you're having access to Keil RTX then using Keil RTX definitely makes sense. It's known to work very well.

Please use code-boxes to add code & compiler outputs to your posts. The error you're getting suggests that there's an issue with the inclusion of the CubeHAL. Either you are using incompatible versions or you didn't include the CubeHAL properly. In your case we'd recommend you to use the STM32F746G-Discovery baremetal make based template project. You should be able to just download, compile and run it without any problems at all as it contains everything you need. We definitely need more information on this in order to help you. You should then be able to either import that project into SW4STM32 or create a new project based upon that template. We can create a complete ready-to-run project for your particular setup but it will take us between one and two weeks until we get the time to do that.

Glad to hear that you managed to get everything to compile. Writing board files is usually the easy part given that everything else works and that you worked with the HAL that you're using before. We definitely recommend using a logic analyzer or oscilloscope to ensure that you get the proper data out of your SPI bus.

Hello and welcome to the community! Could you please tell us what problem(s) you're experiencing? You just told us what you did but we don't know yet what your problems are and what your question is.

Also, it appears that GDISP_HARDWARE_STREAM_READ should be set to FALSE in the RA8875 driver configuration (/drivers/gdisp/RA8875/gdisp_lld_conf.h). I'm not sure why that is currently set to TRUE as the driver clearly doesn't implement stream readings.

That's because they don't exist. That's up to you to implement them. µGFX doesn't care how you talk to the display (eg. what interface you use, which HAL you use and so on). It's the task of the board files to do exactly that. Each driver comes with a board file template (in your case /drivers/gdisp/RA8874/board_RA8875_template.h that you copy to your project and rename to board_RA8875.h) accordingly to the documentation ([1] and [2]). It contains the functions that you can/must implement. You can find plenty of example implementations of board files in the /boards directory. Especially the /boards/addons directory might be interesting. I hope that helps.

We're glad to heard that you got everything up and running and that you like µGFX! We'll look into the issue with the Cortex-M0 specific scheduler issue the following days to further improve performance. If you'd like to tell us and the rest of the community more about your project you can post about it in the User Projects section of this forum. We're looking forward to see more!

Glad to hear that you got it working. With that configuration it's using a generic scheduler which works on every platform that comes with a proper libc implementation. It's just less efficient but in your case you wouldn't notice any performance improvement compared to the dedicated Cortex-M0 implementation. However, we'd still like to fix this problem so if you could answer the question regarding whether you're using the copy of the µGFX library which comes as part of the PSoC 5 example project from our downloads section or whether you're using a different one would be helpful to us. Also, the RAW32 port (which is what you'd be using) got quite a remake in the latest release from two days ago. If you could grab the latest 2.7 release from the downloads page and try with that uGFX version whether setting GFX_CPU to GFX_CPU_CORTEX_M0 works that would be very helpful for us. Well, that's quite a bad thing to say. µGFX is meant to be as small as possible. It's very unlikely that you will find a library with a similar set of features that will be smaller. External resources such as fonts and images are definitely what eats the most memory but µGFX has no control over that. Even the smallest possible fixed-size font that we designed ourselves requires almost a full kB of memory. You have full control over every feature and sub-feature that gets included in the finished binary through the configuration file. Every feature you turn on will require resources (ROM, RAM and CPU time). By default almost everything is turned off. There are of course features which use a lot more program memory than others. For example, circle and arc drawing functions will eat tons of program memory (comparably). The same goes for image decoders. Note that "tons of memory" here means something like 500 to 1'000 bytes. I checked the specs of the microcontroller on your development board and it claims to have 32 kB of FLASH. That's definitely getting tight once you start using multiple fonts and images especially as you probably have other things in your firmware as well. However, there are still several optimizations that you can do with your resources. For example, you can use compressed images. But given the fact that you're working with a comparably slow processor that doesn't offer a whole lot of RAM you definitely don't want to work with something as CPU and as RAM intensive as PNG images. RLE encoded bitmaps might be a better option here. For the fonts you can use the filter ranges of the font encoder to just pick those glyphs that you really need in your application to reduce the font memory footprint. Note that the online font converter only allows setting one font size. However, the offline version which you can find under /tools allows you setting any number of arbitrary font ranges. Furthermore, you don't want to enable things like kerning or unicode support if you don't use/want them. Other optimizations include basic things like telling your compiler to optimize for code-size but that's definitely not going to change anything for the external resources.

Sure, the forum is always open

We're happy to help wherever we can but you gotta tell us what problems you're facing Did you manage to include the µGFX library successfully in your Keil µVision project as shown in the guide here?

Hello @Kabron, First of all: You should (and you will) definitely be able to run µGFX on your PSoC 4 CY8CKIT development kit. µGFX has been designed to run on anything and the Cortex-M0 processor is actually very well supported by µGFX. The *.s files that don't exist anywhere that you are mentioning sound like files that get generated automatically. The fact that they change their name each time suggests that they are just temporary files which you never should have to care about as a user. It's hard to say what's exactly failing here. The errors that you are showing would suggest that the project is being built using the wrong instruction set. However, the fact that this is a PSoC-Creator project for an official dev-board kinda minimizes this chance. The first thing that I'd recommend you doing is setting GFX_CPU to GFX_CPU_UNKNOWN. In case of the libc that comes with the PSoC-Creator compiler is not fucked up like some other ones it should allow you running µGFX with an unoptimized task scheduler. One question though: Are you using the copy of µGFX that was part of the example project from the download section or did you use a more recent copy? If you could provide us with a complete ZIP archive containing your entire project that we can just open and run we could look closer into this. However, that would probably take between 7 and 10 days as our agenda is currently full.

Glad to hear that you got it working! Yes it's correct that the code I supplied contains a syntax fault. I tapped it during a bus ride on my phone so...