Joel Bodenmann

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.

It's correct that you receive that warning. It tells you to make sure that you know that you have to initialize the C runtime yourself - our library doesn't do that. You can suppress that warning by setting GFX_OS_INIT_NO_WARNING to TRUE in the configuration file. You can find the corresponding documentation here: http://wiki.ugfx.org/index.php/GOS#Warnings You must copy the board_SSD1963_template.h file to your project and rename it to board_SSD1963.h. Please do not hesitate to ask if the problem persists or if you have any other questions.

Hello and welcome to the community! As the error message tells you, you didn't enable any underlying system abstraction in the configuration file (gfxconf.h). Now that I am writing this I see where the confusion comes from: Even if you don't use an operating system you still have to specify which GOS implementation you want to use. In case of bare metal (no operating system), please enable the RAW32 port by setting GFX_USE_OS_RAW32 to TRUE in the configuration file. You can find more information about how to use the µGFX library on a bare metal system (without any underlying system) here: http://wiki.ugfx.org/index.php/BareMetal

Great work! Thank you for sharing your project!

Thank you very much for reporting this issue (and providing the corresponding patch). We have applied your patch to the repository: https://bitbucket.org/Tectu/ugfx/commits/25802124fb64a949971a89dd2ef34b749d949494

Sorry for the late reply. We were out of office over Easter. We are glad to hear that you got it working! And we are also glad to hear that it was no problem on the uGFX side of things Enjoy your display!

I'm afraid we can't help you with your debugging environment. However, we can try to figure out what the problem your driver is. For this, can you please open the driver configuration file (the file /drivers/gdisp/ILI9341/gdisp_lld_config.h) and change the value of GDISP_HARDWARE_STREAM_WRITE from TRUE to FALSE? This will prevent using the streaming interface and therefore not try to execute the code that is making you problems. However, this is of course just a work-around to track down the problem and not a permanent fix/solution. Have you ever been able to use the display with µGFX? Is this a new issue? Can you draw other things? Does it happen directly or just after a couple of minutes? Also: What underlying system are you using? Are you doing other stuff as well or is this a bare, basic project with nothing else but µGFX in it?

It's correct that the GADC oscilloscope demo doesn't use the graph widget. The oscilloscope is a custom widget. As C is not an object oriented programming language it's not possible to simply inherit from the existing graph widget and adding your own modifications. There are two possible ways: Create a new widget and copy-paste the corresponding code from the existing graph widget and then modify to your needs Create a new widget that uses the existing graph widget internally. This would mean that inside your own widget you'd have a GHandle and you call gwinGraphCreate() in your own widget init routine. Which of the two you take depends a lot on your needs.If you want to add things like touch events and so on then option 2 will be a lot simpler. Also autoscaling and other things are possible to implement this way because you simply manipulate the data in your own widget and then forward to the actual graph widget instance. Your widget would basically be a proxy widget. However, as soon as you have to modify anything in the existing graph widget that cannot be modified using the provided API then you have to choose option 1. I hope that helps. Please do not hesitate to ask if you have any other questions

Hello pjwl and welcome to the community! Each driver defines his own board file. You can find the corresponding board file template in the driver's directory. In your case, copy the following file to your project: /drivers/gdisp/SSD1963/board_SSD1963_template.h and rename it to board_SSD1963.h. Then it's just a matter of filling in the empty functions. You can have a look at all the existing board file implementations to get an idea how to do that. I can recommend you having a look at this one as it uses the FSMC interface of am STM32 which is very similar to the EBI of an AVR32: /boards/base/Marlin/board_RA8875.h. You don't have to include the board file manually anywhere. The driver (inside the µGFX library) automatically includes a file named board_xxx.h where xxx is the driver name. All you have to do is making sure that the place where your board file is located is part of the inclusion path for the compiler/linked. I hope that helps.

Are you using files generated by the µGFX-Studio? If so, can you please tell us which version (make sure that you use the latest one!) and upload a ZIP archive containing your project as well as the generated files. Otherwise, please show us the code that you are trying to compile. Are you using the make build system? Are you using single-file inclusion? Manually added all required files? ... Please provide as many information as possible.

Hello and welcome to the community! Did you check whether the issues was the one discussed in this thread? If the issue remains, please provide additional information such as the compiler that you are using, the compiler version, the compiler output log and so on.

That's correct, you are not supposed to change those settings. Are you experiencing performance issues or are you just asking generally? You can cache images which will store the decoded image in RAM which will vastly reduce image rendering time as there's no more decoding to do. You can find more information about image caching here: http://wiki.ugfx.org/index.php/Images#Caching For generic speed-ups you might consider using Pixmaps. Pixmaps provide dynamic, partial framebuffers that allow you to render anything in RAM first and then blitting everything in one burst write to any location on the display. This usually speeds things up a lot. You can find more information about pixmaps here: http://wiki.ugfx.org/index.php/Pixmaps Note that it's always a trade-off between speed and memory usage.