inmarket

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.

uGFX is designed to work with most c compilers even unknown ones. The compiler list is largely to work around problems that particular compilers have. I believe that someone has already had uGFX working on the pic32 - search the forum for more information. In any regard, try it as it should just work. If you set GFX_SHOW_COMPILER to TRUE in your gfxconf.h file it should print out a message showing what compiler it thought it detected.

Time #1: GFILE_NEED_FATFS needs to be TRUE even if you are using GFILE_FATFS_EXTERNAL_LIB. Other than that you need to debug to find where gfxHalt is being called. gfxHalt is only called by uGFX when it detects you (or the hardware) have done something very wrong.