inmarket

Another option with the raw rgb if the pixel format does not match your display is to put a windows bmp header on the front of it. You can then use the ugfx image support to display your image. Windows bmp format is the easiest to create from raw rgb values as it is flexible in pixel format and doesn't require compression.

First thing to do is to make sure that your raw32 threads are working properly as they are definitely needed for any touch and can be tricky with raw32. The simplist way of checking this is to make sure that gtimer works as expected. In fact your problem sounds like it could be an issue in this area. Once you know threading and gtimer is working then look in the demos and test subdirectiries (i can't remember which) as there are some test ugfx programs specifically designed for testing touch and getting the right parameters for the various levels and timings. Most drivers work well with the default values but the mcu driver can be a little more finicky as the software is getting no assistance from hardware intelligence.

The issue with needing the extra ../..'s is likely because you don't have the gfx directory on your include path.

KDS is not an environment that we have currently played with yet so you are breaking new ground here. As such I suspect the problem you are getting is related to how KDS has been set up to compile uGFX. The following discussion should help you track down where the problem lies... GDISPVMT_OnlyOne is a symbol that is created by gdisp_driver.h in the situation that there is only one display driver. The definition is the address of the VMT of that driver. gdisp_driver.h is also responsible for defining that VMT. For multiple display scenereo's the way of generating the VMT changes. Unfortunately it is all very complex. The fact that you are getting this error says that something is messed up with the way the driver or gdisp.c includes this file. I suspect from the renaming of the driver file gdisp_lld_ssd1963.c to gdisp_lld_config.c and your use of undefined(?) symbols such as RD_TFT in board_ssd1963.h that you have moved files from their original location in the gdisp structure or customised one of the files. It is highly likely that that is the source of the problem. The gdisp system is very sensitive to changes in this area and is complex in the way it handles its inclusions. This is due to its ability to be used in both single display and multiple display configurations. In single display configurations is auto-configures all the various display parameters for you. You should look carefully at the makefiles (*.mk) in each directory to understand what should and shouldn't be compiled and replicate that within KDS (if you can't use the makefiles directly). The master makefile that kicks everything off is gfx.mk in the gfx main directory. The source files in the gfx directory should not be modified or customised without considerable care - particularly around the gdisp area. In addition to the master makefile you will also need to include the driver. Look in the drivers/gdisp/ssd1963 directory to replicate the behaviour of the makefile for the ssd1963. The only driver customisation required should be to copy the board_ssd1963_template.h to your project directory, rename it to board_ssd1963.h, and then fill in the routines. Again the original structure and files under the gfx directory should not be modified. Note that the top level gfx directory must be on your compiler include path and your driver directory (drivers/gdisp/ssd1963) should also be on your include path. If you look at one of the example project makefiles (under the boards/base/xxx/example... directory) you will see the master makefile that we use to pull everything together.

Those additional files can be opened using gfileOpen() so there is no need to mark them extern. romfs_files.h is supposed to contain the structures and file information for the ROMFS file system (which is accessed using gfileOpen() or gdispImageOpenFile()). It is not meant to be a way to memory address arbitrary objects. The internal elements in ROMFS should never be accessed directly as it is entirely possible that the implementation of ROMFS may change in future. The items put into romfs_files.h are supposed to be accessed using the GFILE api. As an example, in future we may compress data put into romfs_files.h with the GFILE api decompressing that data automatically during read operations This is actually on my TODO list (although near the bottom) as it could save significant amounts of ROM/code space in the final application. In such a situation accessing the ROMFS objects directly using extern would not lead to usable data.

1. We will look at changing the order of those lines to get better detection. 2. The line-endings often change as it is moved in and out of git. We use both windows and unix for code development, and then git sometimes plays with the line endings as well. Have a look at how your git program is handling EOL's as that could be where the problem is. Other than that, when we get a copy of the IAR compiler we will spend some effort in removing some of these warnings - probably just by turning them off with #pragma's. 3. This is because we are defining structs as "typedef struct x {} x". Note that this is perfectly valid C, is used everywhere in all sorts of code (not just ours), and really should not be a warning at all when defined on the same structure. 4. This again is a compiler error because it is complaining about perfectly valid C that has real sementic meaning. Many common modern compilers make this mistake (including GCC). The semantic meaning behind the double const (take note where the const are actually applied) is: the structure GDriverVMT should be put into const (program/code) segment, AND the array definition should ALSO be put into const (program/code) segment. Modern compilers assume that they should both be const when it sees the first const statement and therefore complains when it sees the 2nd const. Note some older DSP micro's and some older super computers require different assumptions as arrays of objects are not necessarily directly addressable as the address of the first element - they must be addressed indirectly as the hardware requires this for management of the pipelining of the array operations. In that situation there are real differences between having just the first const versus having both const's. So, modern compilers often semantically treat this incorrectly and complain about the 2nd const when in fact they shouldn't as it is perfectly valid C with real meaning on some processors.

I just noticed this thread. The problem is related to a problem with the Keil compiler and the RAW32 gos implementation. It certainly explains why GTimer is not working. The problem is discussed here: https://community.ugfx.org/topic/380-f429discoveryraw32-hardfault-after-mouse-calibration/

There are currently known problems using the ARMCC compiler and its associated C runtime library with gos_x_threads.c See this thread https://community.ugfx.org/topic/380-f429discoveryraw32-hardfault-after-mouse-calibration/ for a more detailed explanation.

Unfortunately this is a known bug/problem with the Keil compiler - probably in the Keil C runtime library. uGFX requires a multi-thread system. RAW32 provides this by implementing a very simple non-preemptive (cooperative) scheduler. RAW32 provides this scheduler via one of two means... CPU specific assembly code, or Using the C runtime library setjmp() and longjmp() calls. See /src/gos/gos_x_threads.c for details. For Keil option 1 is not currently available as the assembly code has been written in GCC format which the Keil compiler does not understand. Option 2 does not work for Keil either as the setjmp and longjmp implementation in the Keil C library likely has a bug in it. Note that for option 2 to work the compiler must provide implementations for these two routines that match the code model and CPU of the compilation for the rest of the application. I suspect, but have not confirmed with testing, that that is where Keil is failing. There are five possible solutions: Someone sits down and writes Keil compatible assembly code that we add to that source file, and/or We get Keil to fix their C library implementation of setjmp() and longjmp() [unlikely], and/or We figure out how to patch our scheduler so that it works around the Keil library bugs (which may or may not be possible). Don't use RAW32 with the Keil compiler. Instead use ChibiOS or the Keil CMSIS operating system. Use the GCC compiler option in the Keil IDE rather than the ARMCC compiler. This may work - we haven't tested it. Our preferred solution is option 2, and then option 1. Both require more time than we currently have available although it is on our TODO list. Perhaps you would like to help in option 1 or 3 and contribute it back to the community? It is something we would really appreciate. When looking at option 3 look particularly at these things... The function calling convention or ABI. Make sure that stack boundary checking is turned off. Try with various levels of optimisation as it could be the optimiser that is breaking things.

The reason for this is that the font has too many glyphs in it and therefore the time taken to convert it is longer than your browser timeout. The full font with everything in it is still being generated - your browser is just giving up waiting for it. Filtering glyphs reduces the number of glyphs and therefore reduces the time to convert it.

Just a question - why mark anything in romfs_files.h as extern when they can (and should) be accessed using gfileOpen() calls?

fonts are defined using "static const". This generally puts them into code space (not RAM) and is the most efficient place for them to be on most micro's. Any situation where the font is stored in external flash (or an SD-Card) would require the font to be read back into RAM and then relocated before it could be used. The full font image would therefore be held in RAM for it to be used. This is not a simple job and we currently don't support this.

-O2 on GCC often produces bad code due to bugs in the optimiser. As the compiler versions go up hopefully it is getting better. Generally when compiling we only use -O1

If it is possible to write a block of bytes to the controller then ugfx will do it. The ILI9341 is considered a streaming controller. Normally you set up a window and then stream bytes individually into the window. If you want to accelerate block type operations using DMA then you change the driver definition to turn on routines for those block operations. In gdisp_lld_config.h you would add something like: #define GDISP_HARDWARE_FILLS TRUE #define GDISP_HARDWARE_BITFILLS TRUE and then you would define the appropriate driver functions to implement those calls. When those flags are enabled the gdisp drawing layer will use the accelerated block routines whenever feasible and the normal streaming calls when it can't. This way you get the best performance (non-DMA) for single-pixel/streaming operations and the best efficiency (DMA) for block operations. For an example of a streaming controller that implements these functions have a look at the Nokia6610GE8 driver. This driver does this to get around controller bugs rather than for speed but the method still applies. The Win32 driver also has defines that enable it to emulate just about any combination of controller support. This is useful to identify how GDISP uses the various calls but in a non-embedded environment where it is easy to debug and monitor. Not that you will need to ensure that any running DMA operation is complete before you start a new operation (either DMA or non-DMA). This will obviously (but unfortunately) involve busy polling. Note the best way to do all this is to create a new driver (say ILI9341DMA) rather than directly modifying the existing one as the changes are significant although the new driver can start as a copy of the original.

The reason you are getting the warnings about pixel reading requirements for anti-alised fonts is that you haven't turned on the pixel reading function. Whilst your hardware supports pixel reading it still needs to be turned on in your configuration file. This is done by defining GDISP_NEED_PIXELREAD as TRUE in your gfxconf.h file - NOT in the driver board file (it is too late by then).

But only Keil and certain version GCC compilers - not any arbitrary compiler

Your millisecond counter is perfect for the ugfx systick routines. You dont need to worry if the counter overflows as ugfx performs its time calculations correctly to ensure the overflows are handled without causing problems.

Can you please provide a compiler log so that we can see in more detail what is happening. As you are also not using the ugfx makefile please provide that too. Also please provide a cut down version of the c file you are compiling that produces the warnings. These should all be zipped and attached to a forum reply.

I use eclipse all the time however it has been set up for a couple of years now and i am very careful when playing with the config. It has been on my mind now for a while to find and select an approved ide/debugger but havent had time yet. The one's i have tried all seem to have some oroblem or another. Eg Keil - good ide/debugger, no makefile projects, keil compilers only Eclipse - good ide, frustrating debug, frustrating config Embitz - funny ide editor, some cross platform issues, strange debugger. Interacts strangely with makefile projects in terms of determing project dependancies. Etc etc.

It sounds like gfx.h is not getting included properly or something is playing with the macro definitions. 1. What make and compiler are you using? 2. Are you using the ugfx makefile system or something else?

Clever.

Very nice.

In terms of setting the style - it can actually make sense to set the style to the same style. An example is when the style is being updated and you want the widget to now reflect that changed style. Whilst this could also be done with a gwinRedraw() it also makes sense to do it this way. I will look at adding a macro for the tests you suggest.

This typo has now been fixed in the repository. With regard to the black screen... The RGB888 code was originally written for the STM32F426-iDiscovery board and at that point it worked. That code has been replicated into the generic STM32LTDC driver, updated for the F7 and then remerged with the F4 code. In that time it hasn't been retested in RGB888 mode so it is quite possible that it never worked for the F7 and we might also have broken it for the F4. Any help you can give us in finding and fixing the problem would be appreciated.

There are several reasons the X driver performs poorly... As X is a development and test platform only for uGFX and thus never intended to be used for production, no effort has been spent in adding accelerated routines. Accelerated routines are not that easy for X. There are some fundamental differences in the way the two GUI systems work and that complicates the writing of these routines. We are not really X programmers. Any code we produce for X is not necessarily going to be the best. If you would like to help in updating the X driver we would really appreciate it. The X driver has already taken us more time than any other driver we have written.