inmarket

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.

This driver has now been officially added to the repository.

Thankyou for posting your driver. It is appreciated. When I get a few moments I will look at adding it into the official repository.

In the board directories for the stm32 boards there is a file called stm32....sdram.c. This file is responsible for initialisation of the sdram chip and setting the address (in conjunction with the stm32ltdc_board.h file) for the framebuffer. As you are defining your own board the equivalent of these files will obviously be written by you for your board. In those it will be a simple matter to tell it to use in internal ram address for the framebuffer. What you will need to watch is the size of the framebuffer required for ltdc. If it is put in internal RAM that may leave you very short for stack, heap and other program data. Framebuffers tend to be big in comparison to embedded processor internal ram. A few things you can do that will help conserve RAM... 1. Use a 16bit pixel format eg rgb565 rather than rgb888. This will halve the size of the ram framebuffer. 2. Only use the one display surface. The ltdc controller supports 2 surfaces although uGFX only uses one. Don't attempt to change the driver for the 2nd surface - that will double the framebuffer size. 3. Don't use too large a display. A 320x200 display will use a quarter of the ram required for a 640x400 display. Calculate carefully your ram requirements. Don't forget the stm32 has multiple stacks - both process and interrupt. uGFX also adds its own timer thread stack (typically 2K). You will also need some space for heap. If you can't make it all fit consider not using the internal stm32 ltdc (or even using a cheaper version of the stm32 processor without the builtin ltdc controller). Instead use a display with its own inbuilt controller and framebuffer eg ILI9341. There are plenty available and they are really cheap - often cheaper than displays without a controller atleast for low count manufacturing runs. It may even save pins. If you are worried about speed just stick with a parallel interface. Particularly using the fmsc bus can make this an easy and fast option. I hope that helps.

Change the settings in the uGFX makefile to tell it you are running ChibiOS v3. V17 is effectively the same as v3 (they changed their numbering scheme). You can also use the "git" version number in the uGFX nakefile. This makes changes that should allow the latest git version of ChibiOS to compile. Note that ChibiOS change things often, even in "stable" versions so hopefully the git defines still work - they did as of a few months ago.

Better to ask on the ChibiOS forum as it is a ChibiOS provided file.

Congratulations on solving it. As you found out - avoiding C++ compilation was the solution.

By way of explanation of the compiler bug and looking at the referenced link there are a lot of people defending the undefendable and repeating the mistake that gcc have made in interpreting the C standard. An explanation here will hopefully help future readers. First let me make it clear - I am not talking about a C++ compiler. C++ is a different language with different rules. C is not equal to a limited version of C++. There are some language constructs and rules that are quite different and this is one such area. In C a "const char *x" means x is a readonly pointer to something (in this case a singular character). The something cannot be altered and the compiler will prevent you from altering that data via that x pointer. You could assign x to a char * pointer via a cast and the compiler should let you then try to edit the data via the now char * pointer. A "const char y[]" however is different. This says that y is the address to an array of characters that is readonly. It is not the address that is readonly (persay) but the character data itself. Typically the compiler will put the character data into real readonly storage eg the instruction space or ROM of the cpu. As such assigning a const char * pointer to y is allowed. Assigning a char * pointer to x however should generate an error even via a typecast as the data should never be alterable. Obviously there are ways around it (typecasting to const char * and then casting again to a char *) however the principle applies - x is treated as real constant data not just as a pointer to data. This semantic difference is important in a couple of situations - 1. On parallel processing where this distinction can affect parallelism, and 2. When decisions need to be made about where the data is stored (eg ROM or RAM). Situation 2 is particularly important when compiling for embedded platforms (and therefore for uGFX). A "const char * const x []" therefore is a const array of const char * pointers. Not only is each stored pointer pointing to readonly data, the array of pointers itself should be readonly (and therefore probably stored in ROM by the compiler). Where gcc got it wrong is in not understanding the slight differences in semantics between the two consts. If you leave one of the consts out gcc (and most but not all compilers) will promote the const in both directions ie both the storage and the pointer will be treated as const. This promotion is strictly not correct semantically but it is not against the rules (it is not clearly defined) and it definitely usually reflects the intent of the programmer and therefore cuts down unnecessary warnings so I have no complaint about that. What annoys me however is when the compiler complains about the strictly correct syntax. Note in C++ that promotion is defined and therefore in C++ the double const is not valid. Note this double const only makes sense on array definitions. It does not make sense on singular variables as a singular variable name cannot be used synonymously with a pointer. Only for arrays is the variable name actually the address of the data not the data itself.

Interesting when a compiler bug expressed as a warning in the original compiler becomes a fatal error (and still a bug) in a derivative compiler. That section of code is being rewritten for other reasons in V3 so it will go away there. Unfortunately though not for the keyboard layout definitions. I will have to build a special exemption for gcc derivitives. Note: with the standard arduino IDE this is not a problem last time I tried and it isn't a problem for most gcc derivative compilers because they only generate a warning. For whatever reason UECIDE have decided to convert this warning into an error therefore compounding the seriousness of the compiler bug.

GCC should output an error number for the duplicate const error it is outputting. If we know that number we can add a #pragma to turn it off. Unfortunately I don't have time to research it right now but I may be able to look on the weekend if you haven't found it by then.

There are several stacks associated with the STM processors. The best way to check them is to look at the chibios linker file. It may (for example) be the interrupt stack you are exceeding which would explain why increasing the main stack didn't help. uGFX also has its own stack for its timer thread. By default it is set to 2K which is plenty for any of the uGFX demos. There is a gfxconf.h setting to change that if you desire although that definitely won't be necessary for any of the demos.

It also looks like your IDE is telling GCC to treat all warnings as errors.