inmarket

The most likely reason the fixed2d calls work but the float3d calls don't would be that there is something wrong with the compiler or c library support for floating point for your cpu. This could be as simple as not setting the compiler options correctly for your cpu. The fixed2d routines will invariably be much faster anyway than floating point operations (albiet slightly less accurate ).

Create a pull request with your changes and we will look at integrating them next time we are in that area. Nice work on solving the problem.

This is looking like something that is specific to your implementation relating to fatfs and the devices you use. Can you please try cpu20's suggestion and if that doesn't work can you please debug down to find out why it is failing. GFILE is a thin wrapper around a number of file system handlers so typically (and especially for fatfs) the uGFX call translates directly into a file system call. The GFILE /fatfs interface is well tested on multiple platforms including ChibiOS (it was originally built on ChibiOS and that is why it is the only os with a predefined diskio interface). It will be interesting to see what you find.

Please send us details of the problem you found in the uGFX FreeRTOS code and we will update the repository.

Try reseting the file position back to 0 before calling gdispImageOpenGFile. I am not sure that gdispImageOpenGFile does that automatically and you have already read data from the file with gfileRead. I think the call is gfileSetPos(imgFatFile, 0). Also have you checked that imgFatFile is non-NULL after opening the file?

We will wait for the picture. It is also possible to compile this under windows or linux. It makes debugging much easier and seperates hardware from software issues.

Note the graph window does not store the graph data. After clearing you need to reissue the graph drawing commands. gwinRedraw() does not redraw the graph. Also, have you run the gdisp basics demo to ensure that the display colors and orientation are correct for your hardware? It is precisely to enable you to compare the results you got with what it should look like that we added the images to the demo directories.

Another way is to maintain multiple versions of the image pre-rotated.

There is no image rotation support in uGFX currently. If your display supports changing orientation you can work around this by rotating the display relative to the drawing canvas instead.

Another alternative is to setup your own listener to listen for mouse events. Your main loop would then pick up the touch events. If you are gwin (and it sounds like you are) then Joels method above is easiest. If you are not using gwin then setting up your own listener is the appropriate way.

This macro is now fixed in the repo. Any ideas on what is going on with the endian detection?

Redirect stderr to a file. Without that redirection there are all sorts of reasons you might not see the messages. Eg. Program 2> logfile

Oops. I will get that macro fixed today in the repo. Any idea what is causing the change in endian and size detection? I would appreciate if you could help us find that one.

Yep. If it is something like that that is probably a gating problem.

