Joel Bodenmann

Definitely unrelated to the GADC module as @inmarket already mentioned. It is likely due to a DMA stream collision (if your ADC peripheral has been set-up to use the DMA as well). It has been a long time, I really can't remember which DMA stream the STM32 LTDC driver uses (or even if at all) but you should be able to check the sources and then use a different DMA stream for your ADC. If you say that "it stops working", does that mean that just the DMA halts or do you experience a hard-fault or some other from of crash? As in: Does the CPU keep working and it's just the DMA that gets stuck?

It is a regular C #define. This means that 1000 is 1'000 decimal. If you want 4k of heap you either write 4096 or 0x1000. Regular C syntax, no magic. #define GFX_OS_HEAP_SIZE 4096 // 4k of heap

GFX_OS_HEAP_SIZE can't be dynamically allocated (as that is the whole point). It takes up exactly that amount of memory in bytes of memory at compile time.

Please keep in mind that the latest version of the µGFX library is always available through the master branch of the git repository: https://git.ugfx.io/uGFX/uGFX/ The master branch is always kept in a state where it can actually be used.

Hi, Can you please tell us more about your system (what hardware, which compiler, which underlying system, ...) and show us your configuration file (attachment!)? Also, did you try to use the debugger to figure out what's happening (hard-fault, hang, ...)?

Often the underlying system (that provides the memory management) provides utilities required to track heap usage. However, there's no real magic to that. For embedded systems it's usually just a matter of filling the entire heap area with a known pattern (eg. 0x55555555) at initialization and then using the debugger to dump the memory area to examine how much was left unused. The Raw32 heap manager doesn't offer this. It's also not that critical because RAM usage of µGFX is deterministic once you know what you're doing / what your requirements are. Towards the rest of your application that's completely uncritical as well because µGFX reserves a block of memory the size of GFX_OS_HEAP_SIZE which is known prior to compilation. It's correct that the "default behavior" of µGFX with the STM32F746G-Discovery board files only uses the external SDRAM for the framebuffer(s).

Hello @dswl and welcome to the µGFX community! The problem is caused by having GFXSRC and GFXINC in your Makefile there. Simply remove them and everything should work. The Makefile you're using there is the high-level Makefile provided by the µGFX library. The $(GFXSRC) and $(GFXINC) variables mentioned in the documentation are already being included internally. I hope that helps!

The diskio stuff from FatFS has nothing to do with µGFX. That's not something we can help you with. Usually the underlying system you're using provides a suitable implementation. All major RTOSs do that and I'm pretty sure that the CubeHAL provides one too. In any case this is completely outside of the scope of µGFX. GFILE just uses the high-level API from FatFS. The diskio stuff is on the other end of FatFS. The best way to get this working is by creating a new basic hello-world project for your platform that doesn't use any other dependency (not even µGFX!). Then add FatFS to it and make it work. Once you have a working FatFS environment you can just put µGFX on top of it and enable FatFS in the configuration file.

As @inmarket mentioned the implementations of things like malloc(), setjmp() and so on are often buggy on standard libraries provided with the toolchains for embedded targets. That's why we provide our own generic implementations that work anywhere. The configuration allows to choose any of the options which means that the user of the µGFX library can always pick what's best for his case.

Here you go. Let me know whether that worked out for you.

Hello and welcome to the µGFX community! The list widget uses the fill property of the widget style to highlight the currently selected item (line 782 in /src/gwin/gwin_list.c). A display driver for a monochrome display controller usually interprets the color 0x000000 as black and everything else as white (or what ever the two colors will be). Currently you set all your values to non-zero values. Try setting the fill property to 0x000000. However, that will most likely not be satisfying as you'll no longer get a visual indication for which item is currently selected. In that case, you want to write a custom rendering function for the list widget so you can either invert the colors of the currently selected item or you can add some sort of arrow indicator. Writing a custom rendering routine is very simple, there's a guide: https://wiki.ugfx.io/index.php/Creating_a_custom_rendering_routine You'd usually start of by copying the built-in rendering function and then modifying it to your needs. I hope that helped.

Hello @Oshel and welcome to the µGFX community! Thank you very much for your positive feedback - we appreciate it a lot! Regarding the win32 stuff: I can upload a bare win32 demo project (basically a hello world) that uses Makefiles if you'd like. It's well tested.

Hi, Can you please try to run the /demos/modules/gwin/keyboard demo without modifying it at all?

Thank you for your feedback regarding the documentation. But did you have a look at the /modules/gwin/keyboard? It shows clearly how to use the virtual keyboard. It doesn't get much more detailed than that. It even shows how to grab virtual keyboard visibility changes. Please stop highlighting me or inmarket in your posts just in hopes that we reply sooner. We reply when we have time for it.

