Joel Bodenmann

Yep, sadly as the linked forum posts mentions it's a very common problem that functions like setjmp() and longjmp() aren't working correctly in embedded libraries. It seems like they are simply not tested at all. This even happens with libraries from large companies like Keil (which is ARM itself). We have implemented a scheduler ourselves for all the Cortex-M series including the Cortex-M0. I'm not sure about the Cortex-M0+ but I think that the Cortex-M0 scheduler should work on it just fine. You can enable it by setting GFX_CPU to GFX_CPU_CORTEX_M0 in your configuration file.

It seems like you are missing the configuration for the GOS module in your configuration file: http://wiki.ugfx.org/index.php/Configuration#GOS In your case you want to have at least this minimal configuration: #define GFX_USE_OS_FREERTOS TRUE #define GFX_COMPILER GFX_COMPILER_KEIL #define GFX_CPU ...

Sure, let us know how the test went. We're looking forward to resolving your issue

The GINPUT module will automatically enable the GTIMER module as it's a dependency. Check your compiler output log. You should get a corresponding #warning that tells you that this happened unless you set GFX_DISPLAY_RULE_WARNINGS to FALSE (which isn't a documented feature).

We checked your µGFX-Studio files and everything looks good there. I assume that you are able to see all widgets in the preview that you can generate by clicking the green arrow in the toolbar - is that correct? Sadly we're not able to compile and test your project as we lack the required tools and hardware. We took a look at the project and we couldn't spot anything that's obviously wrong. Can you please check the values of the GHandles that are returned by all the gwinXxxCreate() functions in the guiCreate() function? If some of them are NULL this might indicate a lack of memory which would explain why you only see some of the widgets. You can find more information regarding the memory management on bare metal systems here: http://wiki.ugfx.org/index.php/BareMetal#Built-in_memory_manager If that doesn't help I'd recommend you to start off a clean project that doesn't do anything but flashing an LED and then add the µGFX GUI. It seems like your project still contains unrelated code for manually handling the touchscreen and so on. A couple of general remarks: Take the gfxconf.h file out of the µGFX directory and place it in your project directory. It's part of the project, not part of the µGFX library. This way you can easily upgrade to newer versions of the µGFX library in the future by simply replacing the µGFX directory. You can make your GUI look better by using WidgetStyles, custom rendering routines or by writing custom widgets. If you are using an explicitly supported platform, enable it in the configuration file: http://wiki.ugfx.org/index.php/GOS#CPU If you are using an explicitly supported compiler, enable it in the configuration file: http://wiki.ugfx.org/index.php/GOS#Compiler I'm sorry that we can't give you a guide to success. We have never encountered this problem before. Please don't hesitate to ask if you have any other questions. We are happy to help wherever we can.

Can you tell us what you're not understanding? We are happy to help wherever we can but we need to know what the problem is. You can find many examples of configuration files in the /demos directory of the µGFX library and the download section on this website: https://community.ugfx.org/files/ This article shows all possible configuration options and links you to the corresponding parts of the documentation that explain them: http://wiki.ugfx.org/index.php/Configuration Note that the display driver that you want to use (eg. SSD1289 in your case) is not part of the configuration file. You add it by simply linking against it. In case of you're using the Makefile build systems you can simply include the drivers makefile: include $(GFXLIB)/drivers/gdisp/SSD1289/driver.mk Besides the part for the GOS module the configuration file doesn't contain any platform specific configuration. That's why you can use a tool like the µGFX-Studio to automatically generate the configuration file for you.

Glad to hear that! Thanks for your positive feedback! If you're interested you can post your project in the "User Projects" section in the forum - or, if you'd like - we can give you a separate blog: https://community.ugfx.org/blogs/ In any case we'd appreciate any kind of pictures - especially if you allow us to use them in the demos section of the homepage.

I removed those "ToDo" marks from that page to prevent further confusion. They were meant in the documentation context: The documentation of the existing feature is on the ToDo list It's correct that most often you use the toggle interface for the rotary encoders 'push' action and the dial interface for well... the rotary action.

