inmarket

Another way is to create a separate thread to run other tasks; or put geventEventWait into the new thread and use the main thread to do your other tasks. If you use this thread approach and are using a cooperative schedular (like in the RAW32 or Arduino ports) don't forget to run gfxYield periodically to give other threads a chance to run.

The 2nd parameter to geventEventWait is a timeout. You can specify a timeout in milliseconds for geventEventWait to wait for an event. If it hasn't found an event during that time it returns NULL rather than the event pointer. By placing geventEventWait in a loop with a suitable timeout period, and by handling the NULL that can now be returned, you can now do other things as well in the loop.

I am not sure of why doing it on the command line would differ from doing it as a system call. Perhaps one was settling the date forward and one was setting it backwards? Having said that, geventEventWait has a timeout parameter. You will probably need to debug in to find out what is happening. It sounds like you are using Linux (or some other unix platform) so it is entirely possible that changing the date has affected the timing calls for ugfx. Places to look... geventEventWait - obviously The sleep and other semaphore wait functions in the GOS layer The time handling in gtimer.

I don't know of anything that would cause this as all our fonts with the exception of the UI fonts have been created using that same tool. The UI fonts were handcrafted by us in bitmap format so that is why they didn't use the font converter. A few things to check... Check you are using the same version of DejaVu font. From memory our original ttf font versions are still in the gdisp/fonts folder. Mcufont supports multiple ways to encode a font and several different ways of optimising them. The way we built them is in a script called buildfonts.sh (I think) in that same directory. Note that script uses the command line font converter which can be found in both source and binary forms in the ugfx tools directory. The command line version contains features we have not exposed through the web interface. Internally the web interface uses the same binary. After you have tried the above options it could be that the ttf fonts in our repository have been corrupted. It can happen with win32 git where it tries to do incorrect newline conversions. In that case search the internet and find new versions of the ttf. Note: due to font versioning it may not be exactly the font we used. I hope that helps.

On many controllers rotation is simply not possible due to hardware limitations even in software with everything becoming painfully slow. Although ugfx supports software rotation it still requires certain hardware capabilities. In ugfx V3 we intend to broaden this capability to support rotation on just about any hardware. This however is not simple and requires a redesign of the entire gdisp module and the driver interface. In short, retrofitting generic rotation into ugfx V2 is just not possible. Some hardware support is required. When looking at your datasheet look for wording related to window direction or scan incrementing or wrapping direction. Most controllers support it in some manner, it usually comes down to whether bugs in the hardware make them usable e.g. see the Nokia6610GE8 driver for a list of some of the types of issues and workarounds.

Use the git repository version not the released 2.7 zip. The repository has all the latest updates including the fixes you need. http://git.ugfx.io

Same thing again. Your chibios halconf.h needs to be set to enable the required device.

You can always write your own filled arc routine that supports gradients. This however is very complex. The filled arc routine we currently have is the most complex routine in ugfx and was written from first principles when we couldn't find any other source anywhere to do the same thing.

The difficulty doing the routine as you describe (other than by images as suggested above by Joel) is the gradient filled arcs in the corners. Filled arcs are incredibly complex already.

The heap is used for other things as well. For example, the display driver structure itself is allocated on the heap. Working out how much heap is currently in use is possible but not that easy. Probably the easiest way would be to change the definition of gfxAlloc to record the memory blocks being allocated. You could probably do this most easily with a debugger by setting a breakpoint on gfxAlloc/gfxFree and then manually adding up the sizes as they occur. With regard to possible corruption, on most cpus the heap competes for space with the cpu stack. Typically the heap grows up from the end of the program variables and the stack grows down from the top of memory. If the two meet you end up with corruption and other problems. Each cpu and operating system take different approaches to dealing with the issue from simply ignoring it to full memory segmentation and protection. As this is completely outside of uGFX's scope this is something that we can't help you with. It is best to ask that in a forum specific to your cpu and operating system.

We always compile with -O1 on gcc. If it works with that but doesn't with a higher optimisation level then you have struck (yet another) gcc optimisation bug. Unfortunately the optimiser in gcc has lots and lots of bugs once you turn the optimiser level up. An optimiser is supposed to more efficiently convert your c code to assembly. If it changes what the code does that is a bug. Unfortunately we cannot cater for gcc specific optimiser bugs as uGFX is cross platform and cross compiler. Try a later gcc version and use -O1 or try a different compiler. All code released is tested and known working with gcc. By the way GDISP_NEED_VALIDATION prevents pixels trying to be drawn on the screen outside the screen area. It stops the gdisp drivers being fed out of bounds pixel data. It should never be turned off and the setting is likely to dissappear in V3. If that is culling your drawing it is likely you are trying to draw offscreen. The gdisp public API can be used regardless of what type of controller you connect - it just internally does operations differently depending on the type of controller. None of that detail however is anything you really need to worry about. gfxconf.h is a user supplied file, part of the user project. We give examples for our demos but it is not a part of the uGFX library itself as it is user project specific.

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.