inmarket

Great. Thanks for the clarification @Joel Bodenmann

Deinitialisation is not well supported in ugfx because typically in an embedded environment you never do deinit and the deinit code takes up precious rom space. Yes it should be possible to put a deinit routine there and then get the driver to deinit using the gdriver destroy api call. Afterwards though it may be very difficult to reinitialise it properly. A much better solution is to properly implement the bus arbitration calls in your board files for the touch driver and the audio driver. That is what they are designed for, for when two peripherals share a common bus.

The compiler should have been autodetected. The cpu needs to be manually set but not the compiler. Can you please try not defining the compiler, setting GFX_SHOW_COMPILER (I think that is what it is, see gfxconf.example) and then tell us what compiler it reports when you compile. If you can also give us the details and version number of your compiler we will try and fix it so it detects your compiler correctly.

With regard to the nontouch values, when the surface is not being touched the values are often indeterminate or random depending on the controller hardware. This is of no significance however as the surface is not actually being touched. Many controllers however also return random or bad values while the sirface is still touched but in the process of the touch lifting. This is much more serioys and the mouse driver has special code to overcome these sorts of problems. Another common problem is that controllers that use an external pin to indicate a touch status often have bugs where they in some conditions simply refuse to deassert the pin requiring a full power down to fix. For that and other similar problems we by default never use the status on those pins. Besides, our z value handling code is much more reliable than the firmware un most touch controllers in determining a proper touched status.

2. The spelling of pixel as pixil is a private and historical joke. A pix-el is a picture (pix) element (el). A pixil is then an pix with an ill ie a broken pixel. Thus the spelling of the word pixel as pixil is both an easter egg (hidden treasure) and a comment on the pixels being broken (buggy) hence the joke. The private part refers to a funny incident way back in my early programming history (roughly 35 years ago) that has led me to consistently and intentionally mispell it in my code since then. Well done on finding it. We will probably leave the spelling as it is as it is internal code only, not something a user would normally play with and it always gives me a chuckle.

That message means that the version of the c library on your development machine is not available on your target machine. Make sure glibc v2.17 is available on your target machine or instead compile for the older version of c library available on your target. Unfortunately i can't give you more explicit instructions than that. There are plenty of linux forums where you can ask those questions, or maybe another user here can help.

As it is a raw32 platform please start with the threads demo as getting threading working with raw32 can be tricky as it is very subject to bugs in the c runtime library (and keil is one of those known to have a buggy c library). In your case I think the solution will be to correctly set the GFX_CPU configuration option. Using that option avoids the bug prone areas of the c library.

The GCC link optimizer is a great idea but unreliable. I tend to leave it on as it leads to smaller binaries but turn it off the moment i get any strange linking errors. Glad you found the problem.

We are glad to see you got other demos working. If you need help from us follow the requirements in the 2nd post in this thread.

I am away on business at the moment but when I get back I will pull out my board and sort out what is going on. Unfortunately that will not be until early next week.

This looks like a chibios version issue. Are you using chibios v2.x. If using chibios v16 or v3 please update you makefile to match.

Start with the gdisp/basics demo as this enables us to test the hardware with the least amount of "fluff". Make sure that you have the M4 board not the M4-Plus board as that has different hardware on it. Also the M4 board itself comes in 2 versions, one with the ILI9341 and the other with a different display controller. Make sure you have the ILI9341 version. This is a board that I have myself so last time I tried this configuration was working well. If we can't identify the problem then I will fire up my board and retest however that won't happen until next week as I am currently away on business.

You will need to download the master repository version of uGFX. I don't know how current the zip download is. If you are on windows the program sourcetree is a very good free visual git tool. There should be no need to change the operating system as your compiler is a version of GCC and is therefore well supported for RAW32. What you probably will need to do is set that GFX_CPU setting appropriately.

If you are using GCC or the Keil/ARMCC compiler try setting one of the GFX_CPU options (the appropriate one of course).

The first of the new capabilities are now in the uGFX3 branch. Unfortunately it probably won't compile just yet. The new features: There is a new configuration option GFX_COMPAT_V2. This is turned on by default. It will enable compatibility with the uGFX V2.x API. Configuration options will now be set with GFXON and GFXOFF rather than TRUE/FALSE. TRUE/FALSE are maintained for compatibility when GFX_COMPAT_V2 is turned on. The bool_t data type has new value macros GTrue and GFalse. This, and the item above mean that TRUE and FALSE are no longer required by uGFX. They will only be defined if the operating system uGFX runs on defines them (or GFX_COMPAT_V2 is turned on). This prevents some type conflicts with strange side effects for some operating systems. Similarly the color definitions Red, Green, Blue, Black, White etc are being replaced by GFXRED, GFXGREEN, GFXBLUE, GFXWHITE etc. This prevents name conflicts with some platforms such as Win32 and the STM32 HAL where they are defined differently. The configuration option GFX_COMPAT_OLDCOLORS allows the old color definitions to still be used and is turned on by default. GFX_COMPAT_V2 is also required. Work has started on allowing drivers to be included purely by setting a configuration option rather than having to add it to the makefile. eg GDISP_DRIVER_WIN32 or GDISP_DRIVER_ILI9341. This is going to require a whole new driver API and lots of driver conversion. At the same time it is intended to clean up the drivers and board files to prevent symbol conflicts that currently stop drivers being part of the single file make system. Once complete this will also fix the compatibility issues between the single file make system and certain features such as pixmaps. That's all for now. We will let you know more as time goes by.