The GINPUT already has working and usable interfaces for physical buttons, switches, potentiometers, rotary encoders and so on. These interfaces are called "Toggle" and "Dial". We understand that those names are not the best and might even be misleading but it's the best we could come up with at the time. After all this stuff was written even before the name "µGFX" existed. There's a lot of stuff we'd like to rename but that's something we can't do before the 3.0 release as backwards compatibility would be broken. The toggle interface allows to interface physical input sources that provide digital values/states such as push-buttons and switches. The dial interface allows to interface physical input sources that provide numeric values such as potentiometers and rotary-encoders. The toggle and the dial interface of the GINPUT module are integrated into the GWIN module just like the mouse and the keyboard module: When you add a rotary encoder and you register it properly through the highlevel API, certain widgets will automatically use these input sources when appropriate. For example, the list widget will automatically scroll through the list if you attached a dial to it. A button widget will automatically be pressed if you attached a toggle to it and so on. You can find the corresponding actions in the widgets VMT: http://wiki.ugfx.org/index.php/Creating_a_widget#VMT Of course you can also manually interface these input sources via the high-level API. The advantage of this is that thes einput sources are integrated into the GEVENT system and that you can write platform independent - and therefore portable - code. Now, to be honest at this moment there's only the API documentation (and the source code) available as a documentation source. The wiki doesn't contain any documentation about those yet. However, you should be able to get it working anyway as the interfaces are pretty straight forward to use. Both toggle and dial inputs are interfaced through board files just as with the displays and the touchscreens. I'd recommend you browsing through the corresponding files that you can find in the /src/ginput/ directory. If you have any questions please do not hesitate to ask. We are happy to help wherever we can.

Hello and welcome to the community! Thank you very much for sharing your driver. We will take a look at it and add it to the repository. It would be great if you could post more pictures of your project once your display stuff is done. We'd really need more pictures for our demos section on the website.

All you have to do to use the MCU driver is to copy the board file /drivers/ginput/touch/MCU/gmouse_lld_MCU_board_template.h to your project and rename it to gmouse_lld_board.h. The rest is supposed to work out of the box. It's correct that the GINPUT module will periodically call read_xyz(). This is done through a GTIMER. If it's not working then most likely the GTIMER thread crashed. This can have a couple of different reasons. The most popular ones are that the stack size of the GTIMER thread is too small or that the scheduler isn't working properly. In either case the proper way to debug this is to verify that the GTIMER module is working correctly. Increasing the stack size of the GTIMER thread is fairly easy and can be done in the configuration file as explained in the corresponding documentation. However, the default value is already very big and shouldn't cause any problems UNLESS you are running other GTIMER jobs too. As the documentation explains all GTIMER jobs share the same stack size. If one of them needs more than what the GTIMER module provides it will crash. The more likely case is that the very minimalistic scheduler that's implemented in the RAW32 bare metal port is not working correctly on your platform. The way to check this is to create two threads using the GOS threading API. It's enough to simply toggle an LED in each thread - or, if your display is already working - to increment a counter. But in that case make sure that you enable multi-threading support in the GDISP module by setting GDISP_NEED_MULTITHREAD to TRUE in your configuration file. Please report back your testing results and let us know which architecture/platform you are working on. In case of it's not a specifically supported one note that there's a known problem that causes the scheduler not-to-work: Bugs in the setjmp() and longjmp() function in the clib of embedded toolchains seems to be a very common thing: https://community.ugfx.org/topic/380-f429discoveryraw32-hardfault-after-mouse-calibration/#comment-2828 In case of you are using a platform that is specifically supported by uGFX make sure that you enable the corresponding GFX_CPU_xxx support in the configuration file. Note: Just in case of you're interested, you can find an explanation on why µGFX doesn't provide an interrupt based interface for reading the touchpanel here: https://community.ugfx.org/topic/327-touch-driver-in-semi-polling-mode

The RAW32 port is a port we wrote ourselves. It's just a port of the GOS module that allows running on a bare metal 32-bit system. It's not a 3rd-party OS or anything. All it does is implementing the very minimal things required to run the activated/used components of the µGFX library on a 32-bit bare metal system. There's no documentation available other than the article that explains how to use it: http://wiki.ugfx.org/index.php/BareMetal You can find the RAW32 implementation in these two files: /src/gos/gos_raw32.h /src/gos/gos_raw32.c

You have to copy the file gfxconfig.example.h which you can find in the root directory of the uGFX library to your project and rename it to gfxconfig.h. You can find additional information about this in the documentation. Specifically these two articles: http://wiki.ugfx.org/index.php/Getting_Started http://wiki.ugfx.org/index.php/Configuration

Hey there, Sadly not yep, nope I'll have a look at this during my spare time this weekend. Please excuse the inconvenience.

