Joel Bodenmann

Hello @newbornsun and welcome to the µGFX community! I'm glad to hear that you got everything working! The OPT_LINK_OPTIMIZE = no doesn't surprise me at all. Basically that doesn't do anything but turning LTO off. There is one (known) GCC version which has a bug in the LTO stuff. The -u chThdExit stuff would be surprising however. That's definitely wrong and doesn't belong there.

Great to hear that you got it working! The issues you're having with the touch controller are definitely only related to the driver / board file. It doesn't surprise me that the driver has a few issues as we never got to test it ourselves - it got contributed by a guy that we never heard from again. We'd highly appreciate it if you could investigate and fix it. The issue with the failing touchscreen calibration will most likely be related to the high resolution of the display. The last of the four points that you will press (the one in the middle) is to check the accuracy of the calibration processes. There's a setting that allows setting the maximum number of pixels that the calculated touch coordinates can be away from the actual hair cross on the display. These settings are GMOUSE_FT6x06_FINGER_CALIBRATE_ERROR and GMOUSE_FT6x06_PEN_CALIBRATE_ERROR and should be part of the board file. Try increasing those values.

Dear @AcOCrW, We gave you instructions two times what we need from you in order to be able to help you. As long as you ignore that, we won't be able to help you. Posting twice won't make us help you faster either. Neither will using a larger font size or colored text. Please follow the instructions that we gave you above.

This is somewhat ambiguous to me. Are you maintaining two dedicated framebuffers yourself and just flushing to the one active LTDC layer? The LTDC provides you with two layers and you should definitely let the LTDC handle the two framebuffers. Note that "a layer" is basically a framebuffer. Once you setup the two layers you only have to register one LTDC register to change the active layer. This is basically double buffering implemented in hardware by the LTDC. That is one way to use the two layers of the LTDC. The other way is to use the two layers "at the same time" which is probably what you want for your sliding menu. In that case you still have to initialize the two layers and let the LTDC handle it. The difference is that you ask the LTDC to display the two layers on top of each other (properly using the alpha channel to make the lower layer "shine" through the upper layer). The way to use this from the µGFX point of view is to implement the gdisp_lld_query() commands to retrieve the two GDisplay* pointers of the two layers through gdispQuery() API. This way you can use the regular multiple displays support to draw to the two layers independently. I hope that helps. please don't hesitate to ask if you have any other questions. Keep in mind that I cite these LTDC behaviors/features form the top of my head. You might want to check the datasheet to seek certainty.

Keep in mind that GFX_OS_USE_KEIL is not necessarily the correct setting when using Keil µVision. That setting is used when using the Keil RTX (CMSIS compatible) RTOS. It's possible to use any underlying system such as FreeRTOS or even just running baremetal in a Keil µVision project. The GFX_COMPILER and GFX_CPU macros are the ones you want to worry about in this case.

As long as the threading demo (/demos/modules/GOS/threads) is not working properly there is no need to continue looking any further. The GINPUT module uses a GTIMER which uses threads and that's why you're hitting a problem. Can you please tell us exactly what compiler and what version of µGFX you're using? The RAW32 thread handling stuff got improved a few weeks ago. Make sure that you're on the latest stable release and/or the latest master branch of the development repository (just to give it a try). There have been quite a few reports of issues with RAW32 lately. Unfortunately, we couldn't find a pattern yet (eg. whether it's a specific platform, a specific compiler, or a specific combination of the two). Using the forum search you'll find things like this: So please do the things suggested in this forum post and let us know about the results.

There's no need to send any form of bug report. Instead, please follow the advice/guide in my post above to resolve the issue. Without giving proper information about what you're trying to do, what you're using and the entire build log (like mentioned in my previous post, that is very important) there is nothing we can do for you. Please also read the documentation on the configuration option that you changed. Depending on your setup (which you yet have to tell us), GFX_OS_USE_KEIL might be the wrong option. We'd love to help you but you're currently not making it easy for us

Glad to hear that you got it working And with that: Welcome to the µGFX community!

