inmarket

At the moment the Dev list is already too long for V3 but a having a list may present some ideas that can be easily added as we go. The major differences with V3 are: 1. Drivers will have a new internal API and will be built using gfxconf defines rather than being seperatly linked in. Existing drivers will all be rewritten as the new driver API is not compatible with V2 drivers. 2. All standard features (including drivers) of uGFX will be able to be built using the single file make method. 3. There will be a new GDISP API and many new capabilities. There are gfxconf defines (on by default) that support existing V2 code except for certain multiple display situations. The new API supports all displays on a single drawing canvas similar to how windows supports multiple displays except that uGFX also supports overlapping displays. 4. There are certain symbol changes to fix V2 compiling issues on some platforms eg RED becomes GFXRED, TRUE becomes GFXON or GTrue depending on context, numerous gfxconf changes. Again V2 compatibility is turned on by default. In other words most existing V2 uGFX applications will recompile without changes while still allowing uGFX to move forward. Post v3.0 we will look at changing GWIN to use an internal event model that will fix many GWIN shortcomings and improve extensibility.

V3 has been a much larger task than was originally planned and we have had less time than we expected to work on it. Ahh Gowing pains Officially V2.8 is on lock down and we will only accept new drivers however there are some exceptions to that. The main reasons are that anything that gets added to the V2.8 branch needs to be ported to V3 which can significantly increase the work load for us. V3 has changed quite a few symbols to fix various V2 compile issues and some of the source structure and these always bite us in migrating fixes causing every change to have to be hand merged. The exceptions are: 1. Bug fixes 2. Drivers Having said all that - please submit your changes. Some we may decide to integrate anyway, some we may hold back. For that reason please submit them as one pull for each functional change rather than as one big one. One thing we are very aware of is how long V3 is taking. If enough Delta's build up for V2 then we may even release a v2.9 just to keep things moving forward. Without the pull requests there though, there is no pressure to do that.

I would suggest starting with one of the ili93xx drivers and modifying to suit as they are likely to be similar.

There are two errors here... 1. Your linker is saying it can't find _setjmp in your C library. This could be a broken C library or it could mean the decoration (the leading underscore) is not correct for your library. Look in gos_threadx.c and .h and gos_arduino.c and .h and play with the code that sets the decoration on setup. Note it is interesting that it is not complaining about longjmp. 2. The 2nd error is the undefined GDISPVMT_OnlyOne. This is indicating that there is no driver currently linked in or that the driver itself has been compiled incorrectly as that symbol is defined in the driver via a couple of macro functions produced in the header include system for the driver.

Unfortunately not. The job has proven much bigger than we planned and we have had much less time to work on it than planned. We are currently working on API, interface and architecture issues. Once those are complete all the uGFX drivers will need to be ported. At that point we will probably ask the community to help us just because of the number of drivers that need changing and testing.

One small factor... gfxInit needs to be called before ANY uGFX call including the gdisoFont calls.

For prototyping the stm32f746g-discovery board is fantastic. If you want a larger and higher resolution display for your end product then using a controller like the ra8875 is a good idea. The reason is that for high resolutions bandwidth to the ram over the ltdc interface can become an issue. A seperate controller with its own framebuffer ram obviously takes care of that for you resulting in a significantly reduced load on the CPU busses. This comes however with a slight decrease in the speed of drawing, or a large decrease if the controller is not interfaced properly to the CPU. All in all starting on a stm33f746g-discovery is the simplest solution. An external display using a ra8875 can even be attached later.

Adding more acceleration functions will typically not help you much - or at all. uGFX is very good at drawing efficiently with only the simplest acceleration and the ra8875 driver already has those functions implemented. Implementing others is a waste of time except in the most unusual circumstances and even then it needs to be weighed against the increased code complexity. Also, in many cases the display acceleration function is actually slower than the CPU doing the work.

You need to turn in touch calibration rather than trying to work with driver based auto-calibration. In this case your touch panel is not oriented correctly relative to your display for that to work.

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.

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.