Joel Bodenmann

Hello Jagdish, I'm having troubles finding the link that you're talking about. Can you tell me exactly where I can find that dead "Demos" link?

Excellent work! That pull request has just been merged into the official repository. @Aivars Plume Can you confirm that this fixes the issue that you have been reporting?

Hello @Jagdish Bisawa and welcome to the community! Thank you very much for bringing this to our attention. We took a look at it and fixed several links. Please don't hesitate to let us know if you can find other remaining dead links.

Hello Alex, Thank you very much for sharing your experience. The proper way of handling this is creating separate board files for ChibiOS 2.x and ChibiOS 3.x. If you can share your working board files with us we'd be happy to include them as part of the repository. I hope that your students will enjoy working with µGFX

It would be nice if you could share your finished rendering function. I'm sure that that could be helpful for many people. Maybe it can even be included in the official µGFX library. That might be the case on your computer using the SDL back-end. Running this on real hardware (eg. a Cortex-M4) based system will yield way worse results. The type of interface used between the CPU and the actual display will also have a huge impact.

The gwinXxxCreate() function doesn't exist in that literal form. The "Xxx" are place holders for the name of the widget. You will find functions like gwinButtonCreate(), gwinSliderCreate() and similar. The term gwinXxxCreate() refers to all of these.

Hello Folks, The past couple of weeks we have been busy working on a new website. This time we have been working together with a talented photographer & designer. The result are many great images which give the new website a very polished & professional look. The new website can be found at the usual place: http://ugfx.io The old website will stay available for a few weeks: http://old.ugfx.io Please leave all your comments, feedback, criticism and ideas below. We'd love to hear your opinion!

Hello and welcome to the community! When you say that you can't show them at the same time, what do you have to do to make the others visible? Can you please check that the gwinXxxCreate() functions return valid handles? If the create functions return null pointers that usually indicates that you don't have enough memory left (heap!) to create additional widgets. In that case you want to increase the heap size that you can configure in the configuration file. Alternatively, you can always create all your objects statically and pass the corresponding object pointer as the first parameter to the create function. Are you able to successfully open the font using gdispOpenFont() and draw with the opened font using gdispDrawString()?

Hello and welcome to the community! The way you are using the TOGGLE support of the GINPUT module appears to be correct. The problem you are facing is that the list widget currently simply doesn't support a toggle role to select an entry. Looking at the list widget code we see that right now only two roles to move the selection up and down are defined. To implement the behavior you're looking for, you have to add a 3rd role to the switch() that processes the toggle roles. In that role, you have to programatically select the current list item. I hope that helps. Please don't hesitate to ask if you have any further questions.

Hello David, We'd definitely love to see your gradient code!

Adding a driver for the SSD1322 display controller is currently not on our ToDo list. However, adding such a driver is very easy and doesn't take a lot of time. The reason we don't have it is because we simply never got our hands on an SSD1322 display controller. We can encourage you writing that driver yourself. It is very easy and the existing examples such as the SSD1306 should help you a lot. Please don't hesitate to ask if you have any questions. We are happy to help where ever we can.

Well, I guess I'm a bit late to the party, but here are my two cents (which is really just copy-paste from the documentation) regarding the difference between the Async, GSync and FSync queues that @inmarket mentioned: This is also explained in the corresponding wiki article: https://wiki.ugfx.io/index.php/GQUEUE

Can you please attach a text file containing the complete compilation output?

Hi, Sorry, I was giving wrong information. I was sitting in the bus and didn't check the sources which were written a long time ago... In fact, the current implementation of the graph window doesn't offer changing the line size. You'd have to implement that yourself. As mentioned above, when working with graphs the proper solution is usually to implement a custom widget.

You're welcome

Hi, In µGFX (or rather in the GINPUT module) a mouse and a touchscreen are handled the same way. That is why you will often see variables, functions and options named "mouse" instead of "touchscreen". After all, a touchscreen provides exactly the same input parameters as a mouse does. The terms "mouse up" and "mouse down" refer to the button actions, not the movement of a point. When you click the button on your mouse, you first push it down and then release it. "Mouse down" refers to pushing the button down and "mouse up" refers to releasing it. "Mouse move" refers to moving the mouse around (ie. changing the coordinates). The same applies to the touchscreen: "Mouse down" means that the user put the finger on the touchscreen (without releasing it yet), "Mouse up" means that the user took the finger off the touchscreen and "mouse move" means that the user moved the finger across the touchscreen. I hope that helps. Please don't hesitate to ask if you have any other questions.

