inmarket
-
Posts
1,296 -
Joined
-
Last visited
-
Days Won
4
Content Type
Forums
Store
Downloads
Blogs
Posts posted by inmarket
-
-
I will look at ensuring this init order problem for FreeRTOS is fixed for v3.0
The changes to fix it in v2.8 are too substantial for a branch that is on lock down except for bug fixes and new drivers.
-
We will look into it.
-
Are you running the latest git repository version of uGFX?
-
FreeRTOS should definitely have been inialised by then. The first thing gfxInit does is initialise the OS.
-
Yes using the latest version is a requirement for FreeRTOS as the FreeRTOS support before V2.8 was very buggy.
Yes your example code is close, just put the contents of GUIThread into uGFXMain. There is no need to create a seperate task for it as uGFX sets up a task to run uGFXMain. Returning from uGFXMain (as your code does now) is not supported and in some OS's may even cause a panic.
There is a gfxconf.h setting that determines if the OS is initialised automatically. By default it is and it requires an explicit define to turn that off. I can't remember off the top of my head the setting but it should start with GFX_OS_...
-
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.
uGFX support for USB mouse with BeagleBone Black
in Support
Posted
Using pixmaps with single file make is definitely not supported currently. Even though you managed to get it to compile and partially work the crashes you are seeing will be related to the build method. Effectively the display system is not being built correctly for that scenario.
This is all being fixed in uGFX V3. All uGFX features will be available with single file make.