Run the threading demo program just to make sure that threading is working correctly. You may need to change the printf's in that demo to something that works on your debug platform or even just replace it with a led flash.

There is a good chance this is an issue with RAM bandwidth. Look with particular care at the FMSC timings for the RAM.

~ is not a valid path component. It is normally expanded by the shell to your user home directory. You need to replace the ~ with the path to your home directory eg /home/myusername. You also need to ensure that the root process has permission to get to the executable. Because of that you actually may want to copy the program to a directory such as /usr/local/bin and run it from there instead as part of your boot process. Also, don't forget to turn off X starting up in your boot process as that will prevent µGFX accessing the framebuffer. One last comment... As you are using the linux framebuffer you can safely remove the CFLAGS for sdl from your makefile.

Can you please include a diff or patch on this forum thread for future reference. We will then look at if it is something we should push back to the repository. Also can you please tell us what the compiler is being detected as. There is a macro something like GFX_COMPILER_SHOW that causes the detected compiler to be displayed as a warning during compilation.

For a while now we have been working on a new version of uGFX that includes many fundamental changes including changes that will affect compatibility with the uGFX API. This new work we have loosely labelled uGFX V3/4. As the changes are so significant we have decided to start to integrate some of these changes back into the current version of uGFX in a manner that disrupts as few existing applications as possible. This note is therefore to say that uGFX V2.8 will be the last official release of uGFX v2.x and it will be released at the same time uGFX v3.0 is released. The next major release uGFX v3.0 will retain the existing uGFX user API but the driver interface will be changing. The consequence of this are: If you are using a custom board file (not one of the standard ones we provide as part of the repository), you will need to rewrite your board file for the new driver architecture to use uGFX v3.x. If you have a custom driver for your display or touch device it will need to be rewritten to conform to the new driver API to use uGFX v3.x. Some new API's may appear in uGFX v3.x that seem to replicate existing uGFX functionality. These new API's will be part of the future API for uGFX and the old calls will eventually be deprecated (although not in uGFX v3.x). Note that during uGFX v3.x these new API's may change as the technology develops. It is therefore recommended that these new API's be considered for usage in new applications particularly where long term usage with future versions of uGFX is important. Where stability with a particular version of uGFX is important it is recommended to use the old APIs. To aid in the migration process for custom drivers and board files for common hardware, if you contribute that to uGFX before uGFX V3.0 is officially released we will attempt to port the driver/board file to the new format for you. We may ask you to test that for us as the official release of uGFX v3.0 comes closer. Once uGFX V3.0 is released we will provide no more support or porting for the uGFX V2.x drivers and board files except via paid support. A new uGFX3 branch has been created in the source repository. Prior to the uGFX v3.0 release and starting immediately the uGFX3 will be the main development branch. Only bug fixes and contributed v2.x drivers/board files will be ported back to the master branch to form the basis of uGFX v2.8. This will leave the master branch as the most stable version of uGFX. The new uGFX3 branch may be unstable and may not always compile prior to the uGFX v3.0 release. Once uGFX v3.0 and uGFX v2.8 is released the uGFX3 branch will be merged into the master branch. uGFX v2.x will then enter a period of where only critical bug fixes will be posted and only for a short period much the same way that other version releases are made in uGFX. There is currently no defined timeline for when uGFX v2.8 and uGFX v3.0 is released - just that the process has started. We will post additional information in this thread about the changes as we progress.

You are right. A 800x480 display will have coordinates from 0,0 to 799,479.

Please don't push on our good graces. uGFX is a product that we produce commercially and paid support is one of our main revenue for uGFX. Everyone needs to eat including us. We have made the source code available for free to the non-commercial world as part of our belief in contributing to others. We also provide free support on this community forum however our time is limited as we need to work to make a living and that always has to take priority. We are also working on lots of different parts of uGFX. One specific board on one specific operating system is not currently a priority. There are other combinations that work with that board and the problem with this combination appears to not be in our code. We have also already spent more time than we should on this problem. Rather than complaining that we are not spending our free time on it, how about being part of the solution. For example, debug it, solve it and contribute it back to the community; or, pay for paid support so we can afford to spend the time on it that you believe this problem deserves. Regardless, we will eventually get around to solving the problem. It is on our list of known problems. It will just not be anytime soon as it is marked as low priority.

There is no connection. The heap size of 10000 bytes or so is more than sufficient. If you want to be sure use the original threads demo and config file modified as little as possible eg only add your init sequence and code to make printf work. When you step into CXT_RESTORE (instruction step if you need to) you will either end up in gos_x_threads.c or gos_x_threads_???.c. If you end up in gos_x_threads.c then it is still using the c library implementation rather than the CPU specific implementation. In your case your c library appears to have bugs that are preventing it from working properly. Reasons that it might be using the c library instead of the cpu specific code... 1. The macro GFX_CPU is not set properly, or 2. The compiler you are using is not supported (currently only gcc and keil/armcc are supported for cpu specific code) When you know the answer to the above please let us know and we will see how we can help again.

No. The whole point of the demo is to ensure that multiple threads work. You will need to debug to find the exact point it crashes. Saying it stops in thread 1 is insufficient information.