inmarket

Ahh. That is what is going on. You are including the driver the wrong way. Unless you are using multiple displays do not define GDISP_DRIVER_LIST in your gfxconf.h file. If you are using the standard makefile you just specify the required driver in the makefile. It is clearly documented how to do that in the standard makefile. If you are using an IDE or some other build system you need to add the driver directory to your include path and the driver source file to the build list. Both steps are necessary. With what you are currently doing it is not correctly adding the driver. Note that if you are altering any source within the uGFX directory then you are doing something wrong. By the way, I think from memory the SSD1306 driver is a window region based driver. I therefore wouldn't expect it to have a setpixel routine.

That is likely to be sufficient for most applications. Some general helpful hints... To minimise your code space: keep your list of fonts small as they can only be used from flash. Use filtered fonts eg of the two UI fonts one is filtered and one is not. Don't use anti-aliased fonts as they take considerably more space. Make sure you turn off uGFX modules and options you don't need. Similarly with the ST HAL (that is huge). Play with your compiler optimization levels - too high and you get things breaking die to optimiser bugs (particularly with gcc), too low and the code expands. You can also play with link level optimisation. It can again yield some good gains at the risk of some strange compiling problems. With a minimal application it is useful trying turning uGFX options off and on to see what affect they have on code size. Be careful with images in flash and ROMFS because they can very quickly chew up available code space. Different image formats have different compromises between size, ram required to decode, and speed of decoding. Often simple images can be replaced by polygons in code leading to significant speed and code size improvements even though polygon support itself takes space. In the end a graphics library has a lot of work it needs to do and unfortunately that takes a fair chunk of code space. The advantage however is that application code can be corespondingly smaller because most of the heavy lifting has been done.

Note you don't need a driver bitblit routine for the gdispBitBlit to work. In the case of the ILI9341 a driver bitblit routine would not add much speed as uGFX uses the windowing commands to implement the high kevel bitblit routine.

If you are adding a blit call to the driver you need to turn its use on using the define in the gdisp_lld_config.h You would then use the gdispBlit function to send information to the driver to end up in that call. Note that while you can do it that way you must remember that uGFX can use the gdispBlit function and will expect it to work in the normal fashion. If you are changing the meaning of any of the parameters including the image pointer then you are not going to get what you want. Note the gdispBlit functions are fairly efficient for the ILI9341 so it is unlikely that you will see a huge improvement in performance over the standard driver provided you have the portion of the image being blitted already in RAM. @Joel Bodenmann approach above is probably the best way to handle it without having to make custom changes to the driver. Another way without making custom changes is to use the following strategy... 1. Load a block into buffer 1 using dma 2. Start the next block dma loading into buffer 2 3. GdispBitBlit the first block 4. Wait for buffer 2 to complete 5. Start the load of the next block to buffer 1 6. GdispBitBlit the 2nd buffer 7. Wait for buffer 1 to complete 8. Repeat from step 2. In all cases adding a bitBlit acceleration routine to the driver is likely to give little value. If you do add it make sure it operates in the standard manner or you will cause yourself a lot of unnecessary drama. If you really want your own special driver routines that operates in a non standard way the correct approach is to add it as a gdispControl command.

That flag is normally set in the driver setpixel routine.

Another way to avoid the uGFX supplied ffconf.h is to make sure your project directory with your required version of ffconf.h is before the ugfx directory in your include path. Thanks @cpu20 for sorting the one out.

There are several ways depending on your situation: 1. Your image editor can specify the background color as part of the png file format. Images like this will be displayed with full alpha blending. 2. If you are using the gwinImage object you can specify the background color using the widget style bacground color. Alpha in the image is handled using a cliff value. Alpha values above the cliff are plotted, alpha values below the cliff are left transparent. 3. If just using GDISP then the API link by joel above is the solution. The same cliff characteristics as for point 2 above apply.

Note the conflicts happen with the HAL DMA2D and LTDC code - neither of which is needed because uGFX initialises and controls those devices itself. As @cpu20 mentioned, including them just adds unnecessary code size.

Please listen. You are not looking for a function - you are looking for how the win32 code works. 1. When it gets a windows mouse message it just saves the values and then calls MouseTimerJab. 2. Sometime later the mouse code calls the mouse driver get routine which returns the values previously saved. You will need to follow a similar process. The code is not identical but the way it needs to work is. Please also take notice of the comments on interrupt driven touch devices. Generally they just do not work well.

The api you can find undocumented in gwin_wm.c. What @Steffan did has not been made publicly available by him.

