inmarket

There are two running models with uGFX... 1. gfxInit (optionally) initialises the OS, the display, heap manager etc and then returns. Your application then runs its own event loop etc. 2. gfxInit does the same initialisation as above and then calls uGFXMain(). You put your event loop etc in uGFXMain(). With FreeRTOS the operating system initialisation never returns to the caller thus option 1 is not possible if uGFX is required to initialise the os. It should actually give you a compile error if you try this. The solution is to either tell uGFX not to initialise the OS as you will do it yourself in your main() or to alternatively use option 2. Option 2 is also the preferred methodology for all uGFX programs from V3.x (when it is released) as this works nicely with OS's like FreeRTOS and with systems like Arduino. From memory setting GFX_OS_CALL_UGFXMAIN to TRUE is the way to use option 2. In your main() just call gfxInit - it will never return. Define function uGFXMain() which contains the body of your application. No need to explicitly initialise FreeRTOS, uGFX will do it for you.

The obvious problem here is the time delay between the background re-render and the text being redrawn. These are several choices that could reduce that time: 1. Break up your background image so that no part overlaps a label. Then use image background labels. This way the image under the label text is small and there is no overlapping. 2. As Joel suggested above use an offscreen pixmap. This is more complex, takes lots of RAM and slows refresh but removes the visual gap. 3. A custom widget that effectively does option 1 above but in a single widget (as Joel also suggested). I suggest #1. It is the easiest and reduces the whole background display needing to be updated when you change a label. Overlapping windows are not handled efficiently in uGFX because of its lack of complex clip regions.

No. You can however do a simple test for just the object you are after when you get an event. The source object is one of the fields in the gwin event structure.

I'm sorry, I don't understand your question.

