Joel Bodenmann

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.

What version of the µGFX library are you using? Make sure that you're using the latest master branch from the official repository. Also make sure that you're using the gfxconf.h contents that were generated by the studio. But keep in mind that the studio doesn't generate the GOS part of that configuration file so you'll have to add that yourself. Don't forget to make a clean build.

@cpu20, can I leave this one to you?

Hello @Muhammet and welcome to the µGFX community! We currently don't have a dedicated tutorial for the Atollic True Studio. But if you explain the problems that you're encountering we'll be happy to help you. @cpu20 is very good with IDEs and build environments. I'm sure that he'll be able to help you getting everything up and running in no time

Hello @Vector and welcome to the µGFX community! There is a very detailed guide that shows how to add the µGFX library to an existing Keil µVision project: https://wiki.ugfx.io/index.php/Using_Keil_µVision_5_MDK-ARM So when you have a Keil project with FreeRTOS that runs on your STM32 then it's just a matter of following that guide step-by-step. Make sure that you enable the FreeRTOS OS abstraction in the configuration file. I hope that helps. Don't hesitate to ask if you have any further questions.

There's now also an official generic Eclipse guide written by @cpu20 in the wiki: https://wiki.ugfx.io/index.php/Using_Eclipse

Glad to hear that you managed to track down and fix the issue And: Welcome to the µGFX community!

As mentioned in the post that you linked that really is a relic from older times. I updated the wiki article now. It's correct that the driver has to use the GMOUSE_VFLG_CAL_EXTREMES flag to enable this feature. But that requires modifying the driver. The idea is that a well written driver would expose that feature as an option to the board file. That's currently not the case for the ADS7843 driver so you'd have to add that yourself. I hope that helps. Don't hesitate to ask if you have any further questions.

Fix pushed to the repository. Thanks again for bringing this to our attention!

Yep, great work indeed!

Yep, I definitely missed that last part. My bad! Glad to hear that things are moving forward though.

Hello @Emilito, I appreciate that you ask this question. It's nice to see that there are still people that worry about this kind of thing. It's definitely correct that you need to ensure that you're using a font in a way that you're not violating the font's licensing terms. That is always the case. All fonts come with a license. Some fonts are simply "public domain" licensed which means that you can do literally anything with the font. The DejaVu fonts that come with the µGFX library are public domain licensed which means that you can use them for sure without any further worries. The other fonts (namely the UI1 and UI2 fonts) were created by ourselves and the license allows you to use them in any µGFX application - so nothing to worry there either. I haven't checked the license of the Arial font but it's very well possible that the license only permits usage within Microsoft products. There are fonts from other companies that also have these kinds of licensing terms. Usually the best option you have is picking a font with an open license. You can find tons on sites such as dafont.com, fontsquirrel.com and similar (there are literally thousands of them). There are also fonts that require you to purchase a commercial license but that are actually within the financial possibilities of a regular person or small company. I remember one particular font where you just had to pay 50 USD in order to use it commercial for any purpose within a company. Other than that there are also open/free fonts that have been designed to be an alternative for an existing proprietary/commercial font. A specific example: Our UI-Designer created a design for a customer that used the Helvetica font. The license that would have allowed to use it in the required environment would have been too expensive for that project. The designer then simply looked for an alternative font that is very similar but free/open which we found and then used in the project. I'm not aware of any font licenses or license terms that are specific to embedded devices. I assume that you're confusing the difference between "embedding a font" and "using a font on/in an embedded device". The former (embedding a font) refers to media formats that allow passing a font together with the media content itself. For example, you can embedd a font in a PDF file so that the received/user/viewer of the PDF file gets the correct font without actually having that font on his system. Maybe @thoeby (our graphics & UI-designer) can add some more information to this as he's working with fonts every day.

That looks very good, well done! I added it to the repository.

Why did you have to move the RAM(g) and other macros to the board file? That would be wrong. That is part of the generic driver. Only stuff that changes depending on your wiring must go into the board file. To clarify: I don't say that what we have in the repository is correct right now (as apparently there are a few changes that were applied prior to that) but the framebuffer stuff definitely belongs to the driver, not to the board file.

So this appears to be a bug. The change of using a constant here rather than actually calculating the string with is okay and preferred at this point (hence the change). However, the constant itself is wrong. The clipx1 field is of type coord_t which is usually (and defaults to) int16_t. This means that the maximum positive value is 32767, and not 32768. In this case it seems like you're experiencing an overflow that gives you an x1 clipping coordinate of -32768 which explains why you don't get any text rendered. I don't have time to run the usually battery of tests right now. Could you please adjust the constant to 32767 and check whether everything is working as expected? Also, it would be interesting to see whether you get a compiler warning about this. The compiler should definitely inform about the overflow here. What compiler are you using? Thank you for bringing this to our attention