inmarket

The next step is to use your debugger to find out where it is crashing. Raw32 using a GFX_CPU = GFX_CPU_CORTEXM3 (I think that is the right value - check the documentation to be sure) is a known working configuration for both GCC and Keil/ARMCC compilers.

See the discussion above about the GFX_CPU setting.

Not with the f7. Everything works fine with f4 boards. Note chibios v2 doesn't support the f7 chip at all so chibios v3/16 is the only possible option anyway for this hardware. We really need someone to debug this setup for us. Unfortunately we are currently just too busy and it is considered lower priority for us as other operating systems (eg freertos, keilcms and raw32) have been tested and work with this board. As mentioned before, the symptoms sèem to indicate that chibios is somehow preventing proper initialisation of the hardware but only for f7 boards.

Replace the printf's in the thread demo with something you can see eg toggle a led. Most embedded platforms don't have an output device for printf strings to go to. The printf's are only meant to be a debugging notification. If your debugger has a debug output api you could use that to show messages in your debugger.

The reason it is likely working without your touch driver is that is where it actually uses gtimer. It is on the first use of gtimer that it probably falls over and this is likely because of a crash in the schedular.

There is some incompatibility issue between the specific combination of chibios, ugfx and the stm32f746. The symptoms are exactly as you describe - a blank screen. The combination works perfectly with the stm32f4 boards but not the stm32f7. We have spent a lot of time trying to figure out what the difference is between that and the raw32 equivalent which does work. We have even tried doing a full raw32 init under chibios but even that doesn't work. Consequently we think that chibios is somehow disabling something in its init that is preventing the lcd from working even after the full raw32 init (but only for the f7 platform). We would love someone to get to the bottom of the problem. Unfortunately we have just run out of time to spend on it for now. PS. The reason the f7 didn't include all the necessary headers is because at the time chibios was using different incompatible versions of the stm32 hal header files. Chibios have since updated but we haven't had time to go back and fix the example makefiles. Thanks for providing that. I will get that into the repo as soon as possible.

A little trick that may help... The Cortex A processors are part of the Cortex range. If you find the closest M processor to the A series (i suspect the m7 or m4) you may be able to use the existing cpu specific scheduler just by changing your compiler flags to compile for that platform and set the GFX_CPU macro appropriately. From memory the threads demo contains no reference to gtimer at all so something doesn't sound right here.

It looks like you are running raw32. Raw32 relies on our own non-preemptive threading library. It is likely this is not working. Please try the demos/modules/gos/threads demo to check if threading is working. If it is not working the likely culprit is a bug in the c runtime library shipped with your compiler. Try looking at the GFX_CPU setting. By setting that appropriately we can often work around bugs in the c library. In particular specific cpu code is available for ARM Cortex M0..7 processors.

Nice catch in finding that it was a word wrap problem. That was the key to solving the problem. Pull the latest repository code and the problem should go away.

When uGFX does not have GDISP_NEED_UTF8 set to TRUE it operates in ASCII mode. This is therefore a problem with the definition of ASCII. Officially ASCII is characters ' ' (space) to '~' (tilde). For any characters outside that range ( > 0x7E or < 0x20) the operation is officially undefined. Although this is undefined, the characters above 0x7F work on your Discovery board because the compiler uses unsigned chars and we don't explicitly filter illegal characters. It doesn't work on Linux as that compiler uses signed chars. As you also found, the current operation was also inconsistent between drawing and width routines. Despite the formal ASCII definition, I agree that it is reasonable and more useful to expect that the full character range 1 to 255 works when in non-UTF8 mode. I have therefore made the change that you suggested and uploaded it to the repository.

I have updated the font demo. @vrollei, can you please run that demo (but with GDISP_NEED_PIXELREAD set to TRUE) and show us the results. If you are using an orientation other than 0 degrees please rerun the test at different orientations. I have tested on Win32 and everything appears to work perfectly. This tells us that the problem must be driver or hardware specific. I suspect that the problem might be something to do with FMSC RAM read timings as the framebuffer is in external RAM for the STM32LTDC and the problem is looking like a pixel read-back problem. @Joel Bodenmann, can you please have a look at initialisation for those timings please.

We will investigate. Thanks for preparing the pictures above.

We will add it to our list of bugs to solve. Hopefully i will have time to look at it this week. What it interesting is that it is only the zeros that seem to have the problem. It doesn't appear on the 1 or the colon. Can you please confirm if the rest of the character set has the problem. The reason I ask is to determine whether it is a font or drawing problem.

Using dma is unlikely to speed up the image drawing. The problem is not cpu cycles but the io speed of the sdcard itself so dma is unlikely to make any difference to the speed at all. What you can do to speed up images if you want to keep them on slow storage like the sdcard is to use the gdispImageCache call. This caches the image in ram to give speed as good as loading the image from ROMFS. The downside is obviously the ram usage. The truth is nothing beats using ROMFS (flash) for images. The only downsides are flash size and you have to recompile to change the images.