That is because a slider can be cancelled by moving your finger off the slider while still touched. By default the slider only returns an event when its value is truly set which is on release. To get the extra events it is either a listener flag or more likely a slider init flag (I can't remember which). See the slider demo program because it shows how to get the extra events.

The method described in the wiki is not the only way of doing it, it is just a good way if you are intending to use uGFX in multiple projects with different hardware/configurations. If you look in the board/arduino directory (I think) of uGFX there is described the most basic way of doing it.

../uGFX is obviously not the correct path to your uGFX repository directory. Note Linux paths are case sensitive unlike in windows.

Arduino is now well supported using the single file make mechanism. There is a wiki article on the best way to use it across multiple Arduino projects.

The Linux kernel can provide a "framebuffer" device for supported hardware. Usually X takes over from the framebuffer as the desktop is started. If X is not installed (eg on small embedded devices) or is not running then the framebuffer device can be accessed directly by uGFX. The framebuffer driver is compiled into the Linux kernel and is used by Linux itself to display the penguin logo during boot. Note: if X is running the framebuffer is not usable as X itself takes over control.

Try again now. Joel has fixed a PHP problem this afternoon. I haven't heard what the specific issue was.

Also read the error message. It is claiming it can't find compiler_gcc.mk which is part of the uGFX repository and required for makefile building. Perhaps you haven't set the path to the uGFX directory correctly in your makefile.

Personally I don't like the SDL Linux port. Try the X port. While it is slower it is much easier to build and is fully compatible with a normal Linux desktop. For a real target embedded Linux platform you would drop both X and SDL and instead use the framebuffer and linux-event drivers.

If you look closely you will see that this is a recv error. The most likely cause of this is a partially broken internet connection. I know the uGFX servers are fine - I use them all the time successfully and I reside in Australia - the other side of the world to the uGFX servers. This is most likely a problem with your internet connection. Try doing a traceroute to the uGFX server. Also check your MTU settings as small packets might be working giving the appearance of a working internet connection while large packets might be getting lost.

Unfortunately I am unable to view the images as I am on my phone but based on your description both solutions would be possible. My opinion is that creating this functionality using existing buttons, containers and window objects would probably be easier as all the low level stuff has already been handled - you only need to deal with the GUI animation.

Sorry for the delay. Try replacing the _read() routine in the Linux event mouse driver with the following code... static bool_t _read(GMouse* m, GMouseReading* pdr) { int i; int rb; struct input_event ev[64]; privStruct* priv; // Retrive the private area struct priv = (privStruct*)(m+1); // Assume not touched pdr->buttons = priv->lastReading.buttons; pdr->z = priv->lastReading.z; pdr->x = priv->lastReading.x; pdr->y = priv->lastReading.y; // Read rb = read(priv->fd, ev, sizeof(ev)); // Parse if (rb > 0) { rb /= sizeof(ev[0]); for (i = 0; i < rb; i++) { switch(ev[i].type) { case EV_KEY: switch(ev[i].code) { case BTN_TOUCH: if (ev[i].value == 1) pdr->z = 1; else if (ev[i].value == 0) pdr->z = 0; break; case BTN_LEFT: if (ev[i].value == 1) pdr->buttons |= GINPUT_MOUSE_BTN_LEFT; else if (ev[i].value == 0) pdr->buttons &= ~GINPUT_MOUSE_BTN_LEFT; break; case BTN_MIDDLE: if (ev[i].value == 1) pdr->buttons |= GINPUT_MOUSE_BTN_MIDDLE; else if (ev[i].value == 0) pdr->buttons &= ~GINPUT_MOUSE_BTN_MIDDLE; break; case BTN_RIGHT: if (ev[i].value == 1) pdr->buttons |= GINPUT_MOUSE_BTN_RIGHT; else if (ev[i].value == 0) pdr->buttons &= ~GINPUT_MOUSE_BTN_RIGHT; break; } break; case EV_ABS: switch(ev[i].code) { case ABS_X: if (ev[i].value > 0) pdr->x = ev[i].value; break; case ABS_Y: if (ev[i].value > 0) pdr->y = ev[i].value; break; } break; case EV_REL: switch(ev[i].code) { case REL_X: pdr->x += ev[i].value; break; case REL_Y: pdr->y += ev[i].value; break; } break; } } // Store the current reading priv->lastReading.x = pdr->x; priv->lastReading.y = pdr->y; priv->lastReading.z = pdr->z; priv->lastReading.buttons = pdr->buttons; return TRUE; } Hopefully this will add support for a mouse. Note this code is untested and still doesn't display a mouse cursor. Let us know how it goes.

This is the same problem as above - just a different symptom.

Also uGFX supports calibration. It is not turned on normally for the Linux event mouse driver but that is only a flag in the vmt structure in the driver. Change that flag and you will have calibration support.

If you are getting this font compatibility message it indicates that you haven't set up your build project correctly. In particular it is including directories in the build it should not be including. If you search the forum you will find other posts relating to this 2nd problem along with solutions. I would also suggest that you reread the wiki articles on how to build uGFX.

The stmf100 series chips are pretty low powered for such a large display. You will notice it in particular with larger images and full screen redraws. Fortunately you are using a graphics controller with its own framebuffer which will reduce bus bandwidth requirements. As Joel said, it is possible to use the same bus for the flash, it just may slow certain operations. My thoughts are that it should be fine provided you are not trying to execute code from that flash or do large block fast DMA from there. In other words using it for resource storage (eg fonts and images) should be ok.

This might be a problem with the amount of memory allocated for the history buffer. There is a configuration variable that changes how memory is allocated. In one case it will allocate enough memory to cover the entire window, in the other case it allocated a proportion of that based on a fill percentage for the window given that windows seldom are 100% full of characters. Note that this calculation is done when the window is created. If you change the window font to a smaller font then the memory allocated may be insufficient for a full screen. In any case, the buffer not being large enough will not cause crashes. It will just forget earlier data (contents at the top of the window).

There is no other repository with images etc. We simply used the demo image programs in the repository and just changed the image to display and then visually compared that with the sample output provided by the image suite. From memory there are good suites I found for BMP, GIF and PNG. A simple Google search should find them. The building of demo programs is development platform and target platform specific which is why no build makefile is included with the demos even though the source code itself for most demos is platform independent. Instead we have a generic gmake based makefile that will work for most platforms with minor tweaks for each platform. For example look in /boards/base/stm32f429/examples. You will see our generic makefile. This can be customised for any platform (Dev and target device and embedded os) very simply. In particular there is one variable to set to build any particular demo for the specified platform. All the complex supporting files are in /tools/gmake_scripts. There is a good wiki article on the website on doing a first time build under windows. Of course using a makefile is only one way to build uGFX. Many people use our "single-file-make" system particularly with IDE's. This method however does have some functionality limitations (to be fixed in v3). So, for a automated building and testing something based around our generic makefile would be a good start. The test Dev platform and target platform would need to be specified - my suggestion is it should support Linux/Linux and win32/win32 as programs built for a different target device would be hard verify correctness. I hope that helps

Thank you for your kind comments! With regard to the image decoders, yes the JPG decoder is the odd one out. It was recently added based on contributed code. It is the only decoder that currently requires full in memory decoding (rather than decoding as it is being displayed). It is also the least tested of the decoders. It is basically there for completeness until it can be rewritten to be more consistent with the other decoders. Whilst my primary effort is currently on the upcoming uGFX V3 which is concentrating on the GDisplay/GDriver interface I hope over Christmas to be able to clean up the JPG decoder. With regard to test suites for the image decoders, all the decoders except JPG (and native) have been run against image suites during development. These image suites were not added to the uGFX library itself for a few reasons 1. They are of little use to most uGFX users, 2. There were questions regarding licensing that were created by including them, and 3. They are freely available elsewhere on the internet. Automated unit testing is something that is sorely missing currently in uGFX. Whilst we have a good range of "demo" apps that does not constitute proper unit tests. The reason for this is currently just resourcing. uGFX has grown quickly from a hobby project so there are still many gaps. With regard to your ideas for contribution - we would love it! We are happy to provide assistance wherever we can to help and are happy to change aspects in order to achieve improved development rigor. Regarding alpha blending and APNG, one of the difficulties currently is the lack of support for alpha at the GDISP/GDisplay interface. Whilst doing manual alpha blending is possible by reading back from the display surface, many displays do not support this. To date we have tended to cheat in these situations by only alpha blending when blending against a constant background colour and using an alpha cliff in other situations. In uGFX V3 we are adding alpha channel support into the GDISP/GDisplay/GDriver interfaces. This should make alpha blending and APNG much more easily obtainable. It was the intention that some time after uGFX v3.0 that the image decoders would get some rework to use new GDISP capabilities such as streaming support in order to again reduce resource requirements and improve speed. Any help you can provide would absolutely be appreciated!

uGFX doesn't decode the whole image into RAM (unlike most image libraries) except for the JPG decoder. Instead it decided on the fly straight from the encoded image in flash. Each of the image calls returns detailed error information if it fails. Use your debugger to determine what the error code is. I suspect that your problem is not enough heap memory. GIF images take a minimum of 12k RAM while they are decoding (it is due to the memory requirements of the compression algorithm) so when you only have 16k total heap that makes things VERY tight which is why you can get it to work raw32 but not with the overhead of freertos. That 12k is only used while decoding an image so you can use that same 12k to decode one image after another with no problems. I would suggest that you use BMP images, perhaps rle encoded and with the minimum number of bits possible for your image in order to save space. GIF, PNG, JPG images will all require too much decoding ram for your situation.

This is because of cpus speed. Decoding PNG images and other similar tasks are very CPU intensive. Also 640x480 is a lot of data to push. The f0 chip also does not use caching. To give you an example of the difference it can make, the f4 also doesn't have a cpu cache whereas the f7 does. The f7 at the same clock speed appears about twice as fast as the f4.

Another thing you might want to look at... There are some forum posts of a person who updated the stm32 ltdc driver to support a 2nd page which was drawn into by uGFX rather than to the primary display surface. They then used the display sync period to DMA data from the 2nd buffer to the primary display surface using the DMA2D controller in the 746. This prevented tearing and allowed uGFX to work without the need for pixmaps.