The line size is part of the GGraphLineStyle_t struct that in turn is part of the GGraphStyle_t struct. You can change the line size in your style struct, re-apply the modified style using gwinGraphSetStyle() and then issue a redraw using gwinGraphDrawAxis(). Note that by design the axes will now be in the foreground. This means that if your plotted data covered part of the axes the axes will now be covering that part of the data. Therefore, depending on what you are doing you might want to issue a complete redraw of the graph using gwinRedraw(). Furthermore, it might be worthwhile to note that the built-in graph is usually just enough to get started and make a simple proof-of-concept. For any serious application you'll end up implementing a custom widget.

Yes, creating a custom widget is usually the best solution. There is a guide on the wiki explaining the process of creating a custom widget. You can take all the existing widgets as an example (they are all located in /src/gwin/). Creating a custom widget is not as hard as it might look at first glance. Others did it before you as well:

The STM32F746G-Discovery board doesn't have a VS1053 audio codec (it's an external chip!) so you won't be able to run that demo at all. However, you can write a driver for the audio codec that is on that board and then you can use the GAUDIO module. Once you wrote the driver, you will be able to easily play sounds from flash, an SD-Card or any other source that is accessible via the GFILE module. The same applies to the GADC module: The STM32F746G-Discovery board files don't include a driver for the GADC module. You can use it once you wrote the corresponding driver. Feel free to open new forum topics if you have any questions on how to implement these drivers. We are happy to help where ever we can.

The GADC module provides a high-level abstraction layer to the underlying hardware. Similar to the GDISP and the GINPUT module it requires drivers and board files. In order to use the GADC module you have to implement a matching driver/board file. The file gadc_lld_config.h is the driver configuration file analog to the gdisp_lld_conf.h of the GDISP drivers. The compile error you're getting indicates that you either haven't provided a GADC driver. The GADC driver interface is specified in /src/gadc/gadc_driver.h. It's also part of the API documentation: http://api.ugfx.io/group___g_a_d_c___driver.html This error message indicates that you haven't included the GAUDIO driver in your project. Same as with the GADC one above. You need to include the drivers you want to use the same way as you include the display and touchscreen drivers.

As @inmarket explained: The reason you get an empty box is because a graph is a window, not a widget. As explained in the documentation for the widgets, once of the differences between a window and a widget is that a widget is always able to redraw it self, whereas a windows doesn't know how to redraw itself. The graph is a window and not a widget because it is either too complex or too expensive for the GWIN module to buffer the graph data. The thing about gfxYield() that @inmarket mentioned is only some additional background information. Solely using gfxYield() will not resolve your "problem". To summarize: A graph is not able to redraw itself because it doesn't know the contents that it is displaying. This is a design decision that was made to keep everything small, fast & simple. It is up to the user (you) to redraw the graph when necessary. If you have some very specific needs, it is always possible to implement a custom widget based on the graph window. In that custom widget you can store the data you want to display and do other things that are specific to your application.

The function gfxYield() is a function provided by the GOS module. Yielding is a generic concept of operating systems. A thread can give up his remaining time slice of processor time to other threads by calling gfxYield(). The detailed behavior depends on the underlying system that is being used. API documentation of gfxYield(): http://api.ugfx.io/group___g_o_s.html#ga48e13e354721ffac812c59d360956556

As @inmarket said you want to write a GOS port for that operating system. GOS is the module in the µGFX library that provides a generic abstraction layer. It's basically the layer between the actual µGFX application and the underlying system (which can be anything: BareMetal (no OS), an RTOS such as ChibiOS or FreeRTOS, a non-realtime operating system such as Windows or LInux or anything else - like Frosted. To write a GOS port, navigate to the /src/gos directory in the µGFX library and create the two files gos_frosted.h and gos_frosted.c. You will have to modify the generic GOS files accordingly to take the new port into account (modify gos.h, gos.mk, gos_options.h and gos_rules.h accordingly). You will have to introduce a new #define named GFX_USE_OS_FROSTED. If you want to do everything correctly, don't forget to add that new configuration define to the example configuration file gfxconfig.example.h in the root directory of the µGFX library. From there it's just implementing the abstraction layer in the two files that you created. The file gos.h contains the entire abstraction layer interface with extensive documentation. You can have a look at the numerous existing ports (all the gos_xxx.[ch] files in that directory) to learn how to write your port. I hope that helps a bit. As mentioned: Don't hesitate to ask. We are happy to help wherever we can.

Hello and welcome to the community! Your STM32F103 + RA8875 is a very common combo that is known to work well with µGFX. You should be able to get everything up and running without facing any issues or having to implement something yourself (except for the board file). Can you tell us what underlying system you'd like to use (ChibiOS, FreeRTOS, BareMetal, ... )?

Hello @inakto, The STM32F469i-Discovery board support is on the ToDo list for the next release. The reason we haven't had time to finish it and put it into the repository yet is because the way you implemented it is unfortunately not the intended way. Furthermore, we are experiencing some performance issues. Did you improve/change/modify the implementation that you sent us or are you working with that one?