Not yet however a port would be very easy. The part to be ported would be the GOS module and it would probably only take a couple of hours. You might want to give it a try. There are plenty of other operating systems to use as examples.

The solution posted above is not a general way of increasing redrawing speed. The solution above was specific to that situation, the whole screen was being replaced by destroying one full screen container and replacing it with another full screen container. If that is your situation as well then the above solution will work for you. If not then there is unlikely to be much that can be done to increase the speed of your slow redraw. Check your spi speed. That is the area most likely to yield benefits in redrawing speed.

The framebuffer driver uses gdisp_lld_draw_pixel. Other display drivers use other low level driver calls. See the wiki article on gdisp driver models for more information. The reason you can't trace from gwinSetVisible or gwinDestroy right down to the driver level is because the actual drawing typically occurs on a seperate gtimer thread. Those calls simply set a flag to tell the update code that the windows need updating.

Images are not stored in ram unless you call gdispImageCache(). There are still some overheads in RAM however. It is unlikely that that would be running you out of ram. What you might be hitting however is the limit on the number of open files in GFILE. Check the config for the setting controlling the number of open files. It will be something like GFILE_MAX_FILES. Sorry for the ambiguity, i am on not replying on my computer.

The rotation you show does not make sense. It is not rotation, nor is it reflection. Eg the blue and green rectangle objects have been rotated by 90 degrees but display has not. Note the rotated distances are different in the pictures you show. The way to get the picture you desire is to change the coordinates of the rectangles you are drawing, not trying to rotate the display.

In your main.c after including gfx.h you will need to #undef Red, Green and Blue. Both the Stm32 hal and ugfx define these symbols but they unfortunately define them differently. As you are using the stm32 style reference to them using the undef after including ugfx.h should enable that to work. Typically we put such hardware specific code into a different source file that doesn't include ugfx.h. Your main.c can then be clean normal ugfx code.

All font files require space to encode. Large Chinese fonts are exactly that - large no matter how you encode them. It really then comes done to two factors, the number of glyphs and the efficiency of encoding. With uGFX the number of glyphs can be controlled by using the glyph filtering capabilities of the font encoder. The web interface allows a single filtering range but the command line utility allows unlimited filter ranges. I suspect this is where your problem lies - you are not sufficiently filtering the glyphs in your font to reduce the size. Particularly for Chinese fonts this is very important. With regard to efficiency, ugfx supports a couple of encoding schemes. Different schemes provide different results for various fonts. Particularly look at rle as that is likely to be the most efficient scheme. With regard to the xbf font format, yes it allows fonts to be used that don't fit in RAM. The RAM overheads for that however are still significant. The big problem with xbf fonts is that they require dynamic loading of font data while drawing. For SPI flash this is unacceptably slow especially for sparse character sets such as Chinese. Yes large fonts can be used but the price is unacceptable performance. xbf is a reasonable format to use if you have fast flash storage. uGFX in the same situation however does one better, the uGFX font can be stored entirely in addressable flash, has zero RAM usage and does not have the speed overhead problems that the xbf format has. So, the only downside to the uGFX format is that it can't be directly operated out of non-addressable memory such as SPI flash. The xbf alternative whilst it will work in that situation will have performance so bad that it is totally unacceptable in real life. The best solution for your problem is proper filtering and encoding of your font.

Using a font in SPI flash would not be directly feasible. The reason is that SPI flash is very slow and fast memory based access is required when the system is drawing the font. There are therefore two solutions to your problem... 1. Load the font from SPI flash into RAM. Whilst we have now provided the ugfx api function to add fonts from RAM we have not added the functions to load a font into RAM as there are fixups and relocations that need to occur. There might be old third party code on the forum to help with this but we have never tested it. Adding an official uGFX api for this second part is on the todo list but is not currently high priority. 2. Filter the range of characters during the font conversion to reduce its size. Antialiasing a font also increases its size so turn that off too. The font can then be integrated in the normal fashion. Unfortunately large fonts will always be large on any platform and fast access is required for drawing. I hope this helps provide some tips to make them work for you.

The new header files you can ignore. They are part of the internal working of the code. In your code make sure you define GFX_CPU_CORTEX_M7_FP to TRUE and the new code will automatically be included when you are using raw32. The GFX_OS_PREINIT_FUNCTION macro defines an optional name of a function that gfxInit() will call as part of its startup. This function could for example be used to initialise hardware. Using this enables the writing of main() functions that are ugfx only ie they contain no hardware specific code.

Don't add the mcufont directory to your include path. Instead add the directory that contains your gdisp driver to the include path.

The error messages say that you have configured a mouse/touch and a keyboard. In the same way you added a display driver yiu will need to add a mouse/touch driver and a keyboard driver or turn them off. I suspect you will want to turn off the keyboard (GINPUT_NEED_KEYBOARD set to FALSE) but want to add your touchscreen driver to your project build.