Joel Bodenmann

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.

All of these things sound like issues in the board files that you're using. As the library doesn't come with board files for that setup I guess you're using some 3rd-party board file, is that correct? We need to see your board files as well as images that show the problem in order to further help you with this. Please attach these things to your next forum post.

Hello @ronan_rt, We contacted you via e-mail to further discuss the quotation/offer on this.

It's correct that the RA8875 itself integrates a touchscreen controller. However, in many modules that one isn't used but a dedicated one instead. This also depends on whether you're using a parallel or serial interface to talk to the display controller. It's up to the manufacturer of the module that you're using and your own configuration. Currently the µGFX library only provides the basic display driver for the RA8875 - not for the corresponding touchscreen. However, it works well and is easy to implemented. We implemented a complete RA8875 driver for a commercial customer project that implements both the touchscreen controller as well as the advanced hardware acceleration - it works very well. Unfortunately we're not allowed to put the driver into the public µGFX library. Long story short: You have to write the driver yourself - but it's very easy as the interface of µGFX is very simple and there are tons of examples. Furthermore, we're happy to help if you have any questions. Alternatively, we can implement the driver for you as this is part of the services that we offer.

That is very interesting to know. I put this on our ToDo list.

Yes, @inmarket updated that demo. You have to grab the latest master branch of the repository. This is the corresponding commit: https://git.ugfx.io/uGFX/uGFX/commit/9360b2725035727262df05ae720654a48d620c69

ADS7843 / XPT2046 / TSC2046 / UH7843 , STMPE811, STMPE610 and the MAX11802 are the classic resistive touchscreen controllers which are all supported by µGFX. Additionally we have the "ADC driver" which is a driver that can be used when the four wires of the resistive touchscreen panel are connected directly to the ADC peripheral of a microcontroller. Is there something that you misunderstand or didn't you find something you were looking for?

Initializing the required peripherals is the job of the init() function in the driver and the init() function in the board file. The driver has to take care of doing driver specific initialization. In this case that means setting up the LTDC and other things that are required to use that driver no matter what actual board is used (eg. the pin configuration from one board to the other can be different although both use the LTDC driver). The board file init() on the other hand is responsible for initializing things that are specific to that board. Those are usually just the pin configurations. The images you're showing definitely suggest an issue with the clock setup. However, unfortunately I don't have time right now to dive into the datasheet and corresponding examples - that would take a lot of time. Could you simply have a look at the example that @Maytham and/or @inakto created? They have a working setup - it's just not properly integrated in terms of the driver level of uGFX but they are able to properly display things which means that they set up the clocks correctly.

Don't even think about doing that. That is a part private to the display driver itself. You must never touch that. There's a lot of stuff hidden that you don't necessarily see. Stuff like synchronization, grouped flushing, different redrawing modes and so on. If you tell us why you want to do that we'd be happy to tell you how to solve your problem or how to archive what you want correctly without breaking anything.

@vrollei Sorry for the late reply, currently having too much on our plate. As @inmarket mentioned it's very interesting to see that it appears to only happen with the '0' glyph. If you could print some A - Z and 0 - 9 set of that font (and a different font) to confirm whether it's just with the '0' or not that would be very helpful. At first I thought this might be an issue with the first read-back being inaccurate which would indicate requiring a dummy read. However, this really just happens with externally connected framebuffers where the parasitic charges haven't been discharged properly. Also, this can't be the case because your manual gdispSetPixel() / gdispGetPixel() test was successful.

Hello @viji s, We're happy to help you resolving this issue but we require a bit more information to do so. When I understand you correctly you're using the existing framebuffer driver, is that correct? Are you using pre-made board files for a known target/hardware or did you write your own board files? -> What hardware are you using? Additionally, pictures that show the problem would be very helpful. The framebuffer driver handles rotation internally by simply modifying the pixel address mapping and therefore there really shouldn't be any issues. However, bugs are always possible. A couple of pictures would be very helpful for us to see what is going on.

The rotation/orientation handling is not part of the board file - the driver is responsible for that. The board file is really just for sending the correct bytes over the used interface, physically controlling the backlight and things like that. Board files have no effect on orientation and other stuff like that. When I understand you correctly you get "correct" or "sane" output on the display but with the wrong orientation or even mirrored, is that correct? If so, look at the driver initialization sequence inside of the driver code (inside gdisp_lld_init()). The ILI9325 display driver has two bits called AM and ID (when I recall correctly) that are used to control the display orientation and mirroring/inverting. They are very well documented with good illustrations in the corresponding datasheet. Most likely you just have to change one byte value in the initialization sequence to get your display up and running. The reason for these problems is because it depends how the manufacturer of the display module connects the actual display panel to the ILI9325 display controller. The order of the physical wires dictate the correct settings for these AM and ID bits. As there are different ways to connect these wires different settings are required. For the SSD1963 driver we simply added an INVERT_X and INVERT_Y configuration macro. For µGFX 3.0 we will be using a different, more versatile display interface that allows coping with these problems. For now you simply have to adjust the AM and ID bits in the driver. I hope that helps.