You have not fully initialised the Gwi structure. There is a gwin call that you can call to fully initialise the structure before you set the fields you want (sorry I am on my mobile currently so I can't easily look it up for you). Have a look at the gwin demos. While this may or may not solve your problem, it is definitely a bug in your existing code.

Set the mouse timer period to TIME_INFINITE. This is done in your gfxconf.h file. In yiur driver interrupt save the x and y and then call MouseTimerJab (I think that is what it is called). Some time later the mouse code will call your driver read function and you can then return the values you saved in the interrupt handler. The reason you do not want to turn off the mouse timer is that there are all sorts of other things that are also being handled by the mouse timer. Also using the timer jab allows all the heavy cpu processing and inter-thread communication to happen outside the interrupt handler. Note that in our experience touch controller chips are very unreliable when run with interrupts. They tend to freeze up, give wrong values, sometimes just forget to interrupt at all or generate tonnes of spurious interrupts. For chips that supply a "touched" interrupt the point it generates the interrupt is invariably nowhere near as good or as reliable as we can determine for ourself. That is why for all existing mouse drivers except a couple of emulation touch drivers we have not used the interrupts - they are just too flaky.

Please post the video of the problem, do the bandwidth calculations and the testing suggested to identify the area causing the problem. Those will make a large difference to the solution required. Personally my feel is that bandwidth could be a large part of this. What I suspect is happenning is that at certain periods the synchronisation between the cpu clock and say the ltdc clock or ram clock is causing the bandwidth available to be exceeded. Another poosibility is the gating on the ltdc pins causes the pins to be gated due to some other operation. When this aligns timing wise with the ltdc refresh or possibly the dma2d operation you get the symptoms you are seeing. An any case the tests suggested will give you a lot more information on where to look.

uGFX predates any interaction with the STM32 HAL. It was originally ChibiOS only and has become much more cross-platform over time. The RED, GREEN & BLUE macros were in uGFX well before the STM32 became a platform option. In retrospect those macro names are not the best either in uGFX or in STM32 HAL however they have needed to be maintained in uGFX for API compatibility reasons. So, from V3.x those macro names have been deprecated. They are still included by default in order to maintain compatibility with the uGFX V2.x API but that can be easily turned off with a setting in gfxconf.h In V3.x there are new names for these colors in uGFX. uGFX V3.0 will be released sometime in the next few months.

Great you found a solution. Well done!

First please post a link to a video showing the effect. It may help us recognise what is going on. Make sure the video shows both the starting of the glitch and the ending. My first thought was something fishy with the dma2d copy of the framebuffer. The real test is whether the uGFX framebuffer is corrupt during that period or the display framebuffer or neither. If the uGFX framebuffer is corrupt then we start looking at the uGFX drawing operations. If the display buffer is corrupt then we start looking at the dma2d code. If neither are corrupt then it must be to do with the display refresh from the display framebuffer. Probably the eadiest way to start is to use a hardware input on the board to trigger operations stopping eg pass 1, stop any uGFX drawing (but leave the dma2d running) after triggering the hardware input. Trigger it during the problem and see if the problem resolves itself as it normally would. Pass 2 use the same mechanism but just turn off the dma2d transfer. If neither of those stop the problem resolving itself after the 61sec then the problem is definitely display refresh related. Another thing to do is to do bandwidth calculations on your external ram. For a 800x400 display at high bit color depths check that you have plenty of bandwitdth to spare when doing refresh, a dma2d read, and a dma2d write from the external ram "simultaneously". Another thing to check is that before starting your dma2d copy you are flushing the cpu data cache. With the normal f746 driver this is not really required because even if you miss the data being flushed for this frame refresh you will eventually see it when the cpu flushes it out to cache other data. Those gaps are not normally visible to a human. By seperating the display and the drawing framebuffer not flushing the cpu data chache will be very visible as updates will be missed by the dma2d as the f7 dma does not flush or read through the cpu cache. I hope that will give you some hints on where to look.

Not currently. Support for arbitrary rotation is planned for V3.x although possibly not V3.0 V3.x will also be able to rotate the display regardless of controller support albiet with some performance degredation.

gtimerStop (&MouseTimer) and gtimerStart (...) to restart it. There are 2 complications... 1. MouseTimer is local to that C file. 2. The correct parameters will need to be passed to the gtimerStart. Let me say again, just stopping the timer is NOT a good solution and may not solve your problem. You really need to get to the bottom of what the hardware conflict is.

Gqueue, gtimer and some other modules are required as gwin is implemented using these support modules. You can easily tell, turn them off in your gfxconf.h file but leave gwin turned on. When you compile gwin will complain if what it needs is turned off and turn them on automatically for you.

I think just turning off the touch processing is unlikely to solve your problem. This sounds like an interaction between your DMA and the SPI/I2C interface used by the touch. Given the extra detail that you have now provided this is sounding like an interrupt priority issue, perhaps an interrupt stack overflow, hardware resource conflict, or something else directly hardware related and therefore outside the scope of what can be controlled by uGFX. Turning off the touch processing by the gwin system will still leave the touch polling active and thus the problem is unlikely to go away. It is a much more difficult job to turn off touch polling as this happens at the driver level and would require custom library modifications. If you really want to play with the touch polling (and I would suggest that you don't) - the place to look is in src/ginput/ginput_mouse.c. You will need to stop the "MouseTimer" and then correctly re-enable it again afterwards. Note that doing this will not have any affect on an interrupt driven touch device as they don't require polling. Most touch devices however are not interrupt driven (usually because interrupt capabilities on touch devices tend to be VERY buggy).

Let me suggest you start with one of the simple gwin demos. If you are having the same problem there it gives us a good idea on where to start to debug. If the demo works without the same symptom then the problem is likely in the way you have done something that is different to the demos. In that situation it is much harder for us to help without seeing all your code. In this forum we help people find problems relating to the way uGFX works. We are not a general debugging service although we can offer that on a commercial basis. If you are having problems always go back to the provided demos as they are known to work well on supported platforms and are easy for us to find os related issues on other platforms.