Hello and welcome to the community! We don't have any ready-to-download example project for that configuration. However, you should be able to get it done anyway as everything is supported out of the box: µGFX comes with a built-in driver for the SSD1289 that is fairly well tested. µGFX comes with a well-tested port for FreeRTOS. µGFX is known to work very well on an STM32F407. I'd recommend you to search for a working STM32F407 project that uses FreeRTOS. I am sure you'll find plenty of those. If anything, you can use STM32Cube to generate one as it includes support for the FreeRTOS middle-ware. After you have a working project all you have to do is adding µGFX to it by following our guide. Please do not hesitate to ask if you have any other questions or if there's need to clarify something. We are happy to help wherever we can.

We just tried to convert those ourselves and the regular, unmodified one is working nicely. However, we can confirm that the modified one isn't working at all and it seems to crash the encoder. To be honest we're not very motivated to investigate this issue at this moment as it appears to be the very first time that any TTF file doesn't work. The fact that it has been modified by some 3rd party online service and the fact that all the thousands of other TTF files that were used so far with our font engine worked tells us that it's not a high-priority task. I put it on the ToDo list and I archived both font files but we are currently way too busy with other, more important things. If this is a high-priority issue to you (or your boss) then you might want to consider getting this done as part of a commercial support plan. Of course you can also try to find and fix the issue yourself as everything is open source. We are sorry for the inconvenience.

The font converter doesn't distinguish between bold and non-bold fonts. You should be able to convert a bold font just like you convert a non-bold font. Can you please attach the TTF file that you tried to convert but failed so we can investigate?

Hello Greg, Thank you for your feedback regarding Mikroelektronika. We often hear stories like that. Giving the user the ability to use any platform with any compiler is definitely our main goal. We currently just lack the man power to make the actual software become as extensive as that from competitive products. I'm not seeing where you're being ignorant at all I am writing a custom widget for a customer right now. I'll ask him if it's okay if I use some of the code to write a tutorial on the wiki similar to the one for the custom rendering routine. Maybe a bit more extensive and verbose. Edit: He said that it's okay. I will try to write the basic part of the tutorial up within the next two days. I know Rusefi ECU as I am/was very active on the ChibiOS forum as well. It's definitely a very interesting project and I am following it silently ever since it started. Please do not hesitate to ask any question. We are happy to help wherever we can and I am absolutely sure that you are capable of creating a custom widget. The difficult part is understanding how the software is structurized, which function calls which and so on. The actually programming part isn't that hard and your level of motivation is definitely a big bonus too.

Thank you. We put this on our ToDo list.

Thanks, we'll have a look at this. However, we are currently very very busy. It might take up a couple of days until we get to it. Sorry for the inconvenience.

We are happy to hear that you got it working! It's true that it's quite complicated to add the µGFX library to a project manually. That's why we try to encourage using the Makefile system whenever possible. Never the less we definitely have to improve the documentation for the other two solutions. If you have any feedback or ideas on this we are happy to hear them! Regarding the missing "../.." in some files - is it possible for you to tells us where they are? That's something we should fix if that's really a problem. We also put the two comments regarding the code generated by the µGFX-Studio on our ToDo list. We'll fix those things.

Thank you very much for your feedback and the positive words. We appreciate it a lot and we are very happy to hear that you like the µGFX library and we will continue to further improve it Regarding multiple images: You can create a custom struct that contains multiple pointers to different images and pass that to your custom rendering routine via the custom parameter. Such a "configuration" or "control" structure allows you to pass as many parameters as you want to a custom renderer. Please do not hesitate to ask when you have any other questions. We are happy to help where ever we can and we appreciate all kinds of feedback!

Hello and welcome to the community! We have discussed this and to be honest we have no idea how this could happen. We have never encountered any issue like that ever before. Of course we want to track it down and fix it as quickly as possible For that matter, can you please provide us with a copy of your project (attach a ZIP file!) so we can try to reproduce the problem? It would also help if you could provide a copy of your µGFX-Studio project. Please make sure that you also include all the images and font files that you use so we can recreate the project. Future versions of the µGFX-Studio will come with an export tool that will automatically copy all the required files and generate an archive. Right now this has to happen manually. Sorry for the inconvenience. Please do not hesitate to ask if you have any other questions. We are happy to help wherever we can!