Some touchscreen controllers (usually all that support capacitive touchscreens) support self-calibration. If the µGFX driver supports that then there's usually a configuration option in the corresponding board file. If self-calibration is enabled, the calibration screen won't show up. Other than that there's the interface that allows storing and loading calibration data which also allows bypassing the manual calibration screen. But there is no need to handle that if you're writing a touch driver - everything is done inside of the GINPUT module and as long as the user hasn't enabled that interface/feature in the configuration file nothing happens anyway. A tipp: /demos/tools/touch_driver_test is a good program to use in order to test whether your driver performs well.

If you could additionally provide us with the proper name and version of the compiler itself (eg. arm-none-eabi-gcc v4.9.1) that would be helpful too.

Glad to hear that you managed to get it working - keep us up to date about this!

Great work at getting this working, @nquantum!!! We will definitely have a look at your work soon and report back to you. Unfortunately I don't think that that will happen before next week. In the meantime: Don't hesitate to ask if you have any other questions. We are really happy to help wherever we can. In this case we just don't have any knowledge or experience on that DSI/MIPI interface so we weren't of much help so far

Also, don't forget to make a clean build when changing stuff in your configuration file.

Hello @Steffan and welcome to the µGFX community! The STM32LTDC driver currently doesn't implement the switching feature as described in the post that you linked. Currently you can configure the second layer in your board file but there's no way to tell the LTDC to switch to the second layer - that is the functionality that yet has to be implemented in the existing STM32LTDC driver. The overall goal is to use the multiple displays support to allow drawing to the two different layers individually. Then there's a configuration register somewhere in the real physical LTDC peripheral that allows swapping the currently being displayed layer (or blending the two). The goal is to add an option to gdisp_lld_control() that changes the corresponding parameter in the LTDC peripheral. There is no need to copy the existing driver and using it twice - that would be wrong. The goal is to extend the existing driver to add that capability. You can have a look at the SSD1306 driver which uses the gdisp_lld_control() function to invert the display - that should give you an idea of how to use the gdisp_lld_control() interface. I hope that answers your questions. Please don't hesitate to ask if you have any question.

Hello @AcOCrW and welcome to the µGFX community! You're not really giving us much information here. Please let us know what compiler and IDE you're using, what your target hardware is and so on. For the future, please attach a text file containing the entire compilation output if you have a build issue. From the screenshot it appears that you're using Keil µVision with ARMCC. You're either not properly including the µGFX library into your Keil µVision project (please see this guide to learn how to do that) or you've selected the wrong operating system in the configuration file. Most likely you selected GFX_USE_OS_WIN32 which would be wrong. That setting refers to the operating system running on the target, not your host computer operating system that you're using to compile your application.

The setjmp() and longjmp() implementation is only used when setting GFX_CPU to GFX_CPU_UNKNOWN. In all other cases, specially designed context switching code is used. Can you please tell us which version of the µGFX library and what compiler you're using? All the processor specific context switching code for all ARM Cortex-M family processors have been completely rewritten a couple of months ago by @inmarket to prevent compatibility issues with the ARMCC compiler.

For completeness: It's GFX_CPU_CORTEX_M3

This is very interesting - we never had that problem before. So far the GTIMER issues were always related to task switching problems... Can you please set a breakpoint and step through the code to figure out where it fails (and why, if possible)?

I assume that he kept his config and didn't use the one that is part of the demo (which you really should, @dewees) which might have the GTIMER module enabled which in turn would initialize it upon gfxIni().

Wait... does this mean that the /demos/modules/gos/threads demo is working correctly (the threads are running in parallel) if GTIMER is not used? I see that that demo only creates two threads. If those are working, can you please add a third (and maybe fourth) thread and test again? If the scheduling really is working then I can't think of much else other than a too small GTIMER stack (configuration file!) or a blocking thread (note that RAW32 is a non-preemtive system, you have to use gfxSleepMilliseconds() (or gfxYield()) in your own threads to give other threads a change to run. Running the test as described above as well as running the /demos/modules/gtimer demo as you suggested should help tracking the issue down.

