inmarket

Pixmaps cannot be built with single file make and the current uGFX - the build requirements for multiple displays (and pixmaps is effectively a 2nd display) are just too complex for single file building. One such issue is the symbol space. Most drivers use similar or identical function names resulting in it being impossible to build two or more drivers in the same compilation unit. All hope is not lost however, in the upcoming uGFX v3 these issues will be resolved by a redesigned driver interface. In v3 makefile builds will internally use single file make. Having said that, using makefile builds in eclipse is very easy - just start a makefile project. This is actually our preferred and best supported mechanism. Creating a project using the eclipse automatic makefile building process and intergrating a custom uGFX makefile is I believe possible but NOT simple requiring careful modification of the automatic makefile.

If you look at the widgets demo one of the buttons in the widget demo flashes.

uGFX, like all modern graphics systems, assume 1:1 pixel ratio ie the width of the pixel is the same as the height of the pixel. Historically this hasn't always been true e.g. I think EGA had non-square pixels. The big advantage of VGA when it came out was its high resolution (comparitively) and it's square pixels. Unfortunately it looks like your display is a display without square pixels. I am guessing it is a lower quality cheaper display - certainly it has a design problem and shapes will be warped in whatever orientation you draw, it is probably just more obvious in portrait mode. The only way around this is to take the distortion into account when you draw e.g. use an appropriately sized ellipse rather than a circle.

We will look to add something like a GFLASH directive in ugfx v3. Note the esp8266 has similar problems as the flash is only 32bit addressable, not byte addressable, even for byte level data. To work around the compiler places everything in RAM.

It should be possible to tweak the linker scripts as all the __flash directive is doing is to mark the data to be put into a special linker segment.

When gcc compiles it places static const data into its own linker segment. It is up to the linker, the link map and the flash loader to ensure that is put in flash rather than RAM. On most platforms that results in it being in flash. An example where it does not is the esp8266. For that processor everything is put into RAM because of addressing restrictions and alignment issues with the flash. On your processor you will need to examine the linker scripts to see where static const data is put. In ugfx we define fonts as static const data and therefore expect it will arrive in flash. If it is not on your platform you may need to play with your linker scripts.

Make sure you are using the latest repository version or at least v2.8 of uGFX. There were significant fixes to do with dma and the cpu cache between v2.7 and v2.8

If you are testing on Linux then simply add fprintf's to stderr. When you run your program redirect stderr to a file eg prog 2> file You can then use tail to see the contents of the file as it is executing.

@Stefan can you please send us the changes you made to ugfx. It has always been our intention to put more work into the window manager but we just haven't had time. Your work could possibly save us a lot of that time we never seem to have.

That sounds like an io pin may not have been initialized correctly and you therefore are not reading correct data.

gtimer runs on its own thread. This means that if one timer job takes a long time then that will definitely delay other timer jobs that are ready to run. For a cooperative os like raw32 the same also applies to work done in any other thread. The key point here however is that the delay caused is only after a task is ready to run. It doesn't delay when the task is ready to run. E.g... A timer task at 35000ms system time is set to run in 100ms. This means the task is "ready" to run at 35100ms system time. No matter what else is happening in other tasks that doesn't change. The timer task will then be run at the first available opportunity after 35100ms system time. Having other busy tasks will only delay that first opportunity. The advantage of this is if you set a repeating timer then the cycle rate will average that period even if a specific timer event is delayed due to the cpu being busy doing other things.

As it works for your hardware we will make this a driver option in v3.0

This is a problem in the SDL mouse driver. If you look at line 209 in drivers/multiple/SDL/gdisp_lld_SDL.c you will see that explicit touch support has been turned off with a #if 0. It looks like the reason that this has been turned off is because on some equipment (eg osx touchpads) the coordinates returned are completely wrong. It also looks like the coordinates can come in different forms (0 to 1.0, or 0 to screen size) depending on the SDL version although the code looks like it can handle that. You can try re-enabling that code - maybe it will work for you on your hardware.

Those message look like you are not using an arm version of gdb. Please make sure you are using the arm compiler gdb not the windows/Linux version.

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.