Joel Bodenmann

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

Interesting. That's a change that @inmarket committed. I'm not sure what the story on that is. However, due to how the clipping works that definitely shouldn't lead to the problem that you're experiencing. Especially as that code appears to be working everywhere else. I'll dive into that and report back. Stay tuned.

You should really stop doing modifications in the library itself all the time unless you know what you're doing. This way it will be very difficult to provide support in the future as you'll have a completely different set of code than everybody else. If you have questions or doubt I'd recommend you to ask first. Otherwise it's simply not worth for us spending our spare time finding out why you're having issues when we have to start with "please give us a complete list of changes that you made". To clarify: I'm not saying that the µGFX library is perfect. It's far away from that and there are many known issues and most likely a lot more unknown ones. It just becomes impossible for us to provide support for a version that has tons of changes - some of which are wrong and some of which have huge impacts, even if they appear small. In general we try as hard as possible to provide a library where no source code modifications are needed outside the per-project files such as the configuration files and board files. Unfortunately, there are some exceptions to this like the display initialization sequences but that's something that will be resolved by the next version of the library. But just changing internal code, especially if we tell you how to do it the correct way, is definitely the wrong approach that can and will lead to problems in the future. If you do have questions please just ask - we're always happy to help wherever we can. If we explained something and you feel like it's insufficient information - just tell us that you need a bit more explanation and we're happy to dive into every detail as needed

gdispDrawString() draws a string with the given color without clearing the background. Basically every non-character pixel stays untouched. gdispFillString() on the other hand first fills the bounding rectangle of the string with the given background color and then draws the string on top of that with the given foreground color. The API documentation of those GDISP functions can be found here: http://api.ugfx.io/group___g_d_i_s_p.html

That has nothing to do with rotation. That's because the manufacturer of the display module has different options/choices how to connect the display panel to the display controller. Higher developed GDISP drivers such as the SSD1963 have a configuration flag that allows inverting the long the X and Y axis if required. It appears that the author of the ST7565 driver didn't implement that. If you want to handle this properly then that's the way to go. Quickly looking through the driver I see that things like the display inversion (positive / negative display mode) are hardcoded. These things should be passed through the GDISP control interface. The SSD1306 driver shows how to do that.

Line 84 of the gdisp_lld_ST7565.c file.

Check whether the allocation of the framebuffer in the driver initialization succeeds.

Great! Good luck! Don't hesitate to ask if you have any further questions.

Regarding 6: That flag controls the priority inheritance behavior of the mutex. The problem you have with mutex on operating systems with thread priorities is that when a lower priority thread has a mutex and a higher priority thread is waiting on that mutex the higher priority thread can't do anything for an awful lot of time because the lower priority thread is blocking the mutex. Because the lower priority thread gets less CPU time it also requires more time to do the job and release the mutex. This results in the fact that a lower priority thread can block a higher priority thread which is a huge problem. That problem is called priority inheritance. To prevent that problem most operating systems provide a mutex that has priority inheritance support. What that does is temporarily increasing the lower priority thread's priority to the same priority level as the level of the higher priority thread that is waiting on the mutex. This way the lower priority thread gets more CPU and is thus able to release the mutex a lot earlier and no longer blocks the higher priority thread that long. It's really a basic operating system problem and a basic feature: https://en.wikipedia.org/wiki/Priority_inversion In your case I'd simply use TX_INHERIT to enable the feature.