I'm sorry, I don't understand what you want to achieve. Why do you want to have a button in focus that is on a different display page?

Sounds great! Looking forward seeing the final example project

Just for clarification for people that come around this post: This is not because µGFX doesn't support pixel read-back or doesn't support it well. It's just that, as @inmarket explained, it's often not supported by the hardware itself. µGFX has everything required to read back pixel values. That's correct, I fully agree. But that's also the reason why it would be awesome if somebody else would pick up this task

Hello Kevin, No, we currently don't have built-in anti-aliasing for shape rendering. The goal is to offer that as a 2nd set of functions. If you'd be interested in helping to implement those we'd highly appreciate it. Anti-aliasing for font rendering is fully implemented though.

You never get back a string, you always just get a single character because each time a character is pressed on the keyboard an event gets generated. Therefore, just listen to the event as shown in the demos mentioned in my previous post and create an array from them yourself. It's really just a matter of having an array and a write pointer or an index variable. If you need something more flexible than arrays you might want to consider using GQUEUES.

Hello @manoj, When using the virtual keyboard the keyboard input layer of the GINPUT gets enabled. When that is the case, keyboard events get distributed to the widget in focus. A widget can be focused by either clicking it or by using the arrow or tab keys of a keyboard to move the focus to the next widget in the widgets list. When a button has focus it can be clicked by pressing the enter or space key on a keyboard. This is most likely what is happening here. I'm not sure whether that is a bug in the distribution of the keyboard events to a widget in focus or whether you're doing the visibility handling wrong. It's actually not that unlikely that this is a bug in the µGFX library. I'd recommend you to run some simple tests based on what I described above. Start with two push-buttons and a keyboard widget on the same page and then work your way from there.

Hello @jtronix and welcome to the µGFX community! Thank you for sharing your example sketch. Things like this are always very helpful for other people. Do you feel like the sketch is "good enough" to be added to the downloads section on this website as an example project? Regarding the ADS7843: I don't know of any existing board file for that setup. There's a GDISP board file for Arduino in the /boards/base/ArduinoTinyScreen/ directory but I guess that won't help much as you already got everything working. At the end the stuff you have to do in the ADS7843 board file is exactly the same as for a GDISP board file: Implement the different functions to talk to the hardware (eg. SPI in this case) and that's it. You can find a template board file in the ADS7843 driver directory. If you're having trouble understanding what each function should do we're happy to help where ever we can. If you're having troubles with the Arduino library I guess the folks over at those Arduino forums will be happy to help where ever they can as well

If you didn't find the problem until now there are three things you can easily do: Instead of changing the page, just printf() something. This way you don't run into another issue upon changing pages that might look like the button stuff is not working. Run the button demo that you can find under /demos/modules/gwin/button Quickly fire up the µGFX-Studio (that you can download from this website under Downloads). It allows you to create very simple GUI pages and it generates an event-loop for you. Add that code to your project and give it a try (you'll still have to call the guiShowPage() functions yourself to actually change the page though. The issue mentioned by @inmarket is definitely something that is wrong here too so you might to keep that one in mind for the future. An additional remark: It's usually very bad practice to load fonts upon switching display pages. Unless fonts are being loaded from an external memory source because they are not byte-addressable they don't take up a lot of space. It's merely a header with a bit of metadata. Therefore, fonts are usually kept open indefinitely for regular applications. But at the end this really depends on what you want to do.

@inmarket already mentioned one of the important things: The header file generated by the file2c tool contains a C-Array of the binary raw data of the file that you fed into it. The actual size of the object in ROM will be a lot smaller as it won't be a textual representation of binary data anymore (eg. think of all the commas in the array to separate the individual bytes. All of those will be omitted). Also, very large files usually get split up into multiple C-Arrays which leads to even more textual overhead that won't add any size to the object itself once compiled into a binary. The GFILE module allows you to load data (and therefore images) from pretty much any source. One of those is the microcontrollers ROM through the ROMFS that we wrote ourselves. However, GFILE can easily interface other file systems such as FatFS that allows you loading images from an SD-Card. Everything is already in place to do that. The STM32F7-Discovery board you're working with also has a mass-storage memory connected via QSPI. It's also possible to interface that through GFILE. Once you managed to get your image through the GFILE API the rest of the library doesn't bother anymore so you really have a vast variety of possibilities where to load your image(s) from. If things really get bad you can always implement your own file system using the USERFS interface of GFILE.

For completeness, we're referring to this one: https://wiki.ugfx.io/index.php/Teensy