Joel Bodenmann

Do never ever modify anything inside the uGFX library unless you know what you are doing (eg. custom modifications). Our build system is very complex and adapts itself to each configuration in order to provide the most efficient code possible. There are many things that are evaluated during compile time and change how stuff gets glued together. If you are working with eclipse we strongly recommend adding the µGFX library using the built-in makefile system. This is the most reliable and easiest way to add µGFX to an existing project. This way you don't have to worry about making sure that every source file is included and that all inclusion paths are set correctly which can be a very cumbersome and error prone work. Guide: http://wiki.ugfx.org/index.php/Getting_Started#Makefiles In your current situation it seems like the root path to the µGFX library directory has not been added to the search/include path.

You can try running the converter directly on your computer. There are binaries for Windows, Linux and FreeBSD in the uGFX library repository. But we don't provide any warranty nor support for those binaries.

No worries, that's nothing stupid We are here to help you where-ever and when-ever we can. Good luck with your project!

The SPIConfig is a struct from ChibiOS/HAL. It has nothing to do with µGFX itself. This means that you are trying to use a board file that was written to be used with ChibiOS/HAL which you are not using. The solution is to not use that board file but copy the template that you can find in /drivers/gdisp/ILI9341/board_ILI9341_template.h and implement those empty functions using what ever HAL that you are using (eg. STM32CubeF1).

There's also a limit on the maximum duration that the script can take to convert the font (server side timeout). But to prevent this kind of issue that timeout has been set to 3600 seconds. I just verified that that setting is still correct. There's nothing we can do on your browser side.

Hello and welcome to the community! There are a couple of different tools that you can find in the /demos/tools directory that will help you to troubleshoot your touchscreen issues. I'd recommend running them to pin-point the exact problem. Regarding the GTIMER thread: Make sure that the stack size (GTIMER_THREAD_WORKING_SIZE) is big enough. However, the default setting of 2048 bytes should be more than enough unless you are running other GTIMER jobs that require a log of stack. You can find more information about that here: http://wiki.ugfx.org/index.php/GTIMER Also note that you don't have to use any of the GINPUT API functions inside your application code unless you want to manually add some devices. The touchscreen handling is totally automated for you in the GWIN module.

Thank you for sharing this great guide! I am sure that this will help some people to improve their workflow. There's still a lot to do in the uGFX-Studio but it's nice to see that people can actually do some real work with it

You can find that information here: http://wiki.ugfx.org/index.php/Images Currently three formats are supported: BMP, GIF and Native. We have just finished adding support for PNG format. It's working and we only have to do some more testing. The upcoming release of the uGFX library will contain support for PNG images. The studio itself doesn't allow to add images where the uGFX library doesn't have the matching decoders for. The uGFX-Studio will allow you to use PNG images as soon as the next version of the uGFX library has been released.

Yes, it's correct that using DMA with the ILI9341 driver will require some driver code modifications. However, that shouldn't require a lot of modification. Most drivers have been contributed by countless users over the years. We don't have the resources to properly implement each driver on our own. So as soon as we see that there's a working driver that meets our coding standards we make sure that it works on one way or the other and then it goes into the repository. But the list of implemented features is usually a lot smaller than with the drivers that we implemented ourselves. You can have a look at the SSD1289 driver to get an idea on how to add DMA support to an existing driver. To actually talk about your problem: Make sure that streaming is enabled. That way the GDISP module will make burst writes whenever possible.

Did you make sure that you enabled the native image format as well as the MEMFS for the GFILE module? Are you able to run the example I posted?

Yes, you can. Both the custom rendering routine as well as the custom parameter passed to that routine can be set either in the widget init struct or at any time during runtime using gwinSetCustomDraw(). There you go: container_pixmap_example.zip This is what it should look like:

Yes, the container has no idea when the content of the pixmap changed. The pixmap is a glorified array of pixel values. It doesn't generate any events or similar. Just call gwinRedraw() once you want to redraw the container using the modified pixmap.

Yes, that would be the intended use. Simply assign gwinContainerDraw_Image() as the rendering routine for the container and pass gdispPixmapGetMemoryImage() as the image pointer to the custom parameter of the rendering routine. Should work out of the box and provide you with a lot of joy

