Joel Bodenmann

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...

Glad to hear that you got the pixmaps working! The required memory size can be calculated by this equation: mem_bits = (pixels_width * pixels_height * num_bits_per_pixel) + overhead Note that this equation doesn't account for pixel packing and similar things (which most likely won't be an issue in your case). So if you're using an RGB565 format you need (400 * 240 * 2) bytes of memory for a full framebuffer plus the overhead. The overhead is totally negligible though as it's just a couple of bytes. Furthermore, µGFX allows you to use different pixel/color formats for each individual display driver. As pixmaps are implemented using the real display driver interface this means that you could theoretically use a different color format for your pixmap. However, as you'd have to push the pixels from the pixmap to your physical display at some point that would mean that each pixel would need to be recalculated which is very slow and would prohibit using DMA unless you have dedicated hardware to do that. Depending on the application you wouldn't want to have one or more full-sized pixmaps but instead you'd just have partial, context dependent pixmaps. But that really depends on what your application does and how you implement other things.

I gave it a quick try on a bare project and I can confirm that there's a bug in the Keil specific context switching code for the Cortex-M7 processor. We'll look into this ASAP.

Thank you, we appreciate it. Please don't forget to check for the things that we mentioned in this topic (eg. you must be 100% sure that RTX is no longer running, setting the correct CPU and compiler in the configuration file, ...).

We did a lot of tests on a multitude of different platforms and setups and the RAW32 (baremetal) port of µGFX 2.7 runs fine. Otherwise we wouldn't have released it if there would be a general problem with it. We'll put together an official demo exactly for your specific setup but as mentioned that will take some time as we currently have a lot on our plate. Our recommendation is that you start following the advice we give you. Unfortunately, just saying "doesn't work" all the time doesn't allow us to help you in an efficient way. Other than that you either have to wait until we have to the time to create a ready-to-run example project for you or contact us for commercial support.

There's currently no existing API to do that as you discovered. I added this feature request to our ToDo list. Of course you can always add that function yourself if you are in a hurry. The existing functions of the list widget show how to access items in the list.

Let us know whether that works, we'll look into consider adding actual high-level API for that.

There's currently no high-level API for that. I didn't check the code and I don't have everything in my head but I guess you should be able to just manually modify the keyset member of the GKeyboardObject directly and then issuing a redraw. This would look something like this (untested code): GHandle ghVirtualKeyboard; ghVirtualKeyboard = gwinKeyboardCreate(...); (GKeyboardObject*)ghVirtualKeyboard->keyset = <your new keyset> gwinRedraw(ghVirtualKeyboard);

Okay, I'm a bit confused on what your actual question/problem is. Before we continue on this: Is your question how you can change a key set of the existing pre-defined built-in English1 layout or is your question on how you can change the currently displayed key set programmatically?

The disabled state refers to the state of the entire widget (which you can control through gwinSetEnabled() as well as the corresponding gwinEnable() and gwinDisable() wrappers). With the implementation of the default built-in list widget it's not possible to enable/disable individual list items. If you need such functionality we recommend implement a custom widget. In this particular case you can simply copy the /src/gwin/gwin_list.h and /src/gwin/gwin_list.c files to your project and modify them accordingly. Please don't hesitate to ask if you have any further questions. We're happy to help.

I assume you are hitting the limitation of the single-file-inclusion mechanism as noted here. In that case you'd have to either use the make build system or resort back to the good old adding-each-file-individually technique. Note that in case of you're using our own high-level project makefiles that we supply it might be a simple case of setting GFXSINGLEMAKE to no. If you're not using the single-file-inclusion mechanism: Make sure that you make a clean build. If it still doesn't work

Note: Do not forget to still explicitly set the CPU that you are using by setting the GFX_CPU setting to the correct value as mentioned by inmarket.