That is not a function you should be calling. Whilst I may not have the Jab toutine name 100% correct (i am on my phone so can't look it up now) the method described above is the correct method. For example look at the Win32 mouse driver (part of the Win32 gdisp driver).

This is now incorporated into the uGFX repository. There are a couple of fixes relative to the version above: It is now ChibiOS V2 compatible too (ie dma cache support just does not exist) It now handles the bug where ChibiOS expects the buffer to be 32 byte aligned.

Support has just been added to the STM32LTDC driver for its 2nd layer. To support this change the default device pixel format has been changed to RGB888 instead of RGB565. If you want the old device pixel format (but not the 2nd layer support which requires RGB888) you can define GDISP_LTDC_USE_RGB565 as TRUE in your gfxconf.h. The background LTDC layer is the first display (as it always has been). The 2nd display is the LTDC foreground layer. To access the 2nd display uGFX's multiple display support must be turned on. If you have no other non-LTDC displays the easiest way to do this is to add #define GDISP_TOTAL_DISPLAYS 2 into your gfxconf.h. Note that as this requires multiple display support this currently can't be built using the single-file-make option. You need to use the makefile build method. All the existing known STM32LTDC board files in the boards/base directory have been updated with the correct LTDC initialisation tables to support 2 full size overlapping layers. This may of course be customised for your own project. The use of the 2nd layer increases the bandwidth requirements for your framebuffer RAM so also make sure that you have enough RAM bandwidth to make this work particularly for larger displays. If you define smaller layers in your layer initialisation tables uGFX will handle it. The layers don't need to be the same size or even start at the same origin. As alpha support is required for the foreground layer, ARGB support has been hacked into uGFX. At the moment this is only a hack. Full ARGB pixel formats will be supported as of uGFX V3. The current limitations for alpha support are: It only works with GDISP_PIXELFORMAT = GDISP_PIXELFORMAT_RGB888. It uses unused bits in the RGB888 pixel format to encode the alpha value. Note that this encoding does NOT match the standard ARGB format so don't try to hard code color values - they are unlikely to work correctly. The AHTML2COLOR() and ARGB2COLOR() macros have been added to correctly encode any semi-transparent value. The normal RGB color macros such as RGB2COLOR() and HTML2COLOR() work as per normal producing fully opaque colors. Note: an alpha value of 0 is fully transparent, an alpha value of 255 is fully opaque. This means that ARGB2COLOR(255, r, g, b) produces exactly the same fully opaque color that RGB(r, g, b) produces. Similarly AHTML2COLOR(0xFF00FF00) produces the same as HTML2COLOR(0x00FF00). Note: AHTML2COLOR(0x00FF00) produces a fully TRANSPARENT color!

Your new version has a BIG bug in it... You are returning the address of a stack local variable to outside the scope it is defined in. What will happen is that as you call other functions after the open call it could easily overwrite that stack area hence corrupting the FIL structure. Even worse, any update in the FIL structure could overwrite your call stack leading to strange symptoms and very likely hard fault crashes. If that new routine seems to work for you it indicates that something bad is happenning with your heap memory allocator thus affecting the operation of gfxAlloc and gfxFree. One likely cause of that is having defined too small a stack. Overrunning the stack could affect memory allocation which in turn affects the image.

The most likely reason the fixed2d calls work but the float3d calls don't would be that there is something wrong with the compiler or c library support for floating point for your cpu. This could be as simple as not setting the compiler options correctly for your cpu. The fixed2d routines will invariably be much faster anyway than floating point operations (albiet slightly less accurate ).

Create a pull request with your changes and we will look at integrating them next time we are in that area. Nice work on solving the problem.

This is looking like something that is specific to your implementation relating to fatfs and the devices you use. Can you please try cpu20's suggestion and if that doesn't work can you please debug down to find out why it is failing. GFILE is a thin wrapper around a number of file system handlers so typically (and especially for fatfs) the uGFX call translates directly into a file system call. The GFILE /fatfs interface is well tested on multiple platforms including ChibiOS (it was originally built on ChibiOS and that is why it is the only os with a predefined diskio interface). It will be interesting to see what you find.

Please send us details of the problem you found in the uGFX FreeRTOS code and we will update the repository.

Try reseting the file position back to 0 before calling gdispImageOpenGFile. I am not sure that gdispImageOpenGFile does that automatically and you have already read data from the file with gfileRead. I think the call is gfileSetPos(imgFatFile, 0). Also have you checked that imgFatFile is non-NULL after opening the file?

We will wait for the picture. It is also possible to compile this under windows or linux. It makes debugging much easier and seperates hardware from software issues.

Note the graph window does not store the graph data. After clearing you need to reissue the graph drawing commands. gwinRedraw() does not redraw the graph. Also, have you run the gdisp basics demo to ensure that the display colors and orientation are correct for your hardware? It is precisely to enable you to compare the results you got with what it should look like that we added the images to the demo directories.

Another way is to maintain multiple versions of the image pre-rotated.

There is no image rotation support in uGFX currently. If your display supports changing orientation you can work around this by rotating the display relative to the drawing canvas instead.

Another alternative is to setup your own listener to listen for mouse events. Your main loop would then pick up the touch events. If you are gwin (and it sounds like you are) then Joels method above is easiest. If you are not using gwin then setting up your own listener is the appropriate way.

This macro is now fixed in the repo. Any ideas on what is going on with the endian detection?