I am not quite sure whether I understand your current situation so please forgive me if I am giving a misleading answer. If you are using the image rendering routine of the container and you are using a pixmap instead of an image then you don't need an additional window to display the pixmap. If you are using the window for anything else then you obviously need it for that thing but the container doesn't require an additional window to use the image rendering routine (with or without using a pixmap as an image).

Yep, that's correct. All settings in the gfxconf.h file is about what you want. What the driver is capable of is always located in the *_conf.h file in the actual driver directory itself.

Hello and welcome to the community! The font engine requires fonts to be present in addressable memory. Therefore, if you have an external addressable memory you just have to tell your linker (script) to put the converted font into the external memory and you are done, no file system required - The code stays exactly the same, just the address of the font will change. Loading from other external memory sources such as SD-Cards is currently not possible. Adding support for that is a very low priority task for us as even smaller MCUs tend to have more than enough spare ROM to store a few dozen fonts these days. Proper filter ranges and RLE will further reduce the font size. It's better to keep other resources that are easier to outsource in external memory such as images.

I am glad to hear that you finally got to try the pixmaps. They are really capable of vastly improving performance Can you please post the list issue in a separate topic? It seems to be very unrelated to this topic about flickering with the graph widget.

There should be no difference between using EmBitz or Eclipse if both use Makefile and the same compiler. These IDEs are just glorified text-editors, really. It's difficult to track that issue down. Can you post a picture of the display as well as the information about the compiler that you use for each IDE? You get that by executing this: arm-none-eabi-gcc --version

Regarding the warnings of the STM32_LTDC driver... is it possible that you are not using the latest code? The line numbers in your warnings don't match the ones in the actual driver source-code. We have marked the compiler as tested for now as you reported to us that it's working fine besides those warnings. We will try to figure out the correct pragmas to get rid of these.

We just added the missing default values for these macros: https://bitbucket.org/Tectu/ugfx/commits/3d78787b07ce9c2dafe0869dfd54b734181b7dd6 Can you please grab the latest master of the repository and let us know whether these warnings vanished?

Hello and welcome to the community! As inmarket mentioned you don't have to worry about that in terms of uGFX as we internally take care of that. However, that is in fact a problem you can never avoid. It's a basic principle (or problem) of counters and the systick has the same problem. This problem needs to be handled manually: https://stackoverflow.com/questions/3095623/how-to-deal-with-a-wrapping-counter-in-embedded-c STM32 Systick overflow ... An overflowing systick counter was also the reason why the mouse cursor in Windows 95 stopped working after 47.5 days

Not true. Keil works perfectly fine with 3rd party compilers such as GCC: http://www.keil.com/arm/gnu.asp

Whenever possible: Texteditor & make. Whenever required: Keil. Always avoiding: Eclipse. Yeah, that sums it up pretty well I think Personally I used EmBlocks in the past but it became too cumbersome for me. It has great potential but the project lacks the man-power to move forward. The next thing I want to try is this: http://www.rowley.co.uk/arm/

Hello and welcome to the community! Implementing such behavior would require modifications of the GWIN module. There are similar ways to archive this - all of which come with their own up- and downsides. We just had a long discussion about that and came to the conclusion that it will take a lot more thinking to figure out which is the best way to give the user the ability to implement that behavior. Sadly there's also no quick work-around that we could propose as this requires changes in the GWIN module that will affect all widgets and therefore have to be thought through well. That said it will take some time to get this done due to our current workload being quite high. If this is of high importance we'd suggest purchasing a support package to drastically speed up this process. It will give you direct access to our high-priority support ticket system. Did you see that you can use the existing virtual keyboard widget for that and just create a custom layout that only contains numbers and then assign that using gwinKeyboardSetLayout(). You can have a look at the existing layout in /src/gwin/. It's just a matter of filling in a few structs. That way you will still use the underlying, official code. If we ever change anything (eg. fix some bugs or extend the features of the keyboard widget) you can benefit from them too without changing anything!

Did you follow our guide on how to use the ChibiStudio? There's a step-by-step guide that leads you through the process - it starts with downloading the appropriate Java version: http://wiki.ugfx.org/index.php/Using_ChibiStudio And if you don't like to use that very simplified Makefile we provide then follow the exact same guide but use the Makefile supplied by ChibiOS and modify it according to this guide: http://wiki.ugfx.org/index.php/Using_ChibiOS/RT