Joel Bodenmann

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?

In that case we strongly recommend that you start off with a ChibiOS/RT only project. ChibiOS comes with tons of ready-to-run demos. In fact, there is at least one demo that works out-of-the-box on the STM32F401RE Nucleo board. Take that demo, make sure that it works. Then add µGFX to it by following this guide (or alternatively this one if you are using the ChibiStudio IDE). You can have a look at the various examples in the /boards directory of the µGFX library to learn how to write a board file. In your case, most notably these two might be interesting: /boards/base/FireBull-STM32F103-FB: ChibiOS with parallel port display using GPIO bit-banging /boards/addons/gdisp/board_SSD1963_fsmc.h: ChibiOS with parallel port display using FSMC As mentioned in the previous post we strongly recommend hooking the display up to the FSMC peripheral if possible. That is a lost easier and a lot faster at the same time. Back in the old days where µGFX was still a ChibiOS-only library I actually wrote a very extensive guide about using the FSMC interface to interface SRAM and LCDs for ChibiOS which you might want to read: http://wiki.chibios.org/dokuwiki/doku.php?id=chibios:community:plans:external_ram

The ILI9341 itself would offer an SPI interface. However, unfortunately you won't be able to use SPI with this display module that you are showing. You have to use it with the parallel interface. Note that you should be able to use it in 8-bit mode instead of 16-bit mode which would free you from making 8 connections. Usually there is a jumper to select the 8-bit vs. the 16-bit mode. Judging from the picture this could be J1 but please check with the datasheet of the display module to be sure. Worthwhile to note is that the display will be more than twice as fast in 16-bit mode than in 8-bit mode and probably around 10 times faster in 8-bit mode than SPI mode. In order to keep the CPU load low and to increase the overall speed & performance, you should connect the display to the FSMC peripheral of the STM32. We don't have a ready-to-run example for your specific setup (Nucleo401RE + ILI9341 over parallel). This would also depend on what underlying system you'd like to use (bare metal, ChibiOS, FreeRTOS, ...). However, there's a Nucleo401RE example available in the download section which uses ChibiOS/RT and an SSD1306 based display. You should be able to modify that and using the various example board files in /boards you should be able to write the board file for your setup. If you want to use a baremetal system (no underlying operating system) instead we recommend using a working example/demo project from another source and adding uGFX to that. The most important thing is not to get discouraged. These systems are very complex and the fact that the µGFX library runs on virtually any system with tons of different configuration options doesn't make it easier. It can take you a while to see how things plug together. Don't get discouraged if you can't get it working straight away. The platform you are using is very common (STM32F4 + ILI9341) and you will be able to get it working just fine without any problems or modifications. Don't hesitate to ask if you have any questions. We are happy to help where ever we can.

@cheater any news on this? We'd love to see the code behind this lovely meter!

We didn't find the time to test it yet, sorry. These kinds of symptoms often arise from common errors such as not enabling the image format in the configuration file or having GFILE_MAX_FILES set to a number too small. As these things usually cover 95% of the problems we tend to let the user check those before we spend the time setting everything up on our side. The new µGFX-Studio will have a proper "export as ZIP-Archive" feature which will vastly speed up things like this. That is not so easy, but finally I'll do it. That should be a thing very easy to do. Just store the return value in a variable of type gdispImageError and read out that value (either display it, send it over serial or look at it via the debugger, ...) I'm glad to hear that you found the problem. We will have a look at your images to determine the problem, but that will take some time. There are certain features that the µGFX image decoders don't support such as PNG interlacing as that would simply bloat code-size with little to no gain at all. However, the GIF decoder should be pretty complete. So far we never encountered an image that imposed problems. The reason why the µGFX-Studio displays the image is because it doesn't use our image decoders. That is probably the biggest benefit of the new µGFX-Studio: It actually uses the real µGFX library to render everything.

We are happy to help resolving or fixing any issue. But as mentioned in the previous post we require you to provide us with a minimal-test case that allows us to reproduce the problem.

Did you ensure that you actually have enough memory left to open that many images at once? You might want to check the return value of gdispImageOpenFile() (or equivalent of the Imagebox). The value returned is of the type gdispImageError, it will tell you what caused the failure. The possible values are documented in /src/gdisp/gdisp_image.h. The same applies to gdispImageDraw() (or equivalent of the Imagebox). Just to ensure that I understand this the right way: You are able to display all images - just not at the same time?

Most likely the fault is caused by the GFILE_MAX_GFILES setting in the configuration file which is too low. Can you please try increasing that value and retry? The µGFX-Studio is supposed to calculate the correct number required, however, there might be a bug. In case of you need to access files that the µGFX-Studio doesn't know, you can add those in the GFILE tab in the Project Settings.

Okay... I am having a hard time following you on what is working know and what questions you have. If you have questions that are not related to the first post in this topic, please don't hesitate to create a new topic. It is very important to us to keep the forum clean, structured & well organized. It makes it a lot easier for us to reply to your questions and it makes it a lot easier for other people to find answers using the forum search.

It is a file that contains library-internal specific stuff. It can happen that we modify the file contents. Think of the simple example where we add a new module to the µGFX library: We'd have to modify the gfx_mk.c file. The goal is that you can simply replace the µGFX library directory without any modifications to upgrade to a newer version. When copying library files like gfx_mk.c to your own project you prevent that from working. We strongly advice against doing that. Glad to hear that you got everything working. We appreciate any kind of guide, tutorial, example project or similar. This can be helpful to many people. They are not useless. They are used to calculate the timings during compile-time which vary from display panel to display panel. Of course the users can do the calculations manually and enter the result instead but these calculations happen during compile time and therefore have zero run-time impact. The parameters supplied to those macros are the more natural information than supplying the result calculated by hand. In fact, the parameters passed to those macros is what you will find 1:1 in the display panel's datasheet.

Glad to hear that you managed to compile the project. In that case the problem really was that the toolchain simply didn't provide support for the Cortex-M7 yet.

We recommend using this toolchain: https://launchpad.net/gcc-arm-embedded You should be able to compile the demo project without any problems using that toolchain. Please don't hesitate to ask if you have any further questions. We are happy to help where ever we can.