inmarket

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.

Thank you. It looks like the GCC bug rears its head again. I will look to see if I can add something to turn off that error/warning on GCC.

gwinImageOpenGFile

It looks like I got that wrong. It appears it always closes the file when the gwin object is destroyed. This is not so nice. While it could be changed to match the behaviour above that is a change in existing behaviour so I am reluctant to do that before the next major version.

The gwin virtual keyboard supports layout's. A layout is a structure that allows you to specify what key you want where. There is a gwin function call that allows you to set the kwyboard to use your custom layout. A numeric keypad should be an easy layout to define.

From memory... If you open the image using the filename in the gwin call it will automatically close the file handle when the gwinOmage object is destroyed. If you pass on already open GFILE to the gwin call I suspect the original file is not closed when you destroy the gwin object. The final reference however is the source code. Once I get time later I will check if my memory is correct but have a check for yourself too.

No, the image is not closed after drawing. You can redraw as many times as you like until either the image or the GFILE is explicitly closed. Have a look at the animated image demo which uses this to display sequential frames from a gif image.

Yes that should be logFile in the if statement.

You still haven't added the test for pe being NULL ie <code>if (pe && pe->type == GEVENT_GWIN_BUTTON)</code> What you have currently may be hard faulting because of the lack of the test for NULL.

Great solution Joel. Yep, that really is the best way to handle it.

Great work on creating your own widget! There are a couple of errors in your allocation of the text buffer. There is already a text edit in the gwin module. See demos/modules/textedit and demos/modules/gwin/virtual_keyboard If you compare the source for the gwin textedit to yours you will see the similarities and the differences.

Problem 1: When you called geventEventWait you passed a timeout patameter of 0. This means it can return immediately with a timeout if there is no event waiting. This makes geventEventWait return NULL. You have not tested for NULL and could hard fault on the next line on some processors. Problem 2: calling geventEventWait with a 0 parameter is not good on many operating systems as it does not allow other threads to run - particularly on co-operative operating systems such as RAW32. While FreeRTOS is not one it is still bad practice. Problem 3: You are calling gwinAttachToggle inside the loop. This call only needs to be called once and should not be inside the loop. The solution to the first two problems is to either specify a (non-zero) timeout and test for NULL, or use TIME_INFINITE for the timeout value. When using TIME_INFINITE geventEventWait will never return NULL. Solve those problems first and test again.

RGBA is not currently officially supported but is actually very easy to do for displays that support it. Just set the uGFX pixel format to RGB888 and define your own macro to define colors with alpha. This works because uGFX uses 32bits for a RGB888 color and doesn't mask the top bits when passing it to the driver. What is not supported is color mixing using the alpha values by uGFX itself. The alpha values can only be directly used in the driver.