Hello Greg, There are currently no existing rotary widgets and our ToDo list doesn't contain them either. However, if the demand is there we can obviously get something going. Actually you can do this yourself as it's rather straight forward: You don't have to create a new widget. Instead, you use the existing slider or progressbar widget with a custom rendering routine. Unlike with other (embedded) GUI libraries, widgets in µGFX are distinguished by their attributes and by the way they behave - not by the way the look like. A rotary dialg / meter consists of a minimum, a maximum and a current value - that's exactly what the slider and the progressbar widgets do. The look of a widget can be completely customized through a custom rendering routine. The custom rendering routine basically overrides the paint() function of a widget and allows you to draw the widget however you like using any of the available functions from the GDISP module. You can find further information about custom rendering routines and an easy-to-understand example here: http://wiki.ugfx.org/index.php/Creating_a_custom_rendering_routine If you have more advanced needs it's possible to write your own widget. Sadly we don't have a guide for that yet (it's on the ToDo list!). However, the vast amount of existing widgets together with the /demos/modules/gaudio/oscilloscope demo provide enough different examples. Together with the inline documentation of the widget struct members you should be able to write a custom widget within no time. After all a widget is nothing but a custom struct that you define (the widget object) and the widget VMT (virtual method table, which is essentially a struct of function pointers) which is predefined and documented by the GWIN module. You register your functions to create, destroy and draw your widget along with the functions to handle mouse events and so on in that VMT struct. The GWIN module will automatically call them and provide you with the normalized coordinate parameters and so on. This might sound a bit complex at first but it's really straight forward once you got into it Please do not hesitate to ask any questions. We are happy to help wherever we can!

Hello and welcome to the community! We are happy to hear that you managed to get µGFX working, well done! If you have any feedback on what made it a bit difficult we are all ears! We are happy to improve our documentation to make it easier to get started. Sadly it's not as easy as everything depends heavily on the hardware, the operating system, the IDE that you are using and so on. The µGFX-Studio is in a very early stage of development and sadly it lacks many many features which keep it from being a tool that can be used productively. The µGFX library itself provides tons of features that are currently simply not supported by the µGFX-Studio. Whenever you need to implement some more advanced behavior you have to fallback to modifying the code generated by the studio. Regarding the button(s): One of the main goals of the µGFX library is to be as fast and as small as possible in order to be able to run on virtually any platform. However, this goal puts some limitations on certain features. One of those limitations is taht the GWIN module (the module that handles the widgets) doesn't allow to dynamically change the parent of a widget. As a display page is nothing else but a container that covers the entire display area the button you place on the display page becomes a child of that container (display page) and it cannot be used on a different display page. There are three ways to handle this while sticking to the µGFX philosophy: Create one dedicated button widget on each display page. Give them the the exact same parameters (position, dimensions, text, font, ...) so it appears to the user that it's the same button. Call guiShowPage() with a different index parameter from each button. Make the containers smaller so that there's an area on the display that's not covered by any container. In that area you can place your navigation buttons which will then be visible on ALL display pages because the display page container doesn't cover this navigation bar area. However, in your case where you don't want to show the navigation buttons on one of the display pages you'd have to manually hide those navigation buttons when the home widget is active. Use the tabset widget (http://wiki.ugfx.org/index.php/Tabset) for all non-home display pages. The home display page will be a dedicated display page (container) that covers the entire area that you make visible while hiding the tabset. Note that you have full control over how a widget looks like. It's possible to overwrite the paint() function of any widget. That way you can change how the buttons looks like or how the tabset widget renders the tabs. You can find more information about that (and an example) here: http://wiki.ugfx.org/index.php/Creating_a_custom_rendering_routine If you have more specific needs it's even possible to write an entire widget yourself. It's not as hard as it sounds and there's an example in the /demos directory of the uGFX library. Regarding the display page creation: Creating a display page is a very time consuming operation and is non-deterministic if you're using dynamically allocated objects. Creating the display pages at startup and keeping them in memory and just changing the visibility is a lot faster than destroying and reconstructing them each time. Furthermore, depending on what you are doing (eg. when sampling some data that requires huge buffers) it's possible that you run out of memory during runtime which will make the creation of the display pages fail at which point your user won't be happy because you can't change the GUI page which will leads to the user not having the ability to (fully) control the device. If you are concerned a lot about memory usage, dynamic memory allocation and so on: It's possible to use the µGFX library completely static. For example, all the gwinXxxCreate() functions take a pointer to the corresponding object as the first parameter. If that pointer is NULL the GWIN module will automatically create the object dynamically, otherwise it will use the one that you provided (which allows you to create a fully static GUI!). Regarding the forum: Feel free to create a dedicated thread for each of your problems/questions. It's easier for us to maintain and people that use the forum search will not have to digg through a lot of (for them) unrelated stuff Regarding your question with the button images: There are two possibilities: The button widget provides an image rendering routine which allows you to pass a pointer to an image to the rendering routine. That way the ENTIRE button will be an image. If you are looking for a solution where the button stays a button and there's just a small icon next to the text, look at the article linked above. The example for how to create a custom rendering routine shows exactly that I hope that helps. Please don't hesitate to ask any further questions.