No, that is not how it works. You're selecting the underlying system that you're using. If you enable GFX_USE_OS_FREERTOS then you actually have to run µGFX on top of FreeRTOS. Please follow the advice that @inmarket gave you.

Great work at getting this almost working, @nquantum! I'm really sorry that we can't help more right now, we're drowning in work! Usually we can give some pointers in order to push you towards the correct direction but unfortunately we have never worked with this DSI/MIPI stuff ourselves before. In fact, @nathan.loretan might be the most experienced one with that around here. Maybe he can give you a hint He certainly has the display working in the video mode and I suspect that the offset issue is based on a timing issue (eg. wrong display panel parameters) which would be the same for the video and the adaptive command mode. I'll ask him to check this out. My recommendation is to get the correct timings out of the ST board files. I have them somewhere in an uGFX STM32LTDC compatible manner on my computer but that computer is currently not where I am.

Hello @dewees and welcome to the µGFX community! When running bare-metal you're using the RAW32 port. That port allows running µGFX without modifications on any 32-Bit platform. That port relies on the use of setjmp() and longjmp() functions of the c library to implement a very small and primitive cooperative (non-preemptive) scheduler. Unfortunately many c libraries that come with embedded compilers are known to contain bugs in the implementation of these two functions. It appears that they simply don't get tested because they are a lot less common than stuff like memcpy() and similar. However, they are still the best way for us to implement a generic, platform independent scheduler that is very small and simple but provides everything required to implement a full blown GUI without any draw-backs. Even some larger players like ARMCC have that/these bug(s) in them but they simply don't seem to care to fix them. If you give the forum search a quick try you'll see that this is a very common problem reported here. To workaround that problem we provide custom schedulers for certain processors. That is why the GFX_CPU macro exists (doc). For example, the entire ARM Cortex-M series family is completely supported. Unfortunately there's currently no custom scheduler that would be compatible with the Xilinx Zynq-7000 processor. However, it is fairly easy to create one. After all only the context switching functions need to be implemented which is just a matter of putting the current processor context (registers) onto the stack and getting it back from there again. You can have a look at the implementations of the Cortex-M context switching code at /src/gos/gos_x_threads_*.h. Basically you'd have to write the same code for your processor (which appears to be an ARM Cortex-A compatible one and therefore quite straight forward). Note that the Cortex-M implementations contain code for different compilers so you can simply divide the code you see by two to get an idea of what needs to be done. You can divide it by two again once you realize that we implement the context switching functions for both the Cortex-M cores that come with and without an FPU. But before you do that, you might want to check whether that is actually the problem (it's very very likely that that is the problem provided that you correctly implemented the two functions to retrieve the systick and to convert milliseconds to systicks). You can simply run the GOS threads demo that you can find under /demos/modules/gos/threads to see whether the context switching is working. If not, you'll either have to change your toolchain to one that provides proper non-bugged versions of setjmp() and longjmp() or you have to implement the custom context switching. We are very happy to help with the latter if you have any questions. Please don't hesitate to ask if you have any further questions. We're really happy to help wherever we can!

@AndyD: I'm sorry, I haven't read your post carefully enough. The issue I mentioned is so common that that has become quite a standard response. Good thing that @inmarket already caught up on it

Hello Andy, This is most likely just a case of using the proper font. You tell us which font you're using but I assume you're using one of the built-in fonts. These built-in fonts have a very restricted set of glyphs (characters) in them. Each glyph takes up memory, every glyph that is in your font that you don't use is therefore a waste of memory. When I remember correctly the built-in fonts are only including characters from A to Z (both upper and lower case) as well as the numbers and the most common symbols (punctuation marks). You can take any font that you like (the built-in ones are DejaVu Sans) and set the filter range when converting it to include all the glyphs that you need. Note that the online font converter only allows setting one filter range. You can use the offline font encoder that you can find in the /tools directory of the µGFX library directory to convert your font using any number of any arbitrary filter ranges. This means that you can simply cherry-pick single glyphs or whole ranges. I hope that helps. Please don't hesitate to ask if you have any further questions.