Joel Bodenmann

Ah, empty project name Glad to hear that you managed to get it working. Good work!

Hello @Werner and welcome to the µGFX community! The error message is pretty self explanatory: "Your directory contains spaces. Gmake barfs at that. Please define PROJECT. Stop.". Did you check your path? The last time I used ChibiStudio you were required to have it under C:\ so that should be the issue, but the path reported is relative so we don't know what it gets expanded to. Can you please first make sure that the expanded path still has no spaces and if that doesn't work please investigate that PROJECT thing. That is ChibiStudio related. I have no idea what it is.

Oh wow, didn't know about that one. Great!

I could watch your video - no problems with that. Did you make sure that the maxSize parameter you pass to gwinTexteditCreate() is sufficiently large?

Hello @PaulS, Sure, you can compile anything into a static or shared library. You just have to setup your compiler the right way. If the question is whether we have any guides for doing that with the µGFX library or whether we have support for that built-into our Makefile system then the answer is "no". But the process is the same as for any other thing you'd compile. In general you wouldn't really want to do that in most cases though. The µGFX library is very small and compiles very fast, especially when you use the single-file compile (when using our Makefile system, you can set GFX_SINGLEFILE or something like that to TRUE).

Hello @PaulS and welcome to the µGFX community! I can confirm that there is support for the touch via input system but currently none for the keyboard. It's simply missing because nobody needed it so far - there's no technical limitation or something. So it's really just a matter of writing the driver which shouldn't be too hard.

@ronan_rt?

Great work! We'll integrate your driver into the repository soon.

Hello @aeroman and welcome to the µGFX community! Thank you for sharing your driver with us, we really appreciate it. I gave it a quick look and so far it looks quite good. We've seen way worse. That's pretty good for your first driver, well done! I'm not sure on the command buffer thing but then again I didn't yet find enough time to properly investigate. I think that this is good enough to be included into the repository. The board file template needs to be created but that's easy. What do you think, @inmarket?

Hello @malachib and welcome to the µGFX community! I'm glad to hear that you managed to solve your issue and that everything is running now. Thanks for bringing the issue with the readme to our attention (again).

Hello @besitzeruf and welcome to the µGFX community! The unlimited license allows the license receiver (eg. a company branch or an individual) to use the µGFX library commercially on as many different devices from as many different products/projects as he likes as long as the license receiver is the responsible entity of the product/project. There are no royalty fees and it's a one-time fee. I hope that answers your question. Please don't hesitate to ask if anything is still unclear.

Great work guys! Much appreciated!

From personal experience I can confirm that that is indeed the truth. I'm gonna leave that to @inmarket as he's the original author of the makefile wizardry. It's complex, especially when things like auto-substitution of cygwin paths come in and so on.

Is it just me or is the demo missing the gfxInit() call?

Did you even bother reading the messages that the compiler outputs? > You must alter this demo <

What do you mean by "the debugger stops"? Are you getting a hard-fault or can you just not move to the next line? The latter would indicate that the delay is not properly working. As you are using ChibiOS/RT the gfxSleepMilliseconds() function is really just a wrapper around chThdSleepMilliseconds() (or whatever it is called these days). Could you please try to run one or both of the GOS tests that you can find in the /demos/modules/GOS directory? Those tests only test the OS abstractions (eg. the threading and the delays). The GDISP module and all the other modules are completely disabled.

I'd recommend you to properly debug this. step through the code (eg. through gfxInit()) and figure out where it halts. Then, get a level deeper. There are literally hundreds of problems that can lead to this. It would already be helpful to know whether the driver finishes initialization and so on. We are happy to help wherever we can, but we need to know what the actual issue is.

Yep, that too. I missed that one - sorry.

Please set GFX_COMPILER to GFX_COMPILER_KEIL and set GFX_CPU to GFX_CPU_CORTEX_M4 (or the floating point equivalent if you're using the FPU). Don't forget to recompile from scratch after making those changes (clean build).

There's not really a dedicated example for this as you usually know what you're doing when you need that function. gdispGBlitArea() doesn't require a pixmap. It is a standalone high-level API function. The parameters are explained in the API documentation. Could you be more specific with your question? Are you facing an issue with it?

Hello @leozhang First of all: You shouldn't copy the driver out of the µGFX library to your project directory. The driver itself should remain in the µGFX library directory. You only have to put the board file in your project directory (that is unless you want to modify the driver). If your driver doesn't pass the initialization then please use the debugger to set a breakpoint in the board_init() function and step through the code line by line to figure out where it hangs and why. Keil has a great debugger. I haven't looked at the 3rd party OLED functions that you're calling but the board file itself seems fine on first glance. But you might want to consider adding the implementation for the setpin_reset() function in the board file as well.

Hello @TomCat and welcome to the µGFX community! I moved your post out of the other topic and created a new one. To your question: The board file for the STM32F429-Discovery that you find in the µGFX library repository already does that for you: It uses SPI for the configuration and then enables the RGB interface so that the LTDC can be used. What exactly is the big problem that you're facing?

Sorry, my bad!

Yes, that is intentional and yes, you can disable that by setting GWIN_SLIDER_NOSNAP to TRUE in your configuration file. Here's a copy of all the default values. It's taken from the example config file named gfxconf.example.h that you find in the top-level directory of the µGFX library distribution: #define GWIN_NEED_SLIDER FALSE #define GWIN_SLIDER_NOSNAP FALSE #define GWIN_SLIDER_DEAD_BAND 5 #define GWIN_SLIDER_TOGGLE_INC 20

You're welcome. Don't hesitate to ask if